Jim Lewis

[Jim Lewis]

I have pushed the updated code to the main branch now.

[Jim Lewis]

Hi Michael,
Unfortunately this impacts all OSVVM VC. So the same change is needed for the UartTx.

Are you using sources from OSVVM.org or GitHub? I have updated the GitHub dev branch. I will update the main branch tomorrow. If you are using sources from OSVVM.org, I will update them too, otherwise, they will be updated when 2022.05 is released.

With the addition of the MODEL_ID_NAME, the recommended practice will be:

UART_VC_gen : for i in 0 to 20 generate
  UART_RXD : UartRx
  generic map (
     MODEL_ID_NAME   => "UartRx_" & to_string(i),
     DEFAULT_BAUD    => UART_BAUD_PERIOD_115200
  )
  port map (
    TransRec     => Uart_rec(i),
    SerialDataIn => serial_data_tx(i)
  );
end generate UART_VC_gen;

I did not actually test the above code, but I did test similar code that is in OsvvmLibraries/AXI4/Axi4/testbench_MultipleMemory/TbAxi4_MultipleMemory_Generate.vhd
Again this test case is on the dev branch of the Axi4 libraries.

Regards,
Jim

[Jim Lewis]

Hi Michael,
Thanks for the long winded question – it gives me the information I need.

It looks like the instance name is the same for all instances of the UART.
As a result statement that constructs the ReceiveFifo is connecting them all
together. Currently this:

ReceiveFifo <= NewID("ReceiveFifo", ID, ReportMode => DISABLED) ;

It is just an OSVVM oversight and easy to fix. Changing it to the following and your generate loop should be ok.
ReceiveFifo <= NewID("ReceiveFifo", ID, ReportMode => DISABLED, Search => PRIVATE) ;

If the VC really do have the instance label, then they will also have the same AlertLogID.
In the AXI VC, there is a generic that allows this to be set and the string value of the
generate index can be appended to the name. I should have an official fix shortly.

I will need to simulate it first before I am able to push it though.

Best Regards,
Jim

[Jim Lewis]

Hi Steve,
Thanks for the update. I have plans to test with Xcelium 22.03 soon.
Looking forward to seeing the results.

I will ask them about providing all of the libraries. OTOH, OSVVM has
been doing releases a little more frequently at the moment. So it is
hard for them to have the latest libraries. Like seeing that they
updated to 2022.01.

Best Regards,
Jim

[Jim Lewis]

Hi Antonio,
You will need their latest service pack for VCS. I think there was one in October. The hot-fixes they were providing me for testing did not get integrated until shortly after the 2021.09 release.

Best Regards,
Jim

[Jim Lewis]

Hi Michael,
One thing you can do is in your verification component create a setting that controls whether PRBS is to be inverted or not. Then use SetModelOptions to change the settings. For AxiStream we have numerous settings and use an abstraction layer on top of SetModelOptions called SetAxiStreamOptions. For AxiStream the abstraction layer is created in the package AxiStreamOptionsPkg.vhd.

You can make it so the actions take place immediately or they can take place in conjunction with an action on your DeviceBus.

Best Regards,
Jim

[Jim Lewis]

Please see GetRandPoint (its new name) in RandomPkg User Guide. There are also examples there.

Best Regards,
Jim

[Jim Lewis]

Hi Cols and Nico,
This brings up a bigger question, “how do we debug our simulations when something like this happens?”

First observe the time at which something happens. Look at what transactions were running before that time.

If our simulator supports interactive debugging such as single step and/or breakpoint, then the following may help you find the root cause:
* Run the simulation until it fails and single step beyond the failure point to find which call caused the failure.
* Run until a time value just before the failure happens. If your simulator supports breakpoints, it may be helpful to set them on the transactions that ran just before the time of failure. Single step until the test fails. You can single step over many calls. First we are looking for the call that causes the failure. Once we identify the call, we can step into it as necessary.

If our simulator does not support interactive debugging (such as GHDL), you can probably find this problem doing code analysis. In your editor, find all uses of the transaction record for the first VC. Are any of them outside of a single process? Now do the same for the other transaction record.

Again, if you can share your code with me, I can help you identify the problem.

Best Regards,
Jim

[Jim Lewis]

Hi Cols and Nico,
Did you look at TbAxi4_Shared1.vhd? Each instance of the VC needs to have its own record. See TestCtrl_e.vhd in the same directory.

Send me an email with your TestCtrl in it. It would probably be good to see your test harness also.

Best Regards,
Jim

[Jim Lewis]

Hi Gianico,
Each AxiStreamReceiver needs its own transaction record. In the OSVVM testcases, we are using a single record named StreamRxRec. You need separate ones, such as StreamRx1Rec and StreamRx2Rec.

There is an example of this done with the Axi4 interface. See directory OsvvmLibraries/AXI4/Axi4/testbench_MultipleMemory. In there see the test case TbAxi4_Shared1.vhd which uses Manager1Rec and Manager2Rec. The test harness, TbAxi4_MultipleMemory.vhd, also uses the same names.

The whole purpose of the multiple driver error message is that when you cut and paste pieces of code in this environment, it is easy to forget to use the transaction record that corresponds to the process that drives it.

Generally speaking then, a given record only driven by a single process. We have a methodology to allow that to stop driving a record in one process so another process can drive it, but that is not the case you are looking at.

Best Regards,
Jim

[Jim Lewis]

First, you are using the older, protected type based API. You might want to consider using the newer, singleton based API – it is simpler and does not require the test writer to use protected types (they are hidden internal to the singleton).

If you look at the document, OsvvmLibraries/Documentation/CoveragePkg_user_guide.pdf, you will find GenBin discussed in sections 6.4 and 12.2. Note that these examples are for the newer, singleton based API. For the older, protected type based API, see the documentation in OsvvmLibraries/Documentation/ProtectedType_the_old_way/CovereagePkg_user_guide.pdf.

6.4 Model Coverage: Item Coverage
Internal to the data structure, each bin in an item coverage model is represented by a minimum and maximum value (effectively a range). Bins that have only a single value, such as 1 are represented by the pair 1, 1 (meaning 1 to 1). Internally, the minimum and maximum values are stored in a record with other bin information.
The coverage items are added to the coverage model by using the procedure AddBins and the function GenBin. GenBin transforms a bin descriptor into a set of bins. AddBins inserts these bins into the coverage data structure. The version of GenBin shown below has three parameters: min value, max value, and number of bins. The call, GenBin(1,3,3), breaks the range 1 to 3 into the 3 separate bins with ranges 1 to 1, 2 to 2, 3 to 3.

TestProc : process
begin
  --                    min, max, #bins
  AddBins(Cov1, GenBin(1,   3,   3)); -- bins 1 to 1, 2 to 2, 3 to 3
  . . . 

Additional calls to AddBins appends bins to the data structure. As a result, the call, GenBin(4, 252, 2), appends two bins with the ranges 4 to 127 and 128 to 252 respectively to the coverage model.
AddBins(Cov1, GenBin( 4, 252, 2)) ; -- bins 4 to 127 and 128 to 252

Since creating one bin for each value within a range is common, there is also a version of GenBin that has two parameters: min value and max value which creates one bin per value. As a result, the call GenBin(253, 255) appends three bins with the ranges 253 to 253, 254 to 254, and 255 to 255.

AddBins(Cov1, GenBin(253, 255)) ; -- bins 253, 254, 255

You will also find more detail in the GenBin section:
12.2 Creating Count Bins – GenBin
The following are three variations of GenBin. The ones with AtLeast and Weight parameters are mainly intended to for use with constants.

  function GenBin(Min, Max, NumBin : integer ) return CovBinType ;
  function GenBin(Min, Max : integer) return CovBinType ;
  function GenBin(A : integer) return CovBinType ;

The version of GenBin shown below has three parameters: min value, max value, and number of bins. The call, GenBin(1, 3, 3), breaks the range 1 to 3 into the 3 separate bins with ranges1 to 1, 2 to 2, 3 to 3.

    --                    min, max, #bins
    AddBins(CovBin1, GenBin(1,   3,   3)); -- bins 1 to 1, 2 to 2, 3 to 3

If there are less values (between max and min) than bins, then only “max – min + 1” bins will be created. As a result, the call GenBin(1,3,20), will still create the three bins: 1 to 1, 2 to 2 and 3 to 3.
AddBins(CovBin2, GenBin(1, 3, 20) ) ; -- bins 1 to 1, 2 to 2, and 3 to 3
If there are more values (between max and min) than bins and the range does not divide evenly among bins, then each bin with have on average (max – min + 1)/bins. Later bins will have one more value than earlier bins. The exact formula used is (number of values remaining)/(number of bins remaining). As a result, the call GenBin(1, 14, 4) creates four bins with ranges 1 to 3, 4 to 6, 7 to 10, and 11 to 14.
AddBins(CovBin2, GenBin(1, 14, 4) ) ; -- 1 to 3, 4 to 6, 7 to 10, 11 to 14
Since creating one bin per value in the range is common, there is also a version of GenBin that has two parameters: min value and max value which creates one bin per value. As a result, the first call to AddBins/GenBin can be shortened to the following.

--                    min, max
AddBins(CovBin1, GenBin(1,   3));  -- bins 1 to 1, 2 to 2, and 3 to 3

GenBin can also be called with one parameter, the one value that is contained in the bin. Hence the call, GenBin(5) creates a single bin with the range 5 to 5. The following two calls are equivalent.

AddBins(CovBin3, GenBin(5) ) ;
AddBins(CovBin2, GenBin(5,5,1) ) ;  -- equivalent call

[Jim Lewis]

I try to user either a Verification Component or a Monitor to provide an abstraction layer for all interactions with the DUT.

If there need to be exceptions to this, then you can use external names in TestCtrl to access items from the DUT. To make this feasible, when creating the test harness (top level netlist that connects DUT, VC, and TestCtrl) make sure to instance the DUT first and TestCtrl last.

To use external names, the language a referenced item must already be elaborated. VHDL elaboration of the test harness is top to bottom. The order of instances in the test harness then allows TestCtrl to access signals in the test harness, the DUT or any VC.

The VTI testbenches use external names to access the record. You can see an example there of how to use external names if you have not used them before. See https://github.com/OSVVM/AXI4/blob/fd86f4a797b60f12fbf80c506c8239968eb8a1fb/Axi4/testbenchVti/TestCtrl_e.vhd or if you have the files locally: OsvvmLibraries/AXI4/Axi4/testbenchVti/TestCtrl_e.vhd

[Jim Lewis]

Hi Nico,
We don’t currently have anything to read that format, however, if I understood it right, it does not look too difficult to read.

What you want too look at with this sort of thing is how does the system interact with the image. For example, does the system receive the image via an AXI Stream interface? In this case you can have the file reader in your test code and then pass that as a burst transaction to the interface. The AXI stream burst interface uses a FIFO and data can read and then immediately be pushed into the FIFO.

If you need more help, I would need to know more details of the system.

Best Regards,
Jim

[Jim Lewis]

You should be able to use OSVVM with any QuestaSim version. If you are using 10.5 or beyond, there are no known issues.

Which version are you using? Are you having any problems? Have you run the OSVVM test suite and experienced any problems with QuestaSim?

I test with QuestaSim 2020.04. I have noticed some irregularities with some QuestaSim versions, but it is not related to OSVVM and there is nothing in OSVVM I could change to work around the irregularities.

The issues I have seen seem to have to do with QuestaSim treating an impure function call as pure, and hence, optimizing it by calling the function only once, rather than each time in an iteration. The solution is generally simple too. Assign the output of the impure function call to a variable and then use that variable instead of the function call and all is well.

If you are running into issues with specific code, I would be happy to look at it. I am pretty good at finding root cause and getting a work around.

The issues also tend to be unstable. In 2021.09, I changed some of the UART testbench code so it did not cause problems for QuestaSim, but did not have to change all of the testbenches and several of them had code identical to the code that caused the issue.

I have offered Siemens to use the OSVVM test suite in their regressions (it is open source) and have also offered our private test suite for the utility library.

[Jim Lewis]

Hi Steve,
I am just getting back to testing Cadence. Need to test with their Agile release. I think that may be a different release channel than normal, so I am trying to work through it.

Best Regards,
Jim

[Author]

Posts