Commentary: How ESL can regain credibility
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?
(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?
To read the full article, click here
Related Semiconductor IP
Related News
- How bad is IP theft in China? And what can you do about it?
- How ESL becomes a business imperative
- Survey says: ESL methodologies can improve productivity
- Commentary: Why it's time to redefine ESL
Latest News
- Sofics Extends Interface Voltage Options in TSMC FinFET and Nanosheet Technologies
- aiMotive and Cadence Demonstrate Layer-by-Layer Workload Placement Across Independent AI Engines
- Alchip collaborates with Synopsys to Address Scale Up and Out Bandwidth Constraints
- M31 and Ambiq Collaborate on TSMC N12e® Foundation IP to Address Demanding SoC Power and Area Targets
- Siemens and TSMC advance AI-powered semiconductor design automation