Synplify Problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am using Synplicity Synplify Premiere 8.8 and I ran into the problem that
it keeps retiming my designs such that a great deal of the logic is placed
before the input registers and/or after the output registers.  I was clued
into this when I went finish implementing the design in ISE and the timing
report listed a delay for the input to clock or clock to output (or both)
that was longer than the reported minimum period for the design.  While looking
at timing this close is new to me, I'm guessing the largest of these three
values is the fastest that I can clock my design at, barring any multicycle
or false paths.  Is there any way to constrain Synplify so it won't retime
logic outside of the designs main input and output registers?


---Matthew Hicks



Re: Synplify Problem
Quoted text here. Click to load it


Retiming is a synthesis switch.
You can turn it on or off.

But I'm not sure that this is
your problem as retiming will
not move any gates past the first/last flop.

Maybe what you need are some IO timing
constraints for ISE.

      -- Mike Treseler

Re: Synplify Problem
To see the problem, I did a simple one cycle divider.  To get the maximum
frequency for the divider I thought, "I'll just register the inputs and output
so the tools can have registers to calculate critical path times between.
 While synthesizing it, I kept pushing the requested frequency higher.  Well,
I got it up to 800MHz and thought, "not a chance in..."  I looked at the
technology schematic and all calculations were being done before the input
registers and after the output registers.  The critical path was a wire linking
the input register to the output register.  The minimum input delay before
clock was in the hundred nanoseconds range and so was the maximum output
delay after clock, but that critical path was sure short.


---Matthew Hicks


Quoted text here. Click to load it



Re: Synplify Problem
Quoted text here. Click to load it

Specify your input and output delay constraints.

While I prefer the "OFFSET IN BEFORE" and "OFFSET OUT AFTER" constraints
used by Xilinx, the Synplify constraints are the "OFFSET IN AFTER" and
"OFFSET OUT BEFORE" style constraints popularized by Synopsys which specify
the cycle time from the common clock in the external chip to your FPGA and
from the FPGA to the external chip, virtual-clock to virtual-clock.

I get around the problem by not using retiming.



Re: Synplify Problem
Thanks, I'll work on applying those constraints tomorrow.  For some reason,
I thought those constraints were for informational purposes and not something
I could use to handcuff the tools.

I viewed the informational (sales) items on retiming and they said it doesn't
affect the functionality of the design, so I figured a little extra otimazation
never hurt.  I just didn't think to look at the other timing parameters beside
Fmax.  Now I know.


---Matthew Hicks


Quoted text here. Click to load it



Re: Synplify Problem
Quoted text here. Click to load it

Retiming will not affect a purely synchronous design's behavior.

Do not allow retiming or replication on synchronization registers.
That can result in parallel or other improper synchronization
problems. Don't ask me how I know...

Retiming and replication can be disabled on any register (signal or
variable) with a constraint/attribute. I prefer to put such attributes
in the source code, since I don't always know up front whether I may
need to turn retiming on for the rest of the design.

Andy


Re: Synplify Problem
Thanks for the heads up, I will keep that in mind for when I go back to my
RA job where we will be dealing heavily with crossing clock domains.  As
we don't have Synplify in my reasearch group, I will refer to the Xilinx
ISE constraints guide for info on how to override the default retiming parameter
for specific registers.


---Matthew Hicks


Quoted text here. Click to load it



Re: Synplify Problem
As a follow-up, I found a document wp237, from Xilinx, that explains the
details of the offset in and offset out constraints fairly well.  In addition
to the aformentioned methods, I also found out that in Synplify, you can
specify that all IO registers be packed into the IOB (syn_useioff) which
won't allow retiming outside of the border registers.  This way I can let
the tool retime the internal stages and don't have to worry about my borders
being violated.


---Matthew Hicks


Quoted text here. Click to load it



Site Timeline