It is a good idea to agree up front on all the nitty gritty details, such as the tools and environments to be used for design and verification. There is also a wide variety of platforms (Unix, Linux, Windows, Mac, etc.) on which a developer may design and test a core. This purist approach should ensure that there will be no surprises either half way through or even at the end of development! You must also specify who is to write any test scripts, what language they will be written in (Perl, TCL, C, VBasic), and any associated documentation. There are tools available that let you run tests that were developed on Unix environments on a Windows PC. One such tool, which I used during the Reed Solomon core development, is called Cygwin. It is easy to set up and use, but does incur some overhead during verification.

Verification Strategies

Verification can be a tricky one. It used to be that simple cores could be verified either by code walkthroughs and design reviews, or bt a few simulation runs. However, the cores being developed today are typically much more sophisticated, can have very tight timing requirements, and may interact in complex ways with external logic modules. There are many options available, some of them far more expensive than others. Formal verification is expensive, can be time-consuming, and almost certainly requires quite a lot of specialized knowledge. Hardware accelerators improve simulation and can aid in visualization and debugging, but they also tend to be quite expensive, and are usually hampered by still needing slow and often complex test benches and set-up environments. Simulation on a PC or workstation using a well-known and trusted tool (e.g., ModelTeks Modelsim) is a fairly inexpensive and relatively easy method of verification. However, this is a very slow and tedious debugging technique when the target design gets beyond about 500K gates. The trick here is to get the developer to sign off on doing as much testing as possible before the handover occurs. Also get a solid understanding of the test set-up that the developer will deliver to you. The more comprehensive the test benches, documentation, and test data generators are, the less time you will spend setting up, extending, and familiarizing yourself with the environment.

Hard or Soft?

Probably one of the most important details to sort out is the type of IP core that you want to receive. There can be several different flavors to choose from. The most rigid option is a hard IP core, which means that the core has been preverified and laid out in one specific technology. The timing and area are predefined exactly in a hard core of this type. You do not have access to the source code, so last-minute tweaks are out of the question. The other extreme is a soft IP core. With this type of core, you may be able to get access to the source code, but you probably have to pay more for this option. With soft IP, you typically specify the likely operating conditions such as clock speeds, set-up and hold timing, approximate area requirements, and the type of target FPGA or ASIC. It is far better to specify the target device exactly since both timing and placement can be greatly affected by the device architecture—this is especially true for FPGAs. Figure 2 illustrates the typical IP core delivery options.

Deliverables

The type of deliverables you would expect from an IP core developer vary to some extent, depending on the type of core you have selected, as discussed in the previous section. The most flexible delivery method would be to obtain the full source code along with a preverified netlist, a full suite of documentation, and a solid verification environment. This is the soft IP route, illustrated by the right-hand side of Figure 2. Then, using an Altera FPGA as the host, for example, the netlist could be plugged into a design specified as a floating and partly parameterized (i.e., the area and position would be defined by the Alteras Quartus tool) LogicLock region, and compiled with the rest of your code. A timing and area analysis would then determine if any changes needed to be made to the IP core to bring it in line with your specific requirements. Once you become familiar with the design, you then have the option (as you have access to the source) to modify it at will.

As an alternative many IP developers provide you with an encrypted netlist, some documentation that explains how the core works (usually at the block-diagram level), some test parameters that define the logic resources used, and all the timing limitations. This is the hard IP route, as illustrated by the left-hand of Figure 2. This is a far less flexible approach. Using hard IP, you do not have access to the source, so all modifications must be performed by the original core developer. The core structure (i.e., area usage) may also be set in stone. Going back to our Altera example, you would probably have to implement the core in your design as a fully parameterized LogicLock region, which means that the exact size, position, and shape are completely locked (i.e., the IP core must be positioned to start at row C, column 4, and is x MegaLabs high by y MegaLabs long, in a 20K1000E-1 device).

There are other alternatives—a core's size may be completely specified, but its relative position may be allowed to float within a particular FPGA, or a small family of FPGAs. With all of these approaches, one critical item that must be specified correctly is the I/O requirement. This is especially true if the core resides along an edge of an FPGA and needs to use a specific number and configuration of pins.

Conclusion

This series of two articles has discussed the IP core specification, development, and verification process. The objectives are to first clearly state in your requirements specification exactly what you want. This is probably your main vehicle for communicating all the necessary features and parameters of an IP core. Get this wrong and it could well be a disaster. Next, know the technical trade-offs and state of the art in the field of technology the IP core is aimed at. If you don't go in to negotiations well armed, you could take a mortal blow and not even realize it until it's too late. Pick an experienced, knowledgeable, reliable, and reasonably priced IP core developer. This step should get your project off to a good start. Select the delivery method (hard or soft), a verification and debug environment, and define all tasks and milestones. Who does what and when must be crystal clear to all parties involved in order to develop a trusting and smooth development process. Schedule when deliveries are to be made, what is to be delivered, and who does the testing and debugging. It's no good expecting a fully verified core or module on a specific date, only to find out that the developer thought that you would be doing 90% of the verification and debugging. This lapse in protocol could add months to the Design ® Test ® Debug ® Modify cycle. Finally, ensure that you have regular meetings with the IP core developer to track progress, identify problems early on, and maintain the project's momentum.

Real-Time Processing Using DSPs, FPGAs & uCs Archive

Guides and Experts   Analog Avenue   EDA Tools   PLD   DSP   EDA   Embedded Systems   Power   Test