Experts At The Table: SoC Prototyping

By Ann Steffora Mutschler
System-Level Design sat down to discuss SoC prototyping with Hillel Miller, pre-silicon verification/emulation manager at Freescale Semiconductor; Frank Schirrmeister, group director, product marketing, system development suite at Cadence; and Mick Posner, director of product marketing at Synopsys. What follows are excerpts of that conversation.

SLD: When it comes to verification and validation, is there a way to easily inject errors on the validation side?
Posner: There’s such a thing as a transactor that will bridge the gap so part of it is synthesizable, part of it is in effect, C-based interface. It gives you the ability to be protocol specific—PCI Express—yet have control over it to inject errors. So basically it is like a synthesizable VIP. And actually we have transactors that are designed for FPGA-based prototyping, so in our hybrid environment, there’s a transactor that sits in the middle across standard buses because what you’re modeling is within systems.
Miller: There’s a really new opportunity here. This is a new area and my question to you guys is, how are we making sure that we do this right—and right means for the industry? It means making sure that we basically have a standard way of doing this so that when I take my AVIP (accelerated VIP) from someone—just like simulation—I can take a BFM (bus functional model) that Cadence developed and run it in VCS, and the opposite. How are we making sure we have a standard way of plugging in?
Posner: That should be via SCE-MI. There is a standard for that.
Miller: But SCE-MI is just like TLM 2.0. It’s just the communication interface. There are a whole lot of other things you need to consider when you’re integrating. There are things like starting up the system, shutting down the system, synchronizing the different pieces like synchronizing my AVIP with my configuration reset, etc. How are we actually going to do that in a standard fashion?
Schirrmeister: It’s an open question still. That’s where there is room for standardization.
Miller: Just for your knowledge, there is a standardization group in Accellera called the MultiLanguage Working Group (http://www.accellera.org/activities/committees/multi_language), and that’s what they are tasked with.
Schirrmeister: From a mechanics perspective of the interface, how to connect the pipes, so to speak, SCE-MI is the interconnect between the host and the box. And then in principle—that’s at least how we look at our AVIPs—the synthesizable piece is just synthesizable, so we don’t care where it’s synthesized to. Then you have the SCE-MI interface to it. Where it’s becoming tricky is the interface on the host side where the question becomes, is this like a UVM interface, is it a TLM interface, or is it a custom interface?
Posner: How broad do you want that interface? A hybrid prototype is a good example: it seamlessly plugs into Virtualizer because Synopsys has the hardware, we have the software, it just works. But we need to support other areas so there’s a compile-yourself System C interface, there’s a compile-yourself C++ interface, because there isn’t a set standard on how that interfacing works. So you just have to support everything. It would make sense to have something unified because it would reduce the EDA vendors’ effort.

SLD: And the customers want it.
Miller: It’s a nightmare.

SLD: What else do users need today?
Posner: I’m surprised you haven’t said debug. What’s your experience with debug in FPGA [prototyping]?
Miller: We haven’t achieved much with an FPGA [prototype]. Debug with things like Palladium, it’s a perfect world today—we get what we need and it’s very easy. But the debug that we’re looking for is we now have a multicore chip that has three layers of CPUs: big, big-little, medium and then little. It’s a heterogeneous set of CPUs. It’s going to be like 60 different CPUs. We need to be able to debug software with a software debugger together with an RTL debugger, and if we’re going to be running it on the emulator, we’re going to have to understand why the software is producing some of the behaviors, together with seeing a waveform and being able to visualize that through time.
Posner: I just did a SNUG presentation in Europe on cross debug where it’s a totally different world. The hardware engineer thinks waveforms, he thinks zeros and ones. The software engineer thinks registers. So just the display of information for debug is different and traditionally EDA companies have been very hardware-centric. We do a great job of putting zeros and ones on RTL and we do a great job of waveforms. Where we need to really focus is extending those debug capabilities to both worlds.
Schirrmeister: The interesting thing there is the breed of the engineer who understands the software in full and the hardware in full still needs to be invented. To me, it’s really two different windows into the same house, with your house being the design. You need a software view—he sees registers and wants to get the line by line. And then the hardware guy thinks in waveform. The interesting and perplexing situation I’m facing more and more is who is actually able to comprehend all of that?
Miller: What we are doing is trying to grow our engineers on the fly to have both disciplines. Today if I have a hardware engineer whose main focus has been RTL, I give him different tasks like the integration with a fast model. All of a sudden he has to start figuring out what GCC is, what UVM Connect is, what all these different bits and pieces of software and trying to educate them to become a software engineer. That’s also problematic as the engineers are writing a lot of their test cases in C/C++ so they predominantly are becoming sort of software engineers. Then, since we have to work with different teams from the different software groups, we start looking at how to partition our test code so that it can work together. How do we build these APIs? So that’s also becoming very interesting. The problem is that now we have to do two types of verification: we have to do UVM and then we have to do C/C++. Again, that’s a lot of work and not every verification engineer is willing to do C/C++. They want to do SystemVerilog, but they’re all getting up to speed on a lot of software. Traditional RTL engineers are getting up to speed on such software aspects.

SLD: What other issues with SoC prototyping need to be addressed?
Miller: We are being driven towards FPGAs. FPGA is a great technology and we need to come up a better way of doing FPGAs. I’ve asked several times for design guidelines for
Design For FPGAs. I’ve never seen anything of the sort.
Posner: There is a manual called, “The FPGA-based Prototyping Methodology Manual” which is written just for that.
Schirrmeister: That is a good starting point. What I hear you asking is kind of like the Reuse Methodology Manual was in the 1990’s for RTL: How do I write my RTL so that it is synthesizable? And you are asking how to write code so that it works in an FPGA.
Posner: It’s targeted at the RTL engineer. When they are writing their code, what should they be knowledgeable about? What are some of the best practices for knowing that your code that you’re writing is going to end up on an FPGA?
Miller: But it touches on architecture and microarchitecture.
Posner: Not so much.
Miller: Because FPGAs you have the thing like the number of pins you can have on a certain module.
Posner: The tools mostly worry about that.
Miller: I don’t believe it.