Opening a TrekBox for Your Birthday

Over the more than three years of posts here on The Breker Trekker blog, you’ve seen us reference our TrekBox runtime component on many occasions. We mention it in many contexts: test case visualization, memory usage visualization, test case status, test case debugging, system-level coverage, performance analysis, I/O interfacing, UVM testbench control, and more. We’ve never had a post on TrekBox itself, so today we rectify that and fill in a few details that we haven’t discussed before.

Some of you are familiar with the term “trickbox” in the context of a simulation testbench. We found a nice concise definition of this term in an ARM patent: “Memory mapped (behavioral) test bench component to facilitate verification.” By writing to designated memory addresses, the processors in the design being verified can send messages to the testbench for various actions. Our TrekBox is of course a play on the “trickbox” name, and it provides many presents inside for those who open it.

We generally explain TrekBox in the context of a UVM-based simulation testbench. TrexBox is a utility that runs linked tightly to the simulation testbench and the design being verified. When TrekSoC generates the C test cases that are downloaded and run on the embedded processors, it also generates an “events” file that indexes a wide range of tasks using a simple ID.

Recall that the automatically generated test cases are verifying the SoC “from the inside out” and so the processors are in charge. When the code running on one of the processors wants to send information to TrekBox, it simply writes the corresponding ID to a memory-mapped location. TrekBox receives this ID, looks it up in the events file, and takes the requested action.

One possible such action is placing data into the design, for example, sending an image to the camera port of the digital camera SoC shown above. Another is receiving and checking data from the design, such as an image written out by the SD card controller. These actions might be part of a realistic user scenario, such as taking a raw image from the camera, JPEG-encoding it in the photo processor, and writing the resulting JPEG file to an SD card.

TrekBox can also check the results to be sure that the JPEG encoding was done correctly and that all data was transmitted properly into, around, and out of the SoC design. In this case the scenario model might include a JPEG reference model so that the expected result can be calculated from the original image and compared with the actual result from the design. If an existing reference model is available, it can be easily called from the scenario model.

Since an SoC running embedded code in simulation tends to be slow, the TrekBox approach adds significant value by offloading tasks such as result checking. The processors need only write out the IDs and then all the action occurs within the TrekSoC runtime module without advancing simulation time. Further, TrekBox connects directly to the transactional interface on UVM-compliant testbench VIP components, so the user has to do no work to interface to a UVM testbench.

In addition to commands for I/O activity, the processors can write out various forms of status information via the IDs. One such example is reporting when each task in a test case begins and ends. As we discussed in last week’s post, this gives TrekBox the information it needs to show the actual elapsed times at the end of a test case run in addition to the scheduled times during the run. From this, vital performance statistics for the design can easily be calculated and graphed in a spreadsheet.

In general, any form of information that the processors need to communicate to the user can be handled by TrekBox. This mechanism is useful not only for simulation, but also for hardware platforms. In a lab setup, TrekBox executes on the same host platform that supports download of the embedded code and runs the embedded development environment. Typically, a UART in the design is used as the channel to send the IDs from the processors to TrekBox.

The same post-runtime results shown in the figure above can be gathered from in-circuit emulation, FPGA prototypes, or fabricated silicon just as well as from simulation. This means that the performance analysis metrics can also be calculated for these platforms. TrekBox can also send data on and off chip by using whatever I/O access the hardware platforms provide, perhaps a software interface for emulation or a JTAG port for silicon.

TrekBox is a highly flexible and valuable part of the overall Breker portable stimulus solution. It has far more tricks than a traditional simulation-only trickbox, but it retains the familiar concept of using memory-mapped locations for communication. We hope that we have given you more insight into this utility, but if you have additional questions please do not hesitate to ask.

Tom Anderson

The truth is out there … sometimes it’s in a blog.

Tags: acceleration, applications, apps, bandwidth, Breker, cache coherency, coverage, debug, duration, EDA, emulation, FPGA prototyping, functional verification, graph, multi-SoC, multiprocessor, performance analysis, portable stimulus, reuse, scenario model, simulation, SoC verification, system coverage, transactional, TrekApp, TrekBox, TrekSoC, TrekSoC-Si, UVC, uvm

This entry was posted on Wednesday, June 29th, 2016 at 7:16 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.