Over the years, working with customers designing chips, a few guidelines have been found that assist in the architecture of the Hardware/Software Interface (HSI). Sometimes guidelines will be broken. Sometimes for legacy designs, sometimes because not all the requirements are upfront but keeping these in mind help ensure the architecture will be as robust and anti-fragile as possible.
Getting the Software Teams Involvement
Chip architects and RTL designers should approach the beginning of a project with the idea that the software team needs to be involved early and often, especially when it comes to the HSI (Hardware/Software Interface). The software team understands what is difficult for them to do. They can come up with solutions that the RTL team would struggle to think up because they are approaching the problem from the other side. RTL designers need to be open to ideas from other sources, like software.
Getting input from the software team helps as they access registers and memories in your design. They should be driving requirements for the HSI architecture, for example, interrupts. The hardware and software teams should discuss how interrupts are processed and handled to ensure the architecture meets their requirements.
Keep the software teams in sync during the design process. Try to automate this using a tool or script. Semifore recommends CSRCompiler. Doing this ensures communication of changes, and the software team has their input. Software is the tall tent pole in many designs, and anything the hardware team can do to assist makes the project run smoother.
Address Maps Should Be Either Hierarchical or Leaf
A hierarchical address map only contains other address map objects. A leaf address map has every other thing besides an address map. The architecture is simplified by separating maps that contain address map objects from maps that contain everything else.
Highest Level Map Should Have the Largest Word Size
Many designs have either re-used IP or 3rd party IP that has already been created and vetted. This simplifies the design process; each may have different word sizes or the size of the register represented in software. To make architecture easier, the top map in the design should be equal to or larger than any other map in the design. It is easier for a larger address map to access a smaller one than for a smaller map to access a larger one. For the latter, the design would need some shadow registers or other constructs.
Use of Byte Enables Should Be Determined Up Front
Semifore recommends against using byte enables. Byte-enables make hardware and verification more complicated. If a design needs byte-enables, determine that up front. If a block of the design has byte-enables, the top-level map and intermediary maps need to know about them. The byte-enables need to be passed up to the processor. If one block needs byte enables, it doesn’t mean all the maps in the design need them.
Think of Fields as the Atom
Many different disciplines access HSI information, from verification to tech writers. Each needs the information in various formats. CSRCompiler supports each domain’s standards and common form, but each format has a nuance. For example, in UVM, the standard specifies the atom is a register, not a field. Thinking of fields as the atom for your design ensures correct information for each discipline.
Minimize Different Field Types and/or Access Behaviors in a Register
Registers can have a mix of different fields – each with different functionality and purpose. RTL architects and designers try to use as little space just in case, cramming fields in tight. Smashing all the fields together is a problem in and of itself. What if the design needs to expand a field? There is no space. Most chips have extra address space for registers.
What about a mixture of access types – all combined in one register? Take, for example, mixing registers containing read-only and write-one-clear fields. This mixture of field accesses may lead to unexpected behavior and complex software interaction.
Following these guidelines simplifies the efforts of software and verification teams.
