Several years ago I wrote a Gist on gitHUB describing a process for converting a ROM into a set of logic equations such that a CPLD could be used to store the ROM.

In the general scheme of things, ROMs may be used for microprogramming. However, EPROMs, UV or Flash, have pretty poor access times, and as a consequence, drive any implementation using these devices toward low clock rates. SRAMs can be used to get around this problem, but create other problems such as requiring a way to load them after each power cycle.

Of the nice features of CPLDs is that they exhibit fast pin-pin times, and can thus be used to simulate fast bipolar ROMs such as those used in high performance microprogrammed minicomputers of the 70s and 80s.

Today I decided to implement the algorithm that I described in that Gist six years ago. The result is a fairly compact Python script that reads in a ASCII Binary memory initialization file, i.e. ROM, and generates a synthesizable Verilog module.

I used the microprogram ROM from the MiniCPU project I developed for the 8-bit processor challenge that Arlet Ottens set up on anycpu.org. As a ROM, the microprogram requires 45 64x1 LUTs and 45 registers in the CLBs holding the LUTs. As a Xilinx Coolrunner-2 XC2C64-7VQ100 CPLD, the microprogram utilizes 50/64 (79%) macrocells, 144/224 (65%) p-terms, 45/64 (71%) registers, 57/64 (90%) pins, 77/160 (49%) function block inputs.

The total number of p-terms in the ROM-based implementation are 64 as that is the total number of states in the microprogram ROM. The fact that additional p-terms are needed in the CPLD is an indication that the internal architecture of the CPLD is not a full PLA, so additional terms are needed to expand / share the OR terms from adjacent macrocells. Three microprogram register values are reserved for future use, hence 45 registers instead of 48.

Overall, there is a fairly efficient mapping of the ROM onto the AND/OR architecture of the CPLD.

For anyone interested, the Python program, the input file, and the output file can be found in this repository: https://github.com/MorrisMA/PLATool. I've released the program under the GPLv3 license; found in the repository.

_________________
Michael A.

Nicely done! So that's 64 words of 48 bits, I think? Is there room for a column mux, so we could for example squeeze in 128 words of 24 bits, or 256 words of 12 bits?

I wrote a quick program to split the ROM into 4 blocks of 12 bits. The number of address bits goes from 6 to 8 as expected, and the number of registers goes from 45 to 12. It all still fits in the XC2C64-7VQ100 CPLD. I have configured ISE to autoselect the CPLD, but I have set the clock period to 8 ns to get the timing report out without all of the errors that result when a timing specification is not set.

The new organization of the ROM results in a different resource utilization:

Macrocells: 17/64 (27%) P-Terms: 142/224 (64%) Registers: 12/64 (19%) Pins: 23/64 (36%) FB Inputs: 53/160 (34%).

Don't know that you can draw any significant conclusions regarding the "best" way to use CPLDs to represent ROMs as PLAs. The limiting factor is the number of P-Terms required. In the MiniCPU_uPROM.mif only 48 of the 64 locations are presently being used by the implementation. This roughly corresponds to a 3/4 ratio which appears to match up well with the fact that 256 * 0.75 = 192 is less than the 224 P-Terms available in the CPLD.

Added the ROM splitting tool to the PLA Tool repository.

_________________
Michael A.

Possibly interesting to see an algorithm for this laid out bare, but e.g. Altera Quartus already does this for you. I've used it in several of my designs to implement a tiny bit of bootstrap code. Something like :

always @(address[5:0])
case (address[5:0])
6'b001101 : data[7:0] = 8'b10101001
...
6'b111111 : data[7:0] = 8'b11111111
endcase

to encode a 64 x 8 bit ROM ends up using 'only' 40 LUTs (in three layers). Every data bit is basically a big OR of ANDs. Piece of cake for CPLDs or FPGAs : the data bits basically end up being stored in the interconnect fabric.

In WinCUPL you can use the table definition that does this for you to create a ROM with any number of address bits and and width. The size you can achieve depends highly on the number of bit changes per ROM adress.