MAXDELAY constraint

A

Andrew Holme

Guest
I have a 200 MHz clock gated by a BUFGMUX. I added some unrelated logic and
the routing of the gate control signal got longer and broke the FPGA. The
routing delay in earlier versions was ~ 1.8ns compared to ~ 2.5ns in the
broken version. So I added a MAXDELAY = 1.2ns constraint. The constraint
was not met; PAR only managed 1.748ns; but the FPGA worked. So I changed
the constraint to 1.8ns and re-ran PAR. It failed to meet the constraint,
this time reporting an actual net delay of 2.4ns and the FPGA did not work.
So I know the tools can manage 1.8ns; but I don't know how to make them!

Any suggestions?

TIA
 
On 08/23/2011 06:26 AM, Andrew Holme wrote:
I have a 200 MHz clock gated by a BUFGMUX. I added some unrelated logic and
the routing of the gate control signal got longer and broke the FPGA. The
routing delay in earlier versions was ~ 1.8ns compared to ~ 2.5ns in the
broken version. So I added a MAXDELAY = 1.2ns constraint. The constraint
was not met; PAR only managed 1.748ns; but the FPGA worked. So I changed
the constraint to 1.8ns and re-ran PAR. It failed to meet the constraint,
this time reporting an actual net delay of 2.4ns and the FPGA did not work.
So I know the tools can manage 1.8ns; but I don't know how to make them!

Any suggestions?

TIA
Click to expand...
With ISE you're working with a chaotic system. Small changes in the
input can lead to widely varying outputs.

If asking for 1.2ns yielded 1.748ns and asking for 1.8ns yielded 2.4ns,
then try a binary search between 1.2ns and 1.8ns on your constraint.
Hopefully something in that range will work!

Stephen Ecob
Silicon On Inspiration
Sydney Australia
www.sioi.com.au
 
Andrew Holme <ah@nospam.com> wrote:

I have a 200 MHz clock gated by a BUFGMUX. I added some unrelated logic and
the routing of the gate control signal got longer and broke the FPGA. The
routing delay in earlier versions was ~ 1.8ns compared to ~ 2.5ns in the
broken version. So I added a MAXDELAY = 1.2ns constraint. The constraint
was not met; PAR only managed 1.748ns; but the FPGA worked. So I changed
the constraint to 1.8ns and re-ran PAR. It failed to meet the constraint,
this time reporting an actual net delay of 2.4ns and the FPGA did not work.
So I know the tools can manage 1.8ns; but I don't know how to make them!
Click to expand...
Well, it seems that if you ask for 1.2ns it works.

The tools have to balance the constraints on all nets, including
ones that you specify indirectly. Reducing that one presumably
makes something else slower, but it seems not something that you
care (or know) about.

We like all or nothing (less than, or not less than, 1.9ns), but
minimization algorithms don't work that way.

Can you reduce the constraints on other nets?

-- glen
 
In article <j2umiv$eff$1@speranza.aioe.org>, Steve <theecobs@gmail.com> wrote:
On 08/23/2011 06:26 AM, Andrew Holme wrote:
I have a 200 MHz clock gated by a BUFGMUX. I added some unrelated logic and
the routing of the gate control signal got longer and broke the FPGA. The
routing delay in earlier versions was ~ 1.8ns compared to ~ 2.5ns in the
broken version. So I added a MAXDELAY = 1.2ns constraint. The constraint
was not met; PAR only managed 1.748ns; but the FPGA worked. So I changed
the constraint to 1.8ns and re-ran PAR. It failed to meet the constraint,
this time reporting an actual net delay of 2.4ns and the FPGA did not work.
So I know the tools can manage 1.8ns; but I don't know how to make them!

Any suggestions?

TIA

With ISE you're working with a chaotic system. Small changes in the
input can lead to widely varying outputs.

If asking for 1.2ns yielded 1.748ns and asking for 1.8ns yielded 2.4ns,
then try a binary search between 1.2ns and 1.8ns on your constraint.
Hopefully something in that range will work!
Click to expand...
Another option that we use - take that 1.748ns result, and grab the placements
from that PAR of the relevant logic (i.e. the BUFGMUX, perhaps the fanin logic
of the gate control). LOC down just those blocks in your UCF, and still use the
"realistic" 1.8ns constraint.

This has worked for us in the past. YMMV...

--Mark
 
Hi,

I don't have good experience with MAXDELAY constraint in my Virtex-5
and Virtex-6 designs and ISE 12.x and 13.x tools. Using LOC and
AREA_GROUP constraints produces much better results (timing closure
and build consistency).



Thanks,
Evgeni
http://outputlogic.com
 
I would suggest putting the critical elements of this part of design
into a seperate level of hierarchy either as instantiated elements or
HDL coding. If you turn hierarchy preservation on in synthesis this
will then make floorplanning, and LOCing, of the critical elements
much easier. It will also tend to give less variation in the synthesis
results as well.

You can also do this as a back end edit using FPGA Editor to achieve
extreme end results but this really should be a last resort as it is
very time consuming and has to done every time you rebuild unless you
can create a macro to automate it.

John Adair
Enterpoint Ltd. - Home of Raggedstone2. The Spartan-6 PCIe Development
Board.

On Aug 22, 9:26 pm, "Andrew Holme" <a...@nospam.com> wrote:
I have a 200 MHz clock gated by a BUFGMUX.  I added some unrelated logic and
the routing of the gate control signal got longer and broke the FPGA.  The
routing delay in earlier versions was ~ 1.8ns compared to ~ 2.5ns in the
broken version.  So I added a MAXDELAY = 1.2ns constraint.  The constraint
was not met; PAR only managed 1.748ns; but the FPGA worked.  So I changed
the constraint to 1.8ns and re-ran PAR.  It failed to meet the constraint,
this time reporting an actual net delay of 2.4ns and the FPGA did not work.
So I know the tools can manage 1.8ns; but I don't know how to make them!

Any suggestions?

TIA
Click to expand...
 
On Aug 23, 12:12 pm, John Adair <g...@enterpoint.co.uk> wrote:
I would suggest putting the critical elements of this part of design
into a seperate level of hierarchy either as instantiated elements or
HDL coding. If you turn hierarchy preservation on in synthesis this
will then make floorplanning, and LOCing, of the critical elements
much easier. It will also tend to give less variation in the synthesis
results as well.

You can also do this as a back end edit using FPGA Editor to achieve
extreme end results but this really should be a last resort as it is
very time consuming and has to done every time you rebuild unless you
can create a macro to automate it.

John Adair
Enterpoint Ltd. - Home of Raggedstone2. The Spartan-6 PCIe Development
Board.

On Aug 22, 9:26 pm, "Andrew Holme" <a...@nospam.com> wrote:







I have a 200 MHz clock gated by a BUFGMUX.  I added some unrelated logic and
the routing of the gate control signal got longer and broke the FPGA.  The
routing delay in earlier versions was ~ 1.8ns compared to ~ 2.5ns in the
broken version.  So I added a MAXDELAY = 1.2ns constraint.  The constraint
was not met; PAR only managed 1.748ns; but the FPGA worked.  So I changed
the constraint to 1.8ns and re-ran PAR.  It failed to meet the constraint,
this time reporting an actual net delay of 2.4ns and the FPGA did not work.
So I know the tools can manage 1.8ns; but I don't know how to make them!

Any suggestions?

TIA
Click to expand...
Additonally I think you can form an edif netlist of some route the
design meet the timing on it and use the routed netlist as the input
to make an incremental compilation. This way you preserve the routing
for the clock tree and place all the other modules rather
independently as compared to the critical section. I have not worked
with any designs in this manner, however I think this is quite
possible.
 
Andrew,

here are a few things that you could try:

- Look-up the placements of the BUGMUX and its driving element on an implementation run that meets timing and fix these placements for subsequent runs using LOC constraints in your UCF file. You can either use the FPGA editor or PlanAhead to look-up the placements.

- Try SmartGuide, using an implemented design that meets timing as a reference.

- Try using a different MAP/PAR cost table. Setup the SmartXPlorer to iterate through 15 or so cost tables, and compare the results.

Hope that helps,

Guy Eschemann
FPGA Consultant
Karlsruhe, Germany
http://www.ingenieurbuero-eschemann.de
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top