Joined: Thu May 28, 2009 9:46 pm
Posts: 8387
Location: Midwestern USA
|
WARNING: Long post! 
For some time, I’ve been fooling around with GALs, using WinCUPL to write and simulate the logic. WinCUPL’s occasionally-cantankerous behavior is well known around here; I’ve learned to live with it, but over time, have gotten somewhat suspicious of WinCUPL’s simulator, WinSIM. Simulation uses data generated when the GAL logic is compiled to produce what WinSIM thinks will happen in-circuit. It goes without saying that simulation is illusory; crashing a flight simulator isn’t quite as exciting as is doing the same thing in a real aircraft.
With that in mind, I decided to design and build a contraption that can prove that the logic outputs of a GAL agree with the designed logic and what WinSIM displays. Since the GAL under test would be in a “live” circuit in which inputs may be switched between low and high, it should possible to observe output behavior using a scope or logic analyzer under quasi-dynamic conditions. Hence there would a possibility of seeing an anomaly that would not be apparent in simulation.
While it is possible to monkey-rig a GAL and some LEDs on a breadboard, a breadboard’s sometimes-flaky connections may introduce problems that will produce false results. I figured it would be better to build a test gadget that could produce repeatable results, which meant it had to be fault-free in all respects. So what I’ve done is expand on the monkey-rig concept to produce something that is easy to use, unambiguous in operation...and trustworthy. 
The test rig I built is designed to test a 22V10, which device has 12 dedicated input pins and 10 dual-purpose pins, the latter which may be programmed as inputs or outputs. In my application, I am assuming that the dual-purpose pins are all outputs, an assumption that simplified the test rig’s design, as well as contained its cost. I’m powering the test rig with 5 volts from an old PC power supply, since I always seem to have several laying around.
For convenience, the rig has a ZIF socket for the GAL under test. I was less concerned with the cost of this socket than I was with its reliability and durability, so I chose quality over cheapness—unsurprisingly, it’s the most expensive single part on the rig.  Although the socket is wired to accommodate a 22V10, which has 12 dedicated inputs, a 16V8 or 20V8 could be tested by employing a little Mickey-Mouse-ity with some short jumper wires.
The rig has an array of toggle switches to control the GAL’s inputs, the switches being debounced so they don’t introduce glitches that might mistakenly be seen as something caused by the GAL itself. Each output on the GAL being tested ultimately drives a red/green pair of LEDs to indicate state, with the usual “red-means-high” arrangement.
As GAL outputs are TTL, I used 74ACT drivers to control the LEDs. I did not bias the drivers’ inputs high or low, which means if the unit is powered with no GAL in the socket, or if one or more of the GAL’s outputs is floating, the corresponding LEDs will display random states. A fancier design could be made to detect such a condition and disable the corresponding LEDs, but I didn’t want to go to that much trouble.
Here is a schematic of the unit...
Attachment:
File comment: GAL Test Rig Schematic
gal_tester.pdf [69.3 KiB]
Downloaded 21 times
...and here are some photos of the finished product.
Attachment:
File comment: GAL Test Rig
gal_tester_top.gif [ 1.3 MiB | Viewed 1131 times ]
Attachment:
File comment: GAL Test Rig ZIF Socket
gal_tester_socket.gif [ 1.7 MiB | Viewed 1131 times ]
Attachment:
File comment: GAL Test Rig Output State LEDs
gal_tester_leds.gif [ 665.07 KiB | Viewed 1131 times ]
Attachment:
File comment: GAL Test Rig Input Switches
gal_tester_switches.gif [ 824.78 KiB | Viewed 1131 times ]
The switches, from left to right, control the following inputs to the particular GAL that was the test guinea pig:
A15, A14, A13, A12, A11, A10, A9, A8, A7, A16, VADR, RWB
The switches are generically numbered 1-12, since their functions will naturally depend on how the GAL under test has been programmed. In this case, VADR represents the ORing of the 65C816’s VDA and VPA outputs.
After admiring my handiwork, it was time to do some testing. The guinea pig was the glue logic GAL in POC V1.4—a Microchip (Atmel) ATF22V10C, which has the following memory map:
Code: $000000-$00BFFF — base RAM
$00C000-$00C3FF — I/O hardware
$00C400-$00CFFF — system RAM
$00D000-$00FFFF — ROM (read-only)
$010000-$01FFFF — extended RAM
I/O Hardware Decoding
—————————————————————
$00C000-$00C07F — SIOA: DUART #1
$00C080-$00C0FF — SIOB: DUART #2
$00C100-$00C17F — SIOQ: vQUART status
$00C180-$00C1FF — RTC: realtime clock
$00C200-$00C27F — XIOA: expansion ‘A’
$00C280-$00C28F — XIOB: expansion ‘B’
$00C300-$00C37F — XIOC: expansion ‘C’
ROM can be selected only when the MPU’s RWB output is high—a write operation goes nowhere. The $00C380-$00C3FF address range is not decoded.
During initial testing, I took some voltage measurements for posterity. VCC under load was 5.04. The GAL’s unloaded VOH was ~4.2 volts—in this circuit, loading is vanishingly-small, with only the inputs to the CMOS LED drivers and some parasitic capacitance seen as outputs change state. Curious as to how well the GAL can drive a load, I applied 3.3K to several outputs being driven high, which caused VOH to drop to ~3.7. Increasing that load to 1K caused VOH to drop to ~3.5. These results were significantly better than the data sheet specifications. The GAL’s VOL was typically 0.12 with a 1K ohm load tied to VCC, also better than specified. In a practical application, a GAL usually won’t see such loading.
What follows are some photos with the guinea pig in the socket, the test rig powered and various input combinations set. After a period of operation, the GAL got noticeably warm, which is typical of these devices.
Attachment:
File comment: GAL Test: No Valid Address
gal_tester_no_vadr.gif [ 869.2 KiB | Viewed 1131 times ]
Above, VADR is false, which means the address bus state is undefined, a condition that occurs during intermediate execution cycles of some 65C816 instructions. All GAL outputs are in the false state, which is what is expected.
Attachment:
File comment: GAL Test: RAM Selected
gal_tester_ram_select.gif [ 852.72 KiB | Viewed 1131 times ]
Above, VADR is true and the effective address is $0000xx, resulting in RAM being selected. The GAL’s /WSE (wait-state enable) output is false, since RAM accesses do not require a wait-state. /WSE is represented by the leftmost red/green LED pair and /RAM is represented by the second-from-the-left pair.
Attachment:
File comment: GAL Test: ROM Selected
gal_tester_rom_select.gif [ 814.04 KiB | Viewed 1131 times ]
Above, VADR is true, RWB is high (read) and the effective address is $00E0xx, resulting in ROM being selected. /WSE has been driven true, since ROM accesses must be wait-stated. Had RWB been low (write), /ROM would be false. /ROM is represented by the third-from-the-left LED pair.
Attachment:
File comment: GAL Test: DUART #1 Selected
gal_tester_sioa_select.gif [ 823.25 KiB | Viewed 1131 times ]
Above, VADR is true and the effective address is $00C00x, resulting in /SIOA (DUART #1) being true. Again, /WSE is true, since I/O must also be wait-stated. Although RWB is high, it’s a don’t-care if the effective address is selecting anything but ROM. /SIOA is represented by the rightmost LED pair.
Attachment:
File comment: GAL Test: DUART #2 Selected
gal_tester_siob_select.gif [ 878.64 KiB | Viewed 1131 times ]
Above, VADR is true and the effective address is $00C08x, resulting in /SIOB (DUART #2) being true. Once more, /WSE is true, and RWB is a don’t-care. /SIOB is represented by the second-from-the-right LED pair.
While I was fooling around with the test rig, I connect the logic analyzer to see how quickly the GAL responds to input changes. Here’s one capture:
Attachment:
File comment: Logic Analyzer Capture
gal_test_la_vadr_true.gif [ 18.6 KiB | Viewed 1131 times ]
In the above, the capture was triggered by the low-to-high transition of VADR. The test rig switches were configured to generate the address $00C00x, which corresponds to a DUART #1 (/SIOA) chip select. The logic analyzer was configured to sample signal states for a short period of time before VADR went true. Elapsed time starts at the trigger event.
As can be seen, both /SIOA and /WSE apparently became true only 4 nanoseconds after VADR became true. I say “apparently” because the logic analyzer’s maximum resolution is 2ns. The GAL acting as the guinea pig is guaranteed to have 7.5ns pin-to-pin performance, which is possible in this case because all logic is combinatorial and doesn’t use any pins as nodes. Hence the above capture implies that the logic analyzer is being optimistic about the guinea pig’s performance. More likely, the switching speed is at least 5ns due to logic analyzer fudging. Or...it could be 3ns, which is listed as a TPD minimum in the data sheet for simple, combinatorial logic—but seems very unlikely. Either way, performance is good enough for me!
_________________ x86? We ain't got no x86. We don't NEED no stinking x86!
|
|
Login
Register
FAQ
Search
