hello,
In reply to N Raghava :
Spec is “The SPARC Architecture Manual, Version 8” published by Prentice Hall.
Having verified many processors, including SPARC processors, at the top level,
we always had a C reference model (known to be correct). Instructions are run through
the processor RTL and the C reference model, and comparisons are made in architecturally
visible state - ie all the registers in the spec and external memory.
In UVM, instructions can be delivered to the processor via UVM transactions on the memory bus
The instruction data would all be defined as fields in the data payload of the transaction,
based on the spec.
The instruction bus monitor will need to access the C reference model using the SV DPI
interface, which would feed instructions to the C model AND have to provide visibility
to all the state being compared. The monitor would place the C model’s state in the scoreboard
and also the RTL state in the scoreboard and compare.
We always used directed tests, BUT constrained random do have a place. However there is a fine
line on where it becomes easier to write a directed test than attempt to prevent illegal
instruction sequences and through constrained random testing. Also the design most likely
will be pipelined so many multicycle sequences need to be touched upon for good coverage
Hope this helps
Joan Pendleton
Thanks for your answer, Joan. The processor in reality fetches instructions from the PC pointer in memory. Are you saying that you have a UVM driver that overrides this instruction data normally being fetched from program memory?
I developed UVC’s for audio protocols such as I2S which worked well at block level. Our digital team tried to figure out how to leverage block-level when simulating at chip-level with the DSP. The main problem was how to convert Amba (AHB) config programming into DSP machine language or assembly, rather than using the much slower SPI interface. (At chip-level there is no direct interface to Amba.) We had an idea that might have worked, but it was convoluted. Basically, it involved monitoring the old UVM Amba interface and generating RMH data files. These RMH data files would then be read into memory during chip-level simulation with a readmemh. Then there were usually some additional chip-level configuration needed. Instead, we just wrote our own assembly code for each chip-level testcase (all directed tests). There was still constrained randomization of the I2S data and config, but at chip-level there was no constrained randomization used in the DSP assembly code.
I think you could set up a UVM agent to behave as the program memory in your system. When the CPU fetches an instruction, the slave sequence can return the instruction as a bus transaction. That way you can set up the sequence to create the instruction stream. Note that in this case, it’s probably easier to use the SystemVerilog randcase instruction rather than full constrained-random for generating instruction sequences. That’s actually kind of what randcase was designed for.
You could also use inFact in Questa to specify your instruction stream via a graph and have that run as the slave sequence.
Good luck,
-Tom
Hi All :
This thread is very helpful. I was wondering if there are any good papers in this area, or any recommendation/challenge here ? I have read Mentor Graphic J chan’s paper regarding using OVM to model ISG.
Thanks in advance
In reply to tfitz:
Agreed - replace the instruction memory (that is outside the SPARC DUT) with a UVM agent that drives the instructions to the SPARC DUT.
Also agree on randcase for instruction generation.
NOTE: There will be many sequences of instructions that are illegal if one just lets each instructions be randomized without paying attention to instructions before and after. This is the equivalent of hangs in lab debug (very annoying) typically after a jump/branch to a bad place (ie random/bad offset) And also instruction sequences are needed to test all the pipelining corner cases. This intelligent instruction sequence generation could be done with a series of start_item/finish_item pairs in a single begin/end block in the uvm_sequence_item (the transaction)
This would be my recommendation for forwarding tests, conditional branching tests, trap detection testing, possibly many more scenarios that typically have repetitive sequneces of instructions to exercise the processor. Jumps to various addresses (ie trap and branch targets) will probably need to be recognized and provide intelligent instruction sequences at the targets or all sorts of chaos will break loose (equivalent to hangs in the lab)
Basically, tests will probably end up being a combination of directed instructions with randomized operands,
and some segments of randomized opcodes (ie segments without jumps, branches, traps (all the control transfers)
I have not looked for any papers, so i don’t know if there are any. I have just verified a lot of processors
(SPARC, MIPS, Alpha, Java, Smalltalk, Prologue…) that worked on 1st Si…
Joan Pendleton
PS Actually, thinking about it some more, the control transfers (ie jumps, branches, traps, etc) can avoid going to bad targets by NOT using the target addresses to generate next instruction, BUT INSTEAD, monitor and check the target addresses (basically the target addresses are “results” of the control transfer instructions and get checked just like other results. Then continue feeding the correct/desired instructions into the SPARC DUT. i think this would be an easier and more predictable way to test the control transfer instructions
In reply to pendleton:
Thanks for your answer, pendleton.
Thanks for your answer, Tom Fitzpatrick. I watched your videos it is very helpful.
I’m doing project on “Verification IP for SPARC V8” as apart of Masters in VLSI Design also I’m new to verification.
Would you specify some common rules/guidelines for Verification IP development.
Since i don’t have full accesses to some materials in this blog, since I don’t have a business/corporate mail id.
Hi All
This thread is real useful.
I would be definitely interested ,
-BR
Hash
In reply to pendleton:
Thank you very much Joan Pendleton …
Would you elaborate how to model a C reference for RTL, If possible please mention some examples?
What about the SPARC processor do i get ready made C reference model?
Hello ,
I am working in SPARC V8 (LEON) processor using assertion based method
I want to verify the ISA part
plz provide some suggestion