After consuming the contents of an earlier post [2], UVM Hello World, the engineer is now capable of generating stimuli from a UVM test bench to a design under verification (DUV / DUT), his / her manager wants to put this investment to good use by asking him / her to exercise a specific design - an APB slave.
And then the manager gives the engineer three things:
- The DUV / DUT from [1];
- A piece of legacy test bench source code from [1] or what is commonly known in pre-silicon engineering as verification intelectual property (VIP); and
- A protocol specification of ARM AMBA APB from [3].
Do you think this is sufficient input to accomplish the task at hand?
Before answering that question, let us proceed with what we will learn from this post.
You get to apply stimuli, which is what you learned from [2], to exercise a design and view it. Cool!
The design has an APB slave interface to it. That’s what we’ll use to make the test bench talk to the design and exercise its features.
A lot actually, but based on what your manager asked you to do, what we know is more than enough at least to get you started. First, let's tackle these two questions. What is an APB slave? And what should we expect the test bench to do with it?
This is the first design that we come across in this series of posts that isn't just a stub. And every design interacts with its environment using interface protocols. The DUV in this post uses APB - standard interface.
APB stands for Advanced Peripheral Bus, one of the earlier interface protocols ARM established with its AMBA library, which it uses to architect its processor cores [3]. APB is a low power bus protocol designed to cater to, as its name suggests, peripheral devices. These are the less demanding devices when it comes to performance.
Looking at the signals of the DUV, it has 7 inputs and 2 outputs. It has a PREADY, which is the reason why we are using [3] instead of earlier versions of the APB protocol. Note that in [3], the terms master and slave are referred to as requester and completer, respectively. Also, the prefix P is designated for APB signals in the AMBA protocol library.
| Signal Name | Source | Description |
|---|---|---|
| PCLK | System peripheral bus clock | synchronizes timing of all APB signals with its rising edge |
| PRESETn | System bus reset | active-low reset |
| PADDR | Requester | APB shared address |
| PSEL | Requester | indicates completer selection |
| PENABLE | Requester | indicates 2nd and subsequent transfer cycles |
| PWRITE | Requester | indicates the direction of the data transfer with respect to the requester |
| PWDATA | Requester | transfers data from requester to completer (may be byte, halfword, word long) |
| PRDATA | Completer | transfers data from completer to reqeuester (may be byte, halfword, word long) |
| PREADY | Completer | inserts wait states from completer |
The PREADY signal makes the APB bus transfer a 3-signal handshake instead of a 2-signal handshake with just PSEL and PENABLE as shown in the next section.
As the state diagram suggests, a transfer begins with the requester selecting the target completer device with PSEL = 1 and PENABLE = 0. This indicates transition into the SETUP state for one clock cycle. In the next cycle, the requester modifies PENABLE to 1 to enter the ACCESS state while holding PADDR, PWRITE and, in case of a write transfer, PWDATA unchanged. Finally, the completer signals completion by setting PREADY to 1. This sends the state machine either to IDLE or SETUP depending on whether the requester signals another transfer right after or not.
APB operating states - diagram courtesy of [3]
With just those few sentences, we already captured the essence of APB. And now, we are in a position to run the simulation to see what it does prior to deciding whether the stimuli it generates is the right one for the task or not. Only then can we decide how much of the stimuli generating components can be used as is and which ones require changes.
EDA Playground Example - APB UVM With Scoreboard _ by an unknown author https://www.edaplayground.com/x/ueMH
Note: The source code from [1] does not compile and run as is. That is the case for the Aldec Riviera Pro simulator. To be able to actually run the simulation, you will need to make a few changes.
These changes are for compilation purposes only and will not alter the behavior of the stimuli as discussed earlier. And since EDA Playground currently does not support integration with github or any similar repository management app, you will have to do this manually.
1. Start a web browser session of the [1] playground
1.a. Open a new web browser window for [1] playground
Right-click the link [1], and select "Open Link in New Window." This opens a new window containing [1].
Then, click the "Log in" button on the upper right of the web page as shown in the image below.
There are several options to log in to your account. If you do not wish to use a work or academic email account, you may either use your Google or Facebook account for a secure log in.
For instance, to log in with your google account. Click the "Google" link as shown in the image below.
This opens a secure sign-in dialog from Google to edaplayground.com as shown in the image below.
Select your Google account that you wish to sign in with from the list as shown below and log in.
Since EDA Playground opens an empty playground upon successful log in reopen [1].
Repeat 1.a. This time the session is already logged into your profile.
3. Modify the files to avoid compilation errors inherent with the [1] playground
Modify the testbench.sv file according to the changes from the source code diff of commit 664e098. Line 3.
Modify the driver_apbm.sv file according to the changes from the source code diff of commit 664e098. Line 26.
Modify the Scoreboard_apb.sv file according to the changes from the source code diff of commit 664e098. Lines 84-87, 91-93, 97-98, and 102.
Create a run.do file according to the source code diff of commit 40e447d. All 3 lines.
Click "Tools & Simulators" to expand and show the options dropdown.
Select "Aldec Riviera Pro 2022.04" from the Simulator dropdown menu.
Check the "Use run.do Tcl file" checkbox as shown in the diagram below. This overrides the default run command with what your run.do file contains.
Check the "Open EPWave after run" checkbox as shown in the diagram below. This enables waveform viewing using EDA Playground's waveform viewer.
Trivia: EP comes from EDA Playground.
Click the "Copy" Button as shown in the diagram below. This saves the current state of the playground into a new one.
Click the "Run" Button. This will trigger the compilation and simulation run process using the selected simulator.
When the option in 6. is enabled, the waveform viewer app is invoked immediately after the simulation finishes.
Close the EPWave dialog that appears.
Click the "Get Signals" Button.
In the "Get Signals to Display" dialog, select ".dut_slave" from the "Scope" list. This loads all nets under the ".dut_slave" hierarchy.
Click the "Append All" button to include the selection into the waveform viewer's current window.
Congratulations! You now have your waveform.
With the waveform dump generated by the simulation run, you can visualize the stimuli generated by the VIP as it interacts with the DUV. While exploring, keep in mind the sections on Interface Signals and Operating State Machine. From there, you can evaluate how your test bench stimuli behave against the APB protocol standard. But we'll leave that for part 2.
That's it for this post. And happy waveform checking!
learning interface protocols, adopting VIP, waveform viewing
[1] “APB UVM With Scoreboard _,” www.edaplayground.com. https://www.edaplayground.com/x/ueMH (accessed Jan. 19, 2023).
[2] M. J. H. Borja, “UVM Hello World,” GitHub, Jan. 13, 2023. https://github.com/mjhborja/hello_world_uvm (accessed Jan. 19, 2023).
[3] AMBA APB Protocol Specification. Cambridge, England: Arm Ltd., 2021. Accessed: Jan. 19, 2023. [Online]. Available: https://documentation-service.arm.com/static/60d5b505677cf7536a55c245?token=
The review content, including references to the original source code, analysis, diagrams otherwise stated and overall presentation of the topic, is Martin's original contribution. The base line source code for this post is not Martin's work.