fx2lib-devel

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

[-t <tg...@ya...>]

Message: 3
Date: Sat, 26 Feb 2011 16:35:36 +1030
From: "Daniel O'Connor" <doc...@gs...>
Subject: [Fx2lib-devel] Change sync delay macro
To: fx2lib developer mailing list <fx2...@li...>
Message-ID: <238...@gs...>
Content-Type: text/plain; charset="us-ascii"

Hi,
I modified SYNCDELAY to match the Cypress version - this is useful because GPIF 
designer generates code which calls it and it's a pain to re-edit the file each 
time you change your design.


--->  Hi Daniel, sync delay is used in more places that just GPIF 
implemenations.  Various registers are gated by different clock domains.  When 
the CPU writes to these specific registers the contents may not be updated 
if the sync delay is not executed.  The amount of delay is dependent on the two 
main clock domains.  All the details of sync delay can be reviewed in the 
Cypress TRM.  This one originally had me scratching my head for several days...  
Hope this helps :)  <---

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

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

On 02/03/2011, at 4:11, -t wrote:
> Hi,
> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>  
> --->  Hi Daniel, sync delay is used in more places that just GPIF implemenations.  Various registers are gated by different clock domains.  When the CPU writes to these specific registers the contents may not be updated if the sync delay is not executed.  The amount of delay is dependent on the two main clock domains.  All the details of sync delay can be reviewed in the Cypress TRM.  This one originally had me scratching my head for several days...  Hope this helps :)  <---

I understand that, however when you generate a file with GPIF designer it uses SYNCDELAY; vs fx2lib's SYNCDELAY();

My change alters the calling convention to match Cypress so you don't have to edit the generated file each time.

--
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

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

[Dennis M. <djm...@gm...>]

I never edited the gpif files.  I used the converter script (supplied by 
fx2lib).  Reason being fx2lib has it's own gpif functions that used the 
macro as SYNCDELAY().  You only need the byte arrays from the gpif.c 
file produced by the gpif designer, not the whole file, which like you 
say, was targeted for Keil.  I don't recall but there may be other 
things that didn't work correctly in the generated file.  You'll have to 
compare with the fx2lib gpif functions to double check.

On 03/02/2011 03:15 PM, Daniel O'Connor wrote:
>
> On 02/03/2011, at 4:11, -t wrote:
>> Hi,
>> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>>
>> --->   Hi Daniel, sync delay is used in more places that just GPIF implemenations.  Various registers are gated by different clock domains.  When the CPU writes to these specific registers the contents may not be updated if the sync delay is not executed.  The amount of delay is dependent on the two main clock domains.  All the details of sync delay can be reviewed in the Cypress TRM.  This one originally had me scratching my head for several days...  Hope this helps :)<---
>
> I understand that, however when you generate a file with GPIF designer it uses SYNCDELAY; vs fx2lib's SYNCDELAY();
>
> My change alters the calling convention to match Cypress so you don't have to edit the generated file each time.
>
> --
> 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
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev

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

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

On 03/03/2011, at 9:37, Dennis Muhlestein wrote:
> I never edited the gpif files.  I used the converter script (supplied by 
> fx2lib).  Reason being fx2lib has it's own gpif functions that used the 

Ahh, I forgot about that.

> macro as SYNCDELAY().  You only need the byte arrays from the gpif.c 
> file produced by the gpif designer, not the whole file, which like you 
> say, was targeted for Keil.  I don't recall but there may be other 
> things that didn't work correctly in the generated file.  You'll have to 
> compare with the fx2lib gpif functions to double check.

I have an unmodified file working, it wasn't too hard to get working, I have 2 shim files.

fx2.h ->
#include <fx2types.h>
#include <fx2macros.h>
#include <delay.h>

#define xdata __xdata

fx2sdly.h ->
/* IFCLK 48MHz, CPU clock 48MHz */
#define SYNCDELAY SYNCDELAY3

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 :-/

> 
> On 03/02/2011 03:15 PM, Daniel O'Connor wrote:
>> 
>> On 02/03/2011, at 4:11, -t wrote:
>>> Hi,
>>> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>>> 
>>> --->   Hi Daniel, sync delay is used in more places that just GPIF implemenations.  Various registers are gated by different clock domains.  When the CPU writes to these specific registers the contents may not be updated if the sync delay is not executed.  The amount of delay is dependent on the two main clock domains.  All the details of sync delay can be reviewed in the Cypress TRM.  This one originally had me scratching my head for several days...  Hope this helps :)<---
>> 
>> I understand that, however when you generate a file with GPIF designer it uses SYNCDELAY; vs fx2lib's SYNCDELAY();
>> 
>> My change alters the calling convention to match Cypress so you don't have to edit the generated file each time.
>> 
>> --
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Free Software Download: Index, Search&  Analyze Logs and other IT data in
>> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
>> generated by your applications, servers and devices whether physical, virtual
>> or in the cloud. Deliver compliance at lower cost and gain new business
>> insights. http://p.sf.net/sfu/splunk-dev2dev
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
> 

--
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

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

[Dennis M. <djm...@gm...>]

>
> 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.

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.)

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.

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.

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

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

[Dennis M. <djm...@gm...>]

On 03/03/2011 03:37 PM, Daniel O'Connor wrote:
>
>>
> You don't need to hold off manually, the GPIF handles full FIFOs on the FX2 automatically.
>
>

It was because our device had to also be able to pause.  We were 
streaming from a camera and the camera buffer wasn't always full.  So 
that was what I meant when I said it needed additional output states. 
We had the signal for the fifo ready AND the signal for the camera ready.