On the surface, designing complex systems-on-a-chip (SoCs) with reusable blocks of intellectual property (IP) looks like a breeze. Just throw together your architecture, drop those functional blocks into your design, and send it over the wall for physical implementation. Unfortunately, things aren't so simple in practice.
The topic of IP usage, never mind reuse, is anything but simple in real life. If it were, we wouldn't find so many vendors of EDA tools purporting to have "the answer." One thing is certain, though. Any IP block has to be modeled in a way that accurately captures its functionality and behavior and enables simulation, both as a standalone block and as part of the overall SoC or ASIC.
The designer evaluating a piece of IP wants models that permit checking out the IP, preferably in the context of an overall design, in a reasonable amount of time and at a level of abstraction that won't take weeks to simulate. In the meantime, the provider of said IP hopes to protect itself and its true IP while still giving the designer enough meat and detail to thoroughly evaluate the core in question. Modeling can be carried out on a number of levels, but with those options come tradeoffs that will affect the design process downstream (see the table).
Validating a piece of IP on its own is the easiest part of the equation. Depending on the source of the IP, it often is a given that the block is good and accurately modeled. If it came from a large, well-known supplier of IP cores, it will probably work if used properly.
Established IP suppliers jump through hoops to ensure that their IP works as advertised. Dave Wood, director of product marketing for register-transfer-level (RTL) cores at Mentor Graphics' Inventra IP Division, maintains that cores coming out of the company are exhaustively simulated and prototyped in hardware. "From an IP provider's point of view, our models have to work at the bit level. We must get the model as close to bit level as possible, which still gives us very good verification speed," he says.
But if it's a block with suspect provenance, then caveat emptor is the rule of the day. For example, you might consider a standards-based piece of IP for incorporation into a design, such as a Bluetooth radio. In cases like this, where the technology embodied in the core is in its earlier stages of life, the track record for the core in terms of silicon implementation just isn't there yet. This means that the core might work, but the IP integrator will have to do a considerable amount of homework. Therefore, a method for evaluating and verifying IP is required.
One can verify a block of IP in several ways, thus ensuring the accuracy of the models used for simulation, according to James Hakewill, director of product engineering at ARC Cores. "There are at least five levels of accuracy for modeling and verification: instruction-set simulation, cycle-accurate simulation, HDL simulation, hardware emulation, and the ultimate in accuracy, actual silicon," he explains.
A user most likely wouldn't create a chip to verify that a piece or pieces of IP work. That's more the type of job for the IP provider. For example, ARC Cores creates test chips for its user-configurable processors for demonstration purposes. That leaves IP consumers with the other, less costly, and nominally less accurate methods. Each one brings tradeoffs, primarily in the area of speed versus accuracy.
In most cases, IP consumers will want to begin their evaluation efforts by instruction-set simulation. With this kind of simulation model, designers compile instructions for their IP core to run and simulate its execution of them, checking the states of its outputs on each clock cycle. Typically, one instruction is executed each clock cycle. In the end, you will have checked whether the core put the ones and zeroes on the bus that you wanted it to with each tick of the clock. But the downside to this type of simulation model is that it conveys little or no detailed timing information.
Distinctions must be made between what some call "instruction-set" simulation and what others call "cycle-accurate" or "cycle-true" simulation, and fully detailed "timing-accurate" simulation. If, as in the latter case, you want to know what's happening in your simulation nanosecond by nanosecond, looking at the rise and fall times of clocks, then you must run your simulations using the RTL code (VHDL or Verilog) for your core.
Reprints
