Dedicated PLD programmer:
Stag Microsystem's ZL30A

Jon Gabay

PLD programmers range in price from a few hundred dollars to well over $20,000. Often, choosing a programmer that is flexible enough to handle all the devices you may want to use and is also affordable is not very easy. You might even find yourself stuck having to buy either one very expensive programmer or a few less expensive universal programmers.One of the middle-of-the-road PLD programmers around is the Stag ZL30A.
The ZL30A programs parts from 19 different manufacturers in four package types. On-board Zero Insertion Force (ZIF) DIP sockets are directly supported in 20-, 24-, and 28-pin sizes. LEDs adjacent to each socket indicate the active selected programming socket. Optional expansion modules are available for special parts and package types; these expansion modules plug into a top connector and mount to the ZL30A, which then becomes the unit's base.

An on-board keypad and 16-character alphanumeric display allows manual operation without the need for a host computer. This is very handy for quick copies. Additionally, to facilitate using the programmer via a host-driven computer, an RS232 or HPIB IEEE 488 interface is provided.
This lets a program running on the computer select devices, load files, program, verify and test devices. An additional serial port is provided for handler interfacing.

Updates arrive every quarter or so, and come in the form of EPROMs that replace older ones in the unit. Also, a device file will be issued to those who use the STAGCOM2 software to interface with the unit.The ZL30A has a small footprint (about 10 x 14 x 3 inches) and only weighs a few pounds: It easily fits near a desk and can be transported by one person.

I received the programmer, an expansion module, manuals and software in one box. The connection of the power cord, the serial cable and the expansion module took only a few minutes. Everything was simply and efficiently laid out, and putting it together was a snap. Though it wasn't really necessary to refer to the manuals, I did anyway, because I wanted to check the configuration of the two DIP switches on the rear panel. Since I was using the RS232 port, I didn't have to configure the 488 port; I only had to set DIP switch 1 settings for the serial port. I set up for 9600 baud, no parity, 1 stop bit. This took a minute or so.

Next came the software installation. One of the two short manuals was about the software, so after looking at the installation procedure, I simply created a STAG directory and copied the files from the single diskette that came with it. The four files took up only 150 kbytes of disk space. I configured my Comm-Plex communications port manager to accept yet another serial device. Then I created a batch file to configure it and bring me up online with the ZL30A. I was then ready to go.

I decided to first try the ZL30A in manual mode. Without the host computer connected, I powered up the programmer and watched as it went through a self-test (a few seconds). It came up ready. The programmer, though, thought it was to be used remotely (through the RS232 port) and was awaiting RS232 control, even though I had disconnected the RS232 port. I remembered in the setup procedure that one of the rear-panel DIP switches controlled manual vs. remote operation so I powered the unit down, switched the DIP switch, and then powered up again. This time, after the self-test, the ZL30A prompted me for a device code.

Looking in the manual, I found the listing for a PLHS 473, which gave the device code as 10132. When I entered the device code via the keypad, the numbers echoed on the display. Then, when I pressed edit, the display indicated the PLHS 473, verifying the proper selection.I took a preprogrammed part and loaded it into the socket on the adapter
module with the lit LED. I placed the part in socket pin 1, toward the back (the unit does not clearly indicate which side is pin 1, but after checking the manual to find out which way is up, I verified the direction of pin 1), and hit EMPTY to check if the part was empty. Unfortunately, an "Adapter?" message appeared on the screen and the unit beeped at me.

A look through the manual, however, was fruitless: there was no error-message section listed. In one part, a listing of all the display messages the screen can generate was printed out, but no explanation was given. After combing through the manual, I found a little blurb under the expansion module section of the setup procedure. It said that this message would appear if I didn't have the correct adapter. After checking everything, I realized that the part I had picked up was the PLC 473, not
the PLHS 473. Unfortunately, the message was ambiguous. In addition to meaning that a specific adapter was needed to program this part, it also meant (in this case) that the wrong part was in the socket. An additional error message for this situation would be a nice addition.

When I tried to enter in the new device code of 12132, nothing intuitive on the keypad would let me. Later I found out I had to do a SELECT 0 on the front panel keypad to be able to select a new device code. What I did before I found this out was to simply power the unit down, then back up again. This time, when I entered the device code, a different socket's LED illuminated (on the main unit this time, not on the adapter module as before) and echoed PLC 473 on the display.

I performed a blank check and, as expected, it failed because it was already programmed. I pressed INPUT on the keypad, and the display indicated it was reading the part and echoed the checksum. Then I put in a blank part and did an empty check. As expected, it came back with a pass, meaning the device was empty. By pressing the program key on the keypad, the unit tested the device, programmed the part and came back with a successful message. I further did a verify and, again, the unit told me the verify had passed.

I tried putting an unprogrammed PLD in the socket backwards to see what would happen. When I tried doing blank check, verify, program, etc., the ZL30A came back at me with a CONNECT ERROR message. Good. It noticed. Now the big test: Did it blow the device finding this out? I placed the chip in the socket properly and did a blank check. It passed, and it programmed and verified correctly. I don't know if this is the case with all parts, but, here, an insertion error didn't blow the part.

USABLE BUT CONFUSING

I found the manual-mode keypad and interface usable but a little confusing at first. The need to look up a device code is nothing new to programmers, and it's to be expected in the manual mode of any programmer. But it would be nice if a small flash card or operatmg description was attached somewhere on the panel. That way, when manual mode is used, it wouldn't be necessary to have to remember the exact key sequences needed to copy and program parts quickly.

Also, it would be nice to be able to switch between manual and remote modes of operation without having to play with the little DIP switch in the back of the ZL30A. A front panel switch or key entry would be much easier.

All in all, though, once I had gone through the loop the first time, it was pretty straightforward. What's more, the programmer was forgiving.

For example, when I hit the INPUT command instead of LOAD on the keypad in manual mode, the ZL30A displayed "loading," but it really wasn't, because I was in manual mode. I could break out of the load cycle by pressing another key without having to start from the beginning of the procedure again. That was good, since mistakes like that will inevitably be made. I then switched the rear panel DIP switch back to remote and decided to try using the ZL30A in remote mode.

Before trying the STAGCOM2 software that came with the programmer, I decided to use the programmer in remote mode using a standard terminal program -- in this case, Procomm Plus. I powered up the programmer and connected to it via an RS-232 port. When the terminal program came on line, I got some cryptic characters back on my display.

I perused the manual and found the codes that the programmer uses in remote mode. When I tried a few commands at random, it didn't seem to take. I later found out that the first thing I had to do was send a device code. To set the part manufacturer/device code, I sent S0 MM DD, where MM was the manufacturer code and the DD was the device code. To set the format, I sent the programmer S1 I, where I was a number that represented which fuse map format was to be used.

All the 25 or so commands the programmer responded to were also an ASCII letter or two and a parameter field. That particular part was pretty straightforward, but the coded hex response that came back to the screen of my terminal program was cryptic and mixed with control codes and non-ASCII characters. That makes it barely usable remotely and manually through a terminal program, even with the reference material. An English response mode set via a DIP switch would make using the ZL30A with a standard terminal program much easier.

To test out the most automated operation of the programmer, I ran the STAGCOM2 software from my computer and ran the programmer in remote mode.
When invoked, the comm program, which controls the ZL30A, greeted me with an initial graphic banner and informed me it was attempting to connect to the programmer. Almost immediately, it verified the programmer was on line, prompted me to continue and brought me to the main menu. My first step was to configure.

By selecting the letter P, I was brought into the configuration menu and permitted to choose communications parameters, file formats and enabling/disabling of the handler interface. The menu-driven software uses a sequential alphabetic selection scheme, which forced me to check the screen continually for the proper command

I think a direct letter command would be much better. The letters that are used to select a function are in no way related to the name of the function. It would be quicker to use and easier to remember 'S' to select, 'P' to program, V to verify, T to test and so on.

FORMAT CHOICE

When configuring, I chose to use standard JEDEC format, though the program also supports the Signetics HL format and the XPLOT (old MMI) format for PALs only. I kept the Com parameters at 9,600 baud, no parity, 8-bit word and one-stop bit. The software uses the XON/ XOFF handshake, so I configured my Comm-Plex to use software flow control handshake. Then I went back to the main menu.
My first test was to verify a device I had programmed previously. I first chose the device-selection menu on the computer, which brought me to the manufacturers' list. I choose AMD, which brought me to another screen listing the devices supported from AMD. Using the space bar, I was able to page through the list until I found the part I wanted -- in this case, a 20L10.

I chose the part on the computer and the software automatically set up the programmer. I found this to be much easier than looking through a manual for a device code and manually keying it in. The socket to be used was indicated via the LED adjacent to it, and the display screen on the program indicated 20L10, informing me the programmer was ready to go.

I first took a device I had previously programmed and did a blank check. As expected, the computer informed me that the device wasn't blank, and it gave me a checkswn of the programmed parts' fuse map.

This checksum is helpful in two ways. First of all, it gives each different part a fingerprint. That is, each different designed part has a number associated with it for easy ID purposes. For example, on one design using a 20L10, I had the chip implement an address decoder for a microprocessor. On a different 20L10, I had the chip act as a keyboard encoder. Even though both parts were a 20L10, the checksum of each was different. Thus, the checksum acted as an identifier. If I had an unmarked 20L10 and didn't know what was programmed into it, I could look at the checksum to see what function it was performing by comparing it to the known checksums of the designs.

The second way in which the checksum is helpful is to verify a blank device programmed correctly. A verify option on the computer did a memory-to-device check and regenerated the checksum. If anything was awry, the program would indicate that and the checksum would differ.

Once verified as non-blank, I downloaded the fuse map that had been used to program the device on a different programmer. That went smoothly. The software prompted me for the path and file name of the source JEDEC file.
After entering it, the program automatically downloaded the fuse map file to the programmer, echoing the download to the screen as it went along. So far, so good. When I did a verify, the computer indicated that the device was programmed to match the contents of RAM in the programmer, meaning the device checked.

I then took a blank device and chose to program it. In a few seconds, the programmer came back and told me it was done. I choose to try the test vector option on the main menu, and the program came back with no vectors.
The file I had sent didn't have test vectors included. The test vector operation must get its test vectors from the JEDEC source file -- it doesn't automatically generate and apply a series of random vectors, as some programmers do.

I re-sent a version of the fuse map that had test vectors in it and ran the vectors. The programmer indicated a pass condition. When I put a blank unprogrammed part in it and tried to run the vectors stored in the ZL30A RAM, it, as I expected, indicated failure. When I programmed the part, the vectors would pass.

I plugged the programmed clip into an application circuit that it was designed to function in, and tried it. All worked as expected.
Next, I decided to try the programmer on a few new designs. Since I had been reviewing a few PLD-development programs, I had some fresh design files to play with. I choose a 22Vl0 on the computer menu and, again, the progrannner automatically configured itself. I then tried to download the design file to the programmer that was generated by the PLD-development software. Unfortunately, the download procedure stopped after test vector number 262. Nothing would break out of this lockup situation except a reboot, so I rebooted and tried again. Same deal.

In checking with Stag, I found out that the memory in the unit I had was limited to only 7 kbytes, which didn't allow me to handle all my test vectors. The available memory for test vectors divided by the number of signal pins on the target chip limited the total number of test vectors that I could apply.

In my text editor, I removed the test vectors after 260 and tried again.
This time, it didn't lock up -- it finished transferring the vectors. But at the end, it informed me that the programmer didn't respond.
Furthermore, the display on the programmer was a string of @@@@@. To get on line again I had to power down and repower up.

I did a little digging and found out that I couldn't just edit the fuse-map file with a text editor. The checksum at the end would then be in error with the actual contents of the file. What I had to do was edit my PLD source file and cut back the number of vectors, then recompile. When I did that, all was fine.

According to Stag, all new units are shipped with 64k memory. Although most combinatorial PALs can be fully tested with just a few vectors, this clock divider chip design demonstrates the need for many vectors when testing sequencers.

Once I solved that problem, I programmed the part and verified that the program took. Again, the programmer did its thing without any surprises.
When I ran the test vectors, I was informed that everything was OK. I breadboarded the chip in a solderless breadboard and fed in a clock. I toggled the state bits (S0 and Sl) and watched as the clock output changed through 1/24, 1/48, 1/96, and 1/192 the frequency of the source clock. I verified this using a frequency counter, then checked the waveform on a scope to verify a 50 percent duty cycle. It was.

NICE LITTLE PROGRAMMER

The ZL30A is a nice little dedicated PLD programmer. It may be a little cryptic at first, but it's basically easy to use. Its small size and portability made it easy to transport from computer to computer.

The overall unit is put together pretty well. The manual mode is sufficient for quick copies or tests of parts. You have to keep the old device codes index nearby or make a cheat-sheet of the codes you will be using, but that's no problem.

I liked its automated operation through the STAGCOM2 software. It was colorful, simple to use and, in the end, much easier than manual mode. Not only did it eliminate the need for the device code listings, but it let me quickly configure, load, program, verify and save parts and files. What's more, the software supports the handlers, though I didn't have any for test purposes.

I found the software to be generally good but a little kludgy at times. When errors were encountered, I had to reboot and re-power the unit.
Nothing -- not the escape key, control C or control break -- would get me out of a lockup situation. Also, the cause or errors was not clearly described. With a little perseverance, though, I was able to accomplish what I set out to do.

The remote-mode operation through a terminal program is possible, but I recommend using the STAGCOM2. If you need to develop your own interface for any special applications, it is possible using a terminal program driven by your software. But overall, STAGCOM2 does everything most engineers would want. And for $225, it's not going to break you.

Throughout the course of this review, I programmeded various PALS, GALs and IFLS. The programmer handled most of the parts I wanted to use. Depending on your applications, though, you might need a few different programming adapters. That will have to be taken mto account when you do a cost tradeoff.

All in all, the ZL30A is a cost effective PLD programmer that can satisfy many engineering houses' needs for PLDS.

MANUFACTURER

Stag Microsystems Inc.
3 Northern Blvd., Suite B4
Amherst, New Hampshire, 03031
(603) 673-4380