The paper describes a simulation for a network-on-chip based homogeneous system containing a “ARM-subset” ISS instances with local instruction and data caches, some local RAM, and also some shared RAM. Each core runs its own local software load, there is no SMP operating system. All communication between cores is over shared memory, using explicit operations across the NoC. All cores run a single cycle before they check communications from their neighbors.

This last point is crucial to understanding why this is feasible at all – in general, simulating a general shared-memory multiprocessor machine on a shared-memory multiprocessor falls down on the synchronization overhead. If your simulation semantics dictate that you synchronize every cycle anyway, and you do not try to optimize each core simulator, there is clearly decent room for parallel execution. By including the cache, they increase scalability, since there is more work per target cycle that can be run in isolation.

After reading the article, I am impressed by their work – just getting this to work is pretty good work. But there are quite a few questions which are not really answered in the article and which are crucial to understanding just how well GPGPUs could be used for this kind of ISS work.

• The targeted level of abstraction is a bit confusing. The authors claim it is “instruction accurate and not cycle accurate”, but still simulate caches and cycle-based communications across the NoC. If I read the paper right, communications will take a varying number of cycles depending on the distance for messages to travel. This is more detailed than a typical “instruction accurate” simulator.
• The target system does not run an OS – that might (but I do not know) be an advantage for their approach, since it probably implies less variation in the instruction flow in cores, potentially enhancing the amount of time that all ISSes in a thread group in the GPU can execute the same instruction. This would seem crucial, as if each ISS was running a totally different program, the instruction execution part of the code would be running serialized.
• They should really try to run the same kind of simulation on a high-end x86 CPU like an Intel Sandy Bridge with 8 or more hardware threads. I wonder if their scaling might not work just as well there – and with a much faster serial execution engine. This should give  a much more relevant point of comparison for GPU vs CPU execution of the simulator than…
• the comparison object they use right now, a JIT-accelerated multicore simulation using OVP seems pretty irrelevant since it is not doing the same thing at all. That simulator does not simulate the caches or NoC, just a large number of isolated processors. They also do not run a parallel program on OVP, but rather a large number of single-core fibonacci and dhrystone programs. Thus, the fact that OVP uses a large temporal decoupling time slice does not matter for semantics. It just does not seem like a very relevant comparison point. OVP and their simulator try to solve different problems – fast execution of general code vs. performance profiling of massively parallel machines.
• As I understand it, the given “S-MIPS” numbers in the evaluation tell us the total number of MIPS that we get out across all target cores. That seems to peak around 2000 – which isn’t necessarily that fantastic if we compare to high-performance ISS work in general where a few GIPS is definitely achievable. It is pretty good considering the level of detail here, though, where i would expect a normal ISS + cache simulator to produce at most a few MIPS. Once again, the authors need to be a bit more precise as to what they compare to what.
• Not having an MMU and not implementing any interrupts or exceptions in the target machines avoids a large part of the complexity of a real ISS. That complexity might well be too much for the quite rigid execution environment of a GPGPU.
• They missed that Simics, unique among instruction-accurate mainstream simulators, is parallel since version 4.0.

So, overall, this paper does not really tell us much whether a GPGPU can be used for instruction-set simulation in general. It does tell us that it might be doable, but there are many crucial complications which are not addressed.

Gary Stringham’s lists a number of tips on how to create hardware-software interfaces. Some of them are echoed on his monthly newsletter, which is worth a read (even if it is a bit short on detail). Unfortunately, there seems to be no publicly available version of the text. Gary has definitely kept lecturing on the topic since, at venues like the ESC and DVCon it seems, but more recent lecture notes that I have found in the ESC proceedings are pretty sparse. I guess being a consultant teaching people to do these things for a fee makes you a bit hesitant to share all your knowledge freely with the world… I can understand that position.

Anyway. Some of the comments in the text indicate to me the great value that virtual platforms can bring to the actual design of hardware up front, not just as an execution vehicle for the final design, used by a software engineer who has to take whatever is given.

In particular, the issue of getting ASIC and Firmware designers to collaborate on the same thing at the same time. Quote:

The key to designing an ASIC is to get the firmware engineers involved early. They are the customers that will be using the ASIC. Unfortunately, getting them involved early is often difficult to do because the ASIC design has to start several months before the firmware engineers will get parts

And

When the parts do arrive, the roles are reversed. The firmware engineers are trying to work with
it while the ASIC engineers have mainly forgotten it and have moved on to new projects.

The proposed solution to this problem is to involve the firmware people in the hardware design review process, which is a good idea.

It would be even better, however, if the firmware people could have the hardware interface to try as a live thing rather than just reading the documents. This is exactly what virtual platforms offer: quickly build a fast simple prototype of the interface, and hand it over to the software engineers to try.

This is something that I am currently exploring in some detail with Simics, and that I wrote a piece about in Chip Design earlier this year. Fundamentally, I think this is feasible, provided that hardware designers do not fret too much about timing details and the precise performance of the final implementation, and focus more on the programming interface design first — and then later go on and make sure the timing and performance is right.

It is just like software development is supposed to be done: start by designing a useful interface to a piece of functionality, and then add in the details and optimize performance within the boundary of that interface. Of course, the interface might need some adjustments to support certain optimizations, but it is quick and easy to provide a new virtual platform with a new behavior to the software engineer. Much faster than providing a new piece of silicon or even new documentation.

Register design tools like SystemRDL (now being standardized by SPIRIT), Spectareg, Semifore, etc. all touch on this, but all seem to be lacking the ability to actually describe what a device does beyond some simple basics like software and hardware read/write properties. You really need a full expressive language to write a truly executable model of the hardware (and I like DML for this).

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.

And really, there is no such thing as a standard embedded system. Even if you use a standard backplane and buy off-the-shelf boards and cards to put in it, the combination of cards and added mezzanine cards makes each system quite unique. If you could use completely standard PC hardware for your system with no custom additions or special IO units, the thing would in likelihood not actually be an embedded system.

This article was brought in by Power.org, since Power Architecture is one of the most common processor architectures in rack-based infrastructure equipment. If you wondered why Power Architecture featured so prominently in the article.

The interesting material in the article is the background on WHY he thinks that this is the case. He points to the immense popularity and rise of scripting in much of computing land. In the past ten years, it is clear to him (and I would agree with this too mostly) that languages like Perl, PHP, Awk, Ruby, JavaScript, and Python have eclipse Java and C++ as the most interesting and important programming languages for many practical tasks. Especially for web applications, where Java seems to have a presence but noone would dream of using something as clunky and impractical as C.

What can this teach us for the purpose of simulation and the creation of models of computer system hardware for the purpose of simulation? Maybe a fair bit…

The reason that scripting languages have gotten so popular is primarily that they let you get the job done faster. In web land, this is due to a few important factors listed or hinted at in the article:

• The overall code tends to be shorter and more to the point
• A tendency to make any value into a string when needed (excellent debugging aid)
• Dynamic typing, variables that just appear when needed
• Automatic memory management
• Ease of handling strings
• Most tasks are pretty short
• Performance of computation does not matter very much when processors are as fast as they are today and a single disk or network access operations is likely to dominate programming time

What the article continues with a discussion that we need to focus on programming language pragmatics rather than syntax or semantics. How practical is the language for the everyday tasks of a programmer? And it seems that simple darwinian evolution has propelled scripting-style languages to the top of heap here. Purity and elegance and deep semantical properties are obviously less important than getting the job done in the shortest time possible.

What can this teach us modeling folks?

• A key takeaway is the focus on short code. Code has to be short and focused to be quick and easy to write. You should not need to consult several header files and lots of documentation to understand and formulate your code, which is an ill that keeps hitting C and C++ programs.
• Memory management has nothing to do in a productive programming environment.
• Basic types have to be appropriate to the task at hand.
• Syntax has to be concise and powerful.
• Dynamic typing is much faster to code with than static typing and variable declarations.
• An interactive “try it out” environment is preferable to long compile/link/test cycles.

Obviously, some of these do not translate well into hardware modeling. Hardware entities tend to have very-well-defined types by nature. If I have a 16-bit register containing a 13-bit counter and three status bits, I cannot very well let that counter be a dynamic variable that can take on any numeric value. Or the atom “foo”. It kind of has to be restricted in semantics to how the hardware would behave… it is not just a “value” to be manipulated quite abstractly. Which means that what you probably rather need are types well-suited for the task at hand.

It is also nice if variables can just pop into existence when needed, with the least amount of declaration possible. Another C-family performance killer is the annoying need to declare a function before calling it. That made sense in linearly scanning compilers back in the 1970s, but today, just let the compiler take the entire program into account and find the function. It is not that hard, especially not for the quite small and isolated context that a virtual platform device model is (few device models are more than a few thousand lines of code in my experience).

The interactive nature of scripting is also interesting. The ability to just write new code directly into a running system without an explicit compile usually rests on a virtual-machine approach and does have some cost in terms of performance. And unlike webservers, virtual platforms need all the raw CPU performance they can get! However, it make excellent sense to use an interactive environment to prototype and test things, and then move the resulting code to a harder compile stage.

Right now, we really do not have such a tool at hand. Virtutech DML is in my opinion the most promising step along this road, but it is not really “perl for modeling” at this time. SystemC has too many C++ roots to really behave well in this respect… you get all the drawbacks of explicit memory management, rampant headerfiles, and statically declared types. It might be good to compile, but it sure is an absolute pain to write.

And if we want virtual platforms to really fly, it is not so much “all about the models”, but really “all about model programming” — since there is a huge volume of models that need to written out there, and getting the time needed to write these models down is a primary concern. The total work invested in modeling any particular device is what we need to focus on, really.

The book is obviously a collection of previous work, and the style is quite inconsistent from section to section. Not so much that it detracts from the value of the information, but it does feel a bit rushed.

The book presents four sets of taxonomies:

• Models, which is by far the richest part. In addition to a definition of terms in the field of building models of digital systems, it also offers a detailed classification scheme for the models. The classification scheme uses five “resolution” axes along with an external/internal perspective to define what a model contains and at what level of resolution.
• Functional Verification, which is really just a collection of terms.
• Platform-Based Design, which is more of a marketing discussion in how to define and design platforms. Also mostly a definition of terms.
• Hardware-Dependent Software (HdS), which defines terms. It has some attempts to classify software along some axes, but it does not really work out too well.

The main value is really in the second chapter, where it does provide a decent basis for discussing the level of abstraction at which models are created (note that accuracy is different from abstraction: a very detailed model at a very low level of abstraction can be totally off when considered from an accuracy perspective).

However, I fear that the impact of this work has been fairly limited. No discussion on modeling that I have been participating in has really gone back to this basis and worked from there. I think a key problem here is that the material is only available as a quite expensive book from Springer, rather than as a freely downloadable document on the web. It is clear to me that spreading ideas today depends on free and easy digital access to the information… that’s why I have my own publications page up to make stuff that I have created available for reading.

The hardware-dependent software (HdS) section gave rise to several “but they forgot X” comments from my part. For example, it is missing important aspects like processor virtualization, hypervisors, and IO virtualization (which totally change the game on HdS). Also, SMP operating systems are only giving a passing reference, with the focus on uniprocessors. And why do people keep using the term “Rate-Monotonic Analysis? There are so many much more modern fixed-priority scheduling analysis theories, methods, and tools available that RMA is like talking about programming in assembler…

What a choice for summer vacation reading…  and thanks to Bart Vanhournout at CoWare for the tip about the book in a discussion trying to pin down abstraction levels.

Anyhow, what we set out to do this year was to replace (most of) the twenty-year-old wooden decking on the backside of our small row house with a new one. This was quite an adventure, as we discovered all kinds of interesting designs and problems with the old decking structure. Problems, which do reflect on the realities of computer programming and simulation.

Preserving legacy structures

For the simple reason that we do not want to spend the entire four weeks of vacation building things, we decided to keep the original shed that is located at one end of the decking. Technically, this meant taking a saw, cutting the decking close to the shed, and rebuilding the rest of it. It also meant that we had to constrain the rest of the construction to preserve the original height of the decking, and the thickness of the boards used to construct it. Had we rebuilt everything, we would have done things differently and reconstructed the entire supporting structure of beams.

Now, we were forced to preserve the existing design, which is not quite optimal or fully modern. Very much like how it is when updating a large piece of software. Most of the time, you have to preserve old APIs, pieces of code, and design decisions that are not really optimal or modern anymore. Fixing it means starting from scratch, and quite often it is not considered worth the investment in time and effort.

You also tend to find amazingly poorly done items in old software, and so it was with our decking. A large part of the old deck had sunk some 10cm below its original level. When digging out to find out why, it became apparent that the beams had just been put on a bed of sand with no concrete or metal supports on the part closest to the house. That bed of sand had then been hollowed out by a misconstructed fix to a drain pipe that let the water spill out around the proper drain. Sigh. Not the first instance of poor workmanship around this house… and we had to do a workaround involving bricks, more beams, and a very large load of sand (I have shoveled some 800kg of dirt and sand during this project).

Reflection on simulator construction

The next observation is based on how the decking turned out in terms of the number and size of boards needed to cover the area. I had done some measurements beforehand indicating the width and length of the area to be covered. It looked like a number of 95mm standard boards with 3mm spacing would do perfectly to cover the area and provide a nice even end.

In the end, we wound up buying a small number of 120mm boards for the final row. For some reason, one side was 10mm wider than the other side. Also, the 95mm boards turned out not to actually cover the area quite as well as expected. Due to minor variations between the boards (in practice, they are 94 to 96mm) as well as imperfect spacing and the general plasticity of wood (it is a living material, not lego bricks laid out peg by peg) made our plans fall just short forcing a last-minute change to 120mm boards for the end.

As a simulation expert, you could say that this shows the shortcoming of the analytical approach. By making a single measurement of the width of the field, and assuming a single number for the width of a board, I set myself up for surprises when confronting a variable reality. If I had built a better model of the deck, measuring it at multiple places and measuring my boards and working out on paper – simulating – how they were to be put together, I could have predicted this and bought the 120mm boards in the original load instead of as an afterthought. In principle, this might be true.

But on the other hand, doing that simulation would have been tantamount to actually building the thing. Understanding the spacing between the boards and how their variations interact would have necessitated constructing in my mind, computer, or paper a perfect model of the deck. I doubt that it would have been saving me any time compared to just going out and putting the thing together, especially as the act of putting it together taught my just how variations occurred and how they worked out in aggregate.

I think the same often applies to computer simulation. Yes, you need to have more details and more variation than a simple analytical model. However, you also need to keep the model simpler than reality in order to make it feasible to construct, maintain, and execute at decent speed. Any model will have imperfections where it diverges from reality, and as a simulator constructor the game is not to be perfect but to provide a useful tool to your end users. If it is a bit imperfect, so what, as long as it is imperfect in unimportant ways and mostly provide good guidance. For more on the philosophy of simulation, I would suggest reading a blog post from 2007 about golf games and computer simulation.

So what would a useful model have been for my decking? I guess measuring a few more points would have helped, as well as measuring some set of boards and the device we used for spacing. That might have helped us spot the issue with the too-narrow final board ahead of time. But it was more fun this way, and this is vacation time and hobbyist work and not professional carpentry.

Conclusions

What conclusions can be drawn from this?

1. I guess I am a hopeless nerd who can never stop thinking about technology.
2. I have a very nice deck now, looking forward to some decent days in the next few weeks to make use of it.
3. Building physical things is quite a satisfying experience, even if they do not turn out perfect in all details.

As a side note, a few years ago, I presented on efficient C programming for IAR Systems, guess that would have made Jack Ganssle happy: he complained about the lack of resource-constrained C programming skills in today’s university graduates in a column at Embedded.com recently. Apparently, the major market-driven education companies in the US have also dropped plain C programming from the course rosters… sounds like an opportunity or void to be filled by the embedded companies. Buy a C compiler, get a free efficient programming course.

Any case, the panel said the following, including feedback from the audience (including the author of this post):

• Gary Smith laid out some data indicating that software is overtaking hardware as the main effort even for the core SoC designers for multicore. Today, some 50% is software, by 2012, 75% of the design cost will be software.
• Rudy lamented the difficulty of doing anything with regular unrestrained C code, and
  described some IMEC research where they restrict down C to make it palatable. Probably related to their work on “2D” VLIW architectures. Their “clean C” can easily be analyzed and create statically scheduled code (my interpretation) that runs well without caches and cache coherency. The audience asked how you could actually write a program without using pointers… good point. I think it can work nicely for data crunching, but fails horribly for control-oriented and dynamic codes.
• Grant made the point that there is no need to panic. Today, we can see people actually building successful multicore systems with today’s tools. It is a bit of muddling through, but it does get through. There is a lot of truth to that, but it misses the issue of converting or containing all legacy code that has a hard time moving from a single to multiple processors.
• Grant also said that the applications he had seen the most success with where those typically called “embarrassingly parallel”. But why should anyone be embarrassed that they have such nice problems? There is nothing to be embarrassed about, rather you should be proud of having such a nice system/algorithm.
• Simon Davidmann echoed my favorite theme that simulation is a key tool to develop software for multicore, as it gives you insight and control.
• When asked about hardware debug support, Simon was downright negative and wanted it all in simulation. Grant said that the proper solution was a mix of hardware debug and software simulators, which I agree with (see http://jakob.engbloms.se/archives/17 for some more thinking on this topic).
• Someone pointed out that hardware debug is sometimes taken out of volume chips and is only used in development versions — apparently, that is common in automotive, as the cost of each shipping chip is of utmost importance. Less practical for larger machines, though, where you cannot easily build a development version of your rack/router/switch/server…
• When asked about how to handle billions of lines of legacy code in a mix of C, C++, Java, and other languages, Rudy sounded downright exasperated. He seemed to be most comfortable with expressing algorithms and mapping them down to hardware using tools, rather than trying to deal with managing a zoo of legacy code… that is what I mean with the data-plane/data-crunching mindset of this panel.

Overall, an interesting panel, but a bit disappointing in the lack of large-scale software thinking. Would have been nice to mix in someone with an HPC, server, or large-scale control-plane embedded-systems background in the panel.

Highly recommended.

For this discussion, the most important property of Simics is that it strives to be as fast as possible in executing the software. This requires Simics to make some simplifications in its model of the physical hardware, since that is the only way to speed up the simulation. Fundamentally, the more detail you have in a simulator, the slower it is going to evolve the state of the world (run the software in our case). gt

Usually, computer system simulators aim at reproducing the actual behavior of the computer hardware at a great level of detail. The design goal is to be able to reproduce the timing in order to check that performance goals are being met, and to find design bottlenecks to increase the performance. Such simulators are quite detailed, and anyone familiar with the details of the hardware design will easily accept that the simulator is a valid depiction of the real system.

Unfortunately, such detailed simulators are also dog slow. If you are really lucky, you might see an execution speed of a few million hertz, i.e., simulated clock cycles per real-world second. Often it is less. And that is not really fast enough to run modern large software loads in a reasonable amount of real-world time. At that rate, running a program that takes 10 seconds on a real machine that we assumes clocks at 1 gigahertz will take several hours. Each time you run it. Not fun at all, and singularly unsuitable if your goal is something different from understanding the timing of the hardware.

With Simics, we made the decision that what the world also needs is a simulation that can run fast enough to make that 10 second-long program actually run in a reasonable amount of real-world time. Say around a minute or less. This facilitates using the simulator for software development and debugging, testing software and doing classic interactive debugging. Even for large workloads that contain many billions of interesting instructions. In order to achieve such simulation speed, on the order of hundreds of megahertz, you have to simplify.

(The golf simulator is coming up soon)

The easiest place to start simplifying is the details in the timing of the hardware. It is kind of hard to cheat on the functionality, since for real software to run you do need values to be computed in the right way. But if the values are not resulting at exactly the same time as they would in reality, software usually work totally fine anyway. This is to a large extent thanks to the asynchronicity of modern software, which will be the subject of another blog post/essay some day.

It is in getting the intuition why and how pretty drastic simplifications in a model still provide a useful tool that the golfing simulator analogy comes in.

Let’s Play (Virtual) Golf
The golf simulator in question is the large room kind, where you shoot the ball at a screen showing a course. You are using real clubs and real balls, and the simulator measures the ball flight just before it hits the screen to determine where the shot ends up on the course. The aim is to provide a game where even a good golfer can get a satisfying experience akin to playing a real course, and offer a way to help players improve their game.

The defining property of a serious simulator, of any kind, is that it helps you understand the real world or improve your performance in the real world. This goes for flight simulators, combat simulators, driving simulators, not to mention role-playing games in management training and other analog forms of simulation going back to the “Kriegsspiel” of the Prussian army.

This golf simulator definitely had that property.

But it was not in any way a complete simulation of the world. We noted some case where a ball seemed to be bouncing off of some invisible wall on the side of the field when we managed to hit it really bad (the group I was with were all golf novices and did not always send the ball off in the most appropriate direction). If you hit the ball into the virtual crowd, nobody got virtually hurt or tried to duck. The spectators just disappeared so that you could see the ball. That is certainly a limitation, but not one that detracts from the core game.

Another perhaps obvious limitation is that you can only use the golf simulator to play golf. I cannot use it to learn how mow a golf course in the best way, for example. This is something that always has to be kept in mind when using a simulator: if you use it for the wrong purpose, you have no idea on whether the results will be valid or not. The use case and design goal of any simulator has to be kept in mind when using it and deciding on which simulator to use. Note that some simulators can have pretty broad areas of applicability, but you must always be aware of where the boundaries are.

Finally, the simulator offered the typical simulator ability of providing extra insight. When you hit the ball, you could see the angle it took off, its speed, and the distance it traveled. Not all that easy to do out in the field. From what I can tell from the manufacturer’s webpage, they have some pretty cool training tools in addition to the basic golf game.

It is the same with computer system simulations. They are good for certain things and not so good for other things, and you need to use the right simulator for your needs.

More Reading: If you want to read more about computer system simulation in this style, a good starting point is the three-part article I wrote for Embedded.com earlier this year. It can be found here, here, and here.