RISC-V represents a clean slate. It offers a fantastic opportunity to build a platform that’s fit for 21st century products...
One of the great things about working in tech is that we’re always moving forward. In fact, we’re rewarded for moving forward. Innovation breeds success. Paradoxically, it’s also true that engineers are highly inclined to stick to what they know: to carry on “doing what works”. This is natural – phrases like “if it ain’t broke, don’t fix it”; and “keep it simple, stupid” are our stock-in-trade.
But sometimes, we get an opportunity to sweep away all the baggage and start from scratch. To replace a Frankenstein monster, cobbled together over years, with a fresh, bouncing new-born.
This is where we stand with the advent of RISC-V.
RISC-V represents a clean slate. It offers a fantastic opportunity to build a platform that’s fit for 21st century products. Technically, because it has been architected from the ground up “to be better”. Commercially, because it’s based on an open source model that will break the current hegemony within the processor field. And creatively, as it allows us to develop products in areas we haven’t even thought about yet.
And in case there was any doubt, the opportunity to build extends far beyond the ISA (instruction set architecture) and the CPU core. This is about building systems and putting in place a 21st century ecosystem to support the developer.
We took a big step forward in that effort recently with the ratification within RISC-V of the new processor trace standard. The world of debug has been poorly served in terms of both standards and innovation for some time. Many engineers today are still relying on JTAG, which was invented 35 years ago (if you’re too young to have lived it, that’s season three of Stranger Things; if you’re old enough to have been in tech at the time, it’s the launch year of the Intel 80386). Nexus-5001 is “only” 20 years old (although it was updated in 2012). Arm’s CoreSight, although it has evolved somewhat since its inception, also has its roots in the late 20th century. None of these was architected for the modern world of multi-core, multi-threaded CPUs running at GHz.
So defining the trace standard was a great opportunity for the RISC-V Processor Trace Group, and the community as a whole, to do two things. First, to shed historical baggage and start with a clean sheet of paper. Second, to collaborate across the RISC-V community to give developers a single vendor-independent standard in which they could have real confidence; for as we know, fragmentation is the bane of any open source effort.
Technically, the group considered three main areas:
The requirements were challenging: modern systems often have many, many cores, which generate lots of data when you trace them, so we needed to come up with something that was efficient in terms of on-chip and I/O requirements.
I believe that what the group came up with ticks all of the boxes, for any kind of system, from lean uniprocessor chips to complex multi-core designs. Benchmarks show that the compressed branch trace algorithm chosen for the standard produces something of the order of one-tenth of a bit of data per instruction retired – dramatically more efficient than older algorithms. It’s a testament to what you can do when starting with a clean sheet.
What we need to do now is continue to both innovate and standardize. The newly formed Trace and Debug Standing Committee within RISC-V International is looking at the next steps in standardization: encouraging diversity, open-ness and innovation, while avoiding the fragmentation that often plagues standards efforts, and in particular open systems approaches. We should be looking with fresh eyes at new technologies to achieve that. And to shed the baggage that might hold us back.
The RISC-V opportunity is upon us: in order to grasp that opportunity, we should be looking at the road ahead, not in the rear-view mirror.
— Gajinder Panesar, CTO at UltraSoC.