Register model should support base addresses, slots, and slot size. Sub-blocks should be able to reference.

[chrisnappi]

O2 should support the following concepts natively:

• Hierarchical memory maps - SoC high level description of memory areas
• Base addresses - the address at which a block of registers for particular IP starts
• Slot size - the default and over-ridable size of a block of registers
• Slot - the position of a base address for a peripheral in a memory map

Example: Peripheral memory map begins at 0x4000_0000, UART is in slot 8, ADC is in slot 9. The default slot size is 4K.

Peripheral address = PerfBase + Slot*SlotSize
UART address = 0x4000_0000 + 8*4096 = 0x4000_8000
ADC address  = 0x4000_0000 + 9*4096 = 0x4000_9000

When importing registers from a bulk pre-processed XML (or other) source, sub-blocks should be able to use this as a means to 'claim' registers.

[chrisnappi]

Right now at least, there is no direct mapping. In O1 we typically have separate XML files for each register bank, and then each O1 sub block instantiates them.

I think going forward while we should still allow for this model, we also need the ability to build the SoC memory map separately and then have the sub_block just claim ownership of an address space at the time of instantiation.

So at startup, the main app build the whole chip register map from XML. A sub-block has address ranges it 'owns' as an input for instantiation. The ownership of the register is then transferred to the sub-block and said registers can then be accessed via dut.block.reg .

Just one way to handle it - root problem I am trying to address here is that the memory map for a device is often not available with all needed information at the IP level, and errors in interpreting the parameters needed to describes them at that level lead to the whole problem we are trying to solve with using XML sources in the first place..

[ginty]

I think a some of this e.g. 4KB slot sizes, maybe even the term 'slots', are high-level concerns which may belong more in domain plugins rather than in Origen itself.

Currently O2 is following the IP-XACT hierarchy in its modelling which does give you a lot of layers to play with:

- Block
  - Memory Maps
    - Address Blocks
      - Registers
      - Register Files
        - Registers

So these slots could be modeled in a number of different ways and your domain importer would be making the decision about which Origen layer to represent a slot and so on. So from a hierarchical modelling perspective, I think we are covered.

I think what's missing though is this concept of having 2 concurrent DUT views - an automatically-generated full view, and then an engineer-generated local view of the area of interest. O1 did support that concept via its direct controllers, the guide pretty much aligns to what you are describing here I think - https://origen-sdk.org/origen/guides/controllers/direct/

I haven't really thought until now about how to replicate that concept in O2, except for not wanting to have the same solution of 2 different controller types which is probably confusing for users (generally in O2 I am playing down the model/controller concept and want users to think more in terms of a single unit, 'the block').

So say we have an application layout like this:

# Engineer owned blocks
blocks/
  dut/
    falcon/
      sub_blocks.py # Instantiates the engineer's ADC block
  ip/
    adc/
      registers.py

# Generated blocks, imported from IP-XACT or similar
vendor/
  blocks/
    dut/
      falcon/
        sub_blocks.py   # Instantiates the vendor's ADC block, and the rest
    ip/
      adc/
        registers.py
      uart/
        registers.py
      ...

Then I think adding a line within the engineer block to tell it to use the registers from the vendor block should be trivial:

# blocks/dut/ip/adc/registers.py

import_from_vendor_block("ip.adc")

The real crux of it is how the global address mapping should be handled?

I can see 3 ways (and maybe we need to support them all):

• Only local address offsets are imported from the vendor block, global addresses are defined by the engineer's DUT.
• No global addressing is applied by the engineer's DUT, but global addresses have been applied at import time. i.e. the addresses in vendor/blocks/ip/adc/registers.py are actually fully resolved global addresses.
• The global addresses are defined by vendor, but they are embedded in the hierarchy. Therefore Origen should actually instantiate a vendor/falcon instance in the background to resolve the global addresses of its blocks.

Thoughts @chrisnappi ?

[ginty]

@chrisnappi, do it!

[chrisnappi]

Agree that if we implement the IP-XACT hierarchy we are covered for 'slots' as this is just a way to describe base and end addresses and that can be done at a higher level if desired.

I like the idea of having the vendor directory be a more standardized structure with generated models. As far as the addressing goes, unfortunately I think it is going to have to be flexible.

For clarrification, numbering the options:

1. Only local address offsets are imported from the vendor block, global addresses are defined by the engineer's DUT.
2. No global addressing is applied by the engineer's DUT, but global addresses have been applied at import time. i.e. the addresses in vendor/blocks/ip/adc/registers.py are actually fully resolved global addresses.
3. The global addresses are defined by vendor, but they are embedded in the hierarchy. Therefore Origen should actually instantiate a vendor/falcon instance in the background to resolve the global addresses of its blocks.

If the industry really moved to XML-based descriptions, I think that option 2 would be used most frequently, however currently we are in a situation where option 1 is fairly common. So - these both need to be supported.

At one point, we thought that Origen should be able to implement similar capabilities of the tools to convert re-usable XML to SoC-specific XML - that would be used with option 3. My opinion is we should no longer be trying to fully implement this route.