Timing costraints, how to write an sdc file

[Yaro]

Hi all,

I've found problems in my code with timings.

Two examples:


The fourth signal should go low before fifth signal and this cause errors on first and second signals that should go to low.



I have a huge timing delay in data changing when signal goes high. Would be good to reduce it.

I've never used timing costraints and I can't find any simple guide that tell me how to write an .sdc file like, for example, how to set mains clock costraints and how to write that "the fourth signal should go low before fifth signal". Since I need to solve just this problems please don't post me manuals with 200pages on timing costraints.

 

[ads-ee]

If you haven't used any timing constraints before then you've just been plain lucky that anything has worked prior to this.

First off READ the timing constraints guide for the FPGA vendor you are using. I know you don't want to be told that, but it is something you should do.

First off constrain the clock.

create_clock -period 10 -name my_clock -waveform {0.000 5.000} [get_pins my_clock_pin_name]

Beyond that the rest of your question needs code to understand what constraints apply to the situation. I'm not going to attempt guessing what the circuit looks like where your transfer goes wrong, but I suspect you've got some bad design practices going on in your design like some sort of gated clock and internally generated clock design.

 

[TrickyDicky]

This looks more like a design problem, not something you are going to fix with an sdc file.

And reading the manual is very important. We're not here to do your job for you.

 

[Yaro]

Since all blocks are driven by same clock GLA, when I use 50Mhz PLL I have this kind of error as you see above. When I try with 100Mhz, that is the frequency I should use, I have in addition this kind of error when I simulate compiled code:

** Warning: */IOPAD_TRI PULSE WIDTH High VIOLATION ON D;
#
# Expected := 5 ns; Observed := 4.959 ns; At : 68324.973 ns
# Time: 68324973 ps Iteration: 1 Instance: /testbench/Buff_0/\GLA_pad/U0/U0\

As you adviced I've added this:

"create_clock -name {GLA} -period 10.000000 -waveform {0.000000 5.000000} PLLClock_0/Core:GLA"

But I've also 8 warnings on inferred clocks, why this since I use one clock source? In particular one tells "Found inferred clock Counter|NU_5_inferred_clock which controls 148 sequential elements. This clock has no specified timing constraint which may adversely impact design performance."

Another warning I have that is related to the fourth signal is this "Latch generated from process for signal EN; possible missing assignment in an if or case statement."

This are warning I thinks are related to above timing delays.

I've a questions about this:

- This problems are solvible by timing constraints or by correcting code?
- Is possible to solve this problems by setting timing costraints without change code?

 

[ads-ee]

But I've also 8 warnings on inferred clocks, why this since I use one clock source? In particular one tells "Found inferred clock Counter|NU_5_inferred_clock which controls 148 sequential elements. This clock has no specified timing constraint which may adversely impact design performance."

Like I said in post #2 you are probably using gated clocks and/or clocks generated from counters. Both of these are a bad practice in FPGAs. You should use clock enables and multi-cycle constraints.

Another warning I have that is related to the fourth signal is this "Latch generated from process for signal EN; possible missing assignment in an if or case statement."

This means you didn't do a very good job of coding your combinational code, you probably left out assignments to some of the signals in part of your if-else branches, which requires a latch to implement the circuit.

- This problems are solvible by timing constraints or by correcting code?
- Is possible to solve this problems by setting timing costraints without change code?

GIGO, garbage (code) in, garbage (results) out.
You need to fix your code, otherwise all you are doing is trying to push a cooked noodle around (i.e. you'll be spending weeks adding timing constraints (max delay constraints) trying to fix each new place it breaks. Note increasing the number of timing constraints has direct impact on the run times for implementation of a design.