Chad Spackman, CebaTech(02/02/2007 6:03 PM EST), EE Times
Electronic system level (ESL) design has, for several years now, suffered from a combination of lack of description and resulting unrealistic expectations. We hear from RTL designers things like: "C will never be a good hardware description language," or "a software team will never be able to create hardware with an ESL flow."
How on earth did the latter ever become a realistic expectation? Such expectations and general lack of defined mission have resulted in the acronym "ESL" being synonymous with the acronym "BS". Credible ESL companies now find they have to fight the unfortunate reputation bestowed upon them by the mere fact that they are part of an industry that's been in existence for quite some time, but has accomplished little.
Companies trying to develop a tool that can take an untimed, single-threaded, behavioral input language and produce multi-clocked, resource sharing, multi-threaded hardware have their work cut out for them. Those who have accomplished this — and there are very few — do so with heavy constraints on the design input, such as size of the design and restrictions on usable language constructs, to name just a couple.
And after such a feat, what does it mean to say that the input source code for your design has been debugged? Nothing. How can a bug-free, single-threaded input entity say anything about a multi-threaded output entity? And thus how do we verify functionality?
Click here to read more ...