Forward-Annotating constraints to Quartus

Hi,

I have a problem with Forward-Annotating multicycle, false path constraints from Synplify Pro 7.7.1 to Quartus 4.2 . I have given all the multicycle and false path constraints to Synplify Pro. It is being taken by Synplify and writing to design.tcl file also. The same design.tcl file i am using for porting constraints to Quartus. Whatis happening is in the netlist output given by Synplify, some of the multicycle/false path destination registers have become combo logic(i really don't know why?), and being ignored by Quartus. In fact, there are some valid multicycle registers, terminated by (or through) that combo logic. But the destination register, is not forward annotated by Synplify. Since Quartus sees only a combo logic, and not able to find the destination register(which is the actual multicyle path), its ignoring my assignments. This gives me a lot of timing violations also. There are more than 100s of such multicycle registers, so manually searching and changing to correct registers, is not an easy task, and bound to mistakes. Have anybody encountered these types of problems? Please help me solve this issue.

Thank you,

Reply to
Bala_k
Loading thread data ...

Hi,

I have a problem with Forward-Annotating multicycle, false path constraints from Synplify Pro 7.7.1 to Quartus 4.2 . I have given all the multicycle and false path constraints to Synplify Pro. It is being taken by Synplify and writing to design.tcl file also. The same design.tcl file i am using for porting constraints to Quartus. Whatis happening is in the netlist output given by Synplify, some of the multicycle/false path destination registers have become combo logic(i really don't know why?), and being ignored by Quartus. In fact, there are some valid multicycle registers, terminated by (or through) that combo logic. But the destination register, is not forward annotated by Synplify. Since Quartus sees only a combo logic, and not able to find the destination register(which is the actual multicyle path), its ignoring my assignments. This gives me a lot of timing violations also. There are more than 100s of such multicycle registers, so manually searching and changing to correct registers, is not an easy task, and bound to mistakes. Have anybody encountered these types of problems? Please help me solve this issue.

Thank you,

Reply to
Bala_k

Hi Bala,

It is hard to be sure without seeing your design, but it sounds like the multicycle assignments you're making are to combinational logic. I think your best bet would be to research exactly how Synplify names registers, to ensure you are putting the multicycle constaints on the correct names.

Quartus accepts multicycle assignments only on registers, so it will throw any multicycle assignments away if they're on combinational logic. If you can't figure out how to set the multicycles such that they wind up on the correct registers in Synplify, you can make the assignments in Quartus, but as you say that is a bunch of extra work if you also want to expose the assignments to Synplify, so it's not a perfect solution. Using timegroups, wildcards and entity-based assignments to make the timing assignments in Quartus may reduce the work to a managable level though.

Hope this helps,

Vaughn Altera [v b e t z (at) altera.com]

Reply to
Vaughn Betz

Hi Vaughn,

Thank you for the suggestion.

In Synplify, i am assigning multicycle constraint to registers only. But after mapping synplify adds a mux after register. This essentially blocks the regout to come out of LE. Only a combo out is going out of that LE. So synplify is porting the comboout name instead of the register's. I could find the register in Quartus Resource Property Editor view. But the problem is every rtl change can rename, the register name, and I have to repeat the same exercise every time.

I am now trying to use wild cards, and attributes like syn_keep, syn_preserve etc in Synplify to keep the names.

Vaughn Betz wrote:

the

think

registers, to

names.

throw

If you

the

Quartus, but

the

timegroups,

in

all

being

Whatis

logic(i

there

that

by

find

also.

and

problems?

Reply to
Bala_k

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.