I want to design a scoreboard for self-checking the DUT during verification. The DUT is responsible for being able to write messages()32 bit number) throuwh write interface into memory and providing data via APB interface when appropriate APB read transaction is made. Multiple write transactions can occur and all messages are stored in FIFO memory before reading data.
I am designing a scoreboard which records the message (a 32 bit number) when appropriate handshaking signals are found, and it verifies that correct data has been seen when a read transaction occurs.
My question is what would be the best way to store this data? I am not expecting this database to be stored after test. I am new to verification world and system verilog so any help would be appreciated.
I provide in my SVA Handbook , from the dictionary of assertions chapter, two solutions with regards to this type of problems. The key is to use associative arrays or queues with assertions (or tasks)
I providing the pages from my book that addresses these issues.
See
10.15 Data Integrity in memory: data read from memory should be same as what
was last written
Given a large memory (or a port), the following properties must be verified: * Data should never be read before it is first written; thus only valid data must be read. * Data read from the memory is what was last written into it.
10.16 Data integrity in queues. interface data written must be properly transferred
to the receiving hardware
The data received from an interface (with wr_33 control) must be properly transferred to the
receiving hardware (with rd_25 control). The data is sourced at a 33 MHz rate and is extracted at
a 25 MHz rate. The data extracted by the receiver (rdata) is in the same order that it was
transmitted. The following figure shows a block diagram of the verification environment and the timing diagram for the interface.
For the use of tasks in (or instead of) assertions, see my paper https://verificationacademy.com/forums/systemverilog/paper-understanding-sva-engine-simple-alternate-solutions
Abstract: Understanding the engine behind SVA provides not only a better appreciation and limitations of SVA, but in some situations provide features that cannot be simply implemented with the current definition of SVA. This paper first explains, by example, how a relatively simple assertion example can be written without SVA with the use of SystemVerilog tasks; this provides the basis for understanding the concepts of multithreading and exit of threads upon a condition, such as an error in the assertion. The paper then provides examples that uses computational variables within threads; those variables can cause, in some cases, errors in SVA. The strictly emulation model with tasks solves this issue.
Ben Cohen http://www.systemverilog.us/ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr