For the system designer, the platform is a complex supply chain of internal/externally developed hardware/software intellectual property (IP). It’s a complex set of risks and trade offs that must be analyzed in the decision making process. The winning platform provider will go above and beyond, to provide a whole solution, including a programmers guide to the register map, driver code and maybe even an executable specification model.
There are many different requirements that the System Developer may have for the IP deliverables, including:
- a programmers’ guide on interfaces, interrupts, registers, and so on
- example/reference firmware for driving and testing the IP in a standard configuration
- inter-operable models of the IP in various different languages, at different levels of abstraction (firmware, ESL, HVL, RTL, XML, etc.)
- ability to integrate and even re-code firmware in a system-specific way across all IP in the system
- ability to easily integrate and brand IP documentation across the entire system in a consistent, professional way
A good approach to the modelling and abstraction of the hardware/software interface can help to achieve these requirements for both the IP producer and the system integrator. The SpectaReg register management tool’s approach is to generate the different deliverables from a common, single-source specification model. This provides opportunities for “bottom up” and “top down” approaches to firmware abstraction and system documentation preparation.
Abstraction by the IP Provider - Bottom Up
The IP provider should provide a memory map document of the different memory mapped elements and registers. Better yet, they may additionally provide a device driver code that abstracts the registers to provides a higher level view of the IP. Since the abstraction is created by the engineers specializing in the IP rather than engineers specializing on the overall system we call this “bottom up” abstraction.
Abstraction by the System Integrator - Top Down:
The IP consumer may have their own special way of doing device drivers, system memory testing and diagnostics. They might be targeting a specialized processor or interconnect architecture, language or operating system. They might be optimizing for throughput, power, or memory. They might have custom monitoring, programming and debugging systems. For these reasons the IP consumer might choose to create their own firmware. This “top down” approach to hardware abstraction requires that both the IP provider and consumer have excellent and inter-operable register management workflows.
The Register Supply Chain:
Something we are seeing in our extensive work with registers is that there is a supply chain of register specifications from the different IP providers. For example, the provider of a SPI core may have several registers that they code in Verilog, VHDL, C/C++ and publish in HTML or PDF. Then, the consumer of the SPI core may want to integrate the registers of the SPI core into their overall register map and C/C++ driver code in a way that is consistent across the entire system. Within this process there are various different teams and perspectives that need to consume the specification and produce work based upon that. This is the Register supply chain.
A Semantic Register Specification and the Supply chain:
Ideally the IP developer captures the registers into a semantic specification model that can be used as a single source of the register interface specifications. With SpectaReg, this is done through a browser based GUI and imported/exported using IP-XACT (and many other formats too). The underlying model specifies all relevant information relating to the registers, including typing information relating to how the register’s bit-fields are implemented and how they function. The model also includes inter-relationships between register fields. For example, a certain bit may be defined as an interrupt and it may be associated with a trigger and mask bits. The firmware programmer knows how the interrupt will operate and the RTL developer knows how it is auto-implemented in the Verilog and/or VHDL, based on the typing of the bit. From the semantic model, the related RTL and firmware code can be auto-generated to target different bus interface protocols and different coding and presentation styles that suit the needs of the system integrator.
Simply throwing the semantic register specification over the wall to the IP consumer (say in an IP-XACT XML file) does not solve everything. There are opportunities for the supply chain to get out of synchronization and for non-formalized communication of information to get lost. The flows for making changes and feeding back information from the different parts of the supply chain are not well defined. Using a dynamic web application to manage the specification model and manage the dynamic and collaborative work-flows of the register supply is part of our vision. We see this as the best way to simplify the overall process and address the needs of all stakeholders. What do you think?