Programming your own microcontroller - Embedded.com

Programming your own microcontroller

The following article first appeared in the At the Bench column in the March 1989 issue of Embedded Systems Programming magazine.

Last month* we discussed the differences between general-purpose programming languages and hardware description languages (HDLs). This month we'll look at how HDLs can be used to design embedded systems directly.

Rather than using a general-purpose language to program an embedded processor, you can use an HDL to configure a programmable logic device (PLD). A number of special sets of HDLs are specifically designed to configure PLDs.

Originally, PLDs contained fuses and fusemaps generated from the HDL descriptions of the desired functionality. Although fused devices are still used, modern PLDs can also use programming techniques; higher densities, as well as higher speeds, can be obtained.

Indeed, the most sophisticated PLDs available contain over 600 register bits and operate at clock speeds in excess of 70 MHz. Since the register bits can easily be configured in any width and linked with any logical structure, these larger PLDs are a viable and faster alternative to any microcontroller architecture. These PLDs do tend to cost hundreds of dollars, however. Although they can be priced competitively if they can directly replace an ultrahigh-performance 32-bit microcontroller or application-specific processor, they're beyond the budget of most embedded applications.

Smaller PLDs, which cost only a few dollars, offer a viable alternative to small microcontrollers in small- and medium-run quantities. Because no separate PROM is required, one chip can be sufficient for applications that would require at least two chips if a low-cost microcontroller were used.

Though microcontrollers can be economically mask programmed in sufficient volume to offset the price difference, PLDs offer architectural advantages that can make them more attractive anyway. Most obviously, the pins in a PLD can be configured as they're needed, an advantage for functions that involve switches, indicators, and control lines. Less obviously, PLDs are easy to test. In fact, most PLD development systems can automatically generate a test suite for the part. PLDs can also operate much faster than a microcontroller in the same price range.

There are nevertheless a number of strictures on PLD implementation. The prime restriction is that the least expensive PLDs offer only eight register bits; having more than a few dozen bits automatically puts the price of the chip over $10.

Recent innovations in PLD development system technology are moving PLD design back into the software realm. One expert system for PLD selection from Mine Inc. (Colorado Springs, Colo.), PLDesigner, integrates schematic and HDL environments with simulation and a knowledge-based software mechanism that selects the most appropriate PLD. Systems designers can enter the restrictive parameters necessary for the application, such as cost, speed, device count, power consumption, lead time to delivery, and distribution channels. PLDesigner then tests how well the function fits onto each and every possible combination of PLDs and produces a list of suggested implementation configurations.

* Remember, this is a 20-year-old article. -ESD editors. Back

The PLDesigner development system will be supplied by the leading electronics design system vendor, Mentor Graphics (Beaverton, Ore.). Since Mentor has selected Minc as its sole PLD design tool source, we may trust that PLDesigner really works.

Describing your function
The three most prominent PLD HDLs are found in PALASM, CUPL, and ABEL. PALASM, the first development system for PLD design, was supplied free by Monolithic Memories. Unfortunately, it could only design Monolithic's own PLDs. (Monolithic Memories is now a part of Advanced Micro Devices, Sunnyvale, Calif.)

CUPL is similar to PALASM and is available from a number of PLD vendors. A $50 starter kit containing the full CUPL program (but only configuration files for four PLD architectures) is available from Texas Instruments (Austin, Texas).

ABEL is the most flexible of these development systems. Although similar to PALASM and CUPL in the way it's used, ABEL supports many PLD architectures and some more advanced HDL commands. Unfortunately, it's still necessary to select the PLD architecture into which you want to compile the functional description and declare the pin usage for that PLD.

Listing 1 is a complete HDL program to generate a PLD for controlling the traffic lights at an intersection. Written in ABEL's state-machine format, the listing illustrates the main features of PLD HDLs.

View the full-size image

The first paragraphs contain the header information–device naming, device type, pin declarations, and include files. These are followed by a macro that forces the program into a known state when a RESET signal is applied. Though not absolutely necessary, this feature assists with power-up and test situations. And it's free; since there are unused pins on the chip, we might as well use one for initialization. Other pins could be used as sensor inputs to switch the traffic light only when a car is waiting at a red light.

The state descriptions cycle the traffic lights in an obvious manner. The last state description uses a compiler directive to generate four identical states that are stepped through sequentially to create a four-clock-period delay.

Other HDL structures
When the description is entered, ABEL compiles the HDL into the target PLD architecture and automatically generates a test vector file for the part. Because ABEL is linked to a full-logic simulation system called DASH, the entire hardware configuration can be validated in the same design environment. The generated fusemap files that are used to program the PLDs are also in a standard format, JEDEC, that can be used by many other CAE systems. For example, Logic Automation (Beaverton, Ore.) provides software that turns JEDEC files into behavioral models.

If we tried to compile Listing 1 as it stands, we would get at least one error message. The PLD architecture we've specified in the header field (p16r8 ) contains only eight register bits, and there are 10 states in the system.

It's not difficult to reduce the number of states used by the traffic-light controller to eight. The four register bits used in the four-stage delay can be reduced to two register bits by building a simple two-bit counter. Listing 2 shows how this can be done and presents the other two HDL structures supported by ABEL: truth tables and Boolean equations.

View the full-size image

Truth tables are the most intuitive way to capture a function such as the one we seek and are particularly suitable for describing complex bus decoding and encoding properties. ABEL also supports vector signal descriptions to permit bus modeling.

Listing 2a shows how two register bits are stepped through the binary sequence {0, 0} , {0, 1} , {1, 0} , {1, 1} to create a four-stage counter. Listing 2b illustrates an equivalent truth table reduced to a pair of Boolean equations. The equations may be further reduced to a pair of shorter equivalencies as shown in Listing 2c. The same function may also be described in a state machine in a somewhat lengthier manner (Listing 2d).

State-machine, truth-table, and Boolean descriptions in ABEL can be intermixed with schematic descriptions. This flexibility allows the programmer and hardware designer to work in the design description medium most suited to the task at hand.

ABEL is supplied by Data I/O (Seattle, Wash.), the leading vendor of device programmers. Data I/O also supplies DASH for schematic capture and simulation and PLDtest for automatic test-pattern generation.

Switching environments
HDLs are similar to general-purpose programming languages, the essential difference being that HDLs offer declarative extensions and special data types. Both features are illustrated in our ABEL examples.

In the state-machine descriptions of the traffic-light changes, for example, the order in which the light changes are described is unimportant; all the commands in each state are executed simultaneously. Likewise, all the truth-table lines and Boolean equations are evaluated concurrently. The compiler will alert the erring programmer who assigns more than one change to one signal under the same conditions. It will also automatically combine multiple Boolean equations into single AND/OR equations and optimize the combinatorial networks for the specified device architecture.

Pin names are used to define signal descriptions into and out of the PLD. These constitute one signal type. The aforementioned vector descriptions can also be used to describe signals. The compiler will alert the programmer when a pin name is assigned as a state label or component name. It will also detect erroneous assignment of pins, such as the use of an input as an output.

Writing an HDL description isn't all that different from using a general-purpose programming language. The fact that the compiler generates a fusemap for the interconnection of logic elements, rather than microcode for a processor, is hidden from the programmer.

When to try out a PLD
If an application looks like it requires only a few pages of code, then a PLD can be a low-cost solution. Ideally, such an application should have less than eight states and require specific control lines for switches and indicators. PLDs are also efficient where speed is important, as the functions are evaluated logically rather than by a sequence of macroinstructions.

PLDs are useful at the other end of the design spectrum, where high performance and functional complexity are more important aspects of the design than cost.

If PLD design is a new thought to the embedded systems programmer, then it's one that should be explored. Hardware designers can provide some assistance in this area, though to date only about 20% of all hardware designers have ever used a PLD (according to Data I/O surveys). PLD vendors offer instructional courses, but they're usually aimed at hardware designers rather than software developers. Accordingly, most PLD vendors emphasize schematic rather than HDL design.

HDLs are usually very simple, however, with less than a hundred commands and directives. I've found HDLs easier to learn than any other language. The only real issues are device selection and pin assignment, which are currently addressed only by Minc Inc.

Next month: how software models can be used instead of in-circuit emulators for code development.

Ernest Meyer is an independent technical writer and former editor of VLSI Systems Design.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.