Timing Constraints

[sweet12prof]

Hello!

I hope this finds whoever reads well! Before anything i'd like to say i'm new to HDLs, the design flow and the tools as well. As a result, I lack in generally most areas so please bear with me if i sound too "naive" . 

To the question, I've been able to get my design through the RTL stage, and i'm able to simulate at the vhdl level and it works fine. Moreover, i've decided to move through the next stages of the design flow to implement the design on an FPGA. For the past 10 days, i've explored the IDE proceeding through the other steps of the design flow(sort of just "try-outs"), and read a number of guides that teach the next steps, even reading a number of posts from on here. 

However, I stumbled upon timing analysis and definning timing constraints. I easily understood why they were needed but after proceeding to use the wizard to define them, i find i have little knowledge on how to evaluate the constraints themselves. Atm, i'm stuck at generated clocks, i've read and watched a lot of material concerning the subject but none seems to say how they evaluated the transformations into divides/multiplies and most importantly how they got the factors. Most of the examples were ripple counters btw and it was pretty straightforward in knowing what the next factor was. My circuit is larger and not made up of ripple counters. Atm i'm to define factors for 116 generated clocks, i naively followed the same principles from the ripple counter but fail the analysis every time. 

As a result i'd like to ask for some enlightment on the subject! How exactly are the factors calculated? and btw in the video guides i watched, they seemed to be able to tell through inspection idk if i'm right but some pointers will really put my curiosity and frustration at ease. A reliable resource on the subject is welcomed too. 

Thanks for helping this self-taught newbie in advance!!! and sorry if my punctuations and grammar suck(english is not my native, deeply sorry). 

[ryanjohnson8]

Check out this answer record here: https://www.xilinx.com/support/answers/62488.html, specifically use case 1.

Vivado is able to automatically generate clocks on the output side of clock modifying blocks (MMCM, PLL and BUFR). So, for example, if you are running a 50MHz clock through a PLL that generates a 150MHz clock, Vivado is able to see how that PLL is configured, and create a generated clock on the output side of the PLL at frequency 150MHz. In the case where you are generating a clock from the output of a flop (which is almost completely universally condemned), you will have to understand your own RTL and create your own generated clock constraint for the net, because vivado does not recognize a register as a clock modifying block (CMB).

Also, I am curious--you say you are new to HDL and you're already creating 116 generated clocks in your design? Wow! How are you generating these clocks in HDL?

[avrumw]

It's a little hard to understand your issue... You are talking about "factors" in generated clocks - are you referring to the relationship between the base clock and the generated clock (the -divide_by/-multiply_by/-edges relationships)?

Static timing analysis is static it depends purely on the structure of the synthesized design, not the functionality of the design - the functionality is analyzed via simulation which is dynamic. So, for example, if you have a counter generating a "terminal count", the tools only understand this counter from a structural point of view - it is a bunch of static timing paths that start at clocked elements and end at clocked elements and go through some combinatorial logic. The static timing analyzer does not know (or care) that it is a counter and has no idea that it is generating (for an example) a terminal count every 12 clock cycles - to know that, it would have to do simulation (dynamic).

Since it doesn't understand that the counter is generating a terminal count every 12 clock cycles, then if this terminal count (extending our example) drives the CE of a BUFGCE, it has no way of knowing the behavior of the output of the BUFGCE. If the BUFGCE were enabled all the time then the clock output of the BUFGCE would be the same rate as the input clock. But if the CE is asserted only every 12th clock (the output of the terminal count) then the output of the BUFGCE would behave like a clock with a frequency of 1/12th that of the input clock (and a very imbalanced duty cycle). Since it doesn't dynamically analyze the counter, it can't tell which it is (so it assumes the most pessimistic, which is that the CE is always enabled, and the output clock is the same frequency as the input clock).

That's why it is our job to define the generated clock. In this case we (the designer who designed the 12 cycle down counter and connected it to the CE of a BUFCE) know that the output of the BUFGCE is a decimated clock with 1/12 the input frequency, and we need to explain this to the static timing analysis tool. This can be done with

create_generated_clock -source [get_pins my_BUFGCE/I] -edges {1 2 25} [get_pins my_BUFGCE/O]

(the -edges {1 2 25} describes a clock that rises on the first edge of the input clock, which is also a rising edge, falls on the 2nd edge, which is the falling edge, and then rises again on the 25th edge, which is 12 full clock periods after the first edge)

So the relationship (in this case the -edges {1 2 25}) is determined because we (the designer) know what the system is doing (dynamically).

All that being said...

WHY DO YOU NEED 116 DIFFERENT CLOCKS?!?

Clocks are "special" things in an FPGA - they are handled with dedicated inputs, dedicated blocks to manage them, and dedicated nets to distribute them. These are all finite resources (depending on the architecture there can be as few as 32 global clock nets available). If you are trying to design something that needs 116 clocks, you are almost certainly doing something wrong (or at least going about it in an incorrect way)...

Avrum

[sweet12prof]

I got my reply deleted and marked as spam(i edited). I took a screenshot of the reply and reattached the files in this reply

[drjohnsmith]

that spectacular, esspecialy for a beginner.

Looks like you only have one clock though,

would it be worthwhile getting used to the tools and constraints on a simpler design ?

[sweet12prof]

I'll do just that! Are there any designs you'd suggest to work on, to get used to the tools?

Also, does a single clock imply i shouldn't have as many generated clocks as i do now? 

[avrumw · Accepted solution]

Also, does a single clock imply i shouldn't have as many generated clocks as i do now?

Absolutely!

If you have a single clock, then you should have a single clock only - no generated clocks.

I can see (quickly) that you do have a large number of what the system thinks are generated clocks, as well as latches. These are almost certainly coding errors - from your block diagram and from the general concepts of synchronous design (which I presume your processor is supposed to use) there should be no generated clocks.

So, rather than focus on constraints (which are not the problem here), you need to focus on why your coding is creating these "clocks". In your coding style you should have only

• definition and instantiaton of modules
• sequenctial logic - these should all start with "always @(posedge clk) begin..."
  • There should be no "always @(posedge <something_else>)" where <something_else> is anything other than the top level clock (shown as "CLK" in your block diagram)
• combinatorial logic - these should either be assign statements (outside of begin or end) or "always @(*) begin" blocks
  • In these blocks if you assign a reg a value, it must be given a value in all branches of any conditional statement (if/case/etc...)

These are a very brief set of coding rules - if you stick to these you will get no generated clocks and no latches - and this is what you should be striving for.

Let's take a quick look at the list of generated clocks. The first one is pipe/pdatapath1/IDreg1/ID_RdE[4]_P/Q. This means that in the instance IDreg1, there is some code that says something like "always @(posedge ID_RdE)" or something like that (ID_RdE[4]_P is not the name of a flip-flop, so this is some combinatorial logic inside this module). This is a coding error. While it may functionally do what you want in simulation, this is not proper synchronous RTL design. RTL design (Register Transfer Logic) is a subset of HDL (Hardware Description Language - Verilog/SystemVerilog/VHDL); there are things that you can describe/define in HDL that are not synthesizable (hence are not RTL at all). Furthermore, within RTL, there are things that are not normal synchronous design practices (which are highly discouraged in an FPGA and even an ASIC).

You should probably read a good book on "coding using RTL" - unfortunately, I don't have a good recommendation (I'm sure others will suggest some).

Avrum

[drjohnsmith]

Which HDL do you use .

ASICs are great at multiple clocks, FPGAs have clocks on a special route structure, to get speed, have a much more restricted set of clocks ,

Latches, FPGA tools are VERY very bad at working with latches. they can but not a beginners sort of thing.

[sweet12prof]

Ah!! this gives me ease and happiness all at once. It's been 8 days! At least now i know why! SUPER THANKS.

After migrating to vivado, the IDE prompted me about certain coding errors which didn't show up while i used the older IDE. Also the resource i used in studying HDLs, seemed to mix VHDL standards(Its an old book) and even had some unsynthesisable code. I found ways to get around the problems to get my design to work. I'm 100% sure i violated a lot of rules(if not all) which resulted into the problem i have now. 

I'll  find a better resource to study the appopriate coding styles/principles.

Thanks for making my day. :)

[sweet12prof]

I use vhdl but not really sure what standard. My problem results from bad code. I'm pretty sure i have some latches too. 

Now that i do know tho, i'll look for a better resource on the coding principles and fix the problem. The replies i got from on here were super helpful and put me in the right direction. Thanks a lot. It was good learning a thing or 2 about ASICs too!! thanks :) 

[drjohnsmith]

Dont knock yourself

HDL langiages are very different to C type code, despite what most teachers seem to think

Always remember your describing hardware.

So if you dont know how the tools are going to make your design, then your code is liable to not help the tools make good chips.

before you go spending money on books,
this is a quiet good free book

http://freerangefactory.org/pdf/df344hdh4h8kjfh3500ft2/free_range_vhdl.pdf

VHDL is a very demanding language to start with, its designed to be strict , to encourage you to find as many problems before you get to synthesis time,

Also , always ALWAYS remember to simulate.
Do lots of simulation on every small bit of a design and build up in size by sticking bits together,

And as a touch stone, when you read other peoples code its bad code is :
a) if they use tabs,
b) if the don't use rising_edge()
c) if the include std_logic_arith

Good luck

[sweet12prof]

Thanks a lot for the book and the advice. I'll devote to learning it well and come out even better. Thanks a lot for your help and time!!!

[sweet12prof]

hello! 

i found the portion of the code where i had bad code. I decided to share my mistake just in case someone else (a naive beginner like me maybe, :) ) has a samilar problem in the future.

My problem resulted from the first 2 pipeline registers; they are configured  to have dual resets (synchronous for flushing after data hazards and asynchronous at the start/bootup of the design). In an attempt to describe the hardware, the bad code i wrote created the extra clocks! I'm curious tho, about how the bad code translates into the extra clocks.

Anyways, I've added 2 shots showing one of those registers, before and after i fixed it. Thanks a lot again. 

I'm left with figuring out  I/O delays, i'm betting its no error  to define delays on the I/Os ? It makes sense for the reset pin, however, a reason for the outputs will feed my curiosity. That is if my confident guess is even right. Thanks in advance.  

[drjohnsmith]

well found, and well done for getting back

Yep, only have one rising_edge statement per process is mandatory,

As you have seen, put the sync reset before the rising edge results in "interesting" code trying to be generated,

Whilst on resets,
Generally dont reset unless you need to ,
and especial dont a sync reset

Many discussions on the web about resets, in FPGAs they have a very minimal need.

[sweet12prof]

Oh okay! I'll note that.
The reset i'm supposed to specify a delay for, is the asynchronous one, that resets all the sequential elements in the design on device boot-up.
I read some discussions on resets after you talked about them, I have chosen to connect the resets from the design to the board's equivalent(I believe it's called the GSR port). However just to be extra sure I'm in the right direction, is this correct? and by doing it, there isn't any need to define a delay on the reset input as the wizard recommends is there?.

For my final question (I'm yet to read on output delays but i'd still like to ask), is the output delay constraints equivalent to calculating the delay of the critical path of the circuit.

Thanks a lot.

[drjohnsmith]

output delay, is just from the last register to the output pin on the FPGA. Note, it is a limit, the tool will pass if the delay is less than you specify, The tool can not add delay to make a constraint you set on the output match,

The timing constraint is what you need for register to register,
it is set by defining the timing of the clock into the fpga , this is the MOST important constraint on any design and MUST be present,

also ensure you use the MMCM / PLL in the FPGA,

As for asyncronous reset, why do you need it ?
if the FPGA is not powered, your input pin has no effect.

If your FPGA is powered, if your not configured, then your reset has no effect.

If your fpag is configured, then you have a clock, if you have an asynchronous reset, whats the practical difference between async and synchronous.

If you have asynchronous reset, then you have a meta-stability potential. Very not good, ... So you have to add an asynchronous to synchronous reset circuit,

These are no ASICs , they are FPGAs
IMHO : The only place for asyncronous resets is on SOME outputs , where you must not have signals till the FPAG is reset. BUT then the question is what are you doing with that pin before ad during configuration ?

You will find VERY VERY few cases for asynchronous resets.

Design not to use them unless you HAVE to and then double check.

[sweet12prof]

super sorry, i got marked as spam again.

Thanks for the info on output delays btw.

(rest of the reply in the screenshot)

[drjohnsmith]

FPGas ar configuration , set EVERY register to a defined value.

so in VHDL if you do

signal    fred : std_logic := '0';

Assuming your making fred into a register, then at configuraiton, register fred is set to 0.