[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150930155558.GA17386@openwall.com>
Date: Wed, 30 Sep 2015 18:55:58 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: ztex 1.15y boards, pre-development
Katja,
On Mon, Sep 28, 2015 at 02:39:45PM +0300, Aleksey Cherepanov wrote:
> On Sun, Sep 27, 2015 at 10:41:21PM +0300, Aleksey Cherepanov wrote:
> > On Mon, Jul 27, 2015 at 03:03:34AM +0300, Aleksey Cherepanov wrote:
> > > I think, I got how to bypass it: read 5 times and skip results from
> > > first 4 times. Also there is a difference: with wrong data I got 32
> > > bytes back, while good data come in 34 bytes "packet".
> >
> > I found why there is additional word that causes 34 bytes instead of
> > 32: you check cnt >= 16 while you need cnt >= 15 because you already
> > read 16 words at cnt == 15.
>
> I played a bit and made a slightly different bitstream: it reads only
> once and writes back only once too. The code is in attach.
I made correct code to read, copy, write back.
Speed is about 50kb/s one way. Speed may be improved by factor 8
packing data together to fill whole usb packet. Maybe it is needed to
utilize internal buffer of usb controller fully to make it work
faster. PKTEND should be disabled then.
There are no more glitches in my test runs but the code was obtained
by small (random) modifications, so I am not sure that they align with
documentation and do not fail under other circumstances. Particularly
I did not test multi chip usage.
New code is attached.
> There are problems:
>
> - first time after power cycle it gives zeros, I use workaround: I
> upload bitstream twice, then it works correctly even for the first run
> of transfer_data
I guess that's because I thought that PKTEND is active-high, but it
turned out to be active-low (active when set to 0) by default. I guess
it might send packets with disconnected FD or with FD full of zeros,
hence zeros in the first run.
http://www.cypress.com/knowledge-base-article/function-pktend-pin
"By default, PKTEND pin is active-low; its polarity can be changed via
the FIFOPINPOLAR register"
> - I tried to make reads to return without data after the first one,
> but it is not stable: sometimes I get "got 0 bytes back" (desired),
> but sometimes it sticks with error "Error reading data: No error".
I guess "got 0 bytes back" occurs when PKTEND is active but FD is not
connected, or something like that. Now it always returns error, I
think that's ok.
> I think you messed up work with SLOE, SLRD, SLWR and PKTEND control
> signals. I found a document that describes them:
>
> http://www.cypress.com/file/4455144551
>
> "SLRD pin should be asserted by the master to read data from the FIFO."
> "SLWR pin should be asserted by the master to write data to the FIFO."
> "SLOE: This is the enable signal for the FIFO's output driver."
> "FIFOADR[1:0] These signals select the active endpoint."
A bit more:
http://www.cypress.com/knowledge-base-article/timing-specification-between-sloe-and-slrd-ez-usb-fx2
[...] tOEN (SLOE Turn-on to FIFO Data Valid) [...]
[...] tXFD (SLRD to FIFO Data Output Propagation Delay) [...]
I've got idea about stabilization of FIFOADR from the following code.
I like use of case statement to construct sequence of actions and make
delays.
http://svn.tapr.org/repos_sdr_hpsdr/trunk/AE6VK/EP2_LED/Verilog/EP2_LED.v
But I used your "flipper" with fr_or_sec too, because reading screwed
the first word without it. Writing works well without delays, I don't
know if it is correct and when it can break.
BTW there is a lib for easier fifo from designer of the boards:
http://opencores.org/project,ezusb_io
http://opencores.org/websvn,filedetails?repname=ezusb_io&path=%2Fezusb_io%2Ftrunk%2Fezusb_io.v
Thanks!
--
Regards,
Aleksey Cherepanov
View attachment "intraffic.v" of type "text/plain" (3974 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
