System Design

Designing a 100 kgate Set-Top Box ASIC Using Behavioral Compiler with Verilog

A first-time user of Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys ' Behavioral Compiler describes the development of a high-performance ASIC.

by David C. Black

At Apple Computer (Austin, TX), our small design team was given the task of creating a 100 kgate 54 MHz ASIC for a set-top box. Because of shortened design cycles and insufficient resources, we changed the design methodology from gate-level Verilog to behavioral-level Verilog and used a tool from Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys Inc. (Mountain View, CA) called Behavioral Compiler.

We used Behavioral compiler on a design implemented in the 0.5-µm CMOS TEC2000 Embedded Memory Gate Array Family from Texas Instruments Inc. (Dallas, TX). The design contained vertical convolution that improves the appearance of graphics on interlaced displays for NTSC (U.S.) and PAL (European) televisions (see Figure 1 ). Secondary features of the design included serial communications, a watchdog timer, miscellaneous address decoding, and bus control. Since the design interfaced and managed standard DRAM, we implemented internal line buffers and lookup tables with embedded memories.

Figure 1. The block diagram shows the connections of the various processing blocks within the IC.

The design team was quite small. I was the sole logic designer on the project and was also responsible for tools acquisition and Unix administration. Additionally, we hired an external contractor to provide functional verification tools and tests. Finally, ad hoc responsibility for reviewing the design was passed around among other engineers.

Motivations I chose Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys ' Behavioral Compiler because it promised to provide a high level of abstraction that would enable easy coding and fast simulation, improving the design-cycle time by focusing less on lower-level details and more on the desired functionality. Additionally, a commensurate reduction in text would reduce typos. Reductions in debug could also be realized because behavioral designs tended to simulate faster. For video design, this can be a real issue. A single screen image of data can easily take 8 to 10 hours using conventional RTL simulation. Behavioral's simulations cut the time in half.

Another aspect of higher levels of abstraction is the relative ease in making changes. Because state machine coding and register assignment was avoided, commensurate reductions in complexity made the code easier to change. This also aided reusability of the code.

Figure 2. The design flow through the tool set emphasized functionality.

Finally, I chose Behavioral Compiler because it offers a number of optimization and design exploration features that improve code size. Since the video processing portion of the design is a natural pipeline, the tool's pipeline optimization features would be extremely handy.

Methodology We followed a simple methodology for the project with some home-brew automation (see Figure 2 ). We emphasized behavioral simulation for speed and minimized RTL- and gate-level simulation. For final simulation, we performed min/max gate-level simulations with fabrication and some functional test vectors.

I spent some time documenting functionality, then quickly coded the design. At first, I wrote low-level behavioral simulations but bowed to time pressures and completed the design without low-level functional verification. Mid-way into the design, a hired contractor created a board-level test environment that conformed to the functional test specification. He successfully verified various blocks of the design from the pins out.

For fabrication test synthesis, I used Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys ' Test Compiler for full-scan insertion and ad hoc test vectors to cover internal memories, non-scanable sections, and parametric testing via JTAG. We dedicated several pins for test functionality.

Design description

Here are some of the technology characteristics of our design: CMOS 0.5-µm 100 kgate array. Plastic quad flat pack (PQFP). 54 MHz main clock. The following are design elements: Video processing "pipeline." DRAM controller. Asynchronous processor bus interface. Additionally, I chose to adhere to the following constraints: Synchronous design including reset. Other clock domains synchronized to main clock (using RTL). The final implementation included the following: 38 kbits of embedded synchronous SRAM. 3 10 kbit single-port SRAMs. 4 dual-port SRAMs. 2 miscellaneous single-port SRAMs. Approximately 60 kgates random logic.

File-naming conventions We assigned source files a common naming template. All ASIC HDL source was under a single directory, hdl/. Every Verilog module was in its own directory. Verilog module names began with an uppercase letter. Source files were named <Module_Name>_<Type>.v.m4, where Type was beh or RTL. A makefile rule processed source files and renamed the resultant Verilog <Type>.v within each module's directory. This allowed the Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys script to find the source code and determine behavioral scheduling or RTL compilation. The Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys script was helpful for the following reasons:

• It aided module/file identification for other readers, especially when tracking-down problems.
• It allowed for automation of some tasks.
• It aided the scripting of mixed behavioral/RTL design.

Default script conventions A directory contained commonly used dc_shell scripts. A symbolic pointer from each user's home directory to the common script implemented the common directory . Synopsys _dc.setup . To allow overrides, the . Synopsys _dc.setup script set up a search path that included, in order, the current directory and script directory. The script used the get_unix_variable() function for selecting other setup scripts. For example, get_unix_variable(VENDOR) yielded a name to select the target vendor setups. This created a new script containing vendor specific information for quick netlist retargeting.

A common script directory contained a script for each of the following tasks:

• Determining module type and file names.
• Behavioral analysis and scheduling.
• Default constraints with overrides.
• RTL compilation.

Figure 3. The partial listing shows how signals cross always block boundaries.

The common scripts allowed us to focus on coding, and it only required overrides for the exceptions from general rules. Once in place, common scripts simplified development. They also avoided reinventing each module and ensured general fixes were applied to all modules.

The scripts take advantage of file naming conventions. Source Verilog was always named either beh.v or rtl.v and a similar approach was taken for all output files.

Naming conventions aided architectural debug An interesting aspect of Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys behavioral coding is the concept of "signals" versus local "variables." Signals are primary I/O; although, in a design with more than one always block, a signal is any wire or register that crosses always block boundaries. On the other hand, local variables are entities that stay entirely within the bounds of the always block (see Figure 3 ).

An aspect of Verilog that I was not familiar with was that registers/wires can be defined within a begin/end block. Previously, I defined all variables at the front of the code. Using definitions within begin/end blocks better illuminates local variables.

Signals are either input or output resources. Reading an input or writing an output is a scheduled event with important implications to resultant code. By contrast, local variables are used without similar scheduling impacts. Additionally, output signals are the only items that may use Verilog non-blocking assignments; whereas local variables must use blocking assignments. Thus, it is important to keep these elements distinct within code.

I settled on maintaining a naming convention to aid in this effort. Using a consistent suffix convention, I was able to write tools that automatically ferreted out some mistakes (see Listing 1).

Applicability of behavioral code A natural question when first introduced to behavioral compiler is "how much of my code will be applicable to behavioral coding?" When I first approached this question, I limited behavioral compilation to the design's video processing sections. After taking a behavioral compilation training course and beginning initial coding, I discovered many more modules would benefit from behavioral coding. Behavioral Compiler produces a synchronous design with a state machine and datapath. Since our design was fundamentally synchronous, any state machine in the circuit presented an opportunity for behavioral code. The reduction in coding time again justified the use of Behavioral Compiler.

Here are some statistics from the design:

• 51 modules with 8k lines unexpanded m4 source (34 percent comments).
• Hierarchy 6-levels deep (2 template and 4 functional).
• 18 behavioral modules (5500 lines 60 kgates).
• 19 RTL modules (2100 lines 5 kgates).
• 14 structural modules (650 lines).

Exploration Pressed for time, I focused on quick implementation and minimized architectural investigations. A displeasing aspect of Behavioral Compiler, at the time, was some of the mechanisms to constrain the design relied on source-code line numbers.

One area where I made architectural tradeoffs was in pipelining. Since the pixel clock-rate fixed the initiation interval, there was only one variable to change. Area was a second concern in the design, so I used the largest latency available to maximize resource sharing of multipliers.

EDA design environment

At the outset of the project, our group had no EDA tools for ASIC design. Due to our remote location from main R&D, I was also left to support the workstations myself. The following is a list of hardware and software we acquired to execute this design. EDA hardware 1 HP735/125 MHz, 260/4G, HPUX 9.05. 2 HPJ210/110 MHz, 128/2G, HPUX 9.08. 1 SPARC20/100 MHz, 128/2G, Solaris 2.4. 2 Gbyte project disk space. Tape backup and UPS. Self-administered. EDA software 1 InterHDL (Los Altos, CA) Verilint Turbo license. 2 Cadence (San Jose, CA) Turbo Verilog/Cwaves licenses. 1 Veritools (Palo Alto, CA) Undertow license. 1 Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys Behavioral Compiler license. 1 Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys DesignWare Developer license. 2 Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys Design Compiler licenses. 1 Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys Test Compiler license. 2 Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys DesignWare Foundation license. Idealogy (Boulder, CO) Panda corporate license. Internet software GNU make for design management. cvs & rcs for version management. GNU m4 for macro support. Perl 5.001 for custom tools. Specialized scripts I/O ring synthesis (table driven). Structural stitching (bottom up). DW memory wrapper generation. DW simple function implementation. Log file checker. Statistics tools (lines of code, area, timing, bug management).

Behavioral Compiler features three scheduling modes; however, I used two: cycle_fixed and Superstate_fixed . I felt leery of superstate_floating reordering operations, and I wanted to minimize schedule delays learning to control it.

Scripting hints Here are a few useful ideas for synthesis scripts. If the number of Behavioral Compiler licenses is less than the number of Design Compiler licenses, consider writing a script while waiting for a license to free up. Its worth the extra time, especially if you run large numbers of batch scripts.

Don't forget to use the set_margin command to allow for state machine timing. This is recommended by Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys . Use it!

In your scripts, the two aliases in Listing 2 are very handy, even for non-behavioral use.

Place Abort_unless_ok immediately after any analyze, elaborate, read, schedule, link, and compile commands. This prevents scripts from continuing past a failure and helps to nip problems in the bud.

Before writing out a final db ( Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys ' database representation) after compilation, be sure to set the uniquify_naming_style and perform a uniquify-force or the equivalent. Behavioral Compiler creates designs for state machines that may overlap between modules. This will mess up your top level links--as it did for me. Here is some specific code you could insert before you write:

uniquify_naming_style
= $module_name + "_%s_%d";
uniquify -force;

When writing out RTL source for simulation purposes, the following code gave the best results:

verilogout_equation = FALSE;
write -hierarchy -format
"verilog" -out "rtl.v";


Early adoption issues In general, I had very few execution problems with Behavioral Compiler; however, there were a few rough spots. Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys appears to develop tools for Sun Microsystems (Mountain View, CA) and then ports to Hewlett-Packard (Palo Alto, CA). There are some problems that I experienced as a result of this. Early in development, Behavioral Compiler (version 3.2a) failed several times during scheduling. I discovered error handling on the HP workstations was not as graceful as on the Sun (at the time, I only had an HP system). As a work-around, Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys suggested I compile behavioral code on Sun for these cases. Fortunately, we were about to acquire a Sun SPARC workstation. This "mini-crisis" sped the acquisition of the workstation and solved my problems.

I also encountered a problem when a module apparently had a "large" case statement and was taking a long time--over 18 hours--to compile. Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys acknowledged this was to be addressed in a future version of Design Compiler. They suggested that I break down the case statement and drop the parallel_case directive , which helped a bit.

Finally, a familiar "feature" seemed to rear its ugly head--"synchronous resets." Apparently, a default setting of some variables combined with my settings to create a fatal error. Providing Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys with a test-case and some discussion revealed the problem. Setting the variables correctly avoided the problem; however, it did take some time to debug.

Naturally, none of these "features" appeared at a good time, and they all introduced small delays. However, the "features" also provided learning opportunities--as did the rest of the design process. We successfully implemented a new design methodology that changed our code to a behavioral level of abstraction. The new design flow enables faster design cycles and higher performance in the behavioral coded sections.

This article was presented to the 1995 Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys Users Group and first appeared in John Cooley's on-line newsletter ESNUG, Posts 235 and 236.

David C. Black is a member of the Interactive Television Group, at Apple Computer (Austin, TX).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com

integrated system design  June 1996