Hardware/Software Co-Design:The Concept of Design Re-Use

As the complexity of IC design has increased, a trend to include ever larger portions of functionality on a single chip has been observed. Programs that once would have been considered ‘software’ are now encoded directly into memory within the chip structure. In the past a processor core was used which was controlled by discrete components elsewhere on the same circuit board. Extensive software support in form of compilers, assemblers, and simulators was also encoded into chips separate from the processor. Today these components, as well as peripheral modules (e.g., UART-serial interface, and PIO-parallel input/output interface) are used frequently in so called ‘embedded processors’. These discrete components are inserted block by block directly into the circuit during the design phase.

The Concept of Design Re-Use

Today more functions can be readily integrated into an IC design than can be designed in a reason- able development time by a design team. Even a highly productive engineer does not have sufficient time to develop a circuit design from scratch. Ever shorter development periods demanded by today’s market only exasperated the situation. This situation produces a so called ‘productivity gap’. This gap defines what is possible and what can be accomplished in a reasonable time by a designer. This gap is constantly expanding as improvements in what technology can allow and what can be reasonably done designer compete. A reduction in the gap can only be realized by new procedures and a change of paradigms, Fig. 7.1.

Currently ASICs contain 150k gates on average and 400kbits of memory. Designs of this complexity are typically described by 10,000 lines of  code (VHDL). Five times as many lines of code are required for large, complex chips, but this task is still performed economically. In the future there will be 100,000 lines of code, delivering 500 k gates and with more than 1Mbit of memory. Even designs of this magnitude do not consume what is technologically possible in silicon using 0.18 μm or 0.13 μm technology, see table 7.1.

It has therefore only become possible to design with a high level of abstraction by re-using already developed and established modules in a block de- sign. The growth in complexity must be tempered by partitioning tasks into building blocks. Con- centration on interfaces and standardisation of the data exchange can be carried out to help reduce the overall risk when using this design framework.

Programmable structures and processor cores, which have become common cell blocks, the principle of ‘re-use’ is already applied. So called ‘hard macros’ are placed directly in the chip design; these blocks have been previously verified by use in a previous device and are completely pre-routed. Transferring these blocks into an- other technology with smaller device structures, other designing principles, etc. is difficult and can require substantial development costs. For example: the transition of a technology from 2 metal layers using 0.7 μm CMOS to a modern 0.35 μm technology or 0.18 μm technology with 3 or more metal layers forces a total re-organization of the netlist, a replacing of the cells, and a re- routing of the core. Synthesis tools can help with the new circuit layout, but timing verification must be redone.

What is left to Design? The main idea; the intellectual content of the design, or simply the Intellectual Property (IP).

As the use of VHDL and other hardware design languages has spread it has become possible to formulate an idea in an executable form. Simulators allow the function to be reconstructed and verified against a certain specification. Synthesis programs  create netlists. Additional programs allow blocks to be placed and routed automatically. Functional cells can be generated in the target technology.

Descriptive formulation in high level languages is independent of technology, and easily modifiable. This methodology helps to contain development costs. A similar benefit can be seen in software programming where the use of high level languages (e.g., C or C++) help reduce development costs. IP could play the same role in IC design as libraries do in software programming. IP may be transferred between designers and become the subject of trade and licensing.

Within the software area the transition to high level languages has led to losses in performance of the languages; programs are related to programs assembled in code beforehand. Block IC design also has a large area of reduced efficiency when compared to hand optimised designs. This loss, however, is compensated by a large increase in de- sign productivity, and thus in development speed. Since chip area is plentifully available the new paradigm reads: ‘Time to Market’.

The application of IP modules strengthens this trend. The old paradigm of ‘optimization to minimum chip area’ increasingly loses its meaning. It has already been affected by sub-optimal area consumption by using the standard cell design style compared to full custom design style.

Hard/Soft Macros, Virtual Components and Intellectual Property Devices (IP) The term IP can best be translated as ‘intellectual property subject’ and can be generalized by the concepts soft macro and hard macro which have existed in the design world for quite some time. Lewis in 1997 said that An IP is a design object, predominant value of which came out from the knowledge of the producer, and its revised design would take significant time.

The object is derived from IP, obtaining a piece of silicon by synthesis, placement and routing of standard cells. This is the instances of the IP. ‘Small IP’ in particular interface modules are sometimes called virtual components (VC). Both are described as discrete components in technical data sheets and have guaranteed levels of performance. Today, IP can be differentiated as follows:

• Hard IPs are described at the mask level (e.g., by GDSII data). Typical examples are standard cells provided by the manufacturer, large processor cores (e.g., ARM 7TDI, Intel x86, and TI 320C25), and analogue or mixed signal cells; the latter have substantial dependence on the technology. Complete transceiver and RF front ends are available as hard IP. Common genera- tors for RAM, ROM, MPLY, etc., belong to this class as well, although these are configurable in some way; even though they are configurable, the result of these generators are geometrically defined blocks which cannot be transformed or restructured.

• Firm IPs describe the function at netlist level with predefined placing, however without de- tails of routings. Typical examples are nearly all cores used in FPGA’s. Firm IPs are not directly mappable to other technologies and in this way they are technology specific.

• Soft IP describe the function of the module in a high level language (e.g., VHDL or Verilog). Netlists are produced by synthesis tools. An appropriate program maps to the target technology. Interface modules are typically for this style: basic digital blocks (e.g., counters, adders, shifters, PCI interfaces), small controllers, like the 8051 & 6805-family, digital filters, and more complex functional units like MPEG decoder, viterby decoder, etc. These blocks can be parameterized and are altered to meet the application requirements.

Sometimes there may be a floating transitions be- tween types. With soft IP there are mechanisms which prevent copying, modification or even visualization of the core. This is done to protect copyrights of the IP provider. In many cases, to achieve the desired performance level (register transfer level, RTL) most of the code is written in a structural style, not a behavioural one. This looks like a netlist description. Together with scripts for synthesis, which control the mapping to the target technology and preplacement information, these IPs are more Firm IP than Soft IP.

Based on statistics of design and re-use [7.6] data- bases which keep their cores have been categorized with 49 % hard IP, 25 % firm IP and around 22 % as soft IP. The remaining 4 % are model descriptions at a purely abstract language level. It is predicted that as process standardization and protective mechanisms mature, the portion of Soft IP will strongly increase. The use of building blocks outside the founding organization places a high demand on documentation and quality of the design object. The more complex is the functional block, the greater the expenditure for documentation and interfacing. At the same time, a smaller probability of block re-use can be expected in future. Exceptions are processor cores and standardized interface building blocks (e.g., PCI interface blocks).

Virtual components (VC)

One of the most importent building blocks, be- sides the standard cells themselves, are the generators of regular blocks. Adders, multipliers, counters, shifters, FIFO Memories, and other well known digital blocks can be automatically gener- ated through the use of VHDL statements or other similar mechanisms. Given the bit width of a data path and a general architecture selection, these blocks are derived from a prototype in a systematic fashion with a predefined performance.

Fig. 7.4 shows the input form of a generator as it is used in a typical design system for a FPGA (Actel). The generator produces a model in VHDL or Verilog, with timing data and anticipated performance. This information can be used by a digital simulator or by a synthesiser to generate a netlist for the block. Furthermore it creates a symbol for use in schematics. These automatically generated building blocks are standardized in the Library of Parameterized Modules Standard (LPM). More information on LPM can be found in chapter 17 of this book.

The generators enable detailed selection of an architecture (i.e., a ripple carry architecture, a look ahead carry architecture or a carry select archi- tecture). This affects the timing, performance, and physical size of the block. Generators can be used for different levels. Some generators (e.g., MENTOR LOGIC BLOCKS) are primarily made for the simulation level, essentially they generate behavioural code. These generators are called soft generators because the synthesis process has to be performed at a later time on the results. Since these generators create graphic symbols automatically, they are usable during schematic design input, and they permit fast, clear representation on block schematics.

Using parameterized generators for mapping of arithmetic operators ‘+’ or “*” is called synthesis. If this type of operator is found in the code the synthesis includes a function call for a synthesis library component. Attributes specify and select the appropriate architecture, whilst word size is taken directly from code declarations.

If these library generators are not used the arithmetic operators are analyzed during synthesis in accordance to the IEEE 1164 packages ‘std_logic_arith’ into their basic gates. This technique usually requires much more area and a time delay. Once disassembled, the architecture of a carry select adder or a Booth multiplier cannot be found again in a long synthesis run. Extensive IP libraries are offered for synthesis, see table 7.2 and 7.4.

Parameterizable IP for analogue components (e.g., A/D converters, switched capacitor filters, building blocks for signal processing components and operational amplifiers) are available to the modern designer. These are mostly hard IP generated and are provided in a predefined technology.

Table 7.2 gives an overview of available parameterized IP and generators.

Generators are preferentially found in the FPGA design systems of ALTERA, XILINX, ACTEL and others. In these cases it is easy to parameterize because the hardware is programmable. Generators are commonly provided by third party providers. These providers work closely with both the EDA companies and technology providers

Standardisation, the Virtual Socket Interface Alliance (VSIA)

Spreading the re-use idea is fundamental to the standardisation concept. Standardised should be

• the terms;

• the description forms;

• the models;

• the delivery items;

• the basic legal conditions;

• the EDA aspects in conjunction with the use of virtual components.

In this endeavour the Virtual Socket Interface Alliance (VSIA) was formed by the important, active companies in this area [7.27]. It is their task to establish standards and distribute information on IP and re-usable components from a central location, or their stated goal is: “To specify or recommend a set of hardware and software interfaces, formats, and design practices for the creation of functional blocks that enable the efficient and accurate integration, verification and testing of multiple blocks on a single piece of silicon” [7.27].

More details on this subject can be obtained from the VSIA web site at http://www.vsia.com. This website contains a wealth of information which is freely available for download, see table 7.3. De- tailed specifications, however, are only accessible by members. VSIA represents the interests of IP providers and manufacturers, as well as IP users and customers. The VSIA organization tries to accommodate the interests of both sides. VSIA has  demonstrated its influence on modelling concepts, deliverables, and on the manner in which IPs are implemented into EDA.

Virtual Components as Commercial Objects

Every important EDA provider delivers virtual components and IP today. In most cases they operate as brokers who sell the technology of smaller design houses. A small group of ‘spin- off’ companies which gained knowledge working on design projects for the IP market now sell  their know how of special cells. A partial list is shown in table 7.4. Everyday new companies are founded specializing in this area. A database of these speciality companies can be found at http://www.design-reuse.fr. This website is main- tained by TIMA/Grenoble and at present contains more than 4 000 IPs in a huge database. For each a description, data-sheet, and address of the provider is given. Access to the data base is free of charge, but an on-line registration is required.

In IP marketing the business model of licensing is pursued, similar in structure to software licensing, license fees typically entitle the user to the use of the core in a single design. If additional designs are desired, the license must be renewed; additional licenses are typically provided at reduced costs. At present license fees are significant; they can begin at a few thousand dollars for an FPGA interface core to several $100,000 for a high quality RISC processors (ARM). Smaller controllers (e.g., the

8051 type) are available at around $20,000 and upwards. Owing to strong competition in the market and an increased availability of standardised basic blocks, a price reduction is anticipated in the future. As rule of thumb the price for a license is around 15 to 20% of the cost to design the block from the scratch. It should be noted that license fees cover more than just naked code; the fees may also cover additional services, employee training, documentation, and test time at a site or a workbench to verify the core performance. Adaptations for special customer needs are often made. FPGA cores frequently offer little or no support; for this reason they are often offered at much lower rates than real ASIC designs.

Significant importance in the market must be ascribed to the controller and processor cores, be- ginning with the small 8051 family through to the larger 32 bit RISC cores (e.g., the ARM family). These cores are used in millions of telecommunication devices (e.g., mobile phones, personal digital assistants (PDA) and other mass consumer applications). The cores, when combined with special electronics, form a SOC ASIC. Furthermore, analog cells (e.g., A/D converters, RF components, receiver frontends, and modem components for telecommunications) are important to the ASIC market volume. These blocks are often avoided by systems companies who are not able or willing to invest in analog skills or full custom design for their ASIC development team.

IP and processor cores are provided by universities at no charge under public license conditions and can be downloaded from the internet. A collection of links is maintained at the university of Ham- burg, Germany at http://tech-www.informatik.uni- hamburg.de/vhdl/vhdl.html. Freely downloadable models and links to servers with similar information can be found at this website. The author, who has developed the FHOP16 microprocessor core, offers it and software tools for its implementation without charge at http://www.asic.fh- offenburg.de. A quick search on the internet yielded two processor cores of the 8051 family, one ERC32 core utilizing a SPARC architecture, a PIC clone, a 8085 clone and other less known cores, all available for free. Another valuable source is the website of the Free Model Foundation FMF at http://vhdl.org./vi/FMF. FMF distributes free VHDL-cores. A good source for VHDL models are obtainable at the RASSP Project http://rassp.srca.org. RASSP (Rapid Prototyping of Application Specific Signal Processors), a DAPRA project with a $150 million budget. European developers still dream of such govern- mental support. However, in Europe there is the Open Systems Initiative OMI; the OMI combines activities in this field and is a good source of software and VHDL models. A process similar to the software/operating system is anticipated in this field. LINUX, primarily used in universities, is now spreading into traditional markets. There is enough space for public domain development adjacent to commercial development.

Upon delivery, a virtual component should contain at least:

Soft IP

• VHDL code (or Verilog);

• synthesis script;

• test patterns for the simulation (stimuli), or workbench;

• description of signal behaviour and functional- ity;

• bus model with timing;

• documentation, data sheet with performance data and description.

Hard IPs

• description of geometry (Gds II);

• LVS-files (netlist or similar);

• used design rules;

• Simulation model in C or VHDL (description of behaviour);

• stimuli files or workbench;

• test pattern and associated results;

• documentation with data sheet and performance data.

These are minimum requirements. Typically there are numerous documents detailing the model. When comparing hard IPs and soft IPs, verification and implementation of hard IPs require additional metrics and supporting documents. In order for some metrics to be checked (e.g., a layout versus schematics check (LVS)) netlist information must be available. Since the provider does not want to give detailed connection diagrams away, com- plicated and pedantic mechanisms are commonly employed. Model information and cell layout are provided independently. The two may not even be

derived from the same origin; as a consequence they may not be consistent. Even so, the cell is qualified by silicon prototyping and then verified by measurement. Performance data is reliable with a defined process. Hard IP corresponds mostly to the discrete components used on printed circuit boards.

Soft IPs are charmed, in that they can insert them- selves smoothly into the design flow of the customer, thus the consistency problem is avoided. Performance data, however, depends strongly on the synthesis, and are not typically fully guaranteed. In order to protect the provider and limit the degrees of freedom in the synthesis, the VHDL code is generally delivered in a structural VHDL style. Mapping may be done on a generic library. With the delivered scripts the mapping is normally done without difficulty from the generic library to the target technology. A complete and exhaustive simulation, including timing, is required for each case. Because a simulation of the core cannot be done by the customer without detailed knowledge, complex cores such as microprocessors are not well suited for soft IP. A huge verification effort is required for both cases. A common solution of this verification issue is exhaustive workbench verification; unfortunately this hides detailed performance information about the core, but it does ensure the integrity of the functionality.