Modeling And Verifying Hardware-Software Interface Manual Or Automatic

System and chip design companies are always pushing the envelope to innovate while striving to shorten the development cycles, lower costs and mitigate the tape-out risks. It has now become more important than ever to have the flexibility to morph products quickly to meet the changing trends and yet meet tight time-to-market deadlines. The need to have this flexibility to meet the changing needs, has led design teams to develop a superset of features and modes which can be programmed to create desired variants of SoC’s and IPs.

The growth in areas such as AI, machine learning, virtual/augmented reality and automotive has also increased this need to have the flexibility to program the SoC in different modes and turn on/off the features as needed. This is more so in the case of evolving technologies where developers want to modify the settings of the SoC if needed.  The need for this flexibility has led to much of the functionality in a SoC-based system to be implemented as software leveraging the SoC platform to create the desired upgrades and variants of the chip.

The dual needs for increased productivity and flexibility are typically met by managing the hardware-software interface (HSI) effectively. Writing/reading registers and interrupts are the primary way that the behavior of most SoCs/IPs are controlled and queried. Modeling tens of thousands of registers manually and verifying them is an error prone task and inevitably leads to delays in project timelines, which design teams can ill afford. For the HSI to be successfully implemented, there is a need for interaction between system architects, software developers, hardware designers, system integrators and verification specialists, which is often at best tardy. This has led to a need for developing the HSI specification at higher levels of abstraction to define the different types of registers, memory maps, which can automatically generate an “executable”, such as Verilog, VHDL languages, C header files to be leveraged by all the stakeholders involved in the development of the SoC.

To solve this problem, a few companies have developed “in-house” tools to define the registers needed for the HSI. Some companies for example developed a flow wherein the designers use a XML file generated from an excel file, which is then used by scripts to generate the register models and other derived documents (VHDL packages, HTML documentation, etc.). Some of the manual and in-house tools do not address the requirements for all the teams such as software, silicon validation, documentation etc. With the increase in the complexity of the HSI, register modeling needs to be customized to meet specific requirements. The need to adhere to standards such as IP-XACT or SystemRDL remains a concern as well. As a result, in-house solutions need to be constantly maintained and supported.

Even if the registers have been modeled using either in-house tools or manual means, the question of verification continues to linger around. As a consequence of how fundamental registers are to the correct operation of designs, considerable effort is spent on developing the tests as it forms an important aspect of design verification and bring-up. While it is relatively easy to verify a few hundreds of registers using traditional methods, the problem gets compounded when the number of registers in a design increases to tens of thousands.

Manually verifying the large amount of registers in the SoCs/IPs of today, using the vectors or sequences developed by the verification team is a bit risky. A number of companies have discovered this the hard way much to the chagrin, when the cause of re-spins has been found to be an issue with a register defined as part of the HSI. In addition one has to consider the use of special types of registers and functionality associated with many of these registers while developing the tests. Some of the special types of registers, which need to be handled differently, are registers such as interrupt registers, counter registers, shadow registers, aliased registers, modal registers to name a few.

Ensuring correct connectivity of the registers, is an important aspect of verifying the HSI. For example, it is important to verify that the registers are accessible from the interfaces on an IP block and have the correct reset values. At a subsystem level, verifying access to registers helps to confirm that the interconnect network and address decode have been implemented as per the specification. At the SoC level, verifying access to registers confirms that the processor byte order matches the interconnect implementation, and that the boot code properly configures the memory management unit (MMU) such that IP registers are visible to the processor. With a number of companies using internally developed or 3^rd party IPs in their designs, it also becomes necessary to verify the quality of the HSI of the IPs. In addition, while verifying access to the registers, one has to ascertain that the bus protocols have been adhered to correctly.

Another verification concern, which is often ignored, is the onus of defining the sequences used by the design verification team and the software/firmware team. Each team creates sequences or HAL routines (a simple and small routine to program a few registers of the DUT to configure it to operate in a specific mode) using the coding language and coding style they are comfortable with. For example the verification team uses UVM to define the testbench and sequences while the software/firmware teams use C. The design verification team prefers the use of UVM sequences as it greatly simplifies the testbench architecture and debug. But on the flip side, there is no portability of the test vectors to validate the design on FPGA and silicon platforms. When the design verification team does use C based sequences, they are often not reusable by the software team. The software team on the other hand develops their own sequences, which increases the probability of misinterpretation of the specifications defined. With no relation to the sequences defined by the design verification team, there is always a strong probability of lengthy debug cycles in the lab and/or the tester.

An ideal scenario to facilitate testing between the hardware and software teams would be to build a common set of sequences which can be leveraged across the tests they develop. These sequences would ultimately form the building blocks of the high level tests, which they develop as shown below. By meeting most of the C coding guidelines set by the S/W team, design teams maximize the chances of production software code reusing these common sequences thereby minimizing duplicate work and unnecessary debugging in the lab.

Given the tight development cycles and the complexities involved in the design and verification of HSI, most companies are looking for solutions to resolve the above-mentioned issues. IDesignSpec^TM from Agnisys is one such tool, which solves two major issues. For a start, it provides design teams an easy alternative to define their HSI using a number of options such as GUI, spreadsheets such as Openoffice Calc/MS Excel, documents such as Openoffice Writer/MS Word or text based formats such as SystemRDL, IPXACT, YAML, XML etc. It also generates a number of output formats such as RTL (Verilog, VHDL, System Verilog), C Headers, System C, UVM register models etc. to ensure parallel engagement of all teams throughout the project life-cycle and allow for a flexibility on coding style.

To verify the HSI, ARV^TM or Automatic Register Verification software from Agnisys provides design teams a platform to verify the HSI by automatically creating a UVM testbench and standardized UVM and C tests to validate the RTL and use the same tests for validation in the labs. To enable a better platform for software and hardware co-verification, ISequenceSpec^TM provides design verification teams to develop custom sequences using a pseudo code and generate the output in C, UVM, Python etc. which can be used by the design verification, software and the silicon verification teams.  For more information on these products from Agnisys, go to www. agnisys.com

Tags: Embedded

This entry was posted on Wednesday, January 29th, 2020 at 1:52 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.