In fact, in this column we have a little something for everyone. You're a hardware designer? We have you covered! Software development is your game? No problem! Design is your thing? Have we got news for you! Verification is where it's at? Well just wait till you hear what's hot!

Virtutech and Simics Hindsight

For one reason and another, I've recently been spending quite a lot of time debugging software. You know how it goes — you run a program and it fails, so you set one or more breakpoints and/or watchpoints and re-run until you hit one of them, then you single-step through mounds of code jumping over functions or plunging into them as necessary. Eventually you realize that you've gone too far, but you can't single-step backwards, so you have to set some more breakpoints and then re-run everything from the beginning.

But wait! Those clever folks at Virtutech have just announced their Simics Hindsight product. I saw a live demo and it just about blew my socks off. This little rapscallion allows you to single-step BACKWARDS through your code.

In fact, every classical source-level debugging command has a "reverse" equivalent. So the "continue" command, which runs to the next breakpoint, has a "reverse continue" counterpart that runs back to the previous breakpoint. Furthermore, you can run forward to a breakpoint, then set another breakpoint in the past and reverse continue back to it.

Let's take a step backwards (if you'll forgive the pun) and remind ourselves as to what Virtutech is all about. Their Simics product is a full system simulation environment that can be used to create virtual systems ranging from simple, single embedded processors to complex full-scale networked multiprocessor high-end client-server configurations. These virtual full-scale systems run unmodified binary executables from boot PROM to operating system (OS) to applications.

For example, in past demonstrations I've seen a Windows XP-based IBM notepad run a Simics simulation of 64-bit Sun Solaris system. It's important to note that such a simulation covers the entire Solaris system, including processor, memory, hard drives, file system, and so forth. When you run this simulation, you see the operating system's trace messages coming up in the system console window. Then you can run standard Unix commands to look in folders, copy, rename, and delete files, and so forth.

Okay, that was impressive enough. But now consider what happens when you run the same simulation with the new Simics Hindsight. In this case, if you delete a file from the simulation of the Solaris system, you can set a breakpoint in the past and run the software in reverse. In fact, I saw the entire operating system's boot sequence being run in reverse, including the trace messages disappearing from the system console window!

I personally agree with Virtutech that this could be the most significant development in software terms since the invention of source level debugging. Initially I saw this as being predominantly of interest for folks developing humongous computer environments — say hundreds of PowerPCs linked by Ethernet.

But then I started to realize that this could also be incredibly useful for people developing any form of application software. For example, say you are developing an application to run under Windows XP. In this case, you could be running a Simics Hindsight simulation of your Windows XP system on a real XP system.

Furthermore, you could be running the application you are developing on the simulation of your Windows XP system. Now, if your application crashes, or starts corrupting the file system, or whatever, you can set breakpoints in the past and run back to them to see what is going on.

As the old saying goes: "It's easy to be wise after the event". Well, with Hindsight you can go back to when that event is just about to occur. This is one of those nexus points that could well revolutionize software development as we know it. Once you've used a source level debugger with both forward and reverse capability, you'll never want to go back (pun intended)!

Arteris and Network-on-Chip (NoC)

It comes as no surprise to learn that the size and complexity of system-on-chip (SoC) designs continues to increase in leaps and bounds. The problem is that these really are getting to be humongous systems, so the old ways of linking the functional blocks together, often requiring global synchronization across the device, are beginning to get a bit flaky around the edges.

The answer could be the concept of a network-on-chip (NoC). In order for this to fly, the development system needs to be as unobtrusive as possible. You need to be able to pull a design together using your own functional blocks and third-party IP blocks, and then have an easy way to link them all together with an on-chip network.

Well, the folks at Ateris have a system that does just this. You can define local clusters of functional nodes that talk to each other, and then define links between clusters, and so forth. You can also define whether network links should be synchronous or asynchronous on a link-by-link basis. And when you are done, their tool presents you with the RTL (in Verilog, VHDL, or SystemC) to implement your very own NoC.

Giga Scale IC and InCyte

If you are planning on building a new ASIC or SoC, one of the front-end tasks you will have to undertake is to try to estimate the die size, power consumption, and so forth. These calculations are typically based on a hodge-podge of formulas and statistical data, often embedded in legacy spreadsheets that cannot easily scale to new processes.

And speaking of processes, the number of process variants at the 130 and 90 nanometer nodes are growing in leaps and bounds to the extent that it's almost impossible to create good estimates using conventional techniques.

And so we come to Giga Scale IC and their InCyte product. This little scamp allows you to perform all sorts of "what if" games very early in the design process. For example, InCyte comes equipped with an IP catalog containing the details associated with thousands of pieces of IP in the form of hard and soft macros from a large number of third-party suppliers. InCyte also has knowledge of all of the different foundry processes.

You inform InCyte as to the number of clock domains you require, the number of I/O pins, the types and number of interfaces you are using (e.g. PCI Express), the type and number of memories and memory controllers, and the different blocks of IP. In return, InCyte performs an analysis (in approximately 3 to 5 seconds) of all of the possible implementations and — for different processes — will inform you as to the die size, power consumption, yield, cost, and so forth.

Looking at this another way, InCyte presents you with the actual quantified return on investment (ROI) impact of using any particular piece of IP. By allowing you to analyze all of the different variables that go toward making a new device, InCyte allows you to find the "Sweet Spot" for your masterpiece.

The folks at Giga Sale IC claim that the results generated by InCyte correlate to within 5% to 10% of the final values associated with real devices as they roll off the production line (as compared to the 40% to 50% correlation you typically receive when using traditional spreadsheet-based "suck-it-and-see" techniques). Want to know more? Well if you bounce over to www.ChipEstimate.com, you can download a free version of InCyte that is time-unlimited and can be used forever.

Synopsys and DFT Compiler Max

In my early days as an engineer, I spent a lot of time creating testbenches for functional circuit board testers (does anyone remember the old GenRad 2225?). In those days of yore, we were concerned only with stuck-at (short) and open circuit faults, but creating our test waveforms was still a tedious business.

Of course things are much more complex these days. In the case of modern ASICs and SoCs, we have entire new fault classes to worry about, such as resistive via and bridging faults. These types of faults can only be detected by running vast amounts of at-speed test vectors. The problem is that the shear quantity of test vectors can overwhelm the memory available on the automatic test equipment (ATE).

So I was very interested to learn about the new DFT Compiler Max product from Synopsys. The idea is that DFT Compiler Max compresses the test vectors, which are subsequently uncompressed inside the chip. Using a single synthesis command, this little rascal can intelligently compress text vectors by anything from 10x to 50x with zero impact on the chip's timing or power consumption.

But wait, there's more. Synopsys has taken a holistic approach to the entire test and verification problem. DFT Compiler Max has links to the Synopsys automatic pattern generation (ATPG) engine TetraMAX, which can generate the test vectors required to detect stuck-at, open, resistive via, and bridging faults.

Furthermore, the whole system works in tight conjunction with the automatic test equipment. For example, suppose there is a fault (or a number of faults) on the chip; these will appear as bad responses to the outside world. The thing is, once you have a good enough set of test vectors, it's relatively easy to detect that "something is wrong," but isolating exactly what is causing the problem is a completely different issue — in some cases it can take weeks to identify the cause of the problem.

Now, when an error is detected, the Synopsys system will automatically play "what if" games, injecting faults into the simulation and comparing the results to the real-world responses. The result is that the cause of a fault can often be located and isolated in a matter of hours, which is a phenomenal achievement.

Tharas and Hammer

I've long had a "soft spot" for hardware emulators and accelerators. One problem, however, is that they typically work only with a 2-state logic value set of 0 and 1 (there were hardware accelerators that did more states a couple of decades ago, but they seemed to fade away over time).

What this means is that any unknown X values have to be coerced into logic 0 or 1 values. In turn, this means that a lot of initialization problems associated with a design can "fall through the cracks". The beauty of representing an uninitialized register as containing an unknown X is that this X will quickly propagate itself throughout the system unless the register is initialized appropriately.

So I was very excited to hear the announcement from Tharas about the fact that their processor-based Hammer hardware accelerator now supports 4-state logic (0, 1, X, and Z). This is going to make a huge difference to users, not the least that this 4-state logic is compatible with ASIC vendor cell libraries and it directly ties into the sequences generated by ATPG tools.

At the other end of the spectrum, and of particular interest to embedded software developers, Tharas has also introduced a new API that can be used to link their hardware accelerator directly into the programmer's source-level debugging environment.

Verisity and vManager

The folks at Verisity never fail to amaze me. I was recently chatting to them about their vManager tool. This is a product that manages the verification process all the way from specification to closure.

The real problem with vManager is that it's got so many cool aspects to it that it's too easy to drill in on one particular feature, because you start to think that the value of the tool is in that feature, and then you have to drag yourself back and force yourself to look at the big picture again.

So let's take that step back. We start by creating a vPlan, which captures all of the verification requirements in the team's minds. This is essentially an executable specification that also defines what behavior needs to be observed in order to ensure that the specification has been met.

A key point here is that vPlans are hierarchical in nature. Also, that one vPlan can call one or more other vPlans, which can in turn call other vPlans, and so forth. For example, you could have separate vPlans associated with different blocks in the system, and then have a larger vPlan that gathers these sub-plans together. This is really cool, because it forms a new type of verification IP that can be reused on future projects. Furthermore, the vPlan can specifically define certain verification coverage goals by certain times/milestones. These milestones are used to pace the team and to ensure that commitments to other groups are met.

vManager now takes the vPlan and automatically deploys the right tools to perform the verification. These tools could be in the form of multiple software simulators, hardware accelerators, or formal verification seats. vManager automatically deploys and balances the jobs for each verification session so as to make optimal use of all available resources.

But wait, there's more. vManager allows users (managers and engineers) to generate frequent, accurate, and concise reports in real-time. For example, vManager automatically opens simulation log files, parses them for you, and then gathers and presents any errors.

This is a huge time-saver, because a verification cycle may involve large numbers of different simulation runs. At the push of a button, a manager can immediately see which portions of the design have been verified and which have not. If things are starting to slip, the team can quickly re-deploy effort to focus on problem areas.

And there's still more! When you have large numbers of people writing different regression tests for different parts of a design, you invariably end up with a lot of overlap. In fact, in the case of a large modern design, something like 60% of the simulations performed are partially (or wholly) redundant. This equates to a vast waste of resources. Once again, vManager leaps into the fray, because it can be used to organize everything and to identify redundant tests and simulations.

Lattice Semiconductor

Ever since they opened their doors for business in 1985, the guys and gals at Lattice Semiconductor have continued to provide some truly innovative products. Last year we saw the unveiling of their low-cost EC and ECP families of FPGA devices. And this year they are tempting us with a new range of XP devices that combine SRAM and flash.

This is really cool, because it means that you can program these devices using their flash configuration cells and this data is non-volatile. When the device is powered-up, the data from the flash cells is copied over to equivalent SRAM configuration cells in less than 1ms. In addition to providing "instant-on" capability, this saves you having to have a configuration device on board, and it also protects your intellectual property, because there isn't any configuration bit-stream for anyone to monitor and copy.

And of course, the fact that these devices do have SRAM configuration cells means that they can be reconfigured over and over again, which makes them ideal for prototyping applications.

SystemVerilog Assertions Handbook

There are an awful lot of books and conference papers telling us how important it is to be using assertion-based verification (ABV), but books that actually tell you "how" to do it are few and far between.

So I was delighted to lay my hands on the recently published "SystemVerilog Assertions Handbook (for Formal and Dynamic Verification)," ISBN 0-9705394-7-9. In fact, truth-to-tell, I have this little scamp open on my desk as I pen these words.

There are several great things about this book. First and foremost it was written by people who actually know what they are doing (this isn't always the case, as we all know to our cost). And life just keeps on getting better, because the authors explain things in an understandable fashion.

I can't tell you how many books I've tried to wade through, coming up gasping for breath at the end of a chapter only to realize that I haven't got a clue what the author was talking about. Well, you will be happy to hear that this is NOT the case with this tome. The writing is clear and the book is loaded to the hilt with understandable examples. So, if you are poised to plunge into the assertion maze, this is the book for you.

"Cool Beans" for everyone
Wow! What can I say? I told you that this column was going to have something for everyone. My mind is well and truly boggled with the incredibly cool products that everyone is coming out with, and we're still only at the beginning of 2005 — what will the rest of the year bring to delight us? I can't wait, but suffice it for the moment for us to award an official "Cool Beans" to everyone mentioned here. Until next time, have a good one!

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.