MAXDELAY constraint

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

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

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

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 Enterpo> I have a 200 MHz clock gated by a BUFGMUX. =A0I added some unrelated logi=

c and

The

straint

ed

nt,

k.

gic and

=A0The

onstraint

nged

aint,

ork.

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 implem= entation 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 refere= nce.

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

Hope that helps,

Guy Eschemann FPGA Consultant Karlsruhe, Germany