Virtually broken -

Virtually broken

Recently, I have been working with a prototype board to conduct some studies on the impact of the CPU clock frequency on the Android's performance. I am mainly interested in the side-effects that different clock frequencies have on the dynamics of the embedded software execution. Obviously, many software events are scheduled through timers, etc. and do not simply scale linearly with the CPU clock frequency. The same, of course, holds true with memory bandwidth and contention on the bus.

Unfortunately, I have been able to break the board after just one week of experimenting. Now, it is on its way back to the vendor. What scares me is that although I was only doing low-level software changes in the configuration controllers of the CPU, etc., the thing went dead. Now, it's reporting errors with the static memory controller and SRAM during the self-check phase in the BIOS. I've no clue whether my experiments and the defect are related. In my job, I am not used to those problems. Here (at Synopsys), I am mainly developing embedded software using virtual prototypes. Those may crash in the worst case, but after a restart they are as fresh as on the first day.

Virtual prototypes are simulation models of hardware systems and very suitable for early software development, before hardware becomes available. A virtual prototype runs the final binary software images of the entire software stack including ROM code, operating system, and higher level software platforms such as Android. Thus, I am able to run the same software that I ran on my board as I do have a virtual prototype of this exact board. All experiments that I conduct here with altering clock frequencies or voltages are virtual and do not damage any expensive and rare hardware equipment. Looking at the internals of an OS kernel, such as the regulator framework of Linux, hardware damage using faulty software does not seem to be that unusual:

3. Machine interface.
This interface is for machine specific code and allows the creation of voltage/current domains (with constraints) for each regulator. It can provide regulator constraints that will prevent device damage through overvoltage or over current caused by buggy client drivers. . . .

–From “Linux voltage and current regulator framework” on

My name is Achim Nohl and with this blog, my colleague Victor Reyes and I would like to share our insight into how virtual prototypes can be used for embedded software development. What are the traps and pitfalls, and where are the advantages. However, right now I would be really interested in your experience with damaging hardware by malicious software (overdrive, bad voltages, flash problems). Comments and anecdotes are very welcome!

Achim Nohl is a solution architect at Synopsys, responsible for virtual prototypes in context of software development and verification. Achim holds a diploma degree in electrical engineering from the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany. Before joining Synopsys, Achim has been working in various engineering and marketing roles for LISATek and CoWare. Achim also writes a technical blog for Synopsys at “A View from the Top: A System-Level Blog.”

3 thoughts on “Virtually broken

  1. In an ideal world, hardware would be robust enough to survive on its own–or at least have enough firmware and protection circuitry around it to prevent damage. In practice such safety measures are too expensive, so the embedded field is full of 'secret ha

    Log in to Reply
  2. Back in the 1970's, the PLATO IV system used plasma display terminals that optionally included an internal microfiche projector that could project color images onto the plasma display from the rear. That is, the plasma-generated display would essentially b

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.