Other than propagation delay, are there any downsides to using an EPROM instead of a programmable logic device like a GAL?

I'd think that if the circuit was running at a relatively low speed, say 1MHz, it wouldn't be an issue, right?

 

Speed may not be an issue but an EPROM does not do the same thing as a PLD.
An EPROM stores digital words/numbers
A PLD generates logic functions.

 

Long before computer graphics displays became common place I added graphics to a popular text display terminal. I needed to create logic that would clear/set/invert single bits within a byte. In other words, I needed to read a single byte from display RAM and replace it with one bit altered depending on the clear/set/invert command.

An elegant solution was created using 32Kb EPROMs.

 

crutschow: What I had in mind was a lookup table stored in the EPROM such that:

D0 is low when the address bus was between 0xE000 and 0xFFFF (firmware ROM chip select)
D1 is low when the address bus was between 0x2000 and 0x200F (I/O chip select)
D2 is low when the address bus was between 0x4000 and 0x400F (display driver chip select)
D3-D7 are disregarded (padded out with 0s).

 

An address encoder is designed to do that.. 74hc138

 

Speed may not be an issue but an EPROM does not do the same thing as a PLD.
An EPROM stores digital words/numbers
A PLD generates logic functions.

An EPROM can certainly be programmed to produce (multiple) logic functions. Way back in the mists of time I was tasked to make some custom test equipment which ws an obvious application for a microprocessor but this was not allowed. So I did it with an EPROM providing the 'brain'.

[Added] https://maker.pro/custom/tutorial/how-to-use-eeproms-to-represent-logic-functions-in-circuits

 

Please realize that your EPROM can simulate more complex logic if you latch some of the outputs with a clock and feed the latched bits back into the address pins, thus forming a state machine.

 

The main goal is to minimize the amount of 'glue logic' needed without having to search for a currently available part - I have a few EPROMs on hand I could just erase and reprogram.

I did look at parts like the 16V8, but those I wanted to consider all have long lead times / large MOQs which don't make sense for something that would be a one-off project.

The original design I started with does use a 74xx138, but after consolidating a number of functions into the originally under-utilized PIA (and making the corresponding changes in the firmware), I was left with a number of under-utilized glue logic parts, making that part of the circuit an ideal candidate for simplification by substitution with an EPROM or PLD.

Dick: I have seen EPROMs used like you suggest. My work used to build boards for a customer that sold equipment used for rinsing semiconductor wafers, and several of the boards used a 2516 EPROM or even a ULN2803A transistor array to provide the 'brains' of the various functions (i.e., operating safety interlocks).

 

In the days of microprocess bus system designs we used TTL 256 x 4 PROMs.
For example, 82S126/82S129

UV-EPROMs are too slow.

 

The main goal is to minimize the amount of 'glue logic' needed without having to search for a currently available part - I have a few EPROMs on hand I could just erase and reprogram.

I did look at parts like the 16V8, but those I wanted to consider all have long lead times / large MOQs which don't make sense for something that would be a one-off project.

The original design I started with does use a 74xx138, but after consolidating a number of functions into the originally under-utilized PIA (and making the corresponding changes in the firmware), I was left with a number of under-utilized glue logic parts, making that part of the circuit an ideal candidate for simplification by substitution with an EPROM or PLD.

Dick: I have seen EPROMs used like you suggest. My work used to build boards for a customer that sold equipment used for rinsing semiconductor wafers, and several of the boards used a 2516 EPROM or even a ULN2803A transistor array to provide the 'brains' of the various functions (i.e., operating safety interlocks).

I dont know where you are,
bu ti have just ahd quick look at digikey UK
and they have thousands of CPLDs in stock

i.e.
https://www.digikey.co.uk/en/products/detail/xilinx-inc/XC2C128-7CPG132C/949448
Coolrunner II, 14 thousand in stock

 

EPROMS make great LUTs and decoders...ask me how I know.

 

MrChips: That is a concern, yes, but it seems that at 1MHz, (1000nS period), propagation delay shouldn't be an issue so long as I choose wisely in regards to the specific vendor, right?

drjohnsmith: that is WAY overkill for what I need - I'm only dealing with a 64K address space and only need to generate three chip selects.

 

MrChips: That is a concern, yes, but it seems that at 1MHz, (1000nS period), propagation delay shouldn't be an issue so long as I choose wisely in regards to the specific vendor, right?

drjohnsmith: that is WAY overkill for what I need - I'm only dealing with a 64K address space and only need to generate three chip selects.

PROMS are great as address decoders,
slow,

Out of interest, how are you going to generate the code for the PROM ?
how are you going to program it ?

CPLD's win in that respect, as the tools allow easy coding
and they are generally in circuit programable by a cheap JTAG USB adapter.

But yes,
PROMs are great, if you can cope with the limits

A Note, I once wrote a Fortran program to convert address ranges to a PROM,
yep I'm that old.

But it does raise question of how your going to support this
if its a one off for yourself, thats not a consideration

Since the 80's , I'd just put in a CPLD,

 

As for generating the PROM code, I have an Excel spreadsheet I made when I was trying to get a better understanding of how partial address decoding works. It didn't take long to adapt it so I could generate the list of values I needed for each address in the EPROM.

From there, I just needed to copy the values into a text editor, convert all the carriage returns into spaces, paste the cleaned text into a hex editor, and save it as a .bin file ready to burn into an EPROM.

If it was something I'd be making on any kind of production scale, yes, a CPLD would still be the way to go.