cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
4,768 Views
Registered: ‎08-21-2017

UCF: How to specify a async pad to pad delay?

Dear experts,

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 ;-(

 

0 Kudos
8 Replies
Highlighted
Guide
Guide
4,760 Views
Registered: ‎01-23-2009

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.

 

Avrum

Tags (2)
0 Kudos
Highlighted
Moderator
Moderator
4,716 Views
Registered: ‎11-04-2010

Hi, @plangka99,

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:
-------------------
TimeGroup reg_group:
Blocks
ODDR_inst dout_0 dout_1 dout_2 dout_3

TimeGroup pad_group:
Blocks
dout<0> dout<1> dout<2> dout<3> clk_out

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
4,687 Views
Registered: ‎08-21-2017

Thanks a lot for the really fast response.

I will try it immediately and give Feedback soon

 

 

0 Kudos
Highlighted
Visitor
Visitor
4,654 Views
Registered: ‎08-21-2017

Hello together,

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 ;-)

screenshot_timing.png
0 Kudos
Highlighted
Guide
Guide
4,636 Views
Registered: ‎01-23-2009

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?)

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
4,610 Views
Registered: ‎08-21-2017

Dear Avrum,

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.

 

Kind regards,

Peter.

0 Kudos
Highlighted
Guide
Guide
4,574 Views
Registered: ‎01-23-2009

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?

 

Avrum

 

0 Kudos
Highlighted
Visitor
Visitor
4,226 Views
Registered: ‎08-21-2017

Dear Avrum,

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.

greetings

peter

0 Kudos