SigArch

By Jason Gallicchio

Perhaps you've seen scrolling signs before. Perhaps you've even heard about ACM's old scrolling sign that displayed the e-mails people sent it. What you haven't seen, though, is a 75x21 (that's 1575 LEDs) graphical display capable of everything from scrolling simple text to displaying custom animations people create on our JAVA-enabled web page.

At the heart of the display are 5x7 blocks of LEDs. To light a single LED in one of these blocks, you've got to put 5V on the appropriate row and ground the appropriate column. This seems pretty simple at first, but you can't just light any number of arbitrary LEDs on the block. If you want to light LED (1,1) and (3,3), you're going to get (1,3) and (3,1) going on too.

This is where the refresh circuitry comes in. All LED signs work like your computer monitor -- only a few LEDs are actually on at a time as the circuitry strobes through each row individually. Our entire sign is refreshed this way 100 times a second. In our sign, one of the 21 rows is grounded while the appropriate data for that row is fed into each of the 75 columns. Milliseconds later, the next row is grounded and the data is fed in for that one.

It would be easier if we could divide it up like the old sign where it strobed through the 64 columns and only had to change the data on the eight rows each time. Unfortunately our sign is much bigger, and to our dismay, our LEDs are much dimmer. If we strobed through all 75 columns and provided only the 21 signals for the rows, it would mean that each LED was on just 1.3% of the time. Certainly this wouldn't be bright enough for all of DCL to see, so instead, we strobe the 21 rows.

This leaves the problem of providing the data to each of the 75 columns. If we refresh all 21 rows every hundred seconds, new data has to be provided to each of the 75 columns every half millisecond. Further more, the programmable logic (FPGA) that we're using to control the sign doesn't have nearly enough pins on it, thus we ended up using dual ported SRAMS. Dual ported is like your video RAM where it can be read from and written to at the same time from different "sides." The plan was to connect the outputs of one side of the 5 16-bit wide SRAMs to the 75 columns and always read the data out of this side. The FPGA controlling the whole operation would be in charge of simultaneously strobing the appropriate row and providing the address to the SRAMs for that row.

If you have 75 SRAM outputs, then won't you need 75 SRAM inputs to load the data into them in the first place? That's true, but RAM has a special feature called "chip enable" where you can connect the data and address lines of each of the SRAMS together and when you want to read or write to one, put your address and data on this "bus" and only enable the chip you want. This way we've reduced the pins required to those available on the FPGA, yet maintained a high duty cycle where each LED can be on about 5% of the time.

Progressing up the hierarchy, the next question we had to address was how to load the SRAMS. Since the sign will be given its data through the parallel port of a PC, the job of the FPGA would be to accept the incoming data and route it to the appropriate SRAM. We used a page flipping scheme in the SRAMS where one page is being displayed to the LEDs and strobed to the appropriate row while the other is being loaded from the parallel port. When the new page is done being loaded, the parallel port will send a certain signal and the addresses switch, with the new frame now being displayed and the old frame being written to. All of this control logic implemented on the FPGA was written in VHDL - a Pascal-like hardware description language which is synthesized into custom hardware and downloaded to the reconfigurable logic in the FPGA.

On the software end, several people have been hard at work on both the Java graphical interface, the Windows simulator and control program, the POP e-mail reader so one can still send e-mail to the sign, and perhaps most importantly, the Parallel port code to quickly and reliably send the sign the data it needs. While the controls for loading and strobing the SRAMs are complicated, all the real "thinking" goes on in the software. For example, the text of e-mails is translated into a bitmap and the scrolling is calculated before the bits of the image are blasted to the sign over the parallel port.

As EOH projects go, not many require such a tight coupling of hardware and software. You may have seen scrolling signs before, but none with the capabilities of the SIGArch Internet-based scrolling graphical display. (Ohhhh.)