how can I decrease the time cost when synthesis and implement

2 hours isn't bad. I've got a design in house right now that has taken about 30 hours on the last two place and route runs, and that is with a lot of hand placement (it is a 400 MHz design in a Virtex4 SX55 in the

-10 speed grade and occupies about 70% of the FPGA resources to be fair though)

Synthesis pretty much is what it is. Place and route can be improved by starting with a placement that makes the routing phase easier. That means either doing floorplanning and manually placing the critical parts of the design, or using the guided place and route to leverage the floorplan from a previous place and route. You can also use the modular design tools to break the design into pieces, although I haven't tried that again recently (last time I did, it wasn't really quite working).

It will help tremendously if the timing constraints are not pushing the envelope for your design. Reduce the number of combinatorial levels of logic the signal goes through between flip-flops in order to reduce the propagation delay between flip-flops. Reducing the delay due to the logic elements increases the budget for routing delays, which in turn makes the router's job a lot easier.

I've long since found that more extensive simulation is many times much more productive in weeding out the bugs than trying to debug on actual hardware. I've found this to be true even when you have to create many of the models that surround the FPGA that emulate the board environment. If those models happen to be readily available then it goes that much quicker, but if not, it's not that bad.

When I'm 'developing' I run synthesis sort of in the background. I run it not to produce any file that should be used on the board but just as another set of eyes to catch bugs. An example might be if suddenly I've dropped from 80% utilization down to 70% even though I didn't think I had made any changes to knock out anything like that. The reason for the drop might be because I've misconnected something that now causes the synthesis optomization to reduce out a whole section of logic. Granted I'll find that in simulation as well, but like I said the synthesis runs are meant to be a separate set of eyes looking at the code.

Bottom line is, the best way I've found to break the long synthesis cycle time is to just not do them when you're actively debugging...use the simulator. When you do get to debugging on the board level you'll still find things that require rebuilds and you can spend the two hours build time pondering how you could've caught this bug if only you had modelled _____. And next time you'll have more experience about which things you really should model and catch in simulation and which can be deferred.

KJ

1. Faster computer
2. Parallel Synthesis/Implementation on a cluster

---Matthew Hicks

For fun I just created some graphs that show this at

. The design is a floating point adder and the timing constraint is varied in steps of .05 ns between 1 and 10 nanoseconds. The runtime of par and the performance of the design is shown in the graphs.

I do feel quite lucky that I have not yet created a design which takes

30 hours to route though :)

/Andreas

When you get into the region where the propagation delay is getting close to the constraints, floorplanning can make a huge difference in the run time, as well as in the ability for the design to meet timing at all. A good floorplan essentially narrows the region on your second graph where the run time is greatly increased.

The design I have that is running 30 hours is slowly decreasing in run time as I make adjustments to the floorplanning to improve the timing.

If synthesis consumes a lot of this time, synthesise each component alone, save the results (the netlists) and read the netlists during synthesis of the complete design.

Ralf

Right arount 3.5ns constraint the PAR is able to succeed, and the time it takes to do so drops to a constant. The data seem to indicate the program is floundering around with no hope of success, and it finally gives up in failure. If it can succeed in meeting the constraints, it does so immediately.

The more realistic situation is there are constraints that are attainable, just hard (and time consuming) for the PAR to accomplish.

It's interesting in the PAR problem itself, that if you give it impossible constraints, it doesn't sit there forever trying. So either the program has some sort of timeout, or can conclusively prove to itself it has exhausted all possibilities.

I'll bet PAR code would really benefit from getting moved to open source, if it's all closed-source + proprietary right now.

-Dave

--
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

[...]

Many, many thanks for a delightfully clear exposition of a vital idea.

Just occasionally, the orders-of-magnitude faster throughput of tests that you win from a hardware prototype outweighs the pathetically bad observability and controllability of the physical hardware as compared with a simulation. Only occasionally, though.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

And to prove your point: video processing. Simulating a single frame may take only 20-30 but isolated frames are meaningless while testing a hardware MAADI implementation where it is the overall impression over a long sequence that really matters. Running the same test in hardware may cost an hour in synthesis but it then allows viewing the whole video sequence in real-time instead of having to wait a few days after the simulation.

Simulation is good for finding functionnal flaws and debugging. Hardware validation is best used for real-world performance evaluation.

Throughput is one good argument for hardware testing. For HD video, it is pretty much the only sane option for both throughput and general practicality: testing against a large variety of input sources with various parameters would tie up simulation host/licenses for days and gobble up TBs for storing simulation data.

With hardware validation as a backup, simulations can be more focused on small, highly feature-specific tests while hardware runs help identify missing test cases and problematic areas based on real-world results. Being able to preview a module's performance in real-time and being satisfied with its real-world results beforehand is a major relief when the target device is an ASIC.

--
Daniel Sauvageau
moc.xortam@egavuasd
Matrox Graphics Inc.
1155 St-Regis, Dorval, Qc, Canada
514-822-6000

That's my point...finding flaws and debugging....much quicker in simulation than on hardware.

Not really a good argument. What you should be focusing on with the hardware testing is finding test cases to see whether they 'work' or not (i.e. the various parameters for HD video in your example). If you've found all the functional bugs from simulation you'll find no failures during hardware testing either.

That of course is a very big 'if'. What generally happens is that you do run across some test case(s) that fails on the hardware at which point you either...

- Slap yourself on the head because it is a simple thing that you just forgot about. Fix and retest.

- Characterize what it is about this test case that is different from the test cases that have already been simulated and add on to the simulation testbench to cover that case so you can then use the simulation to debug and then fix the problem.

In any case, you're using the hardware not so much for debugging as it is for uncovering conditions that you didn't adequately test (and are now failing). My contention is that for the typical, experienced designer you'll have fewer of those failing cases in the first place when the simulation is done up front.

Agree completely. Hardware is used to uncover the test cases that you thought you didn't need when you were doing the design and simulation.

KJ

I also have such an experiance with a design with which some 8 hrs efforts the router will say that it is impossibel to route; after a good floor planning will route with in 1/2 hr. Also time driven mapping will do good to the routing, Ray, Is there any conventions that i can use while floor planning. I think i have found one - dont know whether it is true. "Dont separate a block which is very big ino two parts of FPGA because the interconnections between the two parts will cuase problem with the routing of the intermediate logic". Also i think it is good practise to always separte FFs that uses two clocks. Is there any pdf or books available in this topic? regards Sumesh V S