Axis speeds co-verification at Chrysalis-ITS

At Chrysalis-ITS, an Ottawa, Canada producer of e-commerce security products, Terry Thomas, vice president of IC engineering, is using Axis' Xcite product for both software and hardware verification. In this interview, he describes his company's use of the product for chip design.

EEdesign: What kind of chip design are you doing at Chrysalis?

Thomas: We've just formed a semiconductor division, and we're doing network processing chips that are security based. We're doing hardware and software design. The first device we have has extensible RISC engines with embedded software. We're also looking forward to separate processors.

EEdesign: With what chips have you used the Axis box?

Thomas: We've used it with two or three. The first chip has about 2 million transistors. It has no processor core, just mathematical functions. But even through the software is running on the [separate] microprocessor, we still need to interface it to and from the chip. We now have a device with around 5 million transistors that includes five ARC cores that we designed with a partner. We are in the process of releasing a second version. Because it's processor based, a significant amount of software runs on it.

EEdesign: Why did you decide to use Axis for co-verification?

Thomas: One reason we were interested in the Axis box is so we can get cycle-accurate models of our hardware that we can use in emulation mode, and actually run real software on them. One problem we've found in the past is that the model used to develop the software is not cycle-accurate.

You can use the resources of the ARC core in different ways. The core might put in a wait state because it's trying to access something currently under use elsewhere. So you write software that you think will be 5K cycles, and it turns out to be 8K cycles, because you keep getting contention for resources. If the model isn't cycle accurate it's very difficult to predict what the performance will be.

EEdesign: How did you happen to select Axis?

Thomas: We took a device that we had committed to go to silicon. We gave the file to Axis and said, if you can emulate this on your box, that's our acceptance criteria. We didn't think they had a hope of doing it, but they came through. It impressed us greatly.

EEdesign: What's your methodology for hardware/software co-verification using Axis?

Thomas: The Axis box is kind of interesting. You can set it up for hardware and do simulation acceleration, but with their new emulation capability, you can also make it look like a chip and drive it from a board. We make an absolutely accurate model of our chip. Then we have an umbilical [cable] to the board, so we can make a model of our system. We simply run the software on that. Some of the software may be running on the Axis box, some on a microprocessor on the board, or maybe a combination of the two.

EEdesign: How do you get accurate processor models?

Thomas: The ARC core is a soft core, which we synthesize into real gates. Functionally and cycle-wise, it's 100 percent accurate.

EEdesign: How close does the Axis box get to real-time speeds?

Thomas: Nowhere close. We might possibly have a chip in the 100 or 110 MHz range. I suspect that in full emulation mode, where we have a complete system, we're probably running Axis in the KHz range.

But it doesn't matter how fast it runs. What matters is that without a cycle-accurate model of the ARC, you can't get a feel for no-op states, where the ARC catches its breath because it's doing two things at once. It may need to finish one activity before it gets to another because of register contention. If I find the reason is that I'm calling on a register too often, I can change my software and avoid that, run it again, and know for sure. The fact that it's not running at 100 MHz doesn't matter.

EEdesign: How did you handle co-verification before using Axis?

Thomas: Badly. We designed our first chip with a partner company, and we had some surprises. When we put the whole system together it would work, but it didn't work as fast as we thought it would. There were a number of things we didn't understand that caused us to lose performance. Our tools weren't cycle accurate. They verified functionality, but they didn't identify wait states or things like that.

EEdesign: Is the Axis box used more by hardware or software designers?

Thomas: It's used by both. The biggest gain we see is having the software people develop using known-good hardware. They can do that prior to us taping out the chip. We're in 0.15 microns these days and it's the best part of a million dollars to tape out a chip. So being able to verify that the software runs the way you think it does is important.

I think [Axis] could probably save in iteration. If it boosts the chances of first-pass working silicon from 30 to 90 percent, that's a big savings.

EEdesign: Are the software engineers just looking at drivers, or also applications code?

Thomas: Both. We have what we call software, and what we call firmware, which is low-level embedded stuff. We have our own API [applications programming interface] that we present to our customers.

EEdesign: On the hardware side, are you still running software simulation, or is all your verification on the Axis box?

Thomas: We still run software simulation, but we use Axis to do acceleration when we're doing full-chip design. Our group is split into four or five smaller teams, who use simulation as they've always done. The Axis box comes in when we pull it all together and the simulations would take too long to run. Then we run the hardware in acceleration mode, and after that, think about how we can run [Axis] in emulation mode with software on it.

EEdesign: Any improvements you'd like to see with the Axis box?

Thomas: We've only been up and running for under a month, so I can't think of anything. I'm sure in time we'll want to expand in size and do bigger devices. But the engineers have been ecstatic about the use of the thing. We have a fight as to who can get on it in the lab. It doesn't sit empty.