Timing problems, and calculating max and min input delays...

Altera_Forum · ‎11-23-2010

Hi all...

Another day, another problem...

Before I start I should say that I am using the FTDI Morph-IC-II board, which has a Cyclone II EP2C5F256C8 FPGA and an FT2232H Usb bridge, Quartus II 10.0 sp1 web edition, TimeQuest timing analyser and Altera-ModelSim for my project.

I am currently trying to read in a 24 bit deserialised LVDS signal and pixel clock into my FPGA design. The 24 bit LVDS signal is made up of 18 bits of pixel RGB color data, a Hsync and a Vsync signal and 4 reserved channels.

This data is then multiplexed into an 8 bit wide fifo. When required the data is sent a byte at a time over an FT245 Synchronous interface to the TX buffer on the FTDI FT2232H chip. When the FT2232H chip recieves the request from the drivers it then sends the data to the application on my PC over USB...

My problem is that I am currently losing bytes of data and I am pretty sure this is due to timing problems with the inputs to my design.

Before using the actual streamed LVDS data from the module, I created a design that used the real pixel clock, Hsync and Vsync... but used a counter to provide dummy data instead of the 18 bit pixel data, and padded the 4 reserved bits will null values.

This design is fully compiled and time constrained and works, as within the application note for the FTDI 245 Synchronous interface it gave me the required setup and hold times required.

However, my actual LVDS data is being generated by a module and is being passed through the national semconductor DS90C124 Rx De-serializer Board:

http://www.national.com/appinfo/interface/files/national_serdes24-35usb.pdf

I also have a short ~10-15cm loom connecting the deserializer outputs to the inputs.

I don't know what my setup and hold times need to be to constrain these inputs, and am not sure how to work any of it out...

I can attempt a trial and error basis, but was hoping to put more thought behind it and to use a more intelligent way of determining these input delays....

Any help, insight or guidance is much appreciated... I have looked at Rysc's timequest guide, but I don't know where I can find the setup and hold times of "the external device" in order to calculate my max and min input delays the National Semiconductor documentation for the deserialiser board has no timing information, and the documentation I have about the LVDS only breifly discusses timing, but with resepect to the serialised LVDS datastream...

--- Quote Start ---

For input constraints, they look like so:

External device parameters:

Tco_ext = Tsu of external device

minTco_ext = Th of external device

Data delays on board:

Max_ext2fpga = Max board delay from external device to FPGA

min_ext2fpga = min board delay from external device to FPGA

Clock delays on board:21

Max_clk2fpga = Max delay from board clock to FPGA

min_clk2fpga = min board delay from clock to FPGA

Max_clk2ext = Max delay from board clock to external device

min_clk2ext = min board delay from clock to external device

set_input_delay -max = Tco_ext + Max_ext2fpg

set_input_delay -min = minTco_ext + min_ext2fpga

--- Quote End ---

As I said, any help or insight, is very appreciated. If you need anymore information then let me know!

Cheers,

Lee H

Altera_Forum · ‎11-23-2010

The receive clock comes along with the received data over the loom, so the length of the loom has no influence and you can apply the 'source-synchronous' constraint rules for SDR data with a centre aligned clock. Assuming that all signal lengths are reasonably equal we can forget about them. Else you have to add the largest positive difference in travel-time compared to the clock to the TcoMax and likewise add the largest negative difference in travel-time relative to the clock from the Tcomin (effectively making it smaller)

I opened up the DS90C124 datasheet on National's web-site.

On page 11 and pages 4 and 5, you can see that you get a minimal of 40% of Tcyc as both hold and setup times. You can either translate this in skew or in TcoMax and Tcomin values.

Translating it in to Tco: Tcomin is 40% of Tcyc ( = Troh) and TcoMax is then 60% of Tcyc ( = Tcyc - Tros)


# set frequency in MHz
set FreqRClk 25.0
#  calculate cycle time in ns
set Tcyc 
#  and create the clock
create_clock -name RClk -period $Tcyc RClk 
#  calculate the min and max delay
set Tcomin 
set TcoMax 
#  and apply
set_input_delay -clock RClk -max $TcoMax RxD
set_input_delay -clock RClk -min $Tcomin RxD

Altera_Forum · ‎11-24-2010

--- Quote Start ---

The receive clock comes along with the received data over the loom, so the length of the loom has no influence and you can apply the 'source-synchronous' constraint rules for SDR data with a centre aligned clock. Assuming that all signal lengths are reasonably equal we can forget about them. Else you have to add the largest positive difference in travel-time compared to the clock to the TcoMax and likewise add the largest negative difference in travel-time relative to the clock from the Tcomin (effectively making it smaller)

I opened up the DS90C124 datasheet on National's web-site.

On page 11 and pages 4 and 5, you can see that you get a minimal of 40% of Tcyc as both hold and setup times. You can either translate this in skew or in TcoMax and Tcomin values.

Translating it in to Tco: Tcomin is 40% of Tcyc ( = Troh) and TcoMax is then 60% of Tcyc ( = Tcyc - Tros)

# set frequency in MHz
set FreqRClk 25.0#  calculate cycle time in ns
set Tcyc #  and create the clock
create_clock -name RClk -period $Tcyc RClk #  calculate the min and max delay
set Tcomin 
set TcoMax #  and apply
set_input_delay -clock RClk -max $TcoMax RxD
set_input_delay -clock RClk -min $Tcomin RxD

--- Quote End ---

Hi josyb,

Thanks for all of your help. I am trying to make sure I understand how to calculate these things for future reference.

Using the system centric approach, the required information would normally be

Max and min data path delays
Max and min clock path delays
External device tCO (tCO_ext)
External device tCOmin (tCOmin_ext)

And the input delays can be calculated using:

Input delay max = <Max data delay> + tCO_ext - <min clk delay>

and

Input delay min = <Min data delay> + tCOmin_ext - <max clk delay>

These data and clock path delays from what you say I am assuming are all external to the FPGA, i.e. the delays in the external device and loom which connects to the input pins of the FPGA. And we are making the assumption that these are all equal? Which would give:

Input delay max = tCO_ext

and

Input delay min = tCOmin_ext

I can see from your code that to work out the tCO and tCO min you used

tCO_ext = tCLK - tROS

tCOmin_ext = tROH

but where does this come from?????

I then tried to look at the skew approach (FPGA centric) and I found the following equations:

Data Valid Window = UI - 2 * tSKEW

which for clock centred sampling would mean that

tSU_fpga = tH_fpga = 1/2 * Data Valid Window

and from that:

Input delay max = tCLK - tSU_fpga

Input delay min = tH_fpga

I was just slightly confused by this, as this seems to be a very similar equation to the tCO calculations except using the setup and hold times for the fpga rather than the external device.... I think I am just looking for some clarification/further understanding of how the tCO and tCOmin are calculated, and to confirm that we can definately ignore any other board/clock delays????

Cheers for any help on this... It's just one thing to be given an answer and another to understand why it is the answer!

Regards,

Lee H

Altera_Forum · ‎11-24-2010

Lee,

Hope a picture is worth that thousand words.

As the clock is produced by the device that also produces the data, you have a source synchronous set-up and you do not have to consider the actual size of the delays but only the differences between the delay of the clock signal and the other (data) signals. That leaves us

External device tCO (tCO_ext)
External device tCOmin (tCOmin_ext)
Largest positive difference of delays between clock and data (latest arrival)
Largest negative difference of delays between clock and data (earliest arrival)

Input delay max = tCO_ext + largest_positive_skew_data_to_clock

Input delay min = tCOmin_ext + largest_negative_skew_data_to_clock = tCOmin_ext - abs( largest_negative_skew_data_to_clock )

tCO_ext = Tcyc - Trosmin

tCOmin_ext = Trohmin

I feel more comfortable using this approach than the skew approach, and leave it to others to explain the skew approach.

Altera_Forum · ‎11-24-2010

Thank you very much once again...

I think I understand the skew approach, but the system approach does seem to be easier... I am pretty sure I understand it now, It was just getting my head around how tCO and tCOmin was the hard part, and that diagram really helped...

I have constrained my input timing as you suggested but seem to still be getting some timing issues somewhere, as my the logfiles seem to be missing some bytes.

I was clocking my data (ROUT0 to ROUT23) into input registers using the RCLK from the deserialiser board. The RCLK is put through a PLL to give me a clock (MULT_CLK) that is 4xRCLK but is synchronous with it. The 2nd, 3rd and 4th rising edges of MULT_CLK are used to load the 8 of the 24 bits of data into an 8bit wide DCFIFO, the 1st rising edge of mult clock is not used as this occurs at the same time as the rising edge of RCLK, which is when the data changes, and is not used to aviod any race conditions or reads before the next byte has arrived.

I am assuming that there are no timing problems with the other end of my FIFO as before connecting the deserialiser board I was using an 18bit counter, with the real RCLK, H_sync (ROUT18) and V_SYNC(ROUT19) and some null values for the 4 reserved bits. The logic and timing in that design works properly, with no lost bytes etc.

However when using the actual LVDS data rather than the counter I appear to be loosing some bytes, which makes me think I still have a timing problem somewhere still?

My SDC constraints are in the attached .txt document, as this post was over the character limit when I tried to paste it in!

Any ideas are very welcome as I can't see where I am losing these bytes!?

Regards,

Lee H

Altera_Forum · ‎11-24-2010

Lee,

I estimated that even without constraining the inputs the design wouldn't have any difficulty as a Tros and Troh of about 12 ns is very generous.

Could it be so simple that the switch-position on the deserialiser board that sets the active edge of the receive clock (RFB on S1) is wrong?

If all else fails would you send me a .qar of the project?

Altera_Forum · ‎11-24-2010

You were right I did have the RFB set wrong, as it was still on the falling edge default, but correcting that has not changed the fact that I am losing some bytes of data....grrr

how would I go about sending you the qar file... do PM messages allow attachments? sorry I am still relatively new to the forums!

Cheers

Altera_Forum · ‎11-24-2010

Lee,

just try sending a PM with attachment, if that fails I'll reply with a 'personal' e-mail address

Altera_Forum · ‎11-24-2010

I think I may have found the problem... and its with the logic in my design... which is typical! another noob error.... I will let you know whether correcting it fixes the problem... but I foolishly reset something which is active low to '0' rather than to '1'.......

Hopefully this will fix it....

Altera_Forum · ‎11-24-2010

YAY!...all is working now as expected....

I just had one extremely stupid error, which meant that that ROU0 to ROUT23 went to 0 when their input registers were reset, but H_Sync (ROUT18) and V_Sync (ROUT19) needed to be reset to 1 as if it was 0 it satisfied some other logic conditions when they shouldn't; which lead to reading the wrong things at the wrong times and loosing data bytes....

cheers for all your help. I am a very happy guy now, and my first real FPGA design works!

Regards,

Lee H

Altera_Forum · ‎11-25-2010

Great!

Good thing that you found the logic bug, I had simulated your design and could see nothing wrong with the input timing.

Regards,

Josy