XST takes unusually long

Hello All! We're working with a Xilinx Virtex II Pro board. As a part of our project, we had to write a hardware stack. After having made it work, we thought of optimizing the design and hence removed a few states and reduced the no. of states from 8 to 4. The older code was getting synthesized in around 20 mins, but the new code takes hours together to get synthesized, and so does the PAR. How can we reduce the synthesis time? Why is that the code which took lesser time to get synthesized is now taking longer?

-- DotNetters.

Reply to
dotnetters
Loading thread data ...

But it finally gets synthesized?

Break your design into smaller components, synthesize them alone. Try to locate the real source for that problem.

Ralf

Reply to
Ralf Hildebrandt

Ralf, First of all, thanks a lot.

yeah, it finall does get synthesized. But the time differnce is too large.

And how do I synthesize the components seperately and then finally "merger" them together? We work in XPS. Is it possible to do it in XPS itself directly?

Thanks once again.

-- DotNetters

Reply to
dotnetters

Sorry, I don't know XPS. But usually synthesis tools offer the following steps:

1) read HDL source & analyze (= syntax check) 2) elaborate / compile (= synthesis) 3) save the existing database 4) load saved databases plus read & analyze of the next upper component

This means after mapping the function to the primitives (compilation) and before place & route it is possible to save the result. This saved result can be read, when the next upper component needs these already synthesized components.

Another option would be to synthesize and place & route all subcomponents. Don't care the pin mappings (take a "random" mapping). Because you are not interested in the test if the subcomponent is working, you just need the synthesis to complete.

Ralf

Reply to
Ralf Hildebrandt

I'm going to assume here that by hardware stack, you mean a pushdown stack involving RAM and pointers and all that. I ran into a problem yesterday (with ROM, not RAM, but may be the same root cause). The ROM was inferred by VHDL code, not generated with Coregen. The description, although it was perfectly valid, was not one that XST recognized as being synthesizable into BlockRAM, and the RAM (ROM) was being put into distributed memory instead. This absolutely kills performance of both XST and PAR. What XST could not handle was the addition of a reset (init value) to the code description. Although the part (Spartan 3) has this functionality, XST can't handle it. So check your synthesis report, see whether your RAM is going into BRAM or distRAM.

Side note: I see that XST now does support inference of Dual(write)Port BRAMs as of 8.1i (I just loaded SP 3, out today). Kudos to Xilinx, keep it coming, please add the Set/Reset function to XST's BRAM inference repertoire soonest!

HTH, John

Reply to
JustJohn

One thing I've noticed with XST and state machines is that past a certain complexity, XST run time goes up exponentially when adding more states (quickly changing from minutes to hours)

Although since you describe only four states, that may not be your exact problem.

You might try turning off/changing the state machine inference and encoding settings.

What version XST? Any weird warnings? State machine tested in simulation for init/recovery on unexpected inputs?

See also Answer Records 20366, 22654, 22637, 21682

Brian

Reply to
Brian Davis

On a sunny day (25 Mar 2006 19:20:44 -0800) it happened "Brian Davis" wrote in :

ZE xsT programmmmers forGot to Comment oud ze lunch break in ze code.

Reply to
Jan Panteltje

dotnetters wrote

Try Synplicity. You may well get some insight from using another compiler - different warnings, unexpected resource usage, and so on.

Reply to
Tim

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.