Space exploration … design, that is
The other day I was emailing back and forth with my colleague Steve Leibson about the new Cadence ESL synthesis tool. He commented that there seems to be a gap between IP-centric design (such as processor-centric design, or the use of other large configurable IP blocks) and the general ESL world - for example ESL synthesis, which assumes for the most part that you are implementing a piece of functionality entirely in a new dedicated hardware block or blocks. To quote Steve,
A good tool would be able to decide when to use a configurable processor core to implement a block in a hierarchy and when to generate new RTL instead.
Coincidentally, Frank Schirrmeister was musing in the same direction in his recent blog on ESL synthesis. He points out many options for designing a major complex function at high level, concentrating on the topology and interconnect, and many options for designing each major block of functionality from pure software on a fixed ISA processor through to RTL synthesis, leading to at least 35 permutations and options for “function to implementation”. Design space exploration indeed!
Johannes Vermeer, The Astronomer, c. 1668
Early astronomers as pictured here had star charts, globes and early telescopes. Perhaps with processor-centric ASIP design and ESL synthesis we are still in this early stage of development. It seems to me that considerable opportunities lie, as Steve said, for the development of design space exploration tools that link into the various implementation flows from various vendors and for various alternatives and allow people to really explore space effectively. Perhaps a DSE version of the Hubble Space Telescope - without the early optical flaw that necessitated sending a repair crew out into space!
3 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
July 31st, 2008 @ 3:06 am
What about the higher level of system design from ready-made chips? The ESL and EDA companies obviously focus on how to build chips from blocks, cores, and interconnects. But system companies today tend to build systems from standard parts with only the occasional ASIC or FPGA. They also have a problem in design-space exploration: understanding the features available in highly-integrated “platform” chips like the Freescale PowerQUICC series.
For example, should you get the variant with e300 or e500 cores? Use ATM, Ethernet, or RapidIO for the backplane? Use a few smaller cheaper chips or a single more powerful one? Maybe buy a part with some feature missing and implement that function in an FPGA instead? How to divide the software and functions across boards and chips? How to best integrate a farm of DSPs with the controller chips? Or maybe put it all on a massive multicore chip and not using DSPs at all? Which operating system makes sense in which part of the design?
It is a problem similar to DSE, but the units are much larger and tend to be very complex. And fixed, rather than something that can be changed. I think we need to see design tools for exploration move up to that level, as that is what most electronic system designers are facing today.
July 31st, 2008 @ 12:44 pm
Jakob, that is an excellent point. Periodically, over the past 30 (!yes, I am getting somewhat “mature” or perhaps “aged”!), I have worked with colleagues in the EDA industry who have tried to implement concepts of DSE at the levels above chip design - sometimes dealing with HW-SW tradeoffs, sometimes dealing with implementation tradeoffs at the “IP” level (whcih boards/chips/subsystems do I integrate into my shelf/backplane/box), sometimes dealing only with physical issues (e.g. the fit of chips on boards, boards in shelves, shelves and racks into boxes, the power dissipation, the preparation of bills of materials as outputs, and linking to electro-mechanical design tools such as CATIA etc.). For some reason, these kinds of tools never got a bit market and most of the DSE was done on the whiteboard before passing specs on to specialists who would do the mainly physical tasks of PCB design. Given today’s system complexities, this is also well worth a re-look. Right now in EDA, much “beyond the die” thinking still seems to be stuck on chip-package-board codesign - and in the physical/thermal/EMI/ESD domains only. The DSE questions you list as examples would need tools and models of a very different kind.
Grant
August 2nd, 2008 @ 3:00 pm
Yes, we need models which are much more abstracted — cycle-accuracy is a joke for a rack, even once you know what you are modeling (i.e., simulating a done design). You really want an electronic data book with some kind of executable ability to see interplay between different parts.
I guess a big part of the problem is getting truthful data on parts from manufacturers. Usually, it is only once you have a physical piece in yous physical lab that you really now if all these sales people told you the truth, the WHOLE truth, and NOTHING BUT the truth — to paraphrase certain other areas of society…