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
- Chiplet Die-to-Die Interconnect IP Solution
- High speed MACsec Engine 100G/200G/400G/800G/1.6T
- Temperature/Voltage sensors
- AMBA Bus Host to eSPI Controller/Target
- AMBA Bus Host to eSPI Controller
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
- Alliance for Open Media Releases AV2 Codec, Advancing Next-Generation Open Video Coding
- VeriSilicon Drives Commercial Adoption of AV2 Across Next-Generation Video and Streaming Applications
- Cadence Announces Collaboration with Intel Foundry to Accelerate Intel 14A Process Optimization for HPC and Mobile Designs
- Menta and Presto Engineering Announce Strategic Collaboration to Accelerate Adaptive ASIC Architectures with Embedded FPGA Technology
- MIPI A-PHY To Power Industry’s First Four-Company Automotive SerDes Interoperability Demonstration at AutoSens USA