- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
According to the documentation ("Designing with the EZ-USB FX3 Slave FIFO Interface"), the propagation delay for the (watermark/ready) flags from the rising edge of the clock is max. 8 ns (tcflg) without specifying a minimum. So one has to assume it can be anywhere between 0 and 8 ns, right? But if correct that would mean that with a 100MHz GPIF-clock which has a period of 10 ns, one only has a 2 ns window to correctly sample the flag values. When eg. interfacing with a FPGA this means it's a "challenge" or it least not very easy to get the timing constraints right to make this reliably work.
Am I correct? And if so: what are the recommendations to do this the proper way?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arno,
If the typical values you are getting is 7.5 ns/6.5ns latency for your setup and application. The value may not go as low as 0ns.
Also 0ns cannot be assumed as the minimum value for the tcflg parameter
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Yes, you are correct. The trace lengths must be designed to meet the timing requirements.
Regarding the 2ns window, I will discuss internally and let you know in few days.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear AliAsgar,
Do you already have an update concerning the 2ns-window flag-issue?
kind regards,
Arno
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arno,
Worst case for the tcflg parameter is 8ns. Could you please let us know what is the value at your end?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear AliAsgar,
The typical values I'm seeing here (@100MHz clock) is ~7.5ns latency for the watermark-flag and ~6.5ns latency for the full-flag.
Let me know if you need more info.
kind regards,
Arno
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arno,
Please design the board so that flag values are properly sampled after the 2.5ns window.
This may be done by following the schematic and layout guidelines provided in AN70707 or by modifying your application in such a way so as to obey the setup and hold times properly.
We do not have any other recommendations.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear AliAsgar,
Ok, but does this indeed mean then that the minimum value for tcflg (which is not specified in the datasheet) is 0 ns?
kind regards,
Arno
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arno,
Could you let us know why is the minimum value for this parameter needed?
We just specify the worst case delay for the parameter.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Because we want to make sure that it's allowed to sample the flags up till the next(!) rising clock. This would mean that the min-value (which is not specified) is 0 ns (and the max value is 8 ns specified in the datasheet).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arno,
If the typical values you are getting is 7.5 ns/6.5ns latency for your setup and application. The value may not go as low as 0ns.
Also 0ns cannot be assumed as the minimum value for the tcflg parameter
Best Regards,
AliAsgar