Fixing Down Parts of Logic in ISE (8.2)

I have to come to the defense of PlanAhead here. Although I don't use it as part of an incremental flow, I do use it to improve timing, and I found it surprisingly easy to use. I watched the video-on-demand demo, scanned the documentation then started floorplanning. In most cases I've found it sufficient to just assign area groups to modules, but it's not hard to lock the placement (but not routing) of logic elements within the module.

"marc_ely" wrote in message news: snipped-for-privacy@b28g2000cwb.googlegroups.com...

Typically, the main reason for a long par time is challenging timing constraints. The tool is 'throwing darts' initially, and then working towards a locally optimal solution. If you can spend the time to figure out where the trouble spots are, you can: 1) Determine if the timing requirement is real on these critical paths. (Often, there is a multi-cycle path. When you take unnecessary pressure off the tool, it tends to do a better job achieving timing closure.) 2) Lock down the endpoints in the critical paths. Sometimes this is obvious, sometimes it's not. 3) Force (in your code, for instance) register/logic replication to reduce fanout. 4) Prohibit register/logic replication. (The answer is: it depends.) 5) Direct par to leverage a previous route. (This can improve things, and it can make things much worse. It depends.) 6) Use incremental and/or hierarchical design techniques. The tools are very good at solving challenging, but small, problems. They are pretty good at solving easy, but large, problems. Oftentimes blocks A, B, & C will meet timing closure individually quite quickly, but flounder when all three are present. I haven't experimented with the hierarchical design flow in a couple of years, but I did notice that the final par can run much more quickly (achieving timing closure) this way, rather than making the tool solve all the issues at once. Starting with a 'known-good' baseline can really speed things up. Further, it is less susceptible to the impact of small design changes. (The impact is felt when running par on the appropriate block more than it is for the final par.) This technique tends to produce larger designs, but the turnaround time may be quicker.

I haven't upgraded from 8.1sp3 to 8.2 yet, so I can't say. There are reasons I want to (the corrupted project file can be such a pain...), but for compatibility reasons, I stay at 8.1.

I have only used it a little bit; mainly, to get insight, or as a starting point. I've been handplacing critical registers for better than 10 years, and old habits die hard. (Especially when they work. It seems most of by timing challenges have been datapath, and the tool seems to get the most help by hand-placing things register by register. I have seen designs go from almost never meeting timing, to easily meeting timing, by fixing the locations of registers in the critical path. My experience has been: let the tool work hard on what it is good at, and give it explicit directions on what it is not good at.)

Food for thought,

Jason