Enhanced Dynamically Reconfigurable Systems Using CPLD/FPGA

[jmp(FFFA)]

While building up a 65C02 testing platform to be used for my PIC-UART development, I didn't fully grasp how much logic would be ultimately be required to generate all of the various strobes, address decoding, wait state generation, etc. signals. I wound up quickly overflowing the breadboard I started the project out on. As much fun as it is (?) to use 74HC logic to build up a microprocessor system using an ancient 8-bit processor, I found myself desirous of the greater flexibility afforded by programmable logic. I'm not talking about an FPGA running a faux-6502, though I can see the appeal of such systems to some. I'm simply talking about replacing a lot of glue logic with a single CPLD. And given the size of today's CPLDs, I see no reason not to use a larger device in order to add a bunch of potentially useful features.

The idea here is to connect a 65C02 to a CPLD over a "private bus" with 8 data lines, 16 address lines, and control lines. The CPLD would then present a "public bus" to the rest of the system using 8 data lines, 20 (or more) address lines, and various chip selects and strobes as needed. The CPLD would also provide a way for a "controller" -- in my case a PIC, but no reason why an AVR couldn't be used -- to hold the 65C02 in reset at power up, load the RAM with an initial program, write protect the RAM, and then take the 65C02 out of reset in order to start it up. For a device connected to mass storage, the initial program could be a boot loader which bootstraps software from the mass storage device (e.g. a microSD card for example).

The purpose of the CPLD then would be to provide the following interfaces and services to the system:

• Isolate the 65C02 bus from the rest of the system
• Provide a controller MCU the ability to initialize the system (e.g. ROM-ulate or bootstrap as you wish)
• Provide a basic MMU to the system to allow it to address a lot more memory, and to designate various banks of memory as read-only
• Provide a public bus with 20 (or more) bits of address, and 8-bits of data to the rest of the system, along with any needed chip selects, strobes, and wait state generators for slow I/O devices
• Provide limited hardware reconfigurability to allow the system to be adapted to unanticipated needs in the future (via the CPLD).

The idea would would be to provide all of the elements of a useful computing platform as a template which could be customized for an end-users specific needs (e.g. add whatever peripherals you want). No reason why it couldn't be made to work with a 65816 or other similar CPUs, either.

One CPLD family I have experience with and am contemplating using is the Xilinx Coolrunner II family. The XC2C256 part has 256 macrocells and a T(pd) of 6.7 nS. Of course it only runs at 3.3 volts, and in order to limit the complexity of the system I'd run everything at 3.3 volts, but there is no reason why the more ambitious couldn't add a bunch of voltage translators in order to make it work with 5V-only devices.

With 256 macrocells, it even becomes possible to even contemplate a simple VGA subsystem and in fact I have thrown together some HDL which implements a simple 320x200 bitmapped display with a single 32K RAM that fits on a 128-macrocell devices. If fewer than 128 macrocells are needed to implement basic system functionality, then some additional circuitry could be added to provide an analog VGA output as well. I'm probably thinking too far ahead here and perhaps a better VGA subsystem could be implemented on a small FPGA instead of using the CPLD. That would allow for some hardware acceleration and other features along the lines of what Brad is doing with his Vulcan74 project. I think for my first pass at such a system I'll stick with a CPLD and consider the VGA add-on an optional "nice-to-have if there's room when everything else is working."

I've seen a number of other people use programmable logic (mostly PALs) to replace glue logic on their 6502-based systems. I believe 8BIT (Daryl) used a CPLD to make a "65SPI" device but I've not seen others using CPLDs as ambitiously as I'm proposing above. However, I've only been here a short while and may well have missed someone's project. If so, I'd love to benefit from their own experience and would appreciate a pointer.

Edit: Changed the title to reflect that both CPLDs and FPGAs are being considered.

[Arlet]

I had a somewhat similar project using a 65C02 and an FPGA: viewtopic.php?t=2453

The difference in price between the FPGA and the CPLD is minimal, but the FPGA will fit a lot more logic, plus it has plenty of memory inside that can be used for text display generators, or ROM code. The serial flash can hold plenty of additional user data.

[Aslak3]

My project is also similar. I'm using a Altera Flex 10K to implement an MMU, DMAC, SPI, etc. I should point out that I'm using a 6809, though that is a trivial detail in the grand scheme of things.

Previously I used a Xilinx XC95108 CPLD to implement bank switching, interrupt routing, buzzer driver, address decoding, and a few other tasks. I would be VERY interested to see what you could do with that kind of PLD; I reached the limit of what I could do with the 108 macrocell CPLD which led me to look at using a small FPGA for similar "core logic" functions.

There's more info on my blog.

[jmp(FFFA)]

Thanks Arlet. That will give me something to chew on for a while reading through your thread.

I get what you're saying re: FPGAs, and I could be tempted to go in that direction with something like the Lattice XP2 FPGA. Unlike the Spartan 6, these don't need to be externally configured at power up which is a big plus. You're right that there is essentially no price difference between the CPLD and the FPGA and the FPGA is considerably more powerful. I think I could even use the Lattice Brevia as a reference design and simply add in the CPU, PIC, and any peripherals I want to start out with. The only downside is I'll be stuck with a TQFP-144 instead of a TQFP-100.

Will have to dust off Altium and see if I have all of the necessary footprints. Too bad the Brevia doesn't expose more than 50 pins of the FPGA or I could probably bring up a test system with a breadboard before having PC boards made. Hmm, maybe something could still be without fully isolating the 65C02. I need to think on it some more.

[jmp(FFFA)]

Aslak3 wrote:

My project is also similar. I'm using a Altera Flex 10K to implement an MMU, DMAC, SPI, etc. I should point out that I'm using a 6809, though that is a trivial detail in the grand scheme of things.

I have a XC2C256 breakout board I designed a few years ago that I thought of using. You can do a lot with 256 macrocells and recently I was thinking of ripping up my current breadboard and starting over with it. However, I've had my eye on the Lattice XP2 FPGAs for a while because they don't require nearly as much support circuitry as other FPGAs -- in fact for all practical purposes it's an FPGA in CPLD clothing with 5000+ logic elements. Have a look at the dev board here: http://www.digikey.com/product-detail/e ... ND/3456132 The dev system for that line of FPGAs is free from Lattice as well. Arlet makes a good point that I may as well go for the more powerful solution if the costs are about the same and the complexity is only slightly higher with the FPGA. Especially if I can bring something up with the FPGA on breadboard first using the above-referenced dev board before committing the time to put together a PC board.

[Arlet]

While the Spartan 6 needs to be externally configured, it only takes a standard SPI serial flash, and after configuration, you can redefine the configuration pins as general I/O, and get user access to the flash. This allows storing user data (you can get a flash chip that's bigger than needed for the FPGA), or even in circuit CPU-based update of the bitstream. I used a M25P80 flash, which is less than a dollar at digi-key for single qty, and offers 8Mbit of space, of which only about 3Mb is needed for FPGA configuration.

[jmp(FFFA)]

Arlet wrote:

While the Spartan 6 needs to be externally configured, it only takes a standard SPI serial flash, and after configuration, you can redefine the configuration pins as general I/O, and get user access to the flash. This allows storing user data (you can get a flash chip that's bigger than needed for the FPGA), or even in circuit CPU-based update of the bitstream. I used a M25P80 flash, which is less than a dollar at digi-key for single qty, and offers 8Mbit of space, of which only about 3Mb is needed for FPGA configuration.

Hmm, given that I was thinking of putting a microcontroller on the board anyway to initialize the 65C02 (or 6809, or Z80, or whatever), there's no reason why it could not also initialize the FPGA via SPI. Then I can use whatever memory is left over on the JTAG flash memory to store programs or a boot-loader on the 65C02.

Another option would be to eliminate the microcontroller and build up a state machine on the FPGA to bootload the 6502. That's tempting too, though the microcontroller is going to be more powerful and certainly quicker to debug as well.

With all of those logic elements on the FPGA begging to be used, it's going to be tempting to put a Video DAC on board as well and allocate a portion of it to generate a low-resolution bit-mapped display so I need not be limited to a serial data terminal for an interface.

Looks like the Spartan LX9 compares well with the LFXP2-8E from Lattice. The Altera Cyclone IV EP4CE22E22C8N might be worth looking at too as it comes in the same sized package (LQFP-144) but has a lot more logic elements (but what's the point -- 9K is already way more than is needed).

[Arlet]

Quote:

build up a state machine on the FPGA to bootload the 6502

That's what I did in my project. It's pretty easy. You just need to take an internal FPGA memory, and add some logic to attach it to external bus. Especially when you use the FPGA to generate the 65C02 clock, you know exactly in what cycle you can grab the address bus, and drive the data bus.

[Aslak3]

jmp(FFFA):

One of the things that put me off using large FPGAs is wanting a purely 5V board, since I'm using parts from 1978 till today, without any level shifting etc. I'm assuming you'll be using a completely 3.3V board for signalling?

My breadboarding limit is 84pin PLCCs...

[BigEd]

Among the decisive factors, which you may already have tackled, are
- what voltage the thing will run at
- how many signal pins you need
- what kind of package you end up with, in terms of solderability or socketability.
For some purposes, the instant-on of CPLDs is a big win, compared to the fractions of a second an FPGA may take to initialise.

As for VGA output, I saw an interesting blog post about making one with very minimal logic resources... it was for FPGA and slightly out of spec timing-wise but could be interesting for a resource-constrained implementation.
http://www.fpgarelated.com/showarticle/42.php

[BigDumbDinosaur]

I foresee some interesting timing problems associated with interposing a CPLD in between the 65C02 and the rest of the system. The system would be leading or lagging the 65C02 on every bus transaction.

My POC V2 unit uses a CPLD for glue logic but doesn't isolate the 65C816 from the rest of the machine—the '816 talks directly to the buses in this design. The CPLD I am using, Atmel's ATF1504AS, has 64 macrocells, and so far I've only used about half of the available logic resources. The real limitation with it is that I had used every available I/O pin on the device—and could have used a few more, so it is effectively maxed out.

[BigDumbDinosaur]

Aslak3 wrote:

jmp(FFFA):

One of the things that put me off using large FPGAs is wanting a purely 5V board, since I'm using parts from 1978 till today, without any level shifting etc. I'm assuming you'll be using a completely 3.3V board for signalling?

My breadboarding limit is 84pin PLCCs...

That is one of the reason why I decided to use Atmel's CPLDs. Their ATF150xAS series can be run at 5 volts. The ATF1508AS has 128 macrocells and 64 uncommitted I/O pins.

[Aslak3]

BigDumbDinosaur wrote:

That is one of the reason why I decided to use Atmel's CPLDs. Their ATF150xAS series can be run at 5 volts. The ATF1508AS has 128 macrocells and 64 uncommitted I/O pins.

Yes, the XC9108 is similar, with 108 macrocells and 69 IOs. Then there is the Altera Max 7000 series. The largest PLCC84 part in that series has 160 macrocells and 64 IOs. The XC9500s, at least the 5V version, are EOL now though. Not sure about the Max 7000s.

[jmp(FFFA)]

Hey Arlet -- I just finished reading your older thread. There was some talk of a V2 board, but it looks like you dropped the project back in 2013 after putting the first board through its paces.

If you have any interest in making a V2 board, I'm willing to collaborate. Here is a random list of features I'd be in favor of supporting:

• Analog VGA output (25.175 MHz clock would be fine for anything I'm thinking of)
• 8 Mbit of fast SRAM for system use
• 65C02 and 65C816 support (I'm game for other 8-bit CPUs as well)
• SPI flash for FPGA configuration and bootloader storage (just like you did in V1)
• MicroSD SPI interface for virtually unlimited storage of programs and data by the system
• UART for debugging or serial access via something like an ESP8266
• PS/2 port for a keyboard interface (USB is another possibility though more work)

Otherwise I'll probably do something considerably less ambitious, just so I can be reasonably certain of being able to finish in a reasonable amount of time.

[jmp(FFFA)]

BigDumbDinosaur wrote:

I foresee some interesting timing problems associated with interposing a CPLD in between the 65C02 and the rest of the system. The system would be leading or lagging the 65C02 on every bus transaction.

How would it be different from using a bus transceiver to isolate the CPU from an external bus? Something like the 74HC245? A modern CPLD could probably implement 2-3 levels of logic in the T(pd) time of a single 74HC245.

Also, if we were to use an FPGA as Arlet did back in 2013, it becomes trivial to use the PLL (or DCM as Xilinx calls them) to create PHI2 clocks with arbitrary phases relative to the one driving the 65C02. Properly adjusted, this can compensate for fixed propagation delays through the CPLD or FPGA.