How to reduce PAR time

Status
Not open for further replies.

verylsi

Full Member level 2
Joined
Mar 12, 2012
Messages
123
Helped
16
Reputation
32
Reaction score
16
Trophy points
1,308
Visit site
Activity points
2,130
Its taking more than one hour for ISE 9.2 ( Which I must use ) to synthesize, translate and generate Bit file.
Every time I make changes in the design for timing closure, I need to wait for 1 hour to see the result..
My PC is dula core and 4 gb ram, Do I need to upgrade PC or anything else can be done to reduce this time?

Thanks
 

Use the fastest machine possible. For anything more complex than a small design 1 hour is pretty typical.
As your question has no useful information about the design, can't give you any suggestions based on that.
 

Full compilation time increases with various factors: design complexity, targeted device (newer chips take longer as they have more resources to play with), PC horsepower, how full the chip is, timing specs, all have an effect on compile time.

So, whats the device? how full is it?

a 1 hour compile, with a newer device, on your fairly low spec machine, seems pretty good. I have seen designs in a top end stratix 4, that was about 70% full, take 3 hours on a 6 core Xeon with 48GB of ram.
 

I have seen designs in a top end stratix 4, that was about 70% full, take 3 hours on a 6 core Xeon with 48GB of ram.
been there done that on a not so huge Kintex6 part in ISE. Synthesis would take upwards of 2 hours to complete (xst is slow compared to quartus ii).
 

Thanks Tricky and Ads_ee

Yes my design is quite complex, device is spartan 3s 5000 and the utilization is 87%.
Cnt explain much about the design as there are way too many things about it.
But still I believe I got the answer, no need to hastily upgrade the PC as it wont reduce time more than 15 mins.

Thanks again
 

87% with the old tools and it's finishing in 1 hour you should feel very lucky!
 

87% with the old tools and it's finishing in 1 hour you should feel very lucky!

Indeed. XD

ISE pretty much generates multi-core utilization vacuum. Up to quad-core is benificial, but beyond that not so much. I noticed it's mainly memory bound. You can basically plonk in any old crap HDD and you will still have disk io to spare. Tested it with HDD, SDD and infiniband to super-awesomely-fast storage and synth runtime is essentially all the same.

You /do/ get benefit out of more than 4 cores if you are doing smartxplorer runs. But for regular synth runs with the old ISE tools you just grab the fastest quad core you can find with large L3 and high memory bandwidth. And if you only have to answer to yourself (as opposed to bosses & colleagues) you overclock the crap out of it. ;-)

Main benefits are to be had with memory bandwidth, so higher memory clocks at the expense of some extra latency ==> big win.

I think at this point in time an Ivy Bridge-E system with 1 dimm per bank + ballpark 4.5 - 4.8 GHz overclocks will get you best bang per buck. Or maybe even the plain IVB if you don't need 40 PCIe lanes. No wait, I remember. Short version: get the -E version.


But still I believe I got the answer, no need to hastily upgrade the PC as it wont reduce time more than 15 mins.

It depends on how old your current system is. ;-) Way back I upgraded from an old quad-core to a then modern quad-core, optimized it, and got about a x4 speedup. From one frigging hour to a doable 15 minutes for a full synth + PAR for the project at that time.

Incidentally, does anyone know how Vivado scales with multiple cores or multi-processor?
 

Incidentally, does anyone know how Vivado scales with multiple cores or multi-processor?
From what I can tell it doesn't. Two cores. Can't say for sure if that is still the case with the 2014.1 tool suite as I no longer have a 6 core Xeon system but only have a 2 core system at work. My 4 core home system never seems to use more than 2 cores. I think it's on the Vivado plan to use more cores (like most features/support)
 

As far as I know, if you want to change your design and go from the compile steps, there is no way for you to simplify the Xilinx flow.
However, if you only want to add some debugging probes, especially if you want to route an existing signal from the register(as it is easily identified in the netlist), FPGA Editor has a way to routing existing signals in PnR result to output FPGA pins.
I knew that back to 5 years ago, but I'm not sure if Xilinx changed the tool for any reasons or concerns.

Good luck.
 

I knew that back to 5 years ago, but I'm not sure if Xilinx changed the tool for any reasons or concerns.

Last time I checked (significantly less than 5 years ago) you could still do that in fpga editor. This was in ISE 14.something.
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…