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 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?
In English Bay off West Point Grey in Vancouver lies an ideal spot for catching Dungeness Crabs - a wonderful delight to eat. My first experience crabbing was dropping a trap off a friend’s boat en route to Chinook Salmon fishing in the Geogria Straight. It’s not unusual to catch your limit on Spanish Banks if you know what you’re doing and to buy the equivalent at the local fish market will cost you almost $100.
This summer some friends and I went out in Kayaks and were quite successful at catching our limits. Google maps on the iPhone helped us to locate the trap after a paddle around the bay. Being on the water with a 3G connected smartphone is pretty handy.
On another occasion, while trolling on a Salmon fishing mission after having dropped the trap, we pondered how many crabs had entered the trap. At the same time internet radio streamed care of the iPhone’s 3G internet. I got thinking how cool it would be if we had a 3G link to a web camera down below to show us what was inside. Next thing you know I was drawing up plans for an autonomous crabbing vessel.