Why thinking about software and security is so important right at the start of an ASIC design
Designing an ASIC is a massive task to create, layout and test the configuration of billions of parts and connections and is the focus for time and resources. However, this means that the software that runs on the ASIC is often ignored until the ASIC design is finished because the thought process is that you have nothing to run the software on to test it properly; apart from running it on computer simulations of the hardware which is very slow and only gives an indication of how the actual chip could perform.
As a result, many companies wait until the design is nearly finalised before they start coding the software to run on it, often thinking that software is easy to re-write to optimise. But this means that, by then, the hardware design is frozen and has not been optimised for running the software, missing the opportunity to tune the hardware to run the software for better performance and reduced power consumption.
In worse case scenarios, the SoC may meet the hardware specifications but the overall solution fails to perform according the required specifications as the software is running on it in a sub-optimal way, requiring expensive and project-delaying reworks to one or the other or both.
The solution is that the software should actually be considered right at the start of an ASIC project so that the hardware can be developed in tandem with it, initially using simulation models and later on emulation and FPGAs. This enables both hardware and software to be optimised for low power consumption and best performance.
In practical terms, this means starting work on the software running on behavioural simulation models before starting on an FPGA version of a design, as the RTL for the FPGA is best influenced by the software architecture. The simulation model only requires that the behavioural design of the hardware is in place. Even during the behavioural model design process, the knowledge of what the software will need to do should be used to help shape the design, although there isn’t anything to actually run software on. In other words, software expertise should be brought in for the hardware architectural design phase before any models or FPGAs have been started, i.e., right at the concept stage of the design.
Related Semiconductor IP
- AES GCM IP Core
- High Speed Ethernet Quad 10G to 100G PCS
- High Speed Ethernet Gen-2 Quad 100G PCS IP
- High Speed Ethernet 4/2/1-Lane 100G PCS
- High Speed Ethernet 2/4/8-Lane 200G/400G PCS
Related Blogs
- Why SRAM PUF Technology Is the Bedrock of Dependable Security in Any Chip
- Ambient IoT: 5 Ways Packetcraft's Software is Optimized to Enable the New Class of Connectivity
- What is cloud-based security lifecycle management for connected objects and why is it important?
- Masking-friendly signatures and the design of Raccoon
Latest Blogs
- Why Choose Hard IP for Embedded FPGA in Aerospace and Defense Applications
- Migrating the CPU IP Development from MIPS to RISC-V Instruction Set Architecture
- Quintauris: Accelerating RISC-V Innovation for next-gen Hardware
- Say Goodbye to Limits and Hello to Freedom of Scalability in the MIPS P8700
- Why is Hard IP a Better Solution for Embedded FPGA (eFPGA) Technology?