Timing requirements to a part of a circuit

[Altera_Forum]

Does anybody know how to set timing requirements to a part of a circuit? I mean there is a critical part of a circuit that needs frequency optimization, and it's not rational to apply frequency constraint to all block. Thanks in advance.

[Altera_Forum]

Please could you clairfy? if your whole design is synchronous then you should just be able to set timing constraints to the clocks and it will do the work for you. Clock domain crossings need some consideration, but sometimes false paths are sufficient.

[Altera_Forum]

I think it's not a good strategy to optimize whole design in each case. For example, let it consists of several clock domains. One of these domains contains a part which must be optimized (a lot of logic between FFs). Of course we can set a constraint to a whole domain, but from my point of view this approach could lead to a non-optimal routing of other parts of the design. I mean that one part of the domain might operate exactly with clock frequency, while others might use enables and their actual operating frequencies could be much lower then clock frequency, that's why those parts don't need optimization.

[Altera_Forum]

You can define multi cycle paths to allow the fitter more flexibility if such things exists. You can also place logic lock regions to restrict specific parts of the design to specific regions of the chip. This often has the effect of prioritising these parts within the area, and any other non-logic-locked logic will fit in around the locked areas. This will help your timing by keeping an entity close together rather than spreading it apart. 

 You should only consider this though if you are having problems with normal timing (ie. specify the clocks and then compile). using logic lock regions becomes very trial and error and can consume a lot of time.

[Altera_Forum]

Thank you for your answer

[Altera_Forum]

In Altera's examples they set multicycle_path for enabled triggers and thus don't set timing requirements for them at all. However, sometimes this part of a project still needs timing requirements (maybe less strict). Is it possible set timing requirements for such piece of a project? 

Another problem that I've faced is difficulties in specifying triggers to set multicycling option to if they are "buried" into the project's hierarchy.

[Altera_Forum]

--- Quote Start ---  In Altera's examples they set multicycle_path for enabled triggers and thus don't set timing requirements for them at all. However, sometimes this part of a project still needs timing requirements (maybe less strict). Is it possible set timing requirements for such piece of a project? Another problem that I've faced is difficulties in specifying triggers to set multicycling option to if they are "buried" into the project's hierarchy.  --- Quote End ---    In those examples the multicycle constraint is a timing constraint on all registers enabled by the enable signal. Without them setup relationship defaults to one clock period and hold to zero, with them you relax it e.g. to 2 for setup, 1 for hold or 3 for setup, 2 for hold.  A convenient way to locate the nodes is to run TQ and then go to node finder and copy its path and name.

[Altera_Forum]

But I don't see these triggers with relaxed constraints into the report. Now I'm working with Clock Enable Multicycle Constraints project from TimeQuest TA cookbook and the only regs I see are regs from pipelined mult (they are not enabled). I can find them into name finder but I don't know how to add them to the report...

[Altera_Forum]

can you copy that Altera sdc example and design here or provide a link so I can better understand your viewpoint

[Altera_Forum]

Here you are

[Altera_Forum]

sorry I can't run projects now but a diagram and sdc will do.  

Anyway I looked at the TA cookbook/figure 1-16 clock enable multicycle on page 1-25 and all registers are enabled(those into mult and those at mult outputs).  In such cases you can apply sdc command for enable only and you don't need to worry about each single register.  Are you looking at same design?

[Altera_Forum]

kaz, I'm using old version of cookbook (https://vk.com/doc-93602802_401608943?hash=1d128a921cdd322f95&dl=bd60b7ecbf49a6ca84), so there is some difference in projects, in old version they use pipelined multiplier, clocked by fast_clk. So when I click summary setup I can get some information about multiplier's set of registers. Of course if we use mult without pipelining we won't get any setup information. Which command is intended for enable only? OK, I'll look for it in Altera's documents... 

What I expect is to get some information about enabled registers: are requirements met or not, slacks, etc... If it's possible, of course.

[Altera_Forum]

--- Quote Start ---  kaz, I'm using old version of cookbook (https://vk.com/doc-93602802_401608943?hash=1d128a921cdd322f95&dl=bd60b7ecbf49a6ca84), so there is some difference in projects, in old version they use pipelined multiplier, clocked by fast_clk. So when I click summary setup I can get some information about multiplier's set of registers. Of course if we use mult without pipelining we won't get any setup information. Which command is intended for enable only? OK, I'll look for it in Altera's documents... What I expect is to get some information about enabled registers: are requirements met or not, slacks, etc... If it's possible, of course.  --- Quote End ---    The two documents of cookbook have identical diagrams for enable multicycle example. The only difference is the figure number 1-16 & 1-18 sdc command for enable multicycle is given directly at bottom of page and has two parts multicycle and fanout.  If project timing passes then it means all paths are ok including those on enable. To specifically find out about any given path then just follow the usual approach either in TQ GUI or by direct commands.  I am not clear what do you mean by "without pipeline". There are registers on either side of mults, so these are valid timing paths.

[Altera_Forum]

I meant that in my project mult has internal registers, which are clocked by fast_clk. OK, thank you, kaz.

[Altera_Forum]

--- Quote Start ---  I meant that in my project mult has internal registers, which are clocked by fast_clk. OK, thank you, kaz.  --- Quote End ---    if you don't have enable on mults you can add it so that you use enable based sdc approach for multicycle. Otherwise it wouldn't do and you have to identify all paths in your multicycle sdc statements e.g all regs to mult and all regs from mult. Moreover you may have problem with sampling phase of result if you don't control that with enable.

[Altera_Forum]

set_max_delay -from [get_pins inst21[*]|q] -to [get_pins inst24[*]|d] 2.000  

inst21 and inst 24 are registers. If this command is correct? If so, in which cases it works (both regs are clocked by the same clock and enable or clocks and enables could be different)?  I tried it with different enables and common clk, and I got no error or warnings from TA, but from TA reports it's clear that requirement isn't met. At the same time TA doesn't indicate that requirement isn't met. If anybody is interested in such issue, my simple project is applied.

[Altera_Forum]

max delay applies an absolute timing relationship, in nanoseconds between two nodes. It is NOT related to the clocks. If these are 2 registers and you already have clock constraints, then this max delay constraint is already infered at the clock delay. putting a max delay constraint of 2ns is like having a clock constraint of 500Mhz, so you are probably over-constraining the design.  

 This is NOT how you apply multicycle constraints.

[Altera_Forum]

I didn't mean to use max delay with multicycle constraint. I just thought it's possible to restrict a bottleneck without specifing clk frequency and multicycle constraint. So, will it work without set_multicycling_path commands?

[Altera_Forum]

set max delay and multicycle path constraints are usually used to do different things. Max delay will make the fitter work harder, and multicycle path makes it easier for the fitter. They are not the same thing. 

 I still dont understand why you are doing this - if you are meeting constraints with just a clock constraint, why are you trying to overconstrain it? do you have problems with your design? The first method to fix re-occuring problems should be to fix the RTL code (add more pipelining) as this is the quickest and easiest fix.

[Altera_Forum]

I'm just trying different possible approaches. That was my mistake when I used set_multicycle_path and set_max_delay at the same time. Yes, you are right, multicycle relaxes constraints. I'm thinking that in some situations we can use set max delay just to constraint one or several data paths rather then using multicycle together with clock constraint

[Altera_Forum]

the main approach is just to set a clock constraint with any multi-cycle constraints you require. If there are problems, fix the RTL. 

If you then decide you cannot fiddle with the RTL any more, only then should you consider using logic lock regions. Only now when you have a few failing paths should you consider max_delay constraints. Going down this road is a lond and tedious one with lots of trial and error. Much easier to stick with clock constraints.