Editorial

Coming to Grips with Using Reusable IP ISD 's recent experience with the TORCH processor has, not surprisingly, unearthed more questions than answers when it comes to using reusable circuits. by Jonah McLeod

There has been much discussion about the difficulty in designing with reusable intellectual property. In carrying out one set of our EDA platform benchmarks, our consulting engineering partner, Seva Technologies, encountered some of those problems in taking an existing design--the TORCH processor, developed at Stanford University--and using it. Seva's objective wasn't to build a circuit, but rather to synthesize it to evaluate the performance of different hardware and software platforms. But in the process, the same problems other designers confront when they reuse an existing design unaided confounded Seva's engineers as well.

I want to ask you, our readers, for some input on the problems Seva faced. My request concerns how to take an existing HDL description of a processor--in particular the Verilog description of the TORCH processor--and turn it into a final chip.

TORCH runs a superset of the R3000 MIPS processor and is about a million gates in size. The design contains two integer execution units connected to a six-port register file, a floating point unit with an associated register file, and separate instruction and data caches. The two integer units each have different resources. The processor offers static and dynamic instruction scheduling, with the latter providing a very efficient means of supporting speculative instruction execution. (To find out more about TORCH, go to www-flash.stanford.edu/torch.)

For our EDA platform synthesis benchmark ("EDA Platform Benchmark: Synthesis," July, p. 55), Seva fed the entire 16,000 lines of Verilog constituting TORCH to Synopsys Design Compiler as a single block; all that resulted was an internal DC error message. To get something that worked, James Lee and his colleagues at Seva extracted two modules from the design, regfile and dpath , which they were able to use.

My query deals with the actual conversion of the Verilog description into synthesized gates. One designer who e-mailed me about the processor design--he wanted to run some tests on the circuit himself--complained that he couldn't find any design constraints in the directories. The constraints posted by Stanford consisted of simple constraints that define clock period and some set_drive constraints.

Normally, designers would specify some additional boundary timing constraints, clock cycle specifications, etc., so that the design can be synthesized accordingly. How time-consuming is the creation of those constraints? Is it days or weeks of work?

Another consideration when using an existing circuit is to determine what's needed to incorporate the reusable core into a larger design. What should be included on a list of elements needed to make an existing circuit easy to reuse so a designer can get started?

(There are standards organizations--notably the Virtual Socket Interface Alliance--that are attempting to create such a list. However, VSIA is led by EDA vendors whose ultimate product will be a political document shaped to satisfy the conflicting interests of its members. Instead, what I'm looking for are the views of working designers.)

One element on that list should be a complete synthesis script. Can you describe what would constitute a complete synthesis script for a design like the TORCH processor? Another critical element is the test bench. Can you describe what constitutes a satisfactory test bench for TORCH?

To submit a response to my questions, you can reach me at jonah@isdmag.com. Any information you provide will be greatly appreciated. If we get enough information, we'll publish the results as a report; otherwise, we'll publish individual letters.

I look forward to hearing from you.

On a separate note, I'd like to offer some explanation of the different speeds of the PCs used in our latest EDA platform benchmark. All the PCs were supposed to be 400-MHz machines. However, IBM shipped a 450-MHz machine. Owing to the very tight deadlines we were under to get the benchmark completed, we had no time to go back to IBM, so we ran the test with the faster machine.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  November 1998