3 ms·
I think the issue here is that Synthesis and Place and Route tools are squarely in the Computer Science Algorithms domain. Hardware engineers in general don't
by DigitalJack 13y ago
I think the issue here is that Synthesis and Place and Route tools are squarely in the Computer Science Algorithms domain. Hardware engineers in general don't have the background for that kind of work.
And software engineers don't crossover to the hardware side often.
So the people suffering with the "slow" tools etc, are usually not in a very good position to do anything about it.
But really, the slow side is in the place and route. If you don't over constrain your design, this can go pretty quickly actually. It's when timing is tight, and first pass guesses aren't coming up with a satisfactory solution that things slow down.
- cbhl 13y agoIIRC, most of the time these just end up boiling down to 3-SAT, which will make the average Computer Science person throw up their hands in the air and say "it's NP-Hard, you can't make it more efficient" (even though NP is still an open problem). I think there's one EE/CE professor at my university working on the SAT solvers that form the crux of the optimizers in most of these tools, but at the end of the day it's still a bunch of heuristics that, worst case, run in O(2^n) time.
- sliverstorm 13y agoOn the bright side, route is pretty strongly parallelizable. So even if it takes the most CPU time, it doesn't have to be the long pole.