Muli-Cycle Path Constrains in RTL

[luudee]

Hi All,

Is there a standard/common way to specify nets as multi cycle
path within the RTL ? In a way that it would be recognized by
as many synthesis tools as possible ?

Is there a standards document out there that addresses synthesis
specific statements with RTL ?

Thanks,
rudi

 

[Mike Treseler]

luudee wrote:

Hi All,

Is there a standard/common way to specify nets as multi cycle
path within the RTL ? In a way that it would be recognized by
as many synthesis tools as possible ?

No, that is a synthesis timing constraint.

I can eliminate the requirement in my
code by adding a synchronous handshake
or pipeline.

-- Mike Treseler

 

[Andy]

On May 20, 11:24 am, Mike Treseler <mtrese...@gmail.com> wrote:

No, that is a synthesis timing constraint.

I can eliminate the requirement in my
code by adding a synchronous handshake
or pipeline.

    -- Mike Treseler

Not sure I understand...

MCP constraints relax timing on long combinatorial paths that need not
complete in a single clock cycle (due to clock enables, etc). The only
way to avoid them is to speed up the paths, or break them up into
sequential sub-paths that will each complete in one clock cycle
(pipeline). Seems like a lot of hard work to keep the synthesis/P&R
tool from working harder/longer than it needs to (and probably
failing) in the first place.

The problem with MCP constraints is that it is very difficult to
verify that they are properly applied, except with extensive post-
route, full timing simulations. It is also easy to forget non-nominal
situations in which those paths may not actually be MCPs. Users often
fall into the trap of assuming that every input to every register that
is only clock enabled once every N clocks necessarily has an MCP of
N.

There are reportedly tools available (expensive) that will perform
formal analysis and either create accurate MCP constraints, or verify
existing ones without simulation.

If you know your MCP is correctly specified (you are relaxing
constraints on the exact signals/paths you thought you were), you can
use assertions in the RTL to verify them by ensuring that changes to
the value of specific signals do not occur except as expected by the
MCP constraint. If these assertions could be standardized (use
standardized functions, etc), then perhaps synthesis could make use of
them to create associated MCP constraints automatically.

I'm thinking of a function something like: is_stable(input_name, N,
clk_name, enable_name) returns boolean; (sorry this is in VHDL) that
would verify the MC behavior of the signal during RTL simulation.

Andy

 

[Mike Treseler]

On May 20, 11:24 am, Mike Treseler wrote:
I can eliminate the requirement in my
code by adding a synchronous handshake
or pipeline.

-- Mike Treseler

Andy wrote:

Not sure I understand...

It has been my experience, that if something
I have coded doesn't make Fmax, my time
is best spent questioning my assumptions
and revising the design.

Let's say I code a 64 bit "/" operation
(which uses lpm_divide for altera)
in one tick.

Even if I properly constrain
this blob of logic to 27 ticks,
I might very well find the
resulting netlist un-routable.
Maybe I can make better use
of all that time.

-- Mike Treseler

 

[Muzaffer Kal]

On Fri, 22 May 2009 10:58:52 -0700 (PDT), luudee
<rudolf.usselmann@gmail.com> wrote:

Guys,

All I want to know if there is a way to specify them inside my
RTL. For example there are other directives like
"// synthesis full_case".

I am just looking for a convenient way to include those directives
in to the RTL.

In all my readings of synthesis tool documentation I have not seen any
one of them supporting a pragma/directive like that. It's definitely
not in the Verilog RTL synthesis standard either (1364.1)

In my case the MCP is applied to data that travels from one
clock domain to another and is properly "latched" by synchronized
control logic. There are many good and bad uses for MCP ...

Another issue to be careful about MCP is how holds are handled. Some
STA tools move the holds in a dependent way to setup MCP (Primetime)
and some don't (Altera Timequest) and some are programmable (Magma).
To get the same effect, you have to add different hold MCPs to
different tools which make annotating the RTL extremely difficult.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[luudee]

Guys,

All I want to know if there is a way to specify them inside my
RTL. For example there are other directives like
"// synthesis full_case".

I am just looking for a convenient way to include those directives
in to the RTL.

In my case the MCP is applied to data that travels from one
clock domain to another and is properly "latched" by synchronized
control logic. There are many good and bad uses for MCP ...

Thanks,
rudi

 

[Mike Treseler]

luudee wrote:

I am just looking for a convenient way to include those directives
in to the RTL.

If convenient means not changing the design, then no.

In my case the MCP is applied to data that travels from one
clock domain to another and is properly "latched" by synchronized
control logic. There are many good and bad uses for MCP ...

Even the good ones can bite.

-- Mike Treseler

 

[Kim Enkovaara]

luudee wrote:

In my case the MCP is applied to data that travels from one
clock domain to another and is properly "latched" by synchronized
control logic. There are many good and bad uses for MCP ...

Isn't clock domain crossing usually specified as false path not
multicycle path.

--Kim

 

[Andy]

On May 25, 12:50 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:

luudee wrote:

In my case the MCP is applied to data that travels from one
clock domain to another and is properly "latched" by synchronized
control logic. There are many good and bad uses for MCP ...

Isn't clock domain crossing usually specified as false path not
multicycle path.

--Kim

Most static timing tools will not attempt to verify timing on paths
between two unrelated (i.e. asynchronous) clocks. No false path
constraint is required.

Andy