Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Daniel O'C. <doc...@gs...>]

On 04/03/2011, at 2:57, Dennis Muhlestein wrote:
>> To be honest, after using the GPIF designer a few times I was sorely tempted to write a bunch of macros to generate the GPIF data words :-/
>> 
> 
> After using the gpif a bit, my impression was that everyone switched to 
> slave fifo :).  I suppose the gpif can be used for some specific cases, 
> but it had severe limitations if you tried to do anything but what it 
> was specifically designed for.

Hmm, it seems OK to me, I am using it to read data out of an async FIFO on a radar acquisition chassis in 16kbyte chunks.

> We even went as far as to try to get Cypress to help.  They had 
> engineers look at it for weeks, saying it was possible and about the 
> time I had learned everything the Cypress engineer knew we came to the 
> conclusion it wouldn't work.  (I felt like I was teaching the guy at the 
> time.)

Hah, that's a bit sad :)

> Anyway, basic use case:
> 
> Read data from your slave device, through the gpif, to the computer 
> right.  So far so good.  A signal state, a read state, transition though 
> idle, repeat for number of bytes to read.  Easy enough.
> Add requirements, read fast.. (Transfer data at max trans rate).
> So far so good, gpif can clock on rise and fall..  As long as you're 
> transferring less than one fifo buffer size you can make it work.
> Add requirement, hold data off in case of computer slowness or while 
> swapping fifo buffers (and do longer reads)  Doh, it's a no go.  You 
> need a state in the gpif with multiple output states.  Can't be done.

You don't need to hold off manually, the GPIF handles full FIFOs on the FX2 automatically.

My state machine is basically..

S0		S1
--		--
DRQ low		Read
Wait 3		Go to IDLE

And I load the transaction counter with the number of words I want to read out.

> The closest I ever got was to implement a state machine in firmware that 
> started and stopped the gpif for every fifo buffer. (512 or 1024 byte 
> reads).  It couldn't transfer data at 43MB/s though. (I think I got up 
> to 33MB/s or so if I recall).
> 
> To make matters worse, Cypress won't provide a verilog behavioral model 
> so that you can try to get a simulation working.  Debugging was a pain.
> 
> So, to make along story short: Slave fifo solved the issue.

My next version of the board I am using now may use slave FIFO, it certainly seems simpler. In my current version I am interfacing to a legacy system and I only have access to part full, and full flags so it's a bit annoying.

The new one should be synchronous and have access to empty so it should be much easier :)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C