Over the last five years, one of the concerning things about virtual prototyping has been the separation between speed and accuracy. The lack of any meaningful connections between models built for speed and models built for accuracy motivated me to look for better ways to address this gap. I joined Carbon because I believe the company is in the best position to address both architectural analysis and embedded software in a unified way.
My Background
When I first started working in the area, I was focused on virtual prototypes for early software development. I thought the only practical way to run operating systems, device drivers, and test applications is to use abstract models which are built for speed.
When I attended a conference, such as DAC or a SystemC User Group meeting, I noticed a common pattern. About half of the presentations were about early software development, and the other half were about architectural analysis. There was rarely a connection between the two, even though the most commonly-asked questions concerned running software and doing architectural analysis based on the hardware/software combination.
Somewhere along the way, I decided performance analysis wasn’t as interesting to me, not because I don't like computer architecture or hardware design, but rather because SystemC TLM-2.0 AT (approximately timed) models didn't seem like a practical way to create accurate models in a timely manner. I thought the accuracy solution should always be to use the RTL itself – an approach that has always worked well for emulation and FPGA prototyping.
Besides building virtual prototypes for early software development, I have done RTL simulation and emulation and spent time running software on RTL processors. Although these environments are cycle accurate, there had never been an effective way to debug software using a non-intrusive software debugger, see transaction-level views of hardware accesses, and observe a good programmer’s view of registers and memory. I have seen attempts to debug software by simulating the behavior of a processor’s debug access port, or by running an abstract shadow model to provide the software debugging connection; neither approach struck me as the right solution.
The result of this dichotomy between the two use cases for virtual prototyping made the sales process more difficult than it already was. I always ended up in a room full of engineers who introduced themselves as "system architect,” "bus architect,” "memory controller designer,” and various other hardware-related titles. All important jobs, but nothing to do with software, which had always been my focus. I concluded that instead of trying to focus on just one use case, it was necessary to provide a unified approach that provides speed when you want it and accuracy when you need it. If this could be done, the market for virtual prototyping could be larger, and the flow for users could be simplified.
Over time I realized that a better approach to addressing the full spectrum of a project’s needs was necessary, rather than the segmentation of projects into architectural analysis and early software development. Could the 3 kinds of virtual prototypes (see Gary Smith’s ESL Behavior Design diagram) be mapped to a single, comprehensive, effective solution?
Why Carbon?
I came to Carbon to join the company’s quest to provide a virtual prototype solution that addresses both architectural analysis and embedded software in a unified way: when accuracy is needed, by using models based on the actual design RTL, and when speed is needed, by implementing abstract models.
Accurate models shouldn’t be a bunch of HDL files with signals, wires, and registers that nobody can understand. Instead, they should look more like the simplified view I’m used to - abstract models with instrumented views for important things like registers, memories, and pipelines. It should be possible to run fast when required, and to run with accuracy when required. Additionally, you shouldn’t have to start over with a different simulator, or lose your non-intrusive software debugging features when presented with a new CPU model that has a different debugger interface.
The second reason I came to Carbon was to work with the latest IP from all of the excellent Carbon partners. Last week I was watching a recorded Google+ Hangout with Peter Greenhalgh, the Lead Architect for the ARM Cortex-A53 processor. It was interesting to hear him discuss the details of the design. He shared what kind of architecture he would use if he had the chance to design an SoC for a mobile device. He also answered a long set of questions about the Cortex-A53.
The amazing thing is I can easily run a simulation of a system using an A53 ARM Fast Model and see how it actually works. I can run a software program, see the new instruction set, see the 64-bit wide registers, see the exception levels, and more. I can also build my own configuration of the A53 on Carbon IP Exchange and run a simulation and REALLY see how the A53 works at a cycle accurate level. Although the Cortex-A53 is a complex processor, the diagram below shows how easy it is to instantiate and run.
Although I don’t have all of the answers to the challenges that are ahead after just one month, I’m excited to continue the quest to help users build high quality, optimized chips and systems by making use of virtual prototypes for performance analysis and early software development.
Jason Andrews