来自：https://forums.xilinx.com/xlnx/board/crawl_message?board.id=IMPBD&message.id=16979
最近在vivado约束向导中遇到同样的问题，看网友讨论的结果，有所收获，虽然不一定是最终答案，但是，可以帮我们梳理思路，距离真相更近一些。
收获一： tco_min与tco_max来自输入fpga芯片的datasheet。（我们需要从clock/data skew or data setup/hold times 转换出来。）
trce_dly_min/trce_dly_max 来自pcb板延迟。（此延迟很难提前预知。）
The whole idea of constraining an I/O interface is informing the tool the requirements of the system outside the FPGA; i.e. "other" device you are talking to and the board that connects them together. As a result the numbers for tco_min and tco_max come from the datasheet for this external device, and the trce_dly_min/max come from the board design.
In general, the trce_dly_min/max are often not known far in advance, but they tend to be relatively small and not all that different from eachother - in most cases a system designer can come up with reasonable guesstimates for these. But the tco_min/max must come from the other device.
Sometimes the datasheet for the device has numbers that translate more or less equivalently unto tco_min/max, whereas other times other timing numbers are given (like clock/data skew or data setup/hold times) which you (the FPGA designer) must translate to tco_min/max.
收获二：clock jetter 为正负5%
First (and in all cases) we need to define the clock
create_clock -name CAM_PCLK -period 25 [get_ports CAM_PCLK]
The fact that this is derived from an internal FPGA clock is probably irrelevant.
Now, you need to define the jitter and duty cycle of this clock - neither of which are given in your diagram. The jitter is set with
set_input_jitter CAM_PCLK <cycle_cycle_jitter>
The duty cycle is more complex - as we will see later, this is important (so I will come back to it later).
As with most interfaces there are several ways to specify this interface - I am going to use the "simplest" one; one that will work with the default edge relationships.
The data becomes valid 15ns before the rising edge of the clock. Since your clock is 25ns, this means that it is 10ns after the previous edge of the clock; this is the latest the data can become available, hence is the -max for this interface.
The data remains valid for 8ns after the rising edge of clock. This is the earliest it can change to something else, hence is the -min for this interface.
set_input_delay -clock CAM_PCLK 10 [get_ports CAM_DATA[*]]
set_input_delay -clock CAM_PCLK 8 -min [get_ports CAM_DATA[*]]
Note that neither of these have the -add_delay; the -add_delay is only used when adding a second min or a second max to an interface - in practical terms this is usually only used in DDR interfaces (this is SDR).
Furthermore, it there is no set of delays with -clock_fall; this interface is Single Data Rate (SDR) - it sends only one set of data per clock period, and (using my definition), I am relating them to the rising edge of the clock.
Now for the HREF.
For whatever reason, the device specifies the timing of this with respect to the falling edge of the clock. I will follow this. For this signal, the HREF can change anywhere between 0 and 5ns after the falling edge of the clock. This is easy to constrain
set_input_delay -clock CAM_PCLK 5 [get_ports CAM_HREF] -clock_fall
set_input_delay -clock CAM_PCLK 0 -min [get_ports CAM_HREF] -clock_fall
But here is the problem. Unless you specify otherwise the tool assumes CAM_PCLK has a 50/50 duty cycle. Since the HREF is specified with respect to the falling edge of the clock, but (presumably) you are going to capture it using the rising edge of the clock, the duty cycle become important.
Lets say the device specifies the duty cycle of CAM_PCLK as 45/55. This means the falling edge can come anywhere between 5% of a clock period early or 5% of a clock period late - thus +/-1.25ns. In Vivado we can specify this using the following commands
set_clock_latency -source -fall -min -1.25 [get_clocks CAM_PCLK]
set_clock_latency -source -fall -max 1.25 [get_clocks CAM_PCLK]
With this, the interfaces should both be completely specified.
原文如下：
How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-12-2017 12:59 PM
1. When going through the constraints wizard, in the input delays and also the output delays tab, what is a good starting point for the four timing settings (tco_min, tco_max, trce_dly_min, & trce_dly_max) that you have to fill out if you are given a clock period of 10ns? I watched the quick take video on it and estimated values based on the one or two examples given. There should be a general formula though for each of the four values. Who knows if the presenter in the video was entering in sensible values or not.
2. Once you have a the simple, general formula for 10ns, does that scale linearly as the clock period changes?
3. In that same wizard, on the same two pages, how do you know if you need to select "System" or "Source" in the Synchronous column?
4. Next, once those general input and output constraints have been set, how do you prioritize certain paths and conversely, add extra allowable slack to paths that are not as critical? For example, you may have one path that represents camera pixel data being clocked in, which would be very timing-critical, while another path may just be a button that lights up an LED. It should be possible to prioritize some paths vs others.
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-12-2017 01:55 PM
I think you are missing the point...
The whole idea of constraining an I/O interface is informing the tool the requirements of the system outside the FPGA; i.e. "other" device you are talking to and the board that connects them together. As a result the numbers for tco_min and tco_max come from the datasheet for this external device, and the trce_dly_min/max come from the board design.
In general, the trce_dly_min/max are often not known far in advance, but they tend to be relatively small and not all that different from eachother - in most cases a system designer can come up with reasonable guesstimates for these. But the tco_min/max must come from the other device.
Sometimes the datasheet for the device has numbers that translate more or less equivalently unto tco_min/max, whereas other times other timing numbers are given (like clock/data skew or data setup/hold times) which you (the FPGA designer) must translate to tco_min/max.
The same is true of System vs. Source Synchronous interfaces - they are different, and you need to constrain them appropriately.
Properly constraining I/O interfaces is not a trivial exercise. The constraints wizard tries to make it easier, but fundamentally, the designer really needs to understand (and design) the interface and constrain it correctly. And it is essential that it be correct - if not, you can get system failures...
And all this isn't just about creating the proper constraints. As part of designing an interface, you need to design the clocking structure for that interface. For high speed interfaces, using the wrong clock structure will result in not being able to meet the constraints...
As for prioritizing paths, you don't. You describe them (constrain them) accurately - the tool then attempts to find an implementation that meets all the constraints. You are right that something like a camera pixel interface would have constraints that could be tough to meet - if you constrain it properly, the tools will understand that. Conversely, an LED is an asynchronous output - by definition it actually has no requirements. Therefore you would either constrain it loosely, or, more accurately, declare the LED output as a false path.
Avrum
Message 2 of 10 (4,731 Views)
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-12-2017 03:03 PM
Ok. I have a much more specific question then to help clear this up. The system consists of a board camera, an Artix-7, and a TFT screen. I send a 20MHz clock signal to the camera and a 40MHz clock (CAM_PCLK), along with pixel data (CAM_DATA[*]), CAM_HREF, and CAM_VSYNC comes back. Looking at the timing diagram I know how to set up the entity. I already have the design working without issue but it always technically fails timing. How would I get the four values needed with the information provided in the image below?
CAM_PCLK is 40MHz. These are the constaints I currently have that relate to CAM_PCLK and CAM_DATA. If they aren't correct, what should they be?
set_input_delay -clock [get_clocks CAM_PCLK] -min -add_delay 4.000 [get_ports {CAM_DATA[*]}]
set_input_delay -clock [get_clocks CAM_PCLK] -max -add_delay 6.500 [get_ports {CAM_DATA[*]}]
set_input_delay -clock [get_clocks CAM_PCLK] -clock_fall -min -add_delay 4.000 [get_ports {CAM_DATA[*]}]
set_input_delay -clock [get_clocks CAM_PCLK] -clock_fall -max -add_delay 6.500 [get_ports {CAM_DATA[*]}]
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
[ Edited ]
01-14-2017 11:28 PM - edited 01-14-2017 11:33 PM
@david12341234 You need:
set_input_delay -clock [get_clocks CAM_PCLK] -min -15 [get_ports {CAM_DATA[*]}]
set_input_delay -clock [get_clocks CAM_PCLK] -max -add_delay 8 [get_ports {CAM_DATA[*]}]
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
Message 4 of 10 (4,628 Views)
0 Kudos
Participant
Posts: 56
Registered: 11-29-2015
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-15-2017 07:47 AM
Thanks for helping me with this! I would like to be able to come up with these timing constraints myself so I just have a few followup questions:
1. How did you come up with -15 and 8?
2. What about the pair of clock_fall timings? Do they stay as they are or get deleted?
3. Is the missing -add_delay in your answer for -min intentional? If so, why?
4. What else would these -15 and 8 values get applied to, anything where CAM_PCLK is the source?
Message 5 of 10 (4,611 Views)
0 Kudos
Historian
Posts: 4,340
Registered: 01-23-2009
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-16-2017 12:27 PM
I don't believe your timing numbers are correct - as written they say the data will change somewhere between the min and max, which means between 15ns before the rising clock and 8ns after the rising edge of clock - this is the opposite of the timing numbers from the data sheet which show this to be the valid (not invalid) time.
First (and in all cases) we need to define the clock
create_clock -name CAM_PCLK -period 25 [get_ports CAM_PCLK]
The fact that this is derived from an internal FPGA clock is probably irrelevant.
Now, you need to define the jitter and duty cycle of this clock - neither of which are given in your diagram. The jitter is set with
set_input_jitter CAM_PCLK <cycle_cycle_jitter>
The duty cycle is more complex - as we will see later, this is important (so I will come back to it later).
The timing for the data and HREF are different - lets do the data first.
As with most interfaces there are several ways to specify this interface - I am going to use the "simplest" one; one that will work with the default edge relationships.
The data becomes valid 15ns before the rising edge of the clock. Since your clock is 25ns, this means that it is 10ns after the previous edge of the clock; this is the latest the data can become available, hence is the -max for this interface.
The data remains valid for 8ns after the rising edge of clock. This is the earliest it can change to something else, hence is the -min for this interface.
set_input_delay -clock CAM_PCLK 10 [get_ports CAM_DATA[*]]
set_input_delay -clock CAM_PCLK 8 -min [get_ports CAM_DATA[*]]
Note that neither of these have the -add_delay; the -add_delay is only used when adding a second min or a second max to an interface - in practical terms this is usually only used in DDR interfaces (this is SDR).
Furthermore, it there is no set of delays with -clock_fall; this interface is Single Data Rate (SDR) - it sends only one set of data per clock period, and (using my definition), I am relating them to the rising edge of the clock.
Now for the HREF.
For whatever reason, the device specifies the timing of this with respect to the falling edge of the clock. I will follow this. For this signal, the HREF can change anywhere between 0 and 5ns after the falling edge of the clock. This is easy to constrain
set_input_delay -clock CAM_PCLK 5 [get_ports CAM_HREF] -clock_fall
set_input_delay -clock CAM_PCLK 0 -min [get_ports CAM_HREF] -clock_fall
But here is the problem. Unless you specify otherwise the tool assumes CAM_PCLK has a 50/50 duty cycle. Since the HREF is specified with respect to the falling edge of the clock, but (presumably) you are going to capture it using the rising edge of the clock, the duty cycle become important.
Lets say the device specifies the duty cycle of CAM_PCLK as 45/55. This means the falling edge can come anywhere between 5% of a clock period early or 5% of a clock period late - thus +/-1.25ns. In Vivado we can specify this using the following commands
set_clock_latency -source -fall -min -1.25 [get_clocks CAM_PCLK]
set_clock_latency -source -fall -max 1.25 [get_clocks CAM_PCLK]
With this, the interfaces should both be completely specified.
Avrum
Message 6 of 10 (4,582 Views)
0 Kudos
Historian
Posts: 4,340
Registered: 01-23-2009
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-16-2017 12:43 PM
Wait...
There is something odd about this timing diagram...
The last parameter tPDV specifies that data becomes valid at most 5ns after the falling edge of clock. This is (pretty grossly) inconsistent with the tSU parameter, which says it is valid 15ns before the rising edge of the clock.
If CAM_PCLK is 40MHz (thus 25ns), then 1/2 period is (at best) 12.5ns. If the data is valid 5ns after PCLK fall then it would only be valid 7.5ns before PCLK rise; this is inconsistent with tSU which says it is valid 15ns before PCLK rise...
Avrum
Message 7 of 10 (4,579 Views)
0 Kudos
Participant
Posts: 56
Registered: 11-29-2015
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-16-2017 04:32 PM
Yes, the diagram is confusing in that sense. DATA is either valid 5ns or 15ns after the low clock edge...
I check the DATA, HREF and VSYNC signals on the falling edge of a process driven by PCLK (40MHz). If the question you are asking yourself when adding timing constraints is, "How many ns pass after the active edge of the clock before the data is first valid and how many ns pass until the data is no longer valid?" then the constraints I came up with to answer that question are these:
set_input_delay -clock [get_clocks CAM_PCLK] -clock_fall -min 15 [get_ports {CAM_DATA[*]}]
set_input_delay -clock [get_clocks CAM_PCLK] -clock_fall -max 23 [get_ports {CAM_DATA[*]}]
set_input_delay -clock [get_clocks CAM_PCLK] -clock_fall -min 5 [get_ports CAM_HREF]
set_input_delay -clock [get_clocks CAM_PCLK] -clock_fall -max 25 [get_ports CAM_HREF]
From the time that PCLK is low, worse case is that 15ns pass for the setup time and (15+8)ns pass before the hold time is over. In other words, DATA should be valid 15ns to 23ns after the clock is low. For HREF, it doesn't seem like it matters since it stays high. As long as it is caught on the first negative clock edge that HREF is high, then I'm not worried about it. Do these timing setting make sense, or am I missing some key concept?
Message 8 of 10 (4,569 Views)
0 Kudos
Historian
Posts: 4,340
Registered: 01-23-2009
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-17-2017 11:44 AM
How many ns pass after the active edge of the clock before the data is first valid and how many ns pass until the data is no longer valid?"
No. They are "How many nanoseconds after a clock edge before a signal can start changing (i.e. what is the earliest) and how many nanoseconds after a clock edge before the signal finishes changing (i.e. what is the latest)."
The earliest (which defines the start of the invalid window) is the -min and the latest (which is the end of the invalid window as well as the start of the valid window) is the -max.
Assuming we use tSU and tHD (and ignore tPDV) then the constraints I gave you should be correct.
However, the tPDV thing bugs me - I presume this interface is unidirectional; i.e. always driven by the camera toward the FPGA (and never the other way around...)?
Avrum
Message 9 of 10 (4,534 Views)
0 Kudos
Participant
Posts: 56
Registered: 11-29-2015
Re: How to estimate a general starting point for input/ouput timing in the constraints wizard?
01-18-2017 08:01 AM
Yes, it is unidirectional. The DATA signal is pixel color data and always comes from the camera to the FPGA.
1416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
