01-12-2010 03:03 AM
I have no offset constraint, and this is part of the report auto generated:
| Setup to | Hold to | | Clock |
Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase |
data_port<0> | -2.726(F)| 3.467(F)|adtop1/_n0011 | 0.000|
data_port<10>| 1.518(F)| -0.777(F)|adtop1/_n0011 | 0.000|
data_port<11>| 1.095(F)| -0.354(F)|adtop1/_n0011 | 0.000|
data_port<12>| -0.726(F)| 1.467(F)|adtop1/_n0011 | 0.000|
data_port<13>| -3.121(F)| 3.862(F)|adtop1/_n0011 | 0.000|
What do "setup to clk" and "hold to clk" mean? And what is the negative values mean? Thanks very much!
01-14-2010 04:02 AM
I have read the article, and have done a test. "din" is a input data whose bus width is 32bit. I set a offset constraint :
Net "din<31>" offset = IN 2ns before clk_in. Period of clk_in was constrained to 6ns. And i got a result in P&R report:
Constraint Request Actual
din<31>offset... 2ns -3.17ns
All constraints are met.
According to my comprehension of the article, din<31> can lag 3.17ns mostly behind rising edge of clk_in on the PAD. And after data path delay and clk path delay, din<31> can be sampled at the FF correcttly and exactly. Am i right?
But if din<31> arrive 2ns before clk_in rising edge just as offset constraint said, after delay of data path and clk path, clk rising edge will present at nearly (2+3.17)ns with respect to din<31>, that is unstable period of din<31>...
How to explain this situation?
01-14-2010 05:29 AM
your undertanding of the article is right. I do not understand instead your latest statement. The OFFSET IN constraint defines the time that the data becomes valid prior to rising clock edge used to capture the data. You request 2 ns, the report shows -3,17 ns; so the constraint is met.
Please consider that a good design practice is to clock in the data with a d-type flip-flops (the FPGA input signals being directly connected to D inputs) before you use them in combinatorial logic; so the flip-flops will be mapped to IOB and the setup/hold requirements will be independent of the actual routing.
01-14-2010 07:30 AM
Thanks for your reply, Mariano!
Two questions more:
1. I tell OFFSET IN constraint to P&R tool, and then it place and route to make sure that the data can be captured stably on the first stage of FF by rising clk edge after data path delay and clock path delay. Is that right?
2. According to report, when the data lag behind 3.17ns on the PAD, after current P&R's routing delay of both data and clk, rising clk edge can exactly capture data on the first stage of FF(fulfill setup time requirement of the FF in the device data sheet exactly). So, in the same placement and routing, when the data come 2ns before rising clk edge (just as the constraint, and that is the true phase relationship between data and clk on the PAD in the real world), after the same delay of data path and clk path, the data will appear nearly (2+3.17)ns before rising clk edge on the first FF. That is unstable.
Thanks! And i really don't understand that all the time...
01-20-2010 06:43 PM
01-21-2010 05:05 AM
Thanks for your reply. And i wonder whether "setup to clk" is calculated in this way:
We set "setup time of FF"=Tsu, and delay of data path from IPAD to the first stage FF's D input = Tdata, dalay of clk path from IPAD to the first stage FF's clock input = Tclk. And "setup to clk" of this signal = Tdata+Tsu-Tclk. Is that right?
That is to say: if the phase relationship of data and clock at the IPAD is equal to "setup to clk", data can be clocking at the first stage of FFs exactly after data and clock delay from IPAD to the first stage of FF. Right?
03-26-2014 08:07 PM
Hi, I am a green hand about timing analysis.
I am confused of the setup time. I don't know how to understand the follwing eqution:
Setup Time = Data Path Delay + Synchronous Element Setup Time - Clock Path Skew
This is a eqution from Timing closure user guide.
I am looking forward your reply.