OSVVM 2020.08 New user experience
September 18, 2020 at 21:08 #1709
Hi I just created my very first OSVVM test bench based on the example.
It was with release 2020.08.
Here are my experience/questions, mostly about the newly released AXI4 models:
1. Could the test bench be stopped gracefully by stopping all clocks?
I don’t feel like the idea of using assertion or std.env.stop to end the simulation.
Stopping the clock would let simulator see “no more events”.
The AXI responder was not very friendly to a stopped clock. It’s calling procedure DoAxiReadyHandshake which will throw out a time out error. I had to comment out the time out part to make the SIM end gracefully.
2. The AXI4 master procedure GetWriteBurstData() assumes byte-wise narrow burst.
The example test bench broke as soon as I changed the data width and pushed data wider than 8-bits to WriteBurstFifo from the master process.
The narrow burst was nice but I had to comment out to make it work with a wider data bus.
3. Looks like the AXI responder is still AXI-Lite only as of r2020.08?
Write burst is working but read burst is broke. It sent out the first read data then stopped there, waiting for a new address. It is assuming # of address must equal to # of data.
Luckily the AXI memory is functional for read burst. I got around by not using the AXI responder model.
4. Typo? AxRegion is 4 bits only per AXI4 standard. It was defined 8 bits in Axi4InterfacePkg.
I had to change the width to make it compile.September 18, 2020 at 23:54 #1710
First, thanks for the feedback.
Are you using this with a particular design?
You have four questions, so I will give 4 separate answers.
JimSeptember 19, 2020 at 00:06 #1711
4. Typo! You are correct, AxRegion should be 4 bits. I will fix that
in the next release. Anything else like that is an issue?
What do you mean you had to change the width to make it compile? Is this to
connect it to your design? It compiles and runs fine with the OSVVM models
which all use the same incorrectly sized AwRegion/ArRegion.
In general, as an example of how to handle a situation like this, take a
look at Axi4/testbench/TbAxi4.vhd. Any composite interface can be mapped
element by element – provided all the elements are mapped and that once you
start mapping an array element that you finish mapping all of it. In this
case, that means that if you did not (or could not modify the other code)
you could connect a 4 bit “dummy” signal to the unused bits of AwRegion/ArRegion.
Based on the example from TbAxi4.vhd, if you run into a problem like this
with other models (and you don’t have access to edit them), you can do the
Axi4Minion_1 : Axi4Responder port map ( -- Globals Clk => Clk, nReset => nReset, -- Testbench Transaction Interface TransRec => AxiMinionTransRec, -- AXI Master Functional Interface AxiBus.WriteAddress.Addr => AWAddr , AxiBus.WriteAddress.Prot => AWProt , AxiBus.WriteAddress.Valid => AWValid , AxiBus.WriteAddress.Ready => AWReady , AxiBus.WriteAddress.ID => AWID , AxiBus.WriteAddress.Len => AWLen , AxiBus.WriteAddress.Size => AWSize , AxiBus.WriteAddress.Burst => AWBurst , AxiBus.WriteAddress.Lock => AWLock , AxiBus.WriteAddress.Cache => AWCache , AxiBus.WriteAddress.QOS => AWQOS , AxiBus.WriteAddress.Region(7 downto 4) => ErrorAwRegion(3 downto 0), -- the erroneous piece AxiBus.WriteAddress.Region(3 downto 0) => AWRegion, -- the correct piece AxiBus.WriteAddress.User => AWUser ,
Thanks again for catching this. I have already edited my private
dev branch. Will push it to the github dev branch as soon as I
test it.September 19, 2020 at 00:30 #1712
2. The test sequencer interface to AXI verification component burst FIFO is 8 bits. The AXI verification component assembling this into the size of the data bus. So you will always push bytes into the FIFO – even if you make the data bus bigger or smaller. It was tested with a 32 bit AXI data bus, however, it is intended to work with any legal AXI width data bus.
It was not tested with a 64 bit interface. What width are you using?
Can you send me a test case – my email address jim at synthworks.com.September 19, 2020 at 00:33 #1713
3. Correct. The 2020.08 Axi4Responder_Transactor.vhd is intended to be a register access model and does not support bursting. As you noted, Axi4Memory.vhd, implements memory models and does support bursting. This is noted in the README.md at: https://github.com/osvvm/AXI4.
Do you need a transactor that supports bursting? It is on my long term goals – but there are numerous things ahead of it.September 19, 2020 at 01:18 #1714
>1. Could the test bench be stopped gracefully by stopping all clocks?
Do you have a method to gracefully stop clocks? Everything I have seen
has overhead incurred at least once per clock cycle (or some multiple of
the clock cycle).
OTOH, I really like std.env.stop. It only incurs overhead when
it is actually stopping the testbench. Going further, it allows you to
return a value to the calling script by doing:
The one you are looking at is there because, in general,
verification models should not hang. Hence, wait statements
must have provisions for time out clauses in them.
OTOH, Axi Ready is a special case, often it does not need a
timeout. This is certainly true in the responder for
WriteAddress, WriteData, and ReadAddress, however, in the
master/initiator WriteResponse and ReadData both require
Hence, for AXI the overhead on DoAxiReadyHandshake could be avoided
by having two separate versions, however, I would need significant
convincing that clock stopping would remain a viable methodology
in large scale testbenches – consider that there can be a multitude
of clocks to stop.September 19, 2020 at 07:01 #1715
Thanks for the quick response.
#2 – Some learning experience here.
I started the journey by studying the example test bench TbAxi4_BasicBurst.
The example went broken as soon as I changed AXI_DATA_WIDTH to a wider one in TbAxi4.
Looking back, it was probably the test cases.
But at that time I did not realized that the test was doing narrow burst.
I attempted to fix the problem by WriteBurstFifo.Push() wider data in AxiSuperProc.
That change immediately throw out some size mismatch error in procedure GetWriteBurstData().
My use case did not really require narrow burst so I commented out the feature in the end:
aWriteStrb := (others => ‘1’) ;
aWriteData := WriteBurstFifo.Pop ; –Note data sized AXI_DATA_WIDTH was pushed
IMHO, address aligned, full-width burst might be more appropriate for a “Basic” burst example.
The narrow burst can be in an “advanced” burst example.September 19, 2020 at 07:36 #1716
#1 – If stopping the simulation with assertion or std.env.stop, it was not a “real” stop.
Hitting the “run all” button in the simulator would let the test bench continue to run endlessly.
Personally I don’t feel like this behavior.
Stopping the clock is the true end. When the simulator stops, there is nothing more to simulate.
Hitting the “run all” button would not do anything.
Modelsim simply stops.
Aldec is even nicer by printing a message saying “no more events”.
I have an enable signal for the clock process. The test process disable the clock in the end.
The AXI responder was not friendly to this approach of stopping the simulation.September 19, 2020 at 07:59 #1717
#1 I use “run all” to run my tests. Std.env.stop will stop the test. However, stop works much like a breakpoint, so the simulation can be continued. I am ok with this.
If you wanted to prohibit the testbench from running further after it stops, use std.env.finish instead. It also allows an integer parameter, so you can call it as:
std.env.finish(GetAlertCount) ;September 19, 2020 at 08:15 #1718
#2 Did you run the testbench examples before modifying them? The test TbAxi4_MemoryBurst (which runs when you do
build ../OsvvmLibraries/AXI4/Axi4/testbench) does bursts. The first burst in the test is 3 32 bit words – IE 12 bytes and the address is word aligned.
What is 1 wider? Did you mean 64 bits? AXI data supports a power of 2 bytes in a transfer (ie: 1, 2, 4, 8, 16, …).
I am not sure what you mean by narrow transfers. At the end of TbAxi4_MemoryBurst, oddly small bursts are being tested. This is not meant to demonstrate how to do bursts – instead it is intended to verify that the model supports small bursts – as it is required to do.
- You must be logged in to reply to this topic.