hi, all I am developing a design with V4 LX100, and the project is large, which usually cost me 2 hours to synthesis and PAR. It's more than I can bear when debug it. Is there any solutions to decrease the time cost? Incremental design or planahead? Can anybody with these experience figure out what should I do? Many thanks!! Regards King
how can I decrease the time cost when synthesis and implement
Started by ●September 6, 2006
Reply by ●September 6, 20062006-09-06
king wrote:> hi, all > > I am developing a design with V4 LX100, and the project is large, which > usually cost me 2 hours to synthesis and PAR. It's more than I can bear > when debug it. > Is there any solutions to decrease the time cost? > Incremental design or planahead? > Can anybody with these experience figure out what should I do? > > Many thanks!! > > Regards > King >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.
Reply by ●September 7, 20062006-09-07
"king" <frogkinger908@sina.com> wrote in message news:1157590436.111863.250840@d34g2000cwd.googlegroups.com...> hi, all > > I am developing a design with V4 LX100, and the project is large, which > usually cost me 2 hours to synthesis and PAR. It's more than I can bear > when debug it. > Is there any solutions to decrease the time cost? > Incremental design or planahead? > Can anybody with these experience figure out what should I do?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
Reply by ●September 7, 20062006-09-07
"king" <frogkinger908@sina.com> wrote in message news:1157590436.111863.250840@d34g2000cwd.googlegroups.com...> hi, all > > I am developing a design with V4 LX100, and the project is large, which > usually cost me 2 hours to synthesis and PAR. It's more than I can bear > when debug it. > Is there any solutions to decrease the time cost? > Incremental design or planahead? > Can anybody with these experience figure out what should I do? > > Many thanks!! > > Regards > King >1. Faster computer 2. Parallel Synthesis/Implementation on a cluster ---Matthew Hicks
Reply by ●September 7, 20062006-09-07
On 2006-09-07, Ray Andraka <ray@andraka.com> wrote:> It will help tremendously if the timing constraints are not pushing the > envelope for your design.For fun I just created some graphs that show this at http://www.da.isy.liu.se/~ehliar/stuff/place_and_route.html . 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
Reply by ●September 7, 20062006-09-07
Andreas Ehliar wrote:> On 2006-09-07, Ray Andraka <ray@andraka.com> wrote: > >>It will help tremendously if the timing constraints are not pushing the >>envelope for your design. > > > For fun I just created some graphs that show this at > http://www.da.isy.liu.se/~ehliar/stuff/place_and_route.html . 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 :) > > /AndreasWhen 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.
Reply by ●September 7, 20062006-09-07
king wrote:> I am developing a design with V4 LX100, and the project is large, which > usually cost me 2 hours to synthesis and PAR.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
Reply by ●September 7, 20062006-09-07
Andreas Ehliar wrote:> For fun I just created some graphs that show this at > http://www.da.isy.liu.se/~ehliar/stuff/place_and_route.html . The designRight 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
Reply by ●September 7, 20062006-09-07
On Thu, 07 Sep 2006 03:19:32 GMT, "KJ" <kkjennings@sbcglobal.net> wrote:>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.[...] 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.
Reply by ●September 9, 20062006-09-09
Jonathan Bromley wrote:> On Thu, 07 Sep 2006 03:19:32 GMT, "KJ" > <kkjennings@sbcglobal.net> wrote: > >> 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. > [...] > > 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.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
