08-21-2017 08:43 AM
I currently deal with a quite simple issue.
I just want to define a Timing constraint for the Inputs and the Output of a multiplexer. The multiplexer is controlled by a Register that is inside the FPGA.
Inputs are the FPGA Pads "P_A_in" and "P_B_in". Output is the pad "P_out"
I enter the following in my UCF file:
NET "P_A_IN" TNM_NET = TNM_P_A_IN;
NET "P_OUT" TNM_NET = TNM_P_OUT;
TIMESPEC "TS_DELAY" = from TNM_P_IN to TNM_P_OUT 6 ns DATAPATHONLY;
But when compiling the design I finnally get the following Timing Report:
TS_DELAY = MAXDELAY FROM TIMEGRP "TNM_P_IN" TO TIMEGRP "TNM_P_OUT" 6ns;
0 items analyzed, 0 Timing Errors detected.
Actually I don't know why my simple combinatorial path from Input Pad to Output Pad is not analyzed.
What did I do wrong?
How can I achieve this constraint?
Please help. Any comments are welcome. It's quite urgent ;-(
08-21-2017 09:11 AM
You must use the TNM, not the TNM_NET for creating the groups.
In your case, you want the group of pads, not the group of flip-flops that can be reached from the pads. The TNM_NET propagates through the IBUF to the clocked cells beyond it - the TNM stops at the pad.
08-21-2017 07:08 PM
Avrumw's answer is correct.
For testing purpose, you can verify the components of the group by enanle "-timegroups" in the properties of TRACE(Generate post-MAP Static Timing).
In your timing report, you can see the below content:
Table of Timegroups:
ODDR_inst dout_0 dout_1 dout_2 dout_3
dout<0> dout<1> dout<2> dout<3> clk_out
08-24-2017 03:03 AM
the first test worked really fine - now I got just only the cominatorial path from pad to pad that is contraint.
But for another path where I also just like to define the combinatorial path from Input pad to Output pad, ignoring any other pathes that have FF in, it didn't work. Do I need to but in any ignore path Statement? Or how can I any FFs in the path.
Attached you will find the xilinx Timing Report.
Actually I put there only a Timing contraints between Input pad (P_MOD_LVDS_B_CLK_IN) to an Output Pad (P_MOD_LVDS_A_CLK_OUT). And I whish only the combinatorial (no FFs) Timing from Input pad to Output pad should be contraint.
Thanks for further help ;-)
08-24-2017 08:44 AM
So I am not sure what you are trying to do here - you have a combinatorial path from the input clock to the output clock? If so, why? This is very unconventional...
However, if this is the case, and you also have the clock input clocking internal flip-flops, I am not sure that it is even possible to do what you are asking. The timing engine in ISE considers a path from a clock pin through a flip-flip to be combinatiorial, and I am not sure you can convince it otherwise except by placing TIGs on all the paths coming from flip-flops. While this is possible to do, it will basically leave all these clocked paths unconstrained, which is rarely a good thing in a synchronous design.
So what exactly are you trying to accomplish - why do you have a combinatorial clock path through your FPGA (in fact, why do you have any combinatorial path through your FPGA?)
08-25-2017 06:47 AM
thanks for your reply. Okay, that what I like to do is not really "Standard" but quite easy to describe. I have an Input pad, named "P_MOD_LVDS_B_Clk_in" that goes to an global buffer and a clock net. Additional that pad is connected via combinatorial logic to the Output pad, named "P_MOD_LVDS_A_Clk_out". Dont get confused with LVDS in the Name it's all single ended.
I like to set now a Timing constraint just for the combinatorial path from the Input pad to the Output pad. No clock nets should be taken into account. Only the Maximum delay time from this Input pad to exactly the Output pad should be get a Timing constraint.
So my main question is how can I get rid off the additional Timing check that is done and reported for a CLB-FF Output (in my case above it's Name is "IC_in0") to my Output pad? I didn't contraint that, and actually this delay time is not relevant.
08-25-2017 11:37 AM
Only the Maximum delay time from this Input pad to exactly the Output pad should be get a Timing constraint.
So, I don't think you can do this.
It is an oddity of ISE that it doesn't distinguish between the clock in -> clock out combinatorial path vs. the path through a flip-flop. The only way to get it to ignore the FF->clock out path would be to declare it false (with a TIG), but then the path will not be timed at all - in any context.
Furthermore, I still have no idea why you are doing what you are doing. What is the purpose of forwarding your clock through the FPGA? Clearly there is more to this path than just a clock in -> clock out (since there is also a FF -> clock out path), but this is still a very odd thing to do.
Timing check that is done and reported for a CLB-FF Output (in my case above it's Name is "IC_in0") to my Output pad? I didn't contraint that, and actually this delay time is not relevant.
I don't understand how this path can't be "relevant" - if this flip-flop can change value, then there must be some timing requirement on this path...
If the purpose of forwarding the clock through is to generate a "source synchronous" interface to a downstream device, this is not the way to forward the clock. When you want to send a clock and data out of the FPGA with a known relationship, you use the IOB flip-flops for sending the data out, and the ODDR for forwarding the clock to the output pad.
So, again, why are you forwarding your clock through your FPGA?
09-18-2017 07:15 AM
sorry for aswering so late - actually I was on vacation ;-)
But I can explain quite easily why I have this pure combinatorial path between on Input pad and an Output pad. This is due to an alternative usage of these pads in an specific Operation mode. I just like to switch between these two modes within the same FPGA-Design. When using the combinatorial path the Signal is having nothing to do with any clocking. This mode should just route the Input pad within a Maximum allowed delay to the Output pad.
Hope that helps to understand the Scenario.