Forum Discussion
23 Replies
- Altera_Forum
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
I meant that in my project mult has internal registers, which are clocked by fast_clk. OK, thank you, kaz.
- Altera_Forum
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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.