Working with programmable devices introduces new challenges to the design process. While the designer has additional freedoms in deciding what belongs "inside" as opposed to "outside" (configuration vs context), there is also an explosive growth in speciallized tools and techniques that must be embraced.
Due to their interdependence, you should read both (7.3) programming PROMs and (7.4) programming (for) microcontrollers if you are planning to do either. And you would probably do well to read (7.2) programming FPGAs before making a specific component selection, as programming issues may strongly influence your decision.
First, though, let's do the easy stuff.
Small programmable devices (16V8 and 22V10) are typically configured using either the ABLE description language on the Sun(s), or the CUPL language on the NT platform. For the Suns, talk to Mike about getting a copy of his "makefile" that will do most if-not-all of the work, or steal a copy from eng4:/home/job/vme0005/cae/pals. For the NT boxes, talk to Mike as this is still a work-in-progress to make PLD configuration development easy.
Keep in mind that on the Suns, the ABLE compile "path" (specifically the makefile) will produce a VHDL model suitable for simulation. Unfortunately, we don't use VHDL on the NT boxes (we use Verilog) so you will be on your own to write a simulation model for your PLD. This is actually quite easy to do, if you can ignore the timing issues. All of the combinatoric ABLE/CUPL statements can be trivially redone as continuous assigments, and the registered ABLE/CUPL statements become simple procedural assignment paragraphs. This also is a work-on-progress to make life simpler. Talk to Mike.
Now you have a JEDEC file, ready to burn into the device...
The DataI/O programmer is the only unit that we have for burning PLDs, PROMs, microcontrollers, and certain classes of FPGAs. See the dicussion below on (7.2) programming FPGAs to understand the distinctions.
The DataI/O programmer is currently connected to eng1, one of the Sun workstations. It will be moved to an NT box in a few months, but for now the process for using the DataI/O is as presented here. It is a bit convoluted, but easy once you have done it a few times. Hang on!
Before we can begin, it is necessary to talk just a bit about the
serial connection(s!) of the DataI/O to eng1. There are two. The DataI/O
has a "terminal" port and a "host" port. The terminal port is connected
to /dev/ttyb on eng1. Hence, if you execute:
kermit -l /dev/ttyb -b 9600 conon eng1, you will connect (via the kermit serial communications program) through the ttyb port and will be "talking" (typing) to the DataI/O programmer!. If the programmer is already turned on, you might need to "do" something to get the screen repainted. The safest thing to type at this point is:
[esc] O Qwhich is a DataI/O command that means "pop up one menu level" and is almost completely harmless. Don't just type a [return]! The programmer might try to *do* something!
If the programmer is not already turned on, check the floppy disk in the drive to make sure that it is the Boot Floppy (trust me, this will make sense in a moment). The drive is on the lower right front of the programmer. If the Boot Floppy is not there, put it in. If some other non-Boot floppy is there, replace it with the Boot Floppy. Now turn on the power. The power switch is in the back near the power cord. The programmer takes a *long* time to power-up and self-test (5 minutes), so be patient. And if you do not have the right Boot Floppy in place during the self-test, it will take even *longer*! This is why it was important to check the floppy first. It is proper manners to place the Boot Floppy *back* into the drive when you are done with the programmer.
If all is well, you will get a message asking you if you want to choose a different terminal type. No.
If you are having problems and need to reboot the programmer,
the command is:
[esc][ctl-W]Be sure that the Boot Floppy is in the drive before you do this! Then go have a cup of coffee, as this will take 5 more minutes...
While you are twiddling your thumbs waiting for the programmer to self-test, now might be a good time to look at the programming head. More often than not, the DIP head is in place. This head will accommodate essentially all (practical) sizes of DIP components. Just be sure to align the chip toward the *bottom* of the socket, with pin 1 toward the upper left. The lever on the side will close the socket and grasp the pins; this is called a "zero-insertion-force" (ZIF) socket.
If the correct programming head is *not* in place, change it to what you need. We have several different heads available. Ask someone to show you how, the first time, so you don't break it. The surface-mount heads can be a little tricky, and the DataI/O is an *expensive* piece of equipment!
Finally, you have a screen that looks promising. There is documentation near the programmer itself, or you can ask someone to "show you" the first time. While messy, it is not difficult. The following outline should help:
[esc] O Q previous menu (PF 2) [esc] O P main menu (PF 1) Select Device From Main Menu... You may need to swap floppies again since all of the libraries are on the non-boot floppy More Commands Configure System Note: you rarely need this... Edit Programming Algorith type D default (HC11's) Algorith type K keep current (22V10's) HighSpeed Logic N (only if problems with 22V10's) Transfer Data Note: you *always* need this! Download IO Offset usually needs to be set to 0 (defaults to FFFFFFFF, which is "bad") IO Format 91 JEDEC (PLDs) 86 Tektronix Hex format (FPGA config PROMs) 82 s19 records (HC11 code) 14 POF files (Altera) [esc][ctl-T] connect through programmer to eng1 log into eng1; rlogin somewhere else if you need; cd whereever... [esc][ctl-T] back to programmer command: cat file.jed [esc] O P main menu (PF 1) Program Device [esc] O S more info (PF4) If it is an electrically erasable PLD you may need to turn the "Erase" switch on Verify Device If you have test vectors, and they fail, it *might* be related to the "Configure System" stuff above... Come talk to MJH [esc][ctl-T] back to eng1/4/... clean up, log out [esc][ctl-T] [ctl-\] C break to kermit quit
Note the [esc][ctl-T] stuff in the above. This causes the DataI/O programmer to toggle a connection from its "terminal" side to its "host" side. This was mentioned earlier: the DataI/O programmer has two serial ports, and both are attached to eng1. When you [esc][ctl-T] to talk "through" the DataI/O, you are talking to /dev/ttya on eng1. This port (ttya) is configured as a "dial-in" terminal line if you will, so you should be greeted with a "login:" prompt (unless the last person forgot to log out, in which case you are they). Yes, you are going to log in again here, so now there are two of *you* logged into eng1.
This second "you" can change directories, or even remotely log into any other machine for which you have an account. You can do whatever "you" can do. And when you get there (e.g. whereever your JEDEC file is), you will [esc][ctl-T] to return to communicating with the DataI/O. Keep in mind, your second "you" is still out there, exactly where you left yourself. This is where the "command: cat file.jed" stuff comes in. You are asking the DataI/O in the download menu to transmit a character string to its host port. That string is "cat file.jed" in this case. Your second "you" session will see this, and begin to type out the file "file.jed" just as if you had typed the "cat" command yourself. You can use any command you want in this manner, and have the DataI/O transmit it on your behalf. The only catch is that the DataI/O is expecting a stream of program data to come out of this action, so there had better not be any expected interaction between "you" and the DataI/O (e.g. *don't* use the "more" command which stops after each page).
When the data has been downloaded, proceed back to the main menu, program the device, verify (again, since it was verified in the program menu) if you wish, and POOF you have a chip!
Not shown in the above outline... If this is the first chip of a batch that you are about to program, it might be a "good thing" to take a look at the downloaded data. You can find an "Edit Data" in the same secondary menu as the Download Data. You won't actually *change* anything (you better *not* unless you ***really*** know what you are doing!), but you can confirm that what you want got into the right location in the DataI/O's local memory.
Note: you don't have to actually *sit* at eng1 to do any of the above; you can telnet from any machine of your choice. However, since there is some amount of "hands-on" manipulation required to program devices (if nothing else, to put the chip in the socket, then remove it!), it does not make much sense *not* to sit at eng1 to use the programmer.
Clean up you mess. [esc][ctl-T] and log-out the second "you" then [esc][ctl-T] back and exit from kermit. Replace the Boot Floppy in the drive, and turn off the power.
Field programmable gate arrays (FPGAs) come in a variety of architectures and packages, and each as its own programming specificities:
In all of the above cases, the configuration data is generated by software specific to that FPGA manufacturer; see (4.1) tools.
There are important (4.4.1) selection considerations to be addressed, especially for (188.8.131.52) large programmables (FPGAs) as the (184.108.40.206) package styles have a strong influence over how the component is programmed. You should identify what programmer you will be able to use before you make your final device selection.
The Altera programmer is currently connected to Clymene, on of the NT boxes. Someday, this device will be connected to the same machine as the DataI/O programmer.
The Altera programmer is required for programming Altera FPGAs in PQFP packages; for all other Altera devices it is necessary that you use the DataI/O or the Bit Blaster.
Instructions for use of the Altera programmer are available from the Help menu of the MaxPlus2 program. Or talk to someone who has used it.
The Bit Blaster is a serial-port module from Altera; the Xchecker is the same beast from Xilinx. Note: they are *not* interchangeable! They simply address the same problems from similar directions.
The Bit Blaster (Xchecker) can be used to serially configure an FPGA in-situ (i.e. in-service on a pc board), as long as the design of the application has appropriate connections to allow access to the programming pins of the chip. The Bit Blaster (Xchecker) plugs into a serial port on a PC, and has a small connector on the end of the pod for connection to your board carrying the FPGA. The protocols vary both between the PC and the pod, and between the pod and the chip. Some FPGAs use JTAG protocols for programming (the JAM initiative from Altera is pushing this), while many FPGAs use completely proprietary protocols.
The MaxPlus2 software can provide you with Help on using the Bit-Blaster; the Xilinx software can provide you with help in using the Xchecker.
The specifics of programming a PROM do not differ substantially from those of (7.1) programming PLDs. The biggest difference lies in where the data comes from. Support PROMs for FPGAs get their data from the FPGA design (4.1) tools, whereas code PROMs for microcontroller support typically get their configuration from a compiler (read the next section).
This section addresses both the programming of, and programming for, microcontrollers. Our current-and-only microcontroller is the Motorola MC68HC11E9, so most of the following is fairly unique to this device. You should read this section if you are using the HC11, regardless of whether you want to configure the microcontroller chip itself, or are writing code for it.
The memory map of the HC11 is as follows:
We buy the chips blank, then typically burn our own version of the Buffalo Kernel (primitive "display/modify/download/go" interface) into the one-time-programmable ROM from 0xE000 to 0xFFFF. The kernel uses internal RAM from 0x0000 to 0x00ff, so you are advised to stay clear of this.
The kernel also has one "magic" location: 0x2000. This location is external to the chip, and hence should appear as 0x00 or 0xff if nothing is out there. The kernel checks 0x2000 on power-up or reset. If anything *except* 0x00 or 0xff is out there, the kernel assumes that this is the "official" program for the microcontroller, and begins to execute that code (for better or worse...). If 0x2000 appears "empty" the kernel will attempt to send characters out of its serial port, in hopes that there is a user out there to talk to.
From a programmer's standpoint, this means that there are a number of decisions to be made:
Be aware that if you follow this last choice (external PROM), it is not difficult to arrange the circuitry (and *socket*) to allow a RAM to replace the PROM. This will make debug *really* easy! You can also design with a dual-port RAM instead of a PROM, and down-load the code from somewhere else. There are many choices down this path.
And keep in mind that there are a several bits in the HC11 control registers (most notably in the OPTION register) that must be set within some very small amount of time after power up, after which they become read-only. There is a file, I:\Apps\ICC11\init_hc.c which you should copy into your area, and perhaps should incorporate into your code.
Which brings us to the C compiler itself. We are currently using the Imagecraft ICC11 cross compiler, which runs on the NT platform. A batch script can be found (I:\Apps\ICC11\compile.bat) which you should copy to your area so that it can be tailored (editted) before execution. There are comments in this script. Read them, *then* talk to Mike.
If you *do* decide to program the one-time-programmable memory in the HC11, here are a few things to keep in mind:
Talk to Mike. And good luck!