OSVVM 2022.11 Release
As I was writing the blog about the 2022.10 Multiple Verification Component example, my focus was drawn to the issue, “How do I call transactions that iterate across an array of verification components?” Solving this issue became the main goal of the 2022.11 release.
The 2022.11 release includes:
- Updated Multiple Verification Component Test Example
- Created AddressBus and Stream transactions that support indexing arrays of verification components
- Defined array types for transactions: AddressBusRecArrayType and StreamRecArrayType
- Moved the InterruptHandler example to OsvvmLibraries/Common/TbInterrupt
- Added InterruptHandler user guide to the documentation repository
- Scripts now generate Scoreboard reports for user defined scoreboards
- Scripts: TestName deprecates TestCase – coordinates with SetTestName
- Updated default search to PRIVATE_NAME for Scoreboard / FIFO, Coverage, and Memory data structures
How to Call Transactions that Iterate across an Array of VC?
When we have multiple of the same VC in a simulation, if the transaction dispatching is done from a single process, then it is natural to try index the transaction record in the call, as shown below in SendAsync (commented out with ‘–!!’ as a notation to indicate it is illegal).
------------------------------------------------------------
CentralTestProc : process
------------------------------------------------------------
begin
wait for 0 ns ; wait for 0 ns ;
for i in 1 to 16 loop
--!! SendAsync(UartTxRec(i), to_slv(i, 8), "000") ; -- illegal in VHDL
end loop ;
. . .
The issue is that for signal parameters of subprograms, VHDL requires a static signal name. Here the index makes the signal name not static. Details of this issue and fixing it in VHDL is discussed in IEEE issue 275.
While I am committed to making sure Issue 275 gets fixed, what do we do for now?
Created AddressBus and Stream transactions that support indexing arrays of verification components
For VC that use OSVVM’s Model Independent Transactions, OSVVM has provided a general solution – support array versions of the MIT transactions packages – StreamTransactionArrayPkg and AddressBusTransactionArrayPkg. These packages pass the array of transaction records and the index value as separate parameters as shown below for SendAsync. This example is from TbUart_SingleProcessLoop_1.vhd in the directory OsvvmLibraries/UART/testbench_multiple_uarts.
------------------------------------------------------------
CentralTestProc : process
------------------------------------------------------------
begin
wait for 0 ns ; wait for 0 ns ;
for i in 1 to 16 loop
SendAsync(UartTxRec, i, to_slv(i, 8), "000") ;
end loop ;
. . .
Generally, I avoid this situation by using separate processes. Using separate processes to dispatch transactions makes constrained random tests easier to write. An example of this is shown in TbUart_MultipleProcess_1.vhd.
While we could actually create 16 separate processes for TX and 16 for RX, this example uses ‘for generate’. ‘For generate’ is legal since its indices are globally static – which in turn allows the signal to be a static signal name.
Defined array types for transactions: AddressBusRecArrayType and StreamRecArrayType
In order to define transactions for arrays of records, the array type StreamRecArrayType was added to StreamTransactionPkg and the array type AddressBusRecArrayType was added to AddressBusTransactionPkg. Their declarations are shown below.
-- In StreamTransactionPkg.vhd type StreamRecArrayType is array (integer range <>) of StreamRecType ; -- In AddressBusTransactionPkg.vhd type AddressBusRecArrayType is array (integer range <>) of AddressBusRecType ;
<
InterruptHandler
The testbench and test cases for the InterruptHandler example were moved to OsvvmLibraries/Common/TbInterrupt. In addition an Interrupt Handler user guide was added to the documentation repository.
Scripts now generate Scoreboard reports for user defined scoreboards
To generate Scoreboard reports for user defined scoreboards, you must write out a YAML report using WriteScoreboardYaml. If other scoreboard packages were made visible, then WriteScoreboardYaml must be called with a selected name as shown below.
work.ScoreboardPkg_Uart.WriteScoreboardYaml(
FileName => GetTestName & "_sb_Uart.yml" ) ;
In addition, for the scripts to convert the YAML report to HTML (in the test case report), the naming pattern must be exactly as above:
Scripts: TestName deprecates TestCase
Historically we used ‘SetAlertLogName’ to set the name of the AlertLog data structure. When reports were added, this became the way to set the test case name. Long term, the name ‘SetAlertLogName’ no longer made sense. So ‘SetTestName’ was added and ‘SetAlertLogName’ was deprecated. SetAlertLogName will be maintained as an alias so no updates to older testbenches is needed.
With the addition of ‘SetTestName’, the script name ‘TestCase’ was changed to ‘TestName’ to better align the naming. Note that ‘TestCase’ now is simply a procedure that calls ‘TestName’ and will be maintained so older scripts do not need to be updated.
Updated default search to PRIVATE_NAME for Scoreboard / FIFO, Coverage, and Memory data structures
An OSVVM Memory data structure has the ability to share its data structure with another instance / usage of a memory data structure. One application of this capability is in ZYNQ where multiple AXI4 subordinate interfaces share the same memory space.
OSVVM allocates a memory model using a call to NewID as shown below. Here in the Search parameter we specified, search by NAME. As a result, any usage of a Memory that also calls NewID with the name “Axi4Memory” and the Search parameter of NAME will share the same memory space.
signal MemoryID : MemoryIDType ;
. . .
Initialize : process
begin
MemoryID <= NewID(
Name => "Axi4Memory",
AddrWidth => AXI_ADDR_WIDTH, -- Address is byte address
DataWidth => 8, -- Memory is byte oriented
Search => NAME
) ;
. . .
Scoreboards, FIFOs, and Coverage models have this same sort of search capability.
When this feature was added (2022.02), we wanted to make sharing easy, so we created a default sharing of NAME_AND_PARENT_ELSE_PRIVATE. When a parent ID was specified, this resulted in sharing only if both the NAME and the PARENT AlertLogID matched. Unfortunately when iterating across components in VHDL, the lowest level of the instance names matched (they differ at the next level up).
Within a ‘for generate’, this resulted in sharing of data structures when it was not intended. In addition, it happens too easily. As a result, with 2022.11, the sharing default for the Scoreboard/FIFO, Coverage, and Memory data structures was changed to PRIVATE_NAME, which means never share the data structure.