The register map problem
The register-map pattern is widespread in ASSP, ASIC, SoC and FPGA design. To narrow the scope of this article, we assume that you are developing an FPGA-based embedded system using Altera's SOPC Builder and NIOS II soft-processor. The concepts described here also apply to an ASIC flow and to FPGA systems that use other embedded processors. To illustrate these concepts we will build a slave component – a simple programmable traffic light controller (TLC). We will show you how SpectaReg can easily integrate with SOPC Builder to automate away your register-map headaches.
For the hardware logic, you may be using IP components from Altera or other vendors, together with your existing or to-be-developed in-house libraries. To connect IP components to the NIOS II processor, you will use Altera's SOPC Builder and Altera's System Interconnect Fabric – the fabric formerly know as Avalon. Components contribute their register-maps to the software programmer's overall memory-map, providing an interface for configuration and the communication of runtime status and data to the CPU. Some components will have complex memory-maps with thousands of addresses, registers, and bit-fields. Furthermore, interrupts in combination with memory-mapped status flags may be used for real-time, event-based signalling between the component logic and processor. A block diagram of a master with several slave components illustrating how your system might be connected is shown in Fig 1 . Multiple masters could also be used, but we will keep things simple for this article.
1. Example SOPC Builder system.
Registers are one of the more tedious and error-prone aspects of designing and implementing a SoC. Without an automated solution, the effort involved in memory-mapped register aspects can increase exponentially with the number of bit-fields in the design.
To better understand the problem, let us decompose it and look at it from the perspective of the system architect, embedded software developer, logic designer, verification engineer, validation engineer, and documentation engineer (Fig 2). As is often the case, you may wear more than one hat and identify with several of these perspectives.
2. Perspectives intersect around memory-mapped registers.
The system and micro-architecture perspective
As you decompose the system, define features, develop algorithms, and partition between hardware and software, you inevitably start to think in terms of memory-maps and registers. As you evaluate third-party IP, you will be looking at the register-map to determine how you might interface the IP with your embedded system. For new or existing components, getting the registers captured into the micro-architecture specification (MAS) before starting implementation ensures everyone is on the same page. The register map specification will need to be captured in several different formats, and it is imperative that the RTL implementation remain in sync with the testbench, embedded software, and datasheet. Neither you nor your customer should have to waste valuable time debugging problems caused by a lack of synchronization between the implementation deliverables.
The embedded software perspective
As a bare minimum, you will generally have header files defining component base address and register offsets. More sophisticated hardware abstraction layer (HAL) approaches may utilize macros, functions, abstract data types, or classes for reading and writing registers and bit-fields by name. Third-party IP represent a unique challenge since third-party providers do not always follow your HAL coding style and you would like project-wide consistency. Keeping the embedded software's register-map deliverables synchronized with the changing design is best automated from a single source.
3. Programmers' view of memory-mapped components.
The logic design perspective
You need to connect the registers up to the system interconnect interface, decode read and write cycles, and map each bit-field into a specific register address. The logic for each register and bit-field needs to be written and ports declared. Complex register-map elements like counters, interrupt trees, and indirectly accessed RAMs may need to be coded. As the design progresses chances are you will inevitably need to re-factor the register-map, adding or re-sizing a bit-field. You might do this before updating the MAS, thereby creating the possibility of a mismatch between the MAS and other register-map views. Registers are a pain to code up; they are tedious and error-prone and you'd prefer to spend your time working on more exciting and creative aspects of your design.
The verification perspective
It is always a good idea to verify that the RTL register-map works using block-level and top-level test-benches. When you are working with an FPGA, it might be quicker to validate the register-map with embedded software running on an FPGA board. Nonetheless, if the register-map does not work as expected, your best attack is to debug the RTL with a logic simulator. The behavioral data structures and functions/methods for register-access at both the block and system levels will need to be coded up and synchronized with changes to the MAS. Coverage points and assertions would help you do your job better, but it is hard to get the team to apply them consistently, if at all.
The validation perspective
To validate the system's functionality, one of the first things you are going to want to do is test out the memory from the programmers' perspective. Can the software read and write from the register-maps as expected? Are the reset values for each bit-field as expected? Once you have got this covered you can use the register-map as a functionality checklist to work through your functional tests. Diagnostics and debug registers make it easier for you to track down bugs. You may be using the embedded software's HAL to program the registers, or you may be using a completely separate register access layer that is specific to the validation environment. Either way, whenever the register-map specification changes you will have to update your tests or create new ones.
The documentation perspective
To communicate the register-map to the programmer, you detail the location of every component, register, and bit-field. When the RTL for the register-map is changed, ideally the designer will update and propagate the documentation, but this is not always the case. Each designer somehow manages to use a slightly different representation for the component memory-maps that you must aggregate. Also, you have to ensure naming conventions are consistent and that descriptions and addresses make sense. Simple project-wide changes, such as adding a new column for decimal addresses alongside the hexadecimal addresses, can be extremely monotonous tasks. The register-maps from third-party IP components are also troubling and you're looking forward to the day when your vendors ship IP with IP-XACT XML metadata files.
|
