Technology acronyms generally become jargon that loose their original meaning or maybe take on an expanded meaning that looses its original precision. A list of adulterated acronyms could be another interesting discussion but for this piece I wanted to discus the term ASIC. And, specifically, the letter ‘I’ which stands for integrated. ASIC is Application Specific Integrated Circuit and is supposed to differentiate from just an integrated circuit (IC), we could discuss that evolution as well, but again for now lets focus on “integrated”. Before “integrated” there was “discrete” and integrated meant bringing all of those discrete circuit functions into a single package, sometime called a monolithic device, to create a single unit of complex functionality. Through advances in design and manufacturing technology that single unit of complex functionality has become exponentially more complex. There are primarily two ways that this complexity in design has been managed in the development process: abstraction and reuse.
Abstraction is the idea that complex functionality can be described using higher abstract levels and then synthesized into the fundamental “discrete” components that create the intended function. Levels of abstraction evolved from transistor level to gate level to cell or slice level and then sort of stalled at register transfer level (RTL). RTL is currently the most common level of abstraction and efforts to evolve to higher levels have not really been successful. Examples have been behavioral level, system Level, transaction level and most recently high level. Yes, the current effort is just called high level abstraction (HLA) . I guess if that is successful we’ll start working on VHLA. That’s supposed to be a joke for those who know remember the progression of IC to LSI, HLSI (both short lived) and on to VHLI which all preceded ASIC as popular terminology the that which we colloquially call a “chip”. None the less these efforts to comprehend and describe more complex functionality has not progressed significantly in at least 20 years.
So, until HLA makes progress, the more significant method for handling ASIC complexity growth in integrated functionality has been reuse. Reuse in its simplest definition is in someways a reversion back to discrete design. The difference is that the modern discrete is a much more complex and configurable building block than a transistor or gate and discretes are now integrated into the design by way of a computer simulation instead of being physically wired up on a breadboard. Each building block is designed and tested as a unit and often completely implemented to its final physical implementation before being “integrated” with other blocks into the final system on a single silicon die, or possibly multiply silicon die in a single package. This design methodology is now commonly referred to as System on a Chip (SoC). The building blocks being reused are CPU cores, communication cores like USB, PCIe, ethernet transceivers, memory management cores, etc. In SoC we refer to these reusable discretes as IP (intellectual property) which is yet another bastardization of a term that confuses with having to do with patent work.
Many SoC efforts get to a point where due to the high cost and/or the long lead times of getting an SoC from concept to product the SoC developer decides they would like an emulation of the SoC suitable for evaluation and verification by the next pipe stage in the development cycle. Basically a breadboard instead of a simulation because breadboards are faster and facilitate verification in the intended application environment. For example the SoC may contain a number of microprocessor systems that need firmware development, the SoC may communicate with another system that needs to software or hardware development that could be started early, or some initial in-system validation of the SoC concept may be desired to improve confidence in the investment of time and money required to complete to product. For whatever reason the decision to emulate the SoC seems to come late and is often a compromise.
My suggestion is to think about integration again instead of emulation. Use a fast prototyping methodology to build the system, the S, before the chip, the C. Then integrate the S on the C. Balance the value of an early prototype that closely matches the target product, the SoC, with the cost of supporting the limitations of the prototyping methodology. For example, FPGAs are often the basis of a fast prototyping methodology. However, FPGAs may be slower and have IO limitations. So, architect the SoC to work within these limits in the FPGA and scale to the capability of the ASIC technology. The idea is to get back to integration of the building blocks instead of trying to cram an emulation in as an afterthought.