UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer newhunt163
Observer
3,069 Views
Registered: ‎02-26-2014

clocking schemes and Hardware Interface

Jump to solution

Hi Avrum:

         I have seen multiple posts form you with very detailed answers to questions that are related to my issue and yet I still have many questions between the timing constraints and Virtex-6 clocking resources related to the source synchronization interface.

   The FPGA is V6LXT240-T-1156. According to ug362--Virtex-6 FPGA Clocking Resources User GuidePage 10

QQ截图20170521231500.png

Page 63 is the clock summary

QQ截图20170521231558.png

         Of course, the timing parameter about different clocking schemes are <<DS152--Virtex-6 FPGA Data Sheet DC and Switching Characteristics>>.

 

   Now, questions are in the following lines

  1. Consider the Interface

QQ截图20170521231713.png

                                  Skew_bre=5nsskew_afe=6nsskew_bre=7nsskew_afe=8ns

clk is 25MHz The reason Why the skew is so big is data bus that has 16 pins. The skew is use to describe the case. Actual Condition may be not the same and not important.

         Because the interface is Edge source synchronization interface, and the clk and data pins on the FPGA are on the outer left coloumn (IOOL),the software is ISE 14.7.

         But because IOOL only has MRCC/SRCC and IOOL cannot drive MMCM and BUFG, so the clock schematics are impossibility GC+IBUFG or GC+IBUFG+MMCM, The only selection is BUFIO+BUFR, At the same time, I learn that: ISE can recognize the capture edge through the OFFSET IN constraints.

         (The figure comes from the forum question )

QQ截图20170521231909.png

much less than the skew. At the same time, the data pins are assigned to the IOB IDDR. Under the circumstances, Whether the capture edge is modified or not, the delay between BUFIO clk and data can't satify the skew constraint. Is that Right? What I should do?

 

2)If the data interface is SDR not DDR, and the skew is still big. The clk is still the BUFIO clk. Can I affirm that: the data regs are not impossibility assigned to IOB? Is the only scheme is that the data FFs in the fabric? However, If my discussion is right, is there a parameter about the max delay about data FFs relate the input clk in the FPGA? I have found the DS152, but nothing is found. Why?

 

3)Maybe you will ask me to use the CLOCK_DEDICATED_ROUTE = False. But In fact, what I want to know is that: the hardware scheme is incompatible with the clocking scheme, And the clk frequency is not always so low. The conditions Clk is 100MHz or 200M are common. And the three clocking schemes ( GC/MMCM/BUFIO ) are not always incompatible with the Hardware. What should I do? The answer is to modify the Hardware PCB?

 

4) The statistical static timing analysis request to find the Absolute path latency is in the range of clock scheme, but if there is none to be satisfied, what should I do? Modify the PCB?

 

5) Because the IOB reg is in the IOB. So can I understand the delay between IOB reg and pins is constant (if the path doesn’t contain IODealy)? If it is a constant, smaller than 1ns,2ns,or..??

 

6)ISE use OFFSET IN and Vivado uses set_input_delay, they can be modified the capture edge. However, for example, use the

QQ截图20170521232132.png

The capture edge is not the same as ISE default. So the all logic paths in the FPGA are recognized the same edge as offset in constraint? OR the logic paths in the FPGAs are still constrained the ISE default set?

 

7)Usually the clock duty is 45%~55%, Vivado gives a new constraint:

QQ截图20170521232253.png

Is there a solution in ISE 14.7 UCF? And duty is not 50% can be What effect? what I can know is the bigger Eye window,The effect may be the same as clk jitter. but how to calculate the duty effect? Can you give a Example to compare clk jitter and clk duty?

 

 

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
4,994 Views
Registered: ‎01-23-2009

Re: clocking schemes and Hardware Interface

Jump to solution

meaing the delay between GC+IBUFG and IFF.

    a)what's the meaing of "Full Dealy"?

    b)what's the meaning of "IFF"? It refer to Only the IOB Reg? or it can be IOB or FPGA fabir reg?

    c)if the "IFF" can be FPGA fabir reg, I guess the max delay between GC+IBUFG and any FPGA fabir reg is smaller than Tpsfd setup time. Is that right? so if I have a timing edge align SDR, if the skew is bigger than Tpsfd,is there impossibly to capture the data if only using the GC+IBUFG?

 

The Tpsfd/Tphfd is for the specific use case defined (somewhat cryptically) in the description.

 

When you bring a clock in on a clock capable pin and connect it directly to the BUFG, this is the "Global Clock without MMCM".

 

When the tools see this clock mechanism driving an IOB input flip-flop, which they refer to as an IFF here, the tools automatically enable a special delay (sometimes called the ZHOLD delay) in the IOB (this is what "Full Delay/Legacy Delay/Default Delay refers to in this table). This adds a delay element between the output of the IBUF and the input of the IOB flip-flop (or IDDR). This delay element has "similar" delay and PVT characteristics as the large clock insertion delay of this clocking scheme. If it didn't do this, inputs clocked this way would have a large positive hold time requirement, which is very hard to satisfy in a system synchronous system.

 

So, when you do this - clock capable input -> BUFG -> input IOB FF or IDDR

 

the pin to pin timing will be Tpsfd/Tphfd.

 

If you use a fabric flip-flop there is not guaranteed timing. The timing will be determined by the place and route run.

 

2) The second question is still about DDR duty. If clk duty is not 50%,maybe 40/60, if I want to capture data correctly, should I request a wider eye window? For example, the clk is 200MHz,DDR signal , skew=1ns, if the clk is 50%, the eye window is 5ns/2-skew=1.5ns, but if the  duty is 60%, the eye widnow shoud be 1.5ns+(60%-50%)*5ns=2ns? smaller than 2ns, it's impossibly capture data using statics timing analyse?

 

You need to account for the duty cycle somehow. There is no "good" way to do it (like in Vivado). You can try and play with the duty cycle at either extreme (either 40% or 60%) - in a system with symmetrical data valid windows this may be sufficient. But generally you leave the duty cycle at 50% and derate the data valid windows to account for the uncertainty of the falling edge of clock - shorten (move earlier) the trailing end of the first window by 10% of the clock period and shorten (move later) the leading edge of the second window by 10% of the clock period.

 

Avrum

0 Kudos
3 Replies
Highlighted
Historian
Historian
3,005 Views
Registered: ‎01-23-2009

Re: clocking schemes and Hardware Interface

Jump to solution

much less than the skew. At the same time, the data pins are assigned to the IOB IDDR. Under the circumstances, Whether the capture edge is modified or not, the delay between BUFIO clk and data can't satify the skew constraint. Is that Right? What I should do?

 

To this point, everything you have said above is correct.

 

You are correct that the position of your data valid window does not naturally line up with the setup/hold requirements of the ChipSync clocking style. This is precisely the point of

  a) The IDELAY module and

  b) the discussion of which edge is used for capture

 

You have the situation right now that your valid window and your required setup/hold don't overlap. So you need to change the timing relationship between them. This is done with the IDELAY; the IDELAY is a programmable Process/Voltage/Temperature compensated delay line that can can be set to add a fixed delay between the IBUF and the things connected to it. So you can

  1) Add it between the IBUF of the clock and the BUFIO/BUFR connections - this delays your capture edge with respect to the incoming data - hence you "push the clock into the data valid window".

  2) Add it between the IBUF of the data and the IDDR of the data. This delays the data so that the next clock edge can capture it - hence "push the data over the next clock edge".

 

You need to do one of these two - depending on which one you do, you will need to use the constraint format that is consistent with what you plan to do. It is generally better to do 1) since

  - the IDELAY on a clock adds no jitter, but the IDELAY on data adds pattern dependent jitter to the data (tIDELAYPAT_JIT) for each tap of delay used

  - If source generates the forwarded data and clock from the same internal clock source, then the data duty cycle and clock duty cycle are the same - using the "same edge" means you don't have as much of a penalty due to duty cycle

  - using one IDELAY instead of 16 (assuming a 16 bit data bus) uses less power

 

Unfortunately - this isn't going to be enough in your design. You have immense skews here, and the maximum delay that the IDELAY can add is 78ps*32taps, or 2.5ns - this is not enough to deal with your 5-8ns of clock/data skew. The ChipSync clocking is really intended for much faster interfaces - the problem here is that your interface is too slow...

 

2)If the data interface is SDR not DDR, and the skew is still big. The clk is still the BUFIO clk.

 

The same technique can be used regardless of whether the data is SDR or DDR. However, for SDR data you can always consider clocking the receiver on the falling edge of the forwarded clock (which is in the middle of the data eye).

 

In your case, if you can get the clock to be SDR, you can use the falling edge to clock this interface.

 

Can I affirm that: the data regs are not impossibility assigned to IOB? Is the only scheme is that the data FFs in the fabric?

 

I am not following your question here. When using a DDR signal, you must use the IDDR (or at least REALLY REALLY should use the IDDR). For SDR you have the choice of using a fabric flip-flop or the IOB flip-flop; for I/O interfaces, I always recommend using the IOB flop-flop.

 

However, If my discussion is right, is there a parameter about the max delay about data FFs relate the input clk in the FPGA? I have found the DS152, but nothing is found. Why?

 

If you are asking about the maximum delay from an I/O pin to a fabric flip-flop, there is no answer. The delay is based on how the fabric FF is placed and how the net is routed. The tools will attempt to place/route them based on the requirements of the input constraint - so if the constraints are correct (and doable) the tools should place/route the net in a way that meets timing. The tools might be able to insert enough delay on the data (pushing the data forward to the next clock) to get this to meet timing, but it also might not (you could try...)

 

3)Maybe you will ask me to use the CLOCK_DEDICATED_ROUTE = False. But In fact, what I want to know is that: the hardware scheme is incompatible with the clocking scheme, And the clk frequency is not always so low. The conditions Clk is 100MHz or 200M are common. And the three clocking schemes ( GC/MMCM/BUFIO ) are not always incompatible with the Hardware. What should I do? The answer is to modify the Hardware PCB?

 

 

This is not a trivial interface. Your clock period is slow (25MHz), which means that your period is 40ns, so 20ns per half period (assuming 50/50 duty cycle - we will come to this later). However, your skews are huge (and you probably made a typo when typing them because you have the same two parameters twice, rather than all 4 parameters). Assuming are=6 and bfe=7, this is 13ns of the 20ns period - this leaves only a 7ns valid window in pretty much the worst place possible...

 

If this were on a GC or IOCx clock capable pin, you could use the MMCM to fix your clock (using a 90 degree phase shift). But, as you have seen, you can't access the MMCM (directly) from the IOOx column. Using the CLOCK_DEDICATED_ROUTE=FALSE, you could access the MMCM from your current pin, but it will go through fabric routing to get there, and incur a large PVT variable delay that the MMCM cannot compensate. It is possible (but a bit doubtful) that the tool will still manage to find the 7ns valid window in spite of this large delay, but even if it works on a particular implementation run, it may come back to haunt you on a subsequent run. This is a move of desperation (but you don't have a lot of other choices).

 

4) The statistical static timing analysis request to find the Absolute path latency is in the range of clock scheme, but if there is none to be satisfied, what should I do? Modify the PCB?

 

Yes, Static Timing Analysis is (currently) telling you that it cannot capture this interface. Ideally, you should re-route your board to bring this clock to a pin that can get to the MMCM.

 

5) Because the IOB reg is in the IOB. So can I understand the delay between IOB reg and pins is constant (if the path doesn’t contain IODealy)? If it is a constant, smaller than 1ns,2ns,or..??

 

This is a somewhat meaningless question. It really doesn't matter what the delay between the pin and the IOB register is, it really only matters what the whole static timing path does - this includes the data path (possibly including the IDELAY) as well as the complete clock path. But, in answer to your question, the route between these two is "short" - definitely sub 1ns (probably only a couple tens of picoseconds). It is essentially negligible, particularly considering that the delay through the IBUF is significant...

 

6) The capture edge is not the same as ISE default. So the all logic paths in the FPGA are recognized the same edge as offset in constraint? OR the logic paths in the FPGAs are still constrained the ISE default set?

 

The OFFSET IN only affects the timing of the input interfaces (or even of the specific interface if you use a TIMEGRP in front of the OFFSET IN). The internal paths are always "default" timing, unless you change them with a FROM TO TIMESPEC.

 

7) Usually the clock duty is 45%~55%, Vivado gives a new constraint:

Is there a solution in ISE 14.7 UCF? And duty is not 50% can be What effect? what I can know is the bigger Eye window,The effect may be the same as clk jitter. but how to calculate the duty effect? Can you give a Example to compare clk jitter and clk duty?

 

You have limited ability to control the jitter and even less to control the duty cycle. Both are done in the PERIOD TIMESPEC.

 

TIMESPEC TS_clk_pin = PERIOD "clk_pin_p" 5 ns INPUT_JITTER 100 ps HIGH 50%;

 

The INPUT_JITTER is pretty clear.

 

The 50% at the end specifies the high time - in this case, it is 50%. You can change this, but you can only give it one value. So you can set it to 60%, in which case the tool will do timing assuming a perfect 60/40 clock. You cannot give it a range (like you can in Vivado)...

 

Avrum

0 Kudos
Observer newhunt163
Observer
2,965 Views
Registered: ‎02-26-2014

Re: clocking schemes and Hardware Interface

Jump to solution

Hi Avrum:

   Thanks for your response. But I still have two questions:

1) according to the DS152--Virtex-6 FPGA Data Sheet  DC and Switching Characteristics, there is a parameter calling Tpsfd/Tphfd,

QQ截图20170525224136.png

meaing the delay between GC+IBUFG and IFF.

    a)what's the meaing of "Full Dealy"?

    b)what's the meaning of "IFF"? It refer to Only the IOB Reg? or it can be IOB or FPGA fabir reg?

    c)if the "IFF" can be FPGA fabir reg, I guess the max delay between GC+IBUFG and any FPGA fabir reg is smaller than Tpsfd setup time. Is that right? so if I have a timing edge align SDR, if the skew is bigger than Tpsfd,is there impossibly to capture the data if only using the GC+IBUFG?

 

2) The second question is still about DDR duty. If clk duty is not 50%,maybe 40/60, if I want to capture data correctly, should I request a wider eye window? For example, the clk is 200MHz,DDR signal , skew=1ns, if the clk is 50%, the eye window is 5ns/2-skew=1.5ns, but if the  duty is 60%, the eye widnow shoud be 1.5ns+(60%-50%)*5ns=2ns? smaller than 2ns, it's impossibly capture data using statics timing analyse?

 

 

 

0 Kudos
Historian
Historian
4,995 Views
Registered: ‎01-23-2009

Re: clocking schemes and Hardware Interface

Jump to solution

meaing the delay between GC+IBUFG and IFF.

    a)what's the meaing of "Full Dealy"?

    b)what's the meaning of "IFF"? It refer to Only the IOB Reg? or it can be IOB or FPGA fabir reg?

    c)if the "IFF" can be FPGA fabir reg, I guess the max delay between GC+IBUFG and any FPGA fabir reg is smaller than Tpsfd setup time. Is that right? so if I have a timing edge align SDR, if the skew is bigger than Tpsfd,is there impossibly to capture the data if only using the GC+IBUFG?

 

The Tpsfd/Tphfd is for the specific use case defined (somewhat cryptically) in the description.

 

When you bring a clock in on a clock capable pin and connect it directly to the BUFG, this is the "Global Clock without MMCM".

 

When the tools see this clock mechanism driving an IOB input flip-flop, which they refer to as an IFF here, the tools automatically enable a special delay (sometimes called the ZHOLD delay) in the IOB (this is what "Full Delay/Legacy Delay/Default Delay refers to in this table). This adds a delay element between the output of the IBUF and the input of the IOB flip-flop (or IDDR). This delay element has "similar" delay and PVT characteristics as the large clock insertion delay of this clocking scheme. If it didn't do this, inputs clocked this way would have a large positive hold time requirement, which is very hard to satisfy in a system synchronous system.

 

So, when you do this - clock capable input -> BUFG -> input IOB FF or IDDR

 

the pin to pin timing will be Tpsfd/Tphfd.

 

If you use a fabric flip-flop there is not guaranteed timing. The timing will be determined by the place and route run.

 

2) The second question is still about DDR duty. If clk duty is not 50%,maybe 40/60, if I want to capture data correctly, should I request a wider eye window? For example, the clk is 200MHz,DDR signal , skew=1ns, if the clk is 50%, the eye window is 5ns/2-skew=1.5ns, but if the  duty is 60%, the eye widnow shoud be 1.5ns+(60%-50%)*5ns=2ns? smaller than 2ns, it's impossibly capture data using statics timing analyse?

 

You need to account for the duty cycle somehow. There is no "good" way to do it (like in Vivado). You can try and play with the duty cycle at either extreme (either 40% or 60%) - in a system with symmetrical data valid windows this may be sufficient. But generally you leave the duty cycle at 50% and derate the data valid windows to account for the uncertainty of the falling edge of clock - shorten (move earlier) the trailing end of the first window by 10% of the clock period and shorten (move later) the leading edge of the second window by 10% of the clock period.

 

Avrum

0 Kudos