Designing Connected Information Devices Using Programmable Logic

A veteran of the design wars gives a personal view of his migration from ABEL and schematics to VHDL modules for FPGA design development.

by Stephen J. Fricke

The rapidly expanding market for Connected Information Devices (CIDs) follows the explosive growth curve previously seen with products such as cellular phones, pagers, personal computers, and fax machines. CIDs include pagers, cellular phones, PC companions, and other devices that can seamlessly synchronize information with desktop computers and specialized servers. By making it easier and more efficient to communicate, manage, and share information, each of these products has become important to millions of business and home consumers following their introduction into the general market. The CID market is characterized by rapidly evolving technology and a constantly changing competitive landscape. The ability to bring a new product from conception to distribution in a remarkably short time is a requirement for success.

Starfish Software, a wholly owned subsidiary of Motorola, Inc., supplies customized designs for CIDs. I work there as a hardware/software engineer and consider myself to be a veteran of the industry, with 20 years of digital electronics experience. I started designing hardware with discrete components containing simple gates. As my career has progressed, the industry has moved from TTL to CMOS, then PLDs and now FPGAs and ASICs. Each of these moves has contributed to higher operating speeds, lower power consumption, and easier design, as well as reductions in physical size.

In addition to these improvements in hardware, engineering tools to develop electronics have matured considerably. I remember having to use logic templates to hand-draw schematics onto vellum, then running the original schematic through a blueprint machine. The nasty ammonia smell of the blueprint machines seeping through the engineering areas of the company is a thankfully distant memory. Now a variety of CAD tools are available; I use tools from Viewlogic Systems, Inc.

These days I create schematics using existing symbols from a variety of manufacturers, or develop my own symbols using the existing symbols as a baseline. Not only is it easier to design schematics, but now the design can be emulated using the physical characteristics of the target device. Emulation saves development time while reducing errors that would have to be corrected after product development.

From schematic to VHDL

During the past three years, I have been implementing hardware using Viewlogic for schematic and entry emulation, as well as netlist conversion to Cadence's Allegro layout tool for PCB design. I have been mixing PLDs with the FPGAs using ABEL code for the generation of the logic in the PLDs and schematic entry using the manufacturers primitives for the logic inside the FPGAs. This was great, but if I wanted to change any parts or manufacturers, I would have had to reimplement the schematic for the FPGA.

In the past six months, I have changed my FPGA implementation method from schematic entry to VHDL code. I still consider myself to be a VHDL novice, as I have been learning the VHDL language on my own. The transformation from schematic entry to VHDL, however, was fairly easy as I am familiar with both software and digital hardware, and the structure of the VHDL format can be related to C code. I was up and running within a month by editing VHDL code samples to fit my specific requirements.

I had several good reasons for changing my design techniques from using schematics with ABEL to designing with VHDL code. Of course, I don't think that schematic entry will ever disappear completely, especially if the design consists of both digital and analog components. I also like viewing my designs in hierarchical block diagram form, which schematics reveal when implemented properly.

The problem with using schematic entry alone is that the sheer bulk of large designs is overwhelming. Using ABEL code helps reduce the magnitude, but ABEL compilers are generally restricted to PLDs and PALs. I don't object to using ABEL and have become proficient with it, but without a compiler that can target FPGA devices, I find that ABEL isn't well suited for FPGA design.

Enter automation

Viewlogic's Intelliflow tool is a flow manager that automates a number of functions that I would otherwise have to perform manually. I began using the tool with schematics and ABEL and still use it now that I have switched to VHDL. I can use the tool to create a symbol from my ABEL or VHDL code, as well as simulate my design. I can also use it to compile my schematic, ABEL, or VHDL into the target device and create a symbol with pin attributes for use on my printed circuit board (PCB) (see Figure 1).

The tool uses FPGA Express, also from Viewlogic, as its VHDL compiler. FPGA Express runs in the background, just as the ABEL compiler did. The only thing in the flow that has changed is the code itself. I compile the code, make the corresponding symbol, place the symbol on the schematic, and run the simulation. Once I am satisfied with the simulation results, I invoke the back-end compiler through the tool, to route the target device.

I design and build my own VHDL subroutines--which match directly with my existing symbol parts--and replace them directly into my schematics. I then use Intelliflow to build individual symbols and simulate the functionality of the module. The tool automatically compiles my VHDL module for simulation and launches Viewlogic's Fusion/Speedwave simulator. After validating the function of my VHDL code with simulation, I then add that module to the library of building blocks that I use in my continuing designs.

Figure 1 - Mixed-Schematic and VHDL design flow
The mixed design flow begins with the preparation of the VHDL code and its simulation, followed by the transference of the VHDL object into the schematic, and ends with timing verification.

At this time, Starfish is targeting devices from Xilinx, Altera, Actel, and Gatefield, although we do use the device and manufacturer that best fits our needs. Eventually, we will move the designs into ASICs. One of the nice things about implementation with VHDL is that it can easily be compiled to whichever manufacturer and chip we choose. I then use Intelliflow to compile the schematic to the target device.

I entered into the VHDL realm carefully by replacing schematic modules individually with VHDL look-alike counterparts. As my confidence has grown, I have turned to building VHDL modules and using them as components in an overall VHDL design. I then use FPGA Express to synthesize both schematic and VHDL. I enjoy the luxury of RAM-based targets, which allow me to quickly download and troubleshoot the design. Synthesis automatically adds input and output buffers and pins. Then, I assign specific pin numbers in a .pcf file.

Once I have built an FPGA part, I use Intelliflow to generate a symbol containing pin functions with corresponding pin numbers. The tool also generates power pins as well as unconnected pins. I can use the symbols in an overall schematic that mixes different parts from different manufactures. I can then simulate the overall schematic using PALs, PLDs, FPGAs, and individual components. This process lets me complete a hardware design with a 99-percent confidence level before I have to go to PCB implementation.

Drumming up the FIFO

So far, I have employed this method in designing a number of eight-bit computer peripheral devices, including an asynchronous dual-ported FIFO, interfacing two CPUs. I implemented this design from a mixture of VHDL code and schematics on a Xilinx prototype board. The board contained a Xilinx XC4010E and discrete data buffers, which allowed a cellular phone CPU to communicate with another, dedicated CPU. The CPUs resembled each other, except that one CPU had an active write line, the other an active read line.

In the schematics used for this design, the top-level schematic served to test the design (see Figure 2). I used several different VHDL models to form test vectors to simulate the dual-FIFO schematic, along with command files implemented in the simulator. I built the functional equivalent of CPU input and output pins in behavioral VHDL. The functional model consisted of a reduced instruction set of the targeted CPU. Functions allowed the CPU to read from a memory address, write to a memory address, and accept DMA requests. I then used this model to initialize the hardware I was simulating, as well as read from the hardware, and let the hardware perform direct memory access.

I began designing the circuit using schematic entry only, with Xilinx macros and primitives. I have since changed the schematic modules--excepting the Xilinx RAM16X8--to VHDL modules, replacing each module and resimulating the circuit. The FIFO schematic contains two levels of hierarchical format with VHDL submodules within both levels. The parasite dual-FIFO schematic contains Xilinx I/O buffers and pins and two instances of the FIFO block. The schematic labeled FIFO Memory Block is the actual FIFO circuitry.

One overall test schematic simulated the FIFO. It contains two CPU input/output modules--written in VHDL--that perform simple CPU interface functions with eight-bit data buses. Once the circuit was simulated, I used Intelliflow in conjunction with Xilinx back-end tools to generate a Xilinx bit file. I used a Xilinx FPGA board, which contains a 4003E chip with RAM functions. The design almost completely filled the device, using 97 of the 100 CLBs. The LED outputs monitored the state machine, and the MAN1 seven-segment displays monitored the difference between the FIFO input and output pointers. It was easy to change any of the monitor signals by changing the schematic and recompiling. It took about 10 minutes from a complete change to downloading the design to the actual chip.

Figure 2 - Viewing waveforms
The timing diagram in Viewlogic's Vwaves waveform viewer demonstrates the signals. Nested VHDL models appear as block symbols labeled with the name of their VHDL file.

I am currently working on a Manchester encoder that monitors a cellular phone communication bus, outputting the bus information to seven-segment displays. I am also working on a DMA controller that executes several specialized functions in display memory for use in graphical enhancement.

Some "gotchas" exist with VHDL code when implementing into specific target FPGAs. Designers can write code to compile and simulate with no indication of a problem, but the design may encounter problems when being fitted into the target device. For example, when designers use a VHDL block in a schematic and I/O buffers and specify pads, then they must manually insert clock buffers for the clock signal to correctly compile into FPGA parts. If the design is made from total VHDL code and the tool inserts the pads, then the compiler inserts the clock buffers automatically.

As it stands, I will continue to use VHDL for implementing my digital hardware. As my library grows, the engineering time will shorten and products will get out to production faster. And in this design climate, that's the measure of success.

Stephen J. Fricke is a hardware/software engineer at Starfish Software, Inc. in Scotts Valley, Calif. He has over 20 years of design experience.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to jeff@isdmag.com.