The beginning of the argument was found in an EDA Design Line article titled “Unified Verification for Hardware and Embedded Software Developers” by Lauro Ritazzi of Eve USA. In it, he makes the following claim:

While some may have achieved the scope of jump-starting software development, they only address application programs that do not require an accurate representation of the underling hardware design. They fall short when testing the interaction of the embedded software with hardware, such as firmware, device drivers, operating systems and diagnostics. For this testing, embedded software developers need an accurate model of the hardware to validate their code, while hardware designers need fairly complete software to fully validate their application specific integrated circuit (ASIC) or SoC.

The interesting part here is really that jump-start is just for applications, and that OS and drivers require more details than a fast virtual platform can supply. I do not quite agree with this. But let’s first see what Frank Schirrmeister said:

the majority of the software development on virtual platforms is spent on firmware, device drivers, operating system porting and diagnostics. And that is not – as one could assume – on cycle accurate models, but on functionally accurate models with only essential timing, the type of models called loosely timed (LT) in SystemC.

I totally agree with this. As is evident from many different public use cases, OS, BSP, and driver development is a big use of virtual platforms. For example, last summer, Freescale announced the QorIQ P4080 with pretty good software support in terms of Linux and VxWorks operating systems, as well as some middleware stacks. All developed on Simics using an even more timing-abstracted model of the hardware.

However, Frank then makes the following claim that I have a harder time with:

In contrast, application software is developed more often than not using completely hardware independent techniques, including cross compilation from the host development machine using development kits like Apple’s iPhone development kit.

This is to some extent true, but as time goes on, I think this type of development environment is going to be less useful. Traditionally, OS vendors have had tools like VxSim and OSE SoftKernel in place to help customers “run code on their desktop”, while using the API of the operating system of choice. However, such solutions have lots of problems in how close they can get to the target.

• If you have any kind of third-party binary-only application, or want to use an existing binary component without lots of complex recompilation, you need a virtual platform running the underlying OS. You cannot squeeze that into a host-compiled API simulator.
• You are not using the same compiler and code-generation settings and build settings as you are for your actual target, and this can (read: will) introduce nasty compiler version issues.
• It forces you to maintain an additional build variant for your code, which can be pretty expensive for a complex build.
• You are not using the real OS scheduler, device drivers, and interrupt structure found on the target system. This can have a huge impact, especially for multithreaded multiprocessor systems.
• The API simulator needs to be kept in synch with the real software stack, and customized in the same way for any particular target. This is hard to get right (even though it has been done).
• The API simulator does not handle heterogeneous systems very well, such as chips or boards or racks mixing two or more different OS kernels in the same system (like a DSP and a main processor OS).
• API simulation completely falls apart when the OS is no longer the lowest level of the software stack, but you also have a hypervisor layer underneath the OSes on your target system. An API simulator simply cannot represent this kind of case.
• Using a virtual platform and the real target binaires also fits with the very important “fly what you test, test what you fly” principle of embedded software development.

For various subsets of these reasons, I see many users picking up virtual platforms as a way to streamline application development. For example, NASA recently selected a virtual platform based on Simics to develop the software for the new Orion spacecraft. That is going to be a complete software stack, not just OS and drivers, which tend to to be fairly off-the-shelf component for these kinds of systems. Most of the effort is on the application level, and the platform used is a virtual platform.

However, note that there are cases where a fast virtual platform like we are discussing here is not sufficient to validate all aspects of the code. I think the main reason we see different viewpoints on this, is that we are looking at very different types of software-hardware integration.

In a blog post I wrote last year on the dead-ness of cycle-accurate simulation, Grant Martin of Tensilica pointed out that some software desperately needs cycle-accuracy as it is intimately dependent on the timing of the hardware. This is certainly true for some aspects of drivers, and more so for the really early boot code.

Here, FPGA-based hardware-accelerated simulation of the actual design in VHDL or Verilog makes eminent sense as a way to get the details perfectly right. But that is only one part of a much greater system development puzzle, and it really only applies to very small subsystems as  it is kind of hard to fit much more than a single chip inside a hardware acceleration unit. Just as Frank Schirrmeister says, hardware accelerated simulation is very important. The nice article on the IBM z10 development that I blogged about earlier says exactly that: for some parts of the validation, there is no way around using the actual hardware RTL design.

And in the end, you have to test the timing and analogue aspects of a design on physical hardware anyway. There should not be too many suprises at this stage, if you have used all of the cool current tools right. But there surely will be some — even a VHDL simulation is a simulation, and not reality, after all.

The following appears to be to sequence of events:

• Cadence press release, in September, about their “Palladium Incisive Palladium Dynamic Power Analysis and Cadence InCyte Chip Estimator“, quoting Ran:

Cadence Incisive Palladium Dynamic Power Analysis enables SoC designers, architects and validation engineers to quickly estimate the power consumption of their system during the design phase, analyzing the effects of running various real software stacks and other real-world stimuli. The new offerings also include the Cadence InCyte Chip Estimator, which can now provide what-if power analysis through exploration of different low-power techniques. The InCyte Chip Estimator also generates automatically the Si2 Common Power Format (CPF), which helps drive architectural power specification and intent into implementation and verification.

• Frank Schirrmeister blogged “On Chameleons, Low Power and the Marketing Power of Copy Editing“, basically saying that what Cadence was selling was something that was bound to the RTL level and thus arriving with estimates pretty late in the design process, after most important architecture decisions had been made. Instead, he proposed a flow using virtual prototypes that contained a sequence of successively better estimates, from the usual initial spreadsheet to estimates actually derived from RTL later in the process (or for IP blocks that already exist). Synopsys is not alone in this, Neosera and ChipVision are after similar ideas. I think this approach makes excellent sense, following the idea that getting some kind of approximate feedback from a complete system early in the process is better than getting lots of details from a small part of a system late in the process.
• Ran Avinun then blogged a reply to Frank, at “The Power of Cadence System Power Flow vs. Viewing from the Top“. His contention there is that virtual prototypes have their uses, but that real designers will be using hardware accelerators, as that provides the key accuracy needed to do real power work. Also, he sees the creation of a virtual platform as a big problem, and cites a number of cases where running the actual semi-final RTL with power simulation was key to project success. Also, Ran sees the time needed to create a virtual platform as a big obstacle.
• Frank then replied to the reply, at “Hammers, Nails and the Spirits That I Called …“… where he points out that Ran has some misconceptions about virtual platforms, admits that the Cadence flow works well, but that it does miss the point of early power estimation before the design is too frozen to be much changed. There is a pretty but hard-to-read diagram in the post, from a 2005 article he wrote while at ChipVision in Germany, pointing out the need to evaluate designs with actual test data from the real world.

What do I make of all of this?

Ran’s Points

I must admit that I think the Palladium hardware simulation accelerator boxes are very cool pieces of hardware, which at least used to be based on custom logic systems that use several cycles of a fixed sized hardware to simulate multiples of the hardware’s based emulation capacity (so 10M capacity system can use 10 cycles per target cycle to simulate 100M, for example). However, I do agree with Frank that these are dependent on having actual RTL in place to be of much use.

Another issue with hardware emulators is their overall availability: compared to the number of PCs available in an organization, they are going to be very limited. As discussed in many different forums, a key advantage of a pure virtual platform is that it can turn any programmer’s PC into a target system running the real target software. Without having to book time on a limited set of physical target machines, and hardware accelerators are such limited-in-supply hardware machines. So a virtual platform is much more available to people within, and especially outside, a design organization. Also, unless you are happy to release RTL for your design to people outside your organization, hardware acceleration is going to do little to help your end users get the most out of your design, pre-silicon.

My final gripe with hardware emulators is their limited scope. They tend to max out at a the borders of a single chip, or less. A virtual platform, on the other hand, has much more room to scale, to include multiple chips, multiple boards, or even complete racks and networks of networks. You cannot really do that in any hardware simulation, as it involves too many billions of gates running too many billions on instructions. The general rule of simulation still applies with hardware acceleration: you need to increase the level of abstraction to handle larger systems.

As to the problem faced by Ran’s customers, having RTL but no virtual platform: what were they thinking of? Seriously, if you want to do design today a virtual platform should be your starting point, not an afterthought. Time and again, we see examples today where using virtual platforms gets chips to customers ahead of time and provides the ability to test ideas before committing to final RTL. It seems that Ran agrees with this need, but his means are different:

“As was stated above, big reason our customers use RTL emulation platforms is for accuracy, and while virtual platforms can offer certain performance, eventually the need to accuracy becomes critical and can not be overlooked, even for initial performance and power estimation analysis. Frank seems to forget in his statement above that the average bring-up time of new virtual platforms takes 6-12 months while the average bring-up time of many emulated designs takes days.”

The time to create a virtual platform is actually pretty short, if you do it at a sufficently abstract level of detail and don’t worry too much about cycle accuracy. Also, that bringing up of an emulation depends on having a detailed RTL-level description to start with… which is not necessarily the case. I must say that the cited six to 12 months for a VP (for a single SoC as discussed here) sounds reasonable to me — if you are building a cycle-level model that tries to emulate the final timing (which might not be really feasible at at all). If you work at a higher level of abstraction like loosely-timed TLM, that time shrinks by a factor of ten or so. I agree that in the end, accuracy is critical – but before you get there, the approximations used by the VP will have gotten you pretty far in terms of software development and architecture testing.

Ran is also afraid of the lack of accuracy:

Now, even if you build this platform successfully 9-12 months in advance, how do you know that your virtual platform representing your real design? How do you connect it to your verification and implementation environment and realistic power information? Frank seems to overlook these things. Looking at the analogy of the story described at the blog above, using a system-level platform that is not targeting the actual hardware for performance analysis and power trade-offs guarantees that the Chamelon will become a snake and you will get bitten.

As with all simulations, virtual platforms needs to be used with care and understanding. It might also once again be a matter of system scale: for RTL simulation, you are looking inside a single chip, and the detailed design to save power there. With a VP, you might be looking at whether a particular OS kernel does even care to try to turn off unused hardware at all… and that might be just as important in the end as being accurate in how functional units turn on and off inside an accelerator.

In today’s software-driven systems that mostly consist of existing off-the-shelf hardware, not any particular SoC that is being designed right now, the large-scale behavior and smarts of the software in a setting containing lots of chips and functions is far more important than optimizations inside a chip.

Frank’s Points

Since Frank is a virtual platform supporter just like me, I instinctively agree with his points about VPs being pretty fast to develop and available long in advance of actual silicon. I like the way he deals with power in the ARM DevCon presentation cited (do have a look at it), but still there are some lingering doubts and issues…

What I have a hard time understanding is just how detailed the virtual platforms need to be. The use of SystemC TLM-2.0 LT is sensible for speed, but it seems from the DevCon presentation that the main emphasis is on AT-level (and therefore pretty slow) timing-accurate simulations that look at power cycle by cycle in the target. If that is the case, I think we could almost just as well go get ourselves a hardware accelerator, as cycle-level models (even if transaction-driven)

However, Frank also says this which I cannot but agree with: you should not always run around with a hammer and look at everything like a nail — any reasonable chip design process needs both virtual platforms and hardware accelerators, one cannot really replace the other:

When discussing this matter with a friend, he pointed out rightfully so that both Ran’s and my post suffer from “Hammer and Nail-itis”. In fact, he pointed out, the combination of Cadence’s estimators (InCyte), C based synthesis, Palladium, and Synopsys virtual would be pretty powerful! It’s a good thing then that we acquired Synplicity which brought us Synplify high-level synthesis and Confirma FPGA Prototyping to Synopsys, and of course, that we have existing interfaces between our Virtual Platforms and Eve’s solutions.

Conclusion

To me, the lesson from this discussion is clear: A virtual platform should be the starting point of a new design, but once you get down to RTL, hardware acceleration is really pretty useful. You need both, and VP should come first, not second. It is not an either-or issue, rather I expect system and chip designers to use both tools, and the only question is what should come first, which I think is naturally the simulation in the form of a virtual platform. That also allows the chip to be set into a system context, which is otherwise pretty hard before silicon arrives, and something that large system integrators are screaming for.

Perry: OO and onwards!

As Glenn Perry notes, hardware languages have only just now discovered object-oriented programming, and he sees a gap of five to ten years from software development practice to hardware development practice. I think saying that OO is mainstream in 1998 is a bit late… I remember doing my first OO things in object Pascal and Hypercard around 1990, and it was standard fare at that point in time.  So with this perspective, maybe there is some hope that hardware development one day takes up current practices like dynamic typing, explicitly threaded languages, and scripting-style (as I have argued before on this blog).

It also looks to me as if the OO is really mostly applied to verification systems and test benches rather than the actual design. Which is not too surprising: in the end, hardware design is about creating a fixed hardware layout, and polymorphic objects and pointer chains map really poorly to transistors. Considering the incredible difficulties of static optimization of C++ code with fun things like escape analysis and very conservative assumptions, I have a hard time seeing synthesis from arbitrary OO code any time soon.

But the main use seems to be in test benches, and in that world there is no reason to stick to antiquated concepts like static typing and old-fashion OO… it would seem quite feasible to move to an asynchronous message-passing parallel model with dynamic types and special support for validating hardware behavior. I think a limiting factor here is the user base that has little computer science schooling and little exposure to non-procedural languages.

Schirrmeister: The Sword of Damocles

Over to Schirrmeister. His assertion is really that the grass looks greener on the other side, but that that grass is really quite poisonous for those living on your own side:

While I agree with Glenn that the technology in software engineering may be more advanced, for example around languages, I am certain that the required methodologies are fundamentally incompatible. The reason? In hardware engineering the project team always has the “Sword of Damocles” hanging over their head. Mess up the tape out and you will cost the company several millions in NRE (Non recurring engineering, or, “N”ever “R”eturn “E”ver). In addition you have to consider the lost product revenue because of the several months the project is now delaying production.

In contrast, in software engineering there is always service pack 2. The requirement to get everything right is not as deadly as it is in hardware engineering. And as a result of all that Skip Hovsmith is perfectly right – “Just get on with it” is unfortunately often the approach taken in software engineering. It looks to like things have to get a lot worse before this approach changes.

I think this makes some sense… but it is really a bit simplistic.

My Synthesis: It is a sliding scale…

I think that the argument that Frank puts forward has some merit. But it is not true that there is always a next patch in the software world. In my experience, we really have a sliding scale of software criticality and ease of patching.

At one extreme, we have hosted web applications where the code lives on the provider’s servers, and can be and is updated all the time. Here, a user does not even see versions usually, they just see problems being fixed. Wonderful quick turnaround, and also very easy to just send something out for an eternal beta a la google… Development can be very productive as it is very easy to deploy new versions and customers are quite tolerant of issues as long as you can show that you can fix things rapidly. Often, the code is really throw-away and not intended to live for more than a few months anyway, so you can live with glitches and bugs, they are not economically meaningful to patch.

Somewhere in the middle there is PC software that you need to update over the Internet (or diskettes in the good old days). Here, patching is relatively cheap and easy, and most users happily update their software once a week or once a month, basically as often as you can release it. Some Enterprise Customers tend to be slow to adopt the latest patches as they want to check that things do not break before deployment.

Then you have embedded software which is usually much harder to patch in the field. I have only updated my mobile phone a few times in two years. And if you go down to printers, routers, and similar devices they only very rarely get updated. Here, you do need to be quite careful about testing since the cost of fixing goes up.

The most extreme software is safety-critical life-determining items like radiation machines, car brakes, aircraft engine controls, missile guidance, and similar. The cost of developing such software is on par with hardware, since there is no second chance if a bug manifests itself. Patching is about as hard as replacing faulty chips. Methodologies have to be fairly heavyweight, just like in hardware design.

So software can be just as precisely engineered and costly and slow to develop as hardware.

The real question is how to reduce the drag induced by the tough requirements of hardware development, so that at least some parts of the development can be fast and furious and fun. And on par with modern software development.

Virtual platforms is where things meet

In my mind, one of the places for fast and fun development is virtual platforms. A virtual platform is initially a vehicle for exploration and experimentation and iteration on how a design should be. That is an ideal place for software-like attitudes and modern software development. Code quickly, test with software, iterate often is really exactly what you want to do up-front in a hardware or system design project. That the code is incomplete and not sufficient for synthesis does not matter: you want to get to the essential questions as quickly as possible. Or provide a virtual platform for software developers are soon as possible.

The VP itself is not a hardware design, it is really a software program and can be and should be developed as such. Modeling is programming, not hardware design. I do not see the initial VP or the software-development VP as being something that is (necessarily) to be converted into hardware. They are really design specifications and executable data sheets, which at some point are used to create more detailed design that can be actually turned into hardware.

A model of a piece of hardware is usually something that a single programmer with good tools can put together in days, as long as it is kept at a software-timed transaction level. There is no need for heavy processes for these kinds of models, and they offer a chance for hardware designers to have some fun and go off into software land and quickly program things in a more relaxed and richer programming environment. Doing the initial work on a virtual platform is really like web development, where a new version can be generated very often to see what the users think of it. There is no hardware cost or fab cost to dampen enthusiasm…

Virtual platforms are uniquely interesting in that respect, they are really where software and hardware meet, and can be considered to belong on either side. In my mind, they should be considered to be software, as that is what makes it possible to develop them with the required speed.

What is interesting is that most of these tools are graphical in nature. And they do seem to work quite well, which is quite surprising given the otherwise poor record of graphical programming as opposed to text-based programming. There were a pile of graphical programming environments in the 1980′s, none of which amounted to much. What survived and prospered were the good old text-based languages like C, C++, Java, VisualBasic, etc.  In practice, it seems like it is very hard to beat sequential text when it is time to actual get code working. More efficient programming seems to boil down to having to write less text and having text which is easier to write (for example, dynamic typing, rich libraries, garbage collection, and other modern language features that remove intellectual burdens from the programmer).

But graphics do seem to work for domain-specific cases (like control engineering or signal processing), especially for data-flow-style problems. And for abstract architecture work. So there has to be something to it… but what?

Now I read a blog post by Frank Schirrmeister at Synopsys who points out something quite interesting that I had not quite thought about before:

So my conclusion for now is that in refinement from one abstraction level to the next more detailed one, graphical refinement will work fine. However, when being at a specific abstraction level, textual entry using an expressive language is more elegant than graphical design entry.

Does this make sense? I am looking forward to your thoughts and comments!

That actually would seem to agree with my observations over the years. I think I would also add the note that graphics do not work well in being as general as text-based languages.  For example, doing counted loops in graphical notations, it usually ends up being plain contorted. Maybe because the actual act of looping back in a sequential flow is really not particularly graphical in practice. Another example is fan-out. One of the best examples I have seen of this problem is actually owned by Synopsys nowadays… I have seen some examples of the old Virtio “MagicC” language where you have a decision box and then tens of arrows to different function boxes based on the address entered… just painful. For something like that, a plain list of text is so much more powerful. Once you have thousands of different addresses to decode, graphics only hide the essentials.

But Frank’s observation really is telling here: it would seem that once you are at a particular level of detail and really have to sit down and get code to work, text works the best. However, we must recognize that in much design practice, we do have a long exploration and design phase first where graphics definitely help and code will just lock you down unnecessarily.

So there is a place for both, I guess.