multicycle path - synplify pro

[alb]

Hi everyone,

I'm experiencing an issue with Synplify Pro E-2010.09A-1. I have to
insert some multicycle paths in order to be able to implement the design
(no option to break the paths with registers because the management has
decided to not modify the vhdl source at *any* cost...how wise!).

The constraints are:

set_multicycle_path 2 -from [get_cells execute0.fpu0.fpu_op_r*] \
-to [get_cells execute0.fpu0.REGISTER_o*]

set_multicycle_path 2 -from [get_cells execute0.fpu0.fpu_op_r*] \
-to [get_cells execute0.fpu0.result_o*]

Which are well expanded to the following exctract (I spared you with
some long list of unimportant objects):

Constraints with matching wildcard expressions
**********************************************

set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.REGISTER_o* }
@N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
execute0.fpu0.fpu_op_r_i[7]
[skip]
execute0.fpu0.fpu_op_r[0:7]
@N:|expression "execute0.fpu0.REGISTER_o*" applies to objects:
execute0.fpu0.REGISTER_o_192
[skip]
execute0.fpu0.REGISTER_o[58:0]
set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.result_o* }
@N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
execute0.fpu0.fpu_op_r_i[7]
[skip]
execute0.fpu0.fpu_op_r[0:7]
@N:|expression "execute0.fpu0.result_o*" applies to objects:
execute0.fpu0.result_o[31:0]

But when I run the synthesis I get the following timing report (worst
path information):

Path information for path number 1:
Requested Period: 25.000
- Setup time: 0.184
+ Clock delay at ending point: 0.000 (ideal)
= Required time: 24.816

- Propagation time: 41.571
- Clock delay at starting point: 0.000 (ideal)
= Slack (critical) : -16.755

Number of logic level(s): 72
Starting point: execute0.fpu0.alu_op_r[0] / q
Ending point: execute0.fpu0.REGISTER_o[58] / d
The start point is clocked by clk_i [rising] on pin clk
The end point is clocked by clk_i [rising] on pin clk

Now, why the 'requested period' is set to 25.000 ns it is a mistery to
me. The starting and ending points should be well identified as covered
by my multicycle constraint (at least from the constraint check report
above).

Nevertheless the synthesis tool tries to run it as if there were no
multicycle paths constraints... Any idea? Shall I file a bug report or
try with another tool (we have also Precision RTL available)?

Needless to say that I verified in the *.srr file that the constraint
file *is* taken into account:

[sorry for exceeding 80 chars!]

Reading constraint file: /home/debian/repos/9123_FOCS_ITA/branches/multicycle-study/mbfocs/target/rtax1000s352_1/synthesis/../synthesis/constraints.sdc
Adding property syn_multicycle_path1002, value "2.000000 delay from i:execute0.fpu0.fpu_op_r* to i:execute0.fpu0.REGISTER_o*" to view:mblite.core(arch)
Adding property syn_multicycle_path1003, value "2.000000 delay from i:execute0.fpu0.fpu_op_r* to i:execute0.fpu0.result_o*" to view:mblite.core(arch)

Thanks a lot,

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[alb]

Hi again,

alb <al.basili@gmail.com> wrote:
[]

Constraints with matching wildcard expressions
**********************************************

set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.REGISTER_o* }
@N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
execute0.fpu0.fpu_op_r_i[7]
[skip]
execute0.fpu0.fpu_op_r[0:7]
@N:|expression "execute0.fpu0.REGISTER_o*" applies to objects:
execute0.fpu0.REGISTER_o_192
[skip]
execute0.fpu0.REGISTER_o[58:0]
set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.result_o* }
@N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
execute0.fpu0.fpu_op_r_i[7]
[skip]
execute0.fpu0.fpu_op_r[0:7]
@N:|expression "execute0.fpu0.result_o*" applies to objects:
execute0.fpu0.result_o[31:0]

I just found that if I specify the constraint taking into account the
specific register reported by the worst case:

\
-to [get_cells execute0.fpu0.REGISTER_o\[58\]]

then it works. The problem is that I need to run the synthesis for each
multicycle path, while I'd like to provide all the paths concerning a
set of starting points and a set of ending points directly.

From the Design Constraints User Guide (Actel) it looks like I can
create indeed a list of starting points:

[­-through through_list] [-to to_list]

But I have failed to understand how a list can be described.
Any ideas or references I can look at?

Al

 

[alb]

Again it's me... to close this out!

alb <al.basili@gmail.com> wrote:
[]

The constraints are:

create_clock -period 25.0 [get_ports {clk_i}]

set_multicycle_path 2 -from [get_cells execute0.fpu0.fpu_op_r*] \
-to [get_cells execute0.fpu0.REGISTER_o*]

set_multicycle_path 2 -from [get_cells execute0.fpu0.fpu_op_r*] \
-to [get_cells execute0.fpu0.result_o*]

Path information for path number 1:
Requested Period: 25.000
- Setup time: 0.184
+ Clock delay at ending point: 0.000 (ideal)
= Required time: 24.816

- Propagation time: 41.571
- Clock delay at starting point: 0.000 (ideal)
= Slack (critical) : -16.755

Number of logic level(s): 72
Starting point: execute0.fpu0.alu_op_r[0] / q
Ending point: execute0.fpu0.REGISTER_o[58] / d
The start point is clocked by clk_i [rising] on pin clk
The end point is clocked by clk_i [rising] on pin clk

Now, why the 'requested period' is set to 25.000 ns it is a mistery to
me. The starting and ending points should be well identified as covered
by my multicycle constraint (at least from the constraint check report
above).

If I read more carefully the name I would have immediately found that:

execute0.fpu0.alu_op_r != execute0.fpu0.fpu_op_r
^^^ ^^^

Sorry for cluttering the group!