When developers talk about system-on-chip (SoC) designs, they usually talk about embedded systems that contain hardware and software. Many even think that a chip must have at least one embedded processor to be considered an SoC. There are many design and verification challenges for embedded systems, and these also apply to SoCs. The silicon technology doesn’t matter; embedded FPGA designs can be huge these days and every bit as complex as ASICs or full-custom chips. Tackling the development challenges for these systems requires an automated, unified flow that covers both hardware and software, spanning design, verification, software, and documentation.
Huge designs are possible only because there is a lot of reuse from previous projects, commercial IP providers, and open-source sites. Much of this IP requires embedded software such as firmware and device drivers, one primary reason why a unified development flow is so important. The entire system is developed from a specification that traditionally has been a text document. This is a challenging process since the architects must translate intent into natural language, and then the designers, verification engineers, and programmers must translate natural language into silicon and code. The best approach to speed up development is to use executable specifications. In this way, large quantities of hardware and software can be generated automatically.
The value of this automation is even greater when the specification changes, as it does many times throughout every SoC project. There are many reasons for these changes, including new feature requirements, responses to competition, and new versions of applicable standards. In addition, trying to meet timing, area, power, testability, safety, and security goals during implementation may require specification tweaks. Every specification change has ripple effects on the hardware, software, or both. With a purely manual development flow, the designers and programmers have no choice except to make the necessary edits by hand.
The embedded system must be re-verified to check out the new functionality and ensure that nothing was broken in the update process. Specification changes also ripple to the verification team, since often their environment must also be updated by hand. With a purely manual development flow, the designers and programmers have no choice except to make the necessary edits by hand. Without automation, it’s easy for the teams to get out of sync when the specification changes. Verification and validation often uncover issues due to hardware and software teams not working from same version of the specification. All this extra work consumes resources, adds to the project cost, and takes time, lengthening the time to market (TTM).
Automating the design and verification process by using executable specifications has been our prime focus at Agnisys from the very beginning. From the specifications, our tools generate RTL design code, verification test benches and tests, device drivers, documentation, and automated test equipment (ATE) programs for the fabricated chips. Agnisys automates the development of registers, memories, sequences, bus interfaces and various types of IP. In addition, Agnisysprovides tools to combine all these elements and user-developed blocks into a complete SoC. This saves time and resources during initial development and pays dividends throughout the project. Specification changes are automatically reflected in the re-generated hardware, software, testbench, and documentation, ensuring that teams stay in sync.
Agnisys defined a unified development flow for embedded systems that ties all together Agnisys provides a methodology and guidelines for using each tool to achieve the most significant benefit. Agisys worked with leading customers to understand their needs and create a flow that meets their requirements. In addition, Agnisys has developed its own small SoC design to show potential users how the tools and processes work in an actual project. The design averages sensor data received over an I2C interface. Sensor values are read in and converted into an averaged value by user application logic, all under the control of software running on a CPU.
The diagram below shows our SoC design and where our tools were used in the flow. The CPU is the open-source SweRV Core EH1, a 32-bit, 2-way superscalar, 9-stage pipeline implementation of the RISC-V architecture. Other than this core and the averaging RTL and software, the entire project was automated using our unified flow:
- The Standard Library of IP Generators (SLIP-G™)generated the RTL for the I2C master and the code to configure and control it
- Agnisys IDesignSpec™family generated the RTL for the control and status registers (CSRs) and the APB interface to connect to the CPU
- Agnisys used the DVinsight™ smart editor when writing the SystemVerilog RTL for the averaging filter logic block
- Agnisys used the SoC Enterprise™ smart SoC assembly tool to connect all the blocks and create the top-level RTL
- Specta-AV™generated the complete Universal Verification Methodology (UVM) simulation environment, including register model, agents, coverage, and test sequences
- Automatic SoC Verification and Validation (ASVV™) generated a synchronized C-UVM verification environment and the embedded C code to verify the CSRs
Automatic SoC Verification and Validation (ASVV™) generated a synchronised C-UVM verification environment and the embedded C code to verify the CSRs.
Agnisys recorded a webinar detailing the unified embedded development flow and the use of Agnisys tools within the flow, including the results for our example SoC design.