Once I'd created my model I needed to test it, so I created a slightly larger "system-level" model containing a clock, reset, the main busses, a small chunk of RAM, and an I/O port/latch through which I could display intermediate results. I then hand-coded a small program comprising some of the CPU's machine instructions into the RAM, applied an active pulse to the reset signal, and let my baby run wild and free. (Truth to tell, I thought this approach was rather cunning, because I was working in isolation and wasn't aware of any similar techniques being used by anyone else at the time).

I was quite pleased with the results of my machinations, but of course life was so much simpler then. These days the complexity of microprocessor cores makes your hair stand on end, while the intricacy of the software we run on these little rapscallions makes your eyes water.

All of this makes designing System-on-Chip (SoC) devices pretty hairy. The problem is compounded by the fact that today's SoCs are exhibiting much increased software content. Coupled with increased design re-use on the hardware side, this means that verifying the embedded software prior to tape-out is rapidly becoming yet another bottleneck for us all to worry about.

Communications breakdown

The rapid growth of SoC designs is making traditional verification techniques inadequate. What is required is the ability to verify the software and hardware concurrently so as to completely validate such things as the system diagnostics, real-time operating system (RTOS), device drivers, and embedded application software prior to chip tape-out.

Like most things this sounds easy if you say it quickly. In the real world, however, there are a number of problems that have to be accounted for. First and foremost, software and hardware engineers typically act as though they come from different planets, and there's little common ground between them.

The software guys putter around with source code and debug it using source level tracing and memory and register viewing. Meanwhile, the hardware guys immerse themselves in HDL representations, which they debug using graphical waveform displays showing changes in signal values and their associated simulation times.

The end result is that listening in on a conversation between members of the two factions is nothing if not entertaining:

Software Engineer: "I think I may have hit a hardware problem while running my xyz application on the emulation system."

Hardware Engineer: "At what time did the error occur? Can you give me a test case that isolates the problem?"

Software Engineer: "The error occurred at 9:30 am this morning. The test case is my xyz software application!"

Axis Systems unveils XoC

The other problem is that there are many different things to consider, and different ways to represent them, including various types of embedded software and a plethora of verification approaches. Types of embedded software include:

• System initialization routines and hardware abstraction layer
• Hardware diagnostic test suite
• Real-time operating system (RTOS)
• RTOS device drivers
• Embedded application code

• Logic simulation (behavioral and/or gate-level)
• Simulation acceleration (behavioral and/or gate-level)
• Hardware emulation
• Hardware prototyping

Figure 1 -- Nine alternative modes in the verification matrix

The folks at Axis say that all of the big EDA players are working on hardware/software co-design and co-verification. They also note, however, that existing solutions typically require a collection of point-tools from multiple vendors (and we all know how much fun that can be), and they don't cover all of the modes in Figure 1, and they fail to adequately address debugging across the hardware and software domains.

The solution — according to Axis — is their new XoC product, which addresses all of the above modes. In fact XoC even allows users to "hot-swap" (transition on-the-fly) between simulation, acceleration, and emulation.

But the coolest thing about XoC is that it features a transaction-based co-verification debugger, which creates a common communications environment between the hardware and software teams. This debugger is based on a transaction-based concept. All communication between the hardware and software domains is captured in the form of transactions that are stored in a transaction database.

The co-verification debugger links these transactions to the simulation/emulation time value and also to the corresponding software line that initiated the transaction. This allows both hardware and software engineers to track potential problems back and forth across the hardware and software domains.

Strange to relate, when the folks at Axis first explained this transaction-based concept to me, I mentioned that it seemed pretty obvious once someone articulated it, and they said that yes it was, but that no one else had picked up the ball and run with it until XoC made its grand entrance in March 2003.

The first release of XoC focuses on SoC designs featuring ARM processors. This version of XoC uses the ARM source level debugger (which should make the software guys happy, because the last thing you want is to have to learn a new environment), but XoC can work with any debugger that interfaces with JTAG. ARM is one of the primary Axis partners in this endeavor, but Axis notes that XoC technology can be extended to cover additional processor families in the future.

In the January 2003 edition of Electronic Business, Dataquest's Gary Smith stated that "Axis ...[is] reinventing the world of emulation." And I personally heard some very excited feedback from folks who attended the recent DATE conference in Europe, so all in all I'd have to say that XoC is worth an official "Cool Beans" from me!

Quick Quicksilver update

Over the last year I've mentioned QuickSilver's Adaptive Computing Machine (ACM) technology on more than one occasion (for example, see my September 2002 column, "Reconfiguring Chip Design.")

As you may recall, the ACM is a new form of digital IC whose architecture is specifically designed to allow it to be adapted "on-the-fly" tens, or hundreds of thousands of times a second, while consuming very little power. This architecture allows dynamic software algorithms to be directly converted into dynamic hardware resources, and QuickSilver claims that this results in the most efficient use of hardware in terms of cost, size, performance, and power consumption.

Well, I'm delighted to hear that Olympus (of digital camera fame) and ITX (a business development company) recently announced that they are jointly founding/funding a new fabless semiconductor company called AOI. The interesting point as far as we're concerned is that AOI's sole job will be to design chips based on QuickSilver's ACM technology, and they will then sell these chips into a wide variety of vertical markets. One of the first such markets is that of digital cameras. This is due to the ACM's low power consumption and extreme performance, and also its ability to be easily upgraded to use new compression algorithms as they become available in the future.

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.