design flow

Taking a Graphical Approach to Programmable Logic Design Designers of programmable logic devices can make the transition from schematics to HDL relatively painless by migrating to a graphical design capture tool. by Ken Frick and Eric A. Bumbera

Like many design groups in the electronics world, our particular group within the Business Communication Systems division at Lucent Technologies is moving from board-centric design to a greater focus on programmable logic devices. This transition of course promotes more efficient, cost-effective designs in the face of rising system complexity and increasingly shorter design cycles.

In keeping with industry trends, we're moving to an HDL-based design methodology for programmable logic devices. To ease the transition, we're using a graphical approach that provides an intuitive yet powerful HDL environment for programmable logic design.

Overall, we found that the advantages offered by a graphical environment warranted the time and energy required for the conversion itself. One of our major goals was to make the transition as smooth and as painless as possible to minimize any impact on the part of our designers. The transition was in fact easier than expected. The graphical interface, in particular the use of familiar block and state transition diagrams, shortened the learning curve, enabling our designers to quickly use the tools for real designs. Productivity has increased, but not at the expense of quality--indeed, quality has improved as well.

Our designers have responded well to the transition. If we were to take a poll, most of our designers would agree that adopting a graphical approach to HDL design was the right decision. They appreciate the control and flexibility offered by the design environment, which enables them to achieve the quality they want and still meet aggressive design schedules.

Converting to HDL

One of the initial challenges associated with our decision was helping our designers to adopt an HDL design approach. Our design group consists of seasoned engineers with years of experience creating demanding circuit boards--a major advantage indeed. So it was important to convince them that we were moving in the right direction. Our engineers would undoubtedly have to learn new tools and approaches and make some significant modifications in their design methodology. Understandably, they had questions about our move to using an HDL methodology for programmable logic design and wanted to be sure the change provided substantial benefit.

The decision to use an HDL rather than schematics appealed to us on several levels. Most importantly, the HDL environment would support efficient design without compromising the quality of the end product. It enables designers to work at a higher level of abstraction and facilitates the use of hierarchy. A hierarchical design approach makes it easy to partition complex designs into more manageable pieces, simplifying the design and simulation of individual functions. In addition, the use of an HDL for design capture makes it possible to delay the choice of a target silicon vendor or device until later in the process. Other compelling reasons to use a hardware description language for design capture include easier design reuse, better design documentation, and faster simulation.

Next, we looked for tools that would help move our designers into the HDL-programmable logic environment. We evaluated different options for design capture, functional system simulation, and HDL synthesis. Performance and ease of use were important, but we also wanted tools that would be around for the long haul from a vendor that could provide in-depth and long-term support. It was also important that the tool blend easily into our existing design environment. Another important criterion was having all the tools work together as closely as possible to streamline the overall design process. Our hope was to find an integrated flow that would tie HDL design capture, simulation, and synthesis closely together.

After examining the options, we chose EDA tools from Mentor Graphics. Although the tool set was still being refined by Mentor at the time--it was the precursor to the solution being offered today--we anticipated that it would eventually include all the features we required. Working with a major presence in the EDA market ensured the support and long-term commitment to the product we needed. We especially appreciated the graphical user interface and the hierarchical design offered by the tool, eventually called Renoir. It can generate Verilog or VHDL code from block diagrams, Moore and Mealy state diagrams, flowcharts, or truth tables for programmable logic designs. It also includes interfaces to logic synthesis, digital simulation, hardware-software coverification, and requirements tools.

We started changing our designers over to HDL-based design in 1996. Initially, we worked with the first-generation HDL tools, adding newer solutions as soon as they became available. These tools are now an integral part of our design flow.

Taking a graphical approach

Our designers use this graphical HDL environment to create sophisticated designs in an efficient manner. Instead of having to write structural HDL, they can quickly describe the logic using graphical elements. The same state, block, and flow diagrams and truth tables they used in the past for board-level designs are now available for programmable logic design (see Figure 1).

This familiar environment went a long way toward smoothing the transition to HDL design. The graphical interface and toolbars are so intuitive and familiar that our many first-time HDL designers quickly moved up the learning curve and were generating usable code within a short period of time. Fortunately, this ease of use doesn't come at the expense of design quality. Our advanced designers, already familiar with HDL coding, found themselves creating, modifying, and debugging sophisticated HDL descriptions much faster than they could using text editors.

The integration issues were manageable. It took us only a few weeks to install the HDL tools and resolve some minor issues. The ease of installation was a relief, given the diversity of our tool set and the number of designers we employ.

The environment allowed us to build up test benches quite easily, leading to more robust designs--a very important benefit, since our PBX products must be extremely reliable. Although test benches are important, they used to be a necessary evil that required a significant amount of engineering time to build and maintain. Consequently, hand-coding an entire test bench in HDL was something we put off as long as possible. Using the graphical flowchart editor, we can quickly create the test bench as a flowchart and let the tool generate the behavioral HDL (see Figure 2). This method simplifies what was once a very tedious process. Consequently, we now create test benches much earlier in the design cycle, which helps to improve design simulation and verification and thus raise product quality.

Matters of state

Our group finds the hierarchical capabilities of the graphical HDL design environment especially useful. We can enter the device functionality as block diagrams, from which structural HDL is automatically generated.

This block-based approach enables our designers to explore what-if scenarios. At this higher level, they can examine different approaches, finding the best solution without noticeably retarding the design schedule. To fine-tune the design, they can then move down hierarchically to optimize the HDL code for particular blocks. To facilitate design exploration, we use a flowchart during simulation because it's easy to edit and doesn't have to be synthesized.

Using blocks also makes it much easier for our designers to understand each other's work. At a glance, another team member can quickly comprehend a block diagram. That's certainly not the case with HDL code. Sifting through hundreds or even thousands of lines of HDL code can easily take hours and still leave the engineer confused about the overall logic functionality. Block diagrams minimize that confusion. Likewise, we've found the graphical environment just as powerful when creating datapaths for switching logic or when generating truth tables for combinational logic.

Besides the hierarchical capabilities, we also rely heavily on the state transition diagrams. Since our designs are complex and control-oriented, state machines are a crucial component in designing the FPGAs and CPLDs for our PBXs. Creating a complex state machine--especially one containing a hundred or more states--can be a tedious chore. Before we started using the graphical approach, it could take several days to produce a finished state machine. But now we design the state machine graphically and the HDL code is generated automatically (see Figure 3).

Figure 1	Design flow for graphical HDL
Creating HDL code using Renoir significantly boosts the efficiency of the design environment by enabling designers to use familiar state, block, and flow diagrams and truth tables for programmable logic design. The graphical descriptions are converted automatically into high-quality structured HDL code.

For example, we recently created a complex state machine in HDL with over 100 states in just a couple of hours using the graphical interface. We were able to cut and paste repetitive functions, saving significant time. This same state machine would have taken at least a few days to hand-code in HDL--and orders of magnitude longer to create with a schematic-based approach. What's more, updating this diagram at a later date would have been difficult even with HDL code. The graphical approach, in contrast, offers a straightforward operation. Obviously, this improvement in design efficiency frees up valuable engineering time for optimizing the state machine, as opposed to simply capturing it.

We've found this graphical approach to creating state machines useful for both intermittent and expert users. For those designers who occasionally create state machines, the graphical environment helps them to generate sophisticated structures quickly. If we haven't created a state machine for a while, for example, we often examine the generated HDL structures to brush up on state machine coding techniques.

We were a little more concerned about how the experts on our team--who live and breathe state machines--would react to the graphical design environment. To be truthful, they were highly skeptical of a tool that automatically generates structured HDL code. But after using the state machine editor and seeing first-hand how they could maintain total quality control and still reap the benefits of automation, they were convinced. The graphical interface in no way compromises the performance of the resulting state machine. The designer enjoys full control of the state machine environment, ensuring that the resulting structure will deliver optimal performance.

The virtues of integration

A unique aspect of the Renoir environment is its direct links to powerful HDL simulation and synthesis capabilities. Without having to leave the design capture environment, our engineers can perform compilation, invoke simulation, and then create the necessary files for synthesizing a design. The tool takes care of the details, creating the appropriate data files for simulation and synthesis, and even providing cross correlation among the different tasks to facilitate debugging and verification. This tight integration with downstream tools helped to smooth the transition to HDL design and consolidate the overall design process.

Renoir interfaces with all the major simulation and synthesis tools on the market today, working particularly well in conjunction with the Mentor Modelsim simulator and Leonardo Spectrum synthesizer. As a result, our designers can quickly compile, simulate and, when satisfied, synthesize the design.

Since compilation occurs continuously during design capture, the ability to compile without having to leave the design environment is particularly useful. This multitasking capacity greatly simplifies the compilation task and encourages more frequent compilation, leading to more robust designs.

Once we've created a design, the next step is to perform functional simulation. Functional simulation isn't a single event--nor, for that matter, is design capture. An ongoing, iterative cycle occurs between design capture and functional simulation. Often, the cycles depend on the hierarchy of the design. We first design and verify the lowest-level functions. Then we move up a level in the hierarchy to add new functions or combine lower-level functions, which we also verify. This process continues until we complete the top level of the design.

Figure 2	Flowcharts
Using Renoir's flowchart editor, designers can quickly create comprehensive test benches as a flowchart early on in the design cycle.

When it comes time to simulate a design, we can choose to invoke the simulation either within the design capture environment or outside it. The usual approach is to stay within the design environment, as it saves time and greatly simplifies the simulation task. Renoir automatically generates the code for the simulator, puts the data in the right directory, and then calls the appropriate compiler. But sometimes our designers want to perform functional simulation outside the design capture tool. For example, the simulation might require files that specify the setups for wave windows in another directory. In that case, it makes more sense to invoke the simulator through its own interface--that is, outside the graphical design capture environment.

Another feature is the powerful debugging capabilities that stem from the tools' tight integration. For example, during simulation, a designer can watch the progression of the simulation within his state diagram, flow, or block diagram. The graphical HDL environment highlights the progress of the simulation at any given time. The color of the bubble in a state diagram, for instance, changes to indicate where the simulation is at that particular moment. Called animation, this feature gives immediate graphical information that is invaluable when debugging a programmable design.

Automatic scripts

Once we've finished the functional simulation, we synthesize the design. Here again, the tight integration between the design and synthesis tools streamlines the task. Our engineers can have the design capture environment automatically create the script for the synthesis tool, an useful feature for larger programmable designs that might contain several hundred HDL files. To do that by hand--and to get the files all in the right order--can take some time. Automatic script generation makes it much easier to repeat a synthesis run after making design changes. It also simplifies the tracking and controlling of different synthesis runs with variations in parameters, constraints, and hierarchy. In fact, we treat synthesis scripts as part of our design documentation, along with constraints.

At the place-and-route step, where we implement the design netlist in a specific device, we must choose a specific programmable logic device vendor and family. However, if the HDL generated remains generic--in other words, contains no unique component instantiations or attributes--we're free to synthesize for as many vendors and device families as we want. This flexibility can offer a real advantage when we're looking for the most economical implementation or have other dynamic design considerations, such as combining our design with another programmable logic design.

Figure 3	Hierarchical stae diagrams
The Renoir state transition diagram editor allows designers to enter and refine extremely complex state machines--like this one with hierarchical structures--in less than a day.

Programmable logic vendors usually provide tools for this task; we have loaded several on our PCs and workstations. Each tool has its own user interface and its own method for the input of constraints. The place and route activity can involve two loops. If the design doesn't "fit"--doesn't meet area or preliminary performance criteria--we return to either HDL synthesis or, if design changes are warranted, all the way back to design capture. Depending on design complexity or performance requirements, we can spend a lot of time in these loops.

The place-and-route tools yield multiple outputs, generating structural HDL and timing information (usually in Standard Delay Format) for HDL timing simulation. Some tools may output a netlist usable for schematic-based simulation (EDIF, for example), while all generate reports for timing, pinout, and other parameters. Finally, the tool generates the information required to program the device.

The same test bench environment created for functional simulation can work for the HDL timing simulations, because the graphical design environment used to capture the original test bench flexibly supports multiple points of view for the same block diagram. As a result, our engineers can substitute functional-level HDL information with gate-level HDL. To create the environment needed for timing simulations, they simply open a new view for the existing block diagram.

It's difficult, of course, to directly quantify improvements in design throughput, but the group as a whole is doing well in terms of meeting schedules and creating new designs. The quality of those designs has certainly not suffered because of the powerful capabilities of the graphical environment and the ease with which we can produce and optimize logic structures. Our FPGA and CPLD design process is built solidly on this graphical, HDL-based flow, making it an integral part of the way we create our designs, and our group will expand on the approach for future designs.

Ken Frick joined the Business Communication Systems division of Lucent Technologies, Inc. in Denver in 1980. He's a member of the technical staff involved in FPGA design.

Eric A. Bumbera has been an applications engineering consultant at Mentor Graphics Corp. based in Warren, N.J., for the past 8 years, working with customers in the areas of design and verification. Most recently, he's been helping customers adopt high-level design flows and hardware/software coverification. He has more than 14 years' experience in the EDA and electronics industries, including as a project engineer designing system-level components, ASICs, and PLDs.

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

integrated system design  April 1999