OBI Memory Agent

[MikeOpenHWGroup]

Task Outcome

Implement an OBI Memory UVM Agent.

Background information

The so-called "dut wrappers" for both the cv32e40p and cv32e40x instantiate a memory model called mm_ram which supports OBI interfaces for the CV32E40 Instruction fetch and data load/store interfaces, a memory array for I&D, plus a set of virtual peripherals. mm_ram has several short-comings, most notably:

• crude randomization of memory interface timing
• lack of a configuration object for testcase control
• limited ability to support memory protection

The purpose of this task is to replace mm_ram with a UVM Agent.

Location Information

This verification component is expected to be re-usable for all "E-class" CORE-V cores, so it will reside in core-v-verif/lib/uvm_agent/uvma_obi_mem.

Completion Criteria

• Support for all OBI signals, not just what's needed by current design.
• Backward compatibility with mm_ram, specifically the 2-D array (memory) and virtual peripherals.
• Ability to drive master & slave traffic via their own sequence items on the same sequencer
• Ability to add handling for multiple in-flight reads/writes (assume this is this necessary in first release)
• Slave sequences that respond to monitored transactions of master requests (i.e. responds to reads/writes with rdata/err)
• Protocol errors detection for monitor - flags transactions as errored and emits `uvm_error()
• Ability to add error injection mechanisms in future versions
• Measures latencies on monitored transactions
• Master/slave sequence items have multiple, randomizabe latencies
• Transaction logs for master/slave sequence items and monitored transactions
• Self-testing environment (master <-> slave) and test bench to allow for OBI agent development to be separate from RTL

Additional context

There may be some overlap with the existing obi agent. This should be discussed.

[datum-dpoulin]

I've created a new branch from core-v-verif for this issue.

I just pushed in the first version of the new OBI agent that passes the sanity regression in xsim (Vivado simulator) 2019.2. This includes:

• uvma_obi
• uvme_obi_st
• uvmt_obi_st

I haven't added anything to the makefiles yet for simulating the OBI self-test environment and tb. I highly recommend having the OBI (and other agent) self-testing test benches set up for simulation like the core test benches are. They should also be under regression control. Mike, how do we want to set this up?

Once this is set up, uvmt_obi_st will need to be debugged using at least dsim.

[Silabs-ArjanB]

Hi @datum-dpoulin I see in above 'completion criteria' that the intention is to support all OBI signals. For the CV32E40X and CV32E40S the OBI specification has recently been extended with various new (optional) signals, see https://github.com/openhwgroup/core-v-docs/blob/master/cores/obi/OBI-v1.2.pdf. As far as I can see these signals have not yet been accounted for.

[datum-dpoulin]

Thank you @Silabs-ArjanB! I wasn't aware of the updates. I've added the signals to the interface and pushed in the changes. Mike & I are still figuring out the implications to the agent.

@MikeOpenHWGroup, I've pushed in the python sim script I used to develop the OBI agent and updated the OBI ST TB Readme.

[MikeOpenHWGroup]

Hi @datum-dpoulin, sorry its taken me so long to get to this. Having trouble running the self-test because I am not clear on what the "target" argument should be. My command-line is:

$ python3 dvm.py all uvmt_obi

I've tried several variations of "target", all with no luck.

[datum-dpoulin]

Close! Here is an example:

clear && python dvm.py all uvmt_obi_st -t all_access -s 1

[datum-dpoulin]

I've pushed a new version of the script that pulls the mio libs: python dvm.py update

[datum-dpoulin]

Hi Mike, I've pushed in a fix. All 3 OBI ST tests pass for seed 1 with Vivado 2020.3.

[MikeOpenHWGroup]

Hi @datum-dpoulin, recording our agreement on naming:

1. Keep the existing uvma_obi as is until is deprecated.
2. Rename the new uvma_obi_pkg to uvma_obi_memory_pkg (same for the directory name: uvma_obi -> uvma_obi_).
3. Use the new `uvma_obi in cv32 like so: uvma_obi_memory_pkg::uvma_obi_agent_c.
4. Once the old obi agent is removed, we rename uvma_obi_memory_pkg to uvma_obi_pkg, and do a global search & replace for uvma_obi_memory_pkg:: (replace with the empty string).

[datum-dpoulin]

Sounds good @MikeOpenHWGroup. I'll try and get this in tomorrow along with the script changes

[datum-dpoulin]

FYI @MikeOpenHWGroup, it'll be easier for me to create a new branch for this and copy the new obi agent over. That's because I obliterated the old one in my current branch.

[datum-dpoulin]

Hi @MikeOpenHWGroup, I've created a new branch, and committed the modified OBI Agent, its self-testing env and tb, as well as the modified dvm.py script.

[MikeOpenHWGroup]

@datum-dpoulin, how much of a PITA would it be to re-generate this so that all the prefixes where obi_memory_* instead of obi_*? I have a branch on my fork in which I scripted the changes locally. It compiles and runs but I don't trust my regexs.

I'd like to do this because (at least for now), I'd like to have the existing obi_agent (which drives ISA FCOV) and your obi_memory co-existing. The goal would be to replace the existing obi_agent, but not until the obi_memory is stable and fully integrated.

[datum-dpoulin]

It's one command in Eclipse SVE to rename that agent. I'll take care of it tomorrow and ping you once it's checked it.

[datum-dpoulin]

I've renamed the agent to obi_memory (the self-test env and TB keep the same names). ST TB passes for 2020.3.

All files checked in.

[datum-dpoulin]

@MikeOpenHWGroup what are the next steps? We still need to write a virtual sequence to duplicate the behavior of the peripherals and different memories (based around uvma_obi_memory_storage_slv_seq_c). Has the OBI agent been tested in other simulators than vivado?

[MikeOpenHWGroup]

@datum-dpoulin, next step is to integrate obi_memory into core-v-verif. I've started work on that in my merge_obi_mem branch on my cvv fork: https://github.com/MikeOpenHWGroup/core-v-verif/tree/merge_obi_mem. I've been doing this work under Metrics dsim and will also test it with Cadence Xcelium (xrun).

And yes, you are right, once a simple program works, the virtual peripherals need to be added before we can integrated obi_memory into any release branches of core-v-verif. If you have the cycles you can get started on that now. The required behavior is documented here and the current implementation is in mm_ram.sv.

[datum-dpoulin]

Ok, I'll get going on the virtual sequence. Any name you prefer? I was thinking uvme_cv32e40p_mem_slv_vseq_c

[MikeOpenHWGroup]

Any name you prefer? I was thinking uvme_cv32e40p_mem_slv_vseq_c

It could be useful if the seqence had a name that provided a hint that it implements the virtual peripherals. Also, these will be used by all "E-cores" so no need to include cv32e40p in the name. Maybe something like uvmt_obi_mem_vp_vseq_c.

[datum-dpoulin]

First cut of the new virtual sequences implementing dp_ram.sv and mm_ram.sv for cv32e40p has been issued a pull request: https://github.com/MikeOpenHWGroup/core-v-verif/pull/3

[silabs-robin]

@MikeOpenHWGroup Isn't this done?

[MikeOpenHWGroup]

@MikeOpenHWGroup Isn't this done?

Wow, yes it is. This one should have been closed in 2021. Slipped through the cracks. Good catch, thanks.