The Importance of a Standardized Processor Trace

By Gadge Panesar, Chief Technology Officer of UltraSoC and Chair of the RISC-V Processor Trace Task Group For the last eighteen months, the RISC-V International Association Processor Trace Task Group has gone to great lengths to prioritize getting the RISC-V Processor Trace Specification polished and ready for the wider world. I’m proud to have chaired the Group, and to have witnessed the hard work we put in to get it done. The full announcement is available on the RISC-V International Association’s website. For those that want more details and to see the full list of RISC-V specifications, including Processor Trace, those are available to view here. Now that the processor trace specification has been ratified, we are able to offer a robust, highly efficient compressed standard to RISC-V developers and engineers. There is a consistently growing volume of support for RISC-V from all parts of the industry, with an increasing number of commercial implementations. We are witnessing new and exciting application areas opening up all the time. Why is trace so important? Well, depending on the project, somewhere between 50 and 75 percent of software development time is typically spent getting it to work – that’s debugging and integration. The workload gets much worse for increasingly complex systems where understanding the behavior of the whole system becomes very difficult. A key element of this process is the ability to have processor trace.  As the name suggests, processor trace allows engineers to see exactly what instructions the processor core is executing, step by step. Ultimately, it means less time and fewer headaches for those working with RISC-V. Given how time consuming the task of debugging and integrating tools and extensions can be, the importance of a reliable processor trace is clear. It’s vital that developers can select vendors with the knowledge and confidence that their hardware and tools will support a standard: not only now but in the future. The fact is, the importance of standards in open source is just as great, if not more so, compared to proprietary architectures. The trace process needs to be efficient in terms of on-chip and input/output (I/O) requirements, and also needs to be designed for 21st century systems which are increasingly made up of many, many cores. In such systems every bit counts…and there are a lot of bits! To that end, we set up the RISC-V Processor Trace Task Group to define the trace standard and that meant we had to address three main areas:

1. The interface between the RISC-V core and the trace encoder
2. An efficient compressed branch trace algorithm to be implemented in an encoder
3. A novel and highly efficient packet format which is output by the encoder

When we set out, we had a number of priorities in mind. The starting point was that visibility of on-chip behavior is becoming increasingly important. As mentioned, chips in the 21^st century have many CPU cores, often of different types – and that’s not to mention the foundation IP, custom logic and other accelerators that are almost invariably incorporated into the design. With RISC-V we have the added complication of instruction set extensions. So you have to balance the need for visibility with the volume of data you’re going to be generating – whether you’re using it on- or off-chip. That means the trace specification needs to be not only inherently efficient, but also scalable to accommodate the biggest possible range of requirements, from lean single-core devices to SoCs and systems with numerous cores (by the way, tools will also need to scale to accommodate this level of complexity). The great advantage we had, of course, was that the whole ethos of RISC-V is to start with a clean sheet of paper, and build from the bottom up to create something that’s better than what has gone before. Technically, I’m very proud of what we’ve achieved. Trace (and especially multi-core trace) can generate vast amounts of data: our benchmarks indicate that the compressed branch trace algorithm we’ve chosen produces something of the order of one-tenth of a bit of data per instruction retired. However, it’s worth noting that the JTAG interfaces found in legacy debug systems typically max out at around 6Mbit/s – whereas even using our highly efficient solution, tracing the execution of a single-retirement RISC-V CPU clocking at 1GHz is going to generate 100Mbit/s of data. So now we need to move on and take that same clean slate approach to the rest of the debug system. So now that the RISC-V Processor Trace specification is ratified as an open standard within the RISC-V International Association, users are able to choose core vendors and trace encoder suppliers knowing tools vendors will support this same standard. This is excellent news for the developer community, particularly for anyone looking at making full use of an open source processor architecture. Everyone involved should congratulate themselves on a job well done. There is also a newly formed Debug and Trace Steering Committee, and the Processor Trace Task Group will now go on to look at next steps including enhancing the RISC-V trace ecosystem and propose these enhancements to the Committee for its consideration and guidance. If you’re contemplating open source developments, and planning to get a RISC-V project started, it’s worth knowing that UltraSoC recently donated a standards-compliant open source trace encoder (TE) to the community. This is being made available via the OpenHW Group. The open source trace encoder implementation includes test benches and verification tests. If you want to read more about it, see the recent UltraSoC announcement or get in touch with us. Furthermore, if you’re interested in RISC-V, I encourage you to join the RISC-V International Association as a member and contribute to our growing ecosystem. About the Author Gajinder “Gadge” Panesar is the Chief Technology Officer of UltraSoC and Chair of the RISC-V Processor Trace Task Group. As one of Europe’s leading SoC architects, Gadge’s experience includes senior architecture definition and design roles within both blue-chip and start-up environments. He holds more than 20 patents and is the author of more than 20 published works. Prior to joining UltraSoC, he served at NVIDIA (NASDAQ:NVDA). As Chief Architect at Picochip he created the architecture of the company’s market-defining small-cell SoCs, and continued in this capacity after the company’s acquisition by Mindspeed Inc (NASDAQ:MSPD). His previous experience includes roles at STMicroelectronics, INMOS, and Acorn Computers. He is a former Research Fellow at the UK’s Southampton University, and a former Visiting Fellow at the University of Amsterdam.[/vc_column_text][/vc_column][/vc_row]]]>