Do you speak GAL? [Peterzieba] does, and has pulled together a collection of documents and tools so that you can too. There’s a dividing line in electronic engineering education, between those who were taught about FPGAs, and those who weren’t. Blurring that line slightly is gate array logic (GAL). These devices were a preceursor to the FPGA, with a much simpler structure, and usually in those days UV-erasable in the same manner as an EPROM. And oddly enough, they, or at least their successor compatible parts, are still available, and as handy DIP devices that talk to 5 volt logic.
The guide goes into detail about the parts, the terminology surrounding them, and the CUPL language which raises a few memories for us. There are several possible workflows, including for those not faint of heart, the possibility of writing a fusemap by hand. We’re impressed by that one.
If these devices interest you, our colleague Bil Herd wrote a two-part guide (part one, and part two) which should answer your questions.
Thanks [Bjonnh] for the tip!
Featured image: “Commodore Amiga 1000 – sub board – Texas Instruments PAL16L8ACN-0126” by Raimond Spekking
GALs were succeeded by CPLDs, which were succeeded by FPGAs. FPGAs represented a big shift because instead of large product terms, you had tons of smaller ones and a much more capable interconnect.
CPLDs still can have advantages over FPGAs now (even ignoring the “instant on” which isn’t *really* architectural) because they have faster in-to-out times for all pins, as opposed to FPGAs where if pins are across the chip it can take a long time to route through the chip.
Yeah. The repository was actually mainly set up to cover the ATF150x CPLDs. GAL programming was something I tossed in there because might-as-well.
GALs and PALs have a relationship with EPROMs and diode matrix logic. They’re free of any kind of microcode, of software. Everything is purely based on logic/physics. That’s where the beauty lies in.
Oddly enough I do use PAL chips in my work. Sadly the current batch are all “pulls” but they respond appropriately for my needs. Next up will be programming appropriately the few blanks I have-but the big issue will be setting up the environment for that.
ATF16V8 and ATF22V10 are cheap and in-production if you want to replace a good number of PAL models.
The CPLD parts ATF1502 ATF1504 and ATF1508, which are also active/in-production and this is actually what I primarily put this repository up for. The GAL chips were sort of a detail I figured I’d add. The CPLD parts are neat because you can program them with JTAG.
Or just use discreet logic for simple tasks. It can be much easier being replaced/fixed in the decades to come when FPGAs an AVRs are long out of production.
I’ve found a few of these in older Tek and HP gear. A right pain if you have a bad one and no idea of what should be inside…
If the security fuse on them is not blown, you can read out the .JED file with an EPROM programmer and then reverse it to get the logic equations. However, even if the security fuse is blown, provided you know it is only combinatorial logic (address decoding or something similar), people often wire them as though they are an EPROM and simply brute-force all of the combinations of inputs by reading them out with an EPROM programmer
https://github.com/peterzieba/5Vpld#reversing-a-jed-file-back-into-logic-equations
“…writing a fusemap by hand”
Instant Bookmark for later. I’ve been keeping an eye out for this phrase for well over a decade!
And, bonuses in the comments, already!
CUPL.EXE is really pretty easy to get running in both Linux and Windows such that I think generating the fusemap by hand is good only to demonstrate that one could. The issue is that when signals get inverted they can be hard to keep track of, and even more so when internal feedback is used. The CUPL language is actually very straightforward to pick up that it is likely more work to try and do the map by hand than it is to just write some CUPL.
It’s not as absurd as you think. I’ve generated a number of configurations for ATF150x as well as lattice LC4k CPLDs, not exactly by hand but by writing a program that generates the bitstream directly. Once you understand the architecture of the chip you’re using it’s not that different from designing a circuit using 74xx logic. This approach also means you automatically understand what the timing characteristics of your design will be, and makes it easier to deal with designs that just barely fit into a particular device (instead of just having the fitter tell you it doesn’t fit, you know why it doesn’t fit, and what you might be able to do to make it fit).
If anyone is interested, reverse engineered fusemap data for the lattice chips are here: https://github.com/bcrist/re4k
You nailed it…
I’m definitely interested. Thanks for the extra resources. I’m looking forward to digging into this again soon.
Oh wow, this is incredibly cool. Any chance you have worked on the Lattice ispLSI1000 series?
No, sorry, just ispMach4000. Theoretically it shouldn’t be hard to use the same technique to reverse engineer them (which basically boils down to finding two circuits that, when run through the fitter, differ by exactly one fuse) but the 1000 and 2000 series parts seem pretty hard to find these days, and I don’t personally have any of them, so I’m not really motivated to take them on.
Been there done that. I suck so bad at Google, that after an hour of searching for something that would compile the product terms into a JEDEC, I only got one result and it was expensive.
So with the book about GALs on hand, I scanned the empty fusemap in and set it in MSPaint and hand-translated it. It worked after a little bit of trial&error and now both the PALs of an incredibly rare pinball machine (Space Train MAC) are reverse-engineered.
I’ve used OPAL Jr from National Semiconductor to reverse engineer JED files. It’s for MS-DOS so it’ll need to run under DOSBox. It has a JED2EQN program in it, but it converts them to PALASM instead of CUPL. The languages are very similar though.
Yes, I actually cover these approaches in this section (though not in great detail):
https://github.com/peterzieba/5Vpld#reversing-a-jed-file-back-into-logic-equations
I’ve been looking into GALs, CPLDs and PLAs for my own projects – and to hopefully revive some old Elektor projects that I never built back in the day.
CPLDs were meant to be upgrades to PAL/GAL devices with more logic cells available and easier programming, but the still exist in many cases as an FPGA-like device with embedded/routeable blocks that are not necessarily logic. Cypress makes some great inexpensive examples that have CPUs and analog blocks built in where you can create a full system on one device.
I’ve been down this rabbit hole and I concur that the ATF15xx series is the “last great CPLD line.” The article does not do enough talking about the Quartus route. This is by *far* the easiest way to use these devices. In my experience CUPL was extremely crufty and frustrating; in contrast you can write modern(ish) SystemVerilog with Quartus. You target compatible part numbers according to a Microchip app note and use a POF2JED conversion utility:
http://ww1.microchip.com/downloads/en/AppNotes/DOC0916.PDF
Yes, I admittedly did not talk in great enough detail about the process of how to do this with Quartus, but do cover it here:
https://github.com/peterzieba/5Vpld#quartus-free-verilog-vhdl-schematic-capture-indirect-support-for-atf150x
My main purpose was to outline all of the gotchas about the various approaches, and with Quartus it is that you must use a specific version, as Quartus has dropped support for the specific Altera EPM3K/EPM7K series devices one has to convert from in order to use the POF2JED utility you mention. It is a rabbit hole. I welcome any improvements to that repository to make things more clear — it has been forever since I’ve used Quartus.
While I agree that WinCUPL is extremely crufty and frustrating, the 5vpld wrapper I have put around CUPL.EXE eliminates the need for using WinCUPL. The CUPL compiler itself is then actually becomes very usable (and works in Windows / Linux (wine)). The fitters for the Atmel CPLD also run very well in Windows/Linux-Wine.
This has the advantage that one can do very low level work, and if one doesn’t already know Verilog/VHDL it is probably easier to make something simple. VHDL/Verilog are also a bit overkill for simpler GAL devices, and so one can get very fine-grained control using CUPL without having to resort to making dots on a printout of a fusemap. I’d liken this to using an assembler vs. a hex editor.
I see Digikey has Microchip EE PAL devices, and they’re “Active”. I was on a job that used a Xilinx “Coldfire” CPLD, and I liked it a lot, but I’m picking up that CPLD is fading into the sunset.
The Microchip ATF15xx CPLD devices are still active as well. They’re great anywhere you’d love to avoid level shifting and their propagation delays are hard to achieve in other ways.
“Does anyone know where to find some GALS?”
Yeah I got a few myself
Lulz
GAL 20V8 is widely available. There are cheap batches on Aliexpress too, but espect around 10-15% DOD rate
GAL20V8 is widely available. You can find very cheap batches on Aliexpress too, but espect around 10-15% DOD.
This device is intentionally not covered as it is no longer produced or NRND.
Only considered are true 5V programmable devices which are currently in active production.
That said, it is a shame as the DIP ispGAL devices that lattice made actually supported In-circuit programming (JTAG-ish?).
The closest replacement would be the ATF22V10 which I think could be drop-in as it has the same number of pins.
The ATF16V8 is also good to consider if you need fewer pins.