Register modeling for a processor based design architecture using UVM RAL

[pradeey]

Hi,

I would like to have a test bench architecture wherein the register RAL sequence would trigger the configuration reads and writes to the processor within the design.

My approach is that the RAL sequence triggers the sequencer set through set_sequencer call of register map. After the uvm_reg_adapter converts into a sequence item & the sequencer drives it to driver, we placed an API call through which the driver puts SV signature, address & write data into the C memory model.

We later wrote a small ASM code which triggers the processor to fetch the address and write data from C memory model locations once it sees the SV signature. Once write is completed, ASM code will overwrite SV signature with ASM signatures which triggers back the SV enviroment to proceed with the next register transaction. (in short, I used a mailbox sort of mechanism after the transaction is triggered by RAL sequence)

The disadvantage with this approach is that the no of cycles processor takes to complete one write or read is high as it has to continuously monitor the signature, later fetching the address and write data and only later it will perform the write - which means it took a relatively large no of cycles..

Is there any smarter or efficient way of handling these type of design architectures?? Please suggest. Eagerly waiting for a response. Thanks in advance.

Cheers,

Pradeep

The disadvantage with this approach

[Logger]

We do this as well. The advantages are that our processor has multiple bus interfaces, so this one mechanism allows us to generate activity on all of them. It also guarantees that we produce accurate bus cycle activity. As you say, the overhead slows things down greatly. The only solution for that is to bypass the RTL processor model, replacing it with BFMs. There is more than one way to do that.

First, you can just remove the RTL processor model all together and insert all the necessary BFMs to replace it. A LOT of people do it this way.

Depending on your processor you might be able find a 3rd party model from Mentor or Carbon Design Systems that provides a processor model that can run C code as well as has a back door that allows your SV testbench to directly manipulate the busses.

We are using a hybrid approach. We retain the RTL processor model and have a bus model on one of the busses, our main register bus. If the address range being accesses is mapped to that bus, our driver uses forces to directly drive the bus. Otherwise, it forwards the bus request on to the C code running on the processor the same way you do.

Some care has to be taken with that hybrid approach. The processor may try to use the bus at the same time as our driver. So we force some of the control and status signals on the processor in order to prevent it from executing an access on that bus. The effect of this is the processor will stall if it tries to access that bus while we are forcing it. However, if the processor is using any of the other busses, it is free to do so. Best of both.

-Ryan

[pradeey]

Hi Ryan,

Thanks for your response. But my intention is to verify the core in the processor and so I cannot replace it with a fake or bfm model. Any other ideas to trigger the core stimulus (register reads and writes) from SV environment other than the mentioned conventional mailbox mechanism (to communicate between SV and ASM)?

Thanks in advance,

Pradeep

[Logger]

my intention is to verify the core in the processor

Well that begs some other questions. What is the level of verification of this CPU before integration? Is it a heavily verified purchased core? Or is it a custom core you developed?

Processors are complicated things, they deserve a testbench in their own right. Are you just performing integration testing, where you want to also get some additional CPU validation? Or are you attempting to forgo having a block level testbench around your CPU?

-Ryan