Enhanced Dynamically Reconfigurable Systems Using CPLD/FPGA

[jmp(FFFA)]

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.

Nothing against the Atmel CPLDs, but the last time I looked at them (some time ago), it was impossible to get a programmer for them that didn't cost an arm and a leg. With Xilinx, Altera, or Lattice parts, JTAG programmers cost under $50.

The other reason to use 3.3 volts is because very few modern parts work with 5 volts any more so if you're building a hybrid system (e.g. retro CPU with modern peripherals), you're going to need a 3.3-volt interface anyway.

[Aslak3]

Quote:

Nothing against the Atmel CPLDs, but the last time I looked at them (some time ago), it was impossible to get a programmer for them that didn't cost an arm and a leg. With Xilinx, Altera, or Lattice parts, JTAG programmers cost under $50.

That was the main reason I was put of Atmel PLD parts as well. It's a shame, because their AT40K FPGAs sound quite nice. But in addition to the programmer problem, the tooling did not appear to be nice and integrated like it is with the Xlinix and Altera parts (I have no experience with Lattice, yet).

Quote:

The other reason to use 3.3 volts is because very few modern parts work with 5 volts any more so if you're building a hybrid system (e.g. retro CPU with modern peripherals), you're going to need a 3.3-volt interface anyway.

I've yet to come across something I'm desperate to include in my micros that is 3.3V only. Yes there's some funky 3.3V SPI/I2C peripherals but, really, what else 3.3V only would you want to include in a "mostly retro" 8 bit micro? Just curious to hear your ideas, and to find out what I'm missing out on.

[jmp(FFFA)]

Aslak3 wrote:

Quote:

I've yet to come across something I'm desperate to include in my micros that is 3.3V only. Yes there's some funky 3.3V SPI/I2C peripherals but, really, what else 3.3V only would you want to include in a "mostly retro" 8 bit micro? Just curious to hear your ideas, and to find out what I'm missing out on.

In no particular order:

• ESP8266 http://www.instructables.com/id/Using-t ... 66-module/
• Microcontrollers -- I'm working on a PIC24-based UART right now and it runs only at 3.3V
• Lots of SPI & I2C devices only work at 3.3 volts. These include lots of fun devices to play with like sensors (accelerometers, gyros, environmental sensors, etc.).

The third bullet above really does include lots of neat devices. For example a 9-DOF combination 3-axis accelerometer, magnetometer, and gyro can be used for lots of interesting applications if you have a 3.3 volt interface available. Basically, if you're into robotics, sensors, and more you're really going to want a 3.3 volt interface on your system.

[8BIT]

I'm jumping in kind of late, but my SBC-4 does most of the things jmp(FFFA) mentioned. It use an AVR to load RAM during reset, and buffered most of the IO, including 8 bit data bus, 4 bit address, and 4 device selects with assoicated interrupts. I have composite video, pc keyboard, 65SPI with CF FAT16 drive, ethernet, and a 65C22 running through the CPLD with no timing issues.

More info can be found here:
http://sbc.rictor.org/info4.html

thanks!

Daryl

[jmp(FFFA)]

8BIT wrote:

I'm jumping in kind of late, but my SBC-4 does most of the things jmp(FFFA) mentioned.

Thanks Daryl. Indeed it does look a lot like what I started out thinking of, before Arlet convinced me to take another look at using an FPGA instead of the CPLD. I'd certainly prefer to leverage the work one of you folks have already done rather than try to re-invent the wheel myself.

[Dr Jefyll]

BigDumbDinosaur wrote:

I foresee some interesting timing problems associated with interposing a CPLD in between the 65C02 and the rest of the system.

jmp(FFFA) wrote:

how would it be different from using a bus transceiver to isolate the CPU from an external bus? Something like the 74HC245?

It wouldn't be different, although I guess it's somewhat interesting. Even interposing a simple bus transceiver between the 65C02 and the rest of the system results in a timing penalty. For example a read requires an address to be sent from CPU to memory and for the data to be sent back to the CPU. Usually a direct path is fastest. Sometimes a transceiver (or other interposed circuitry) is unavoidable -- or maybe there's an associated benefit which outweighs the penalty -- and that's fine.

But running all the address lines and data lines through the CPLD may be overkill. If the state of the address lines, for instance, ends up simply being input on one set of CPLD pins and then output, unmodified, on another set of pins then you've incurred the penalty but there's no benefit.

8BIT wrote:

I'm jumping in kind of late

Tell me about it! I just replied to the last post on page 1, not realizing that several subsequent posts had caused a page 2 to appear!

[jmp(FFFA)]

Dr Jefyll wrote:

But running all the address lines and data lines through the CPLD may be overkill. If the state of the address lines, for instance, ends up simply being input on one set of CPLD pins and then output, unmodified, on another set of pins then you've incurred the penalty but there's no benefit.

Agreed. I'll admit I can't conceive of any scenarios offhand where it would make sense to run, say, the lower 8-10 address lines through the FPGA or CPLD (depending on the pagesize of the MMU you were planning). OTOH, it's just those previously un-thought-of scenarios that make reconfigurable hardware an asset if it's connected.

If nothing else comes up, I think I'll go ahead and re-build my existing testing system using my XC2C256 CPLD breakout board or maybe with a suitable small+cheap FPGA board like the Lattice Brevia if I want to play around with VGA video. But not, of course, until I have the PIC-UART up and running.

[BigDumbDinosaur]

jmp(FFFA) wrote:

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?

If the only thing between the MPU and all other hardware are bus transceivers then all devices, including the CPLD, are seeing the same signals at the same time. When the CPLD becomes the bus transceiver, its innards are seeing signals slightly sooner that the outside world.

Quote:

A modern CPLD could probably implement 2-3 levels of logic in the T(pd) time of a single 74HC245.

You keep focusing on 74HC logic, yet there are several other logic families that are faster, such as 74AC (what I used in POC V1) and 74ABT. For example, a 74ABT245's typical input to output prop time on 5 volts at 25° C is 2.2ns. The same value in a 74HC245 under the same operating conditions is 7ns. Also, the 74AC and 74ABT devices have greater fanout. I haven't built anything with 74HC logic in a long time, as it offers little more than 74LS, except better noise immunity.

You might find this page on NXP's website to be of interest, as it lists the logic families for which they are producing discrete devices. Take a look at the buffer/driver units and bus transceivers listed under the 74ABT family.

[Arlet]

Quote:

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)

Sounds interesting. I'm kinda busy with other work right now, but starting next week, it should ease up a bit, so I could do some fun stuff again. The biggest problem I was struggling with is the FPGA pin count. Using a design where the FPGA sits between the CPU and the memory requires a lot of I/O pins, leaving very little for anything else (V1 had 11 I/O pins left on the FPGA). I don't know how many colours you want for the VGA, but potentially it could cost quite a few pins.

That's why for V2, I had decided to attach the SRAM directly to the processor, and the FPGA hanging on the bus as a peripheral. The disadvantage is that you have less control over the memory, and it wastes a lot of SRAM access time that could otherwise be used to do DMA or video. So, even though I had made that decision, I wasn't really thrilled about it.

Adding more pins would require moving to BGA, which I'm not too excited about either. It requires a more expensive board, make assembly harder, and cost more.

[Arlet]

BigDumbDinosaur wrote:

If the only thing between the MPU and all other hardware are bus transceivers then all devices, including the CPLD, are seeing the same signals at the same time. When the CPLD becomes the bus transceiver, its innards are seeing signals slightly sooner that the outside world.

Yes, but that's not a problem. When you add regular decoding logic between the CPU and the peripherals, they also see the signals slightly sooner.

Quote:

You keep focusing on 74HC logic, yet there are several other logic families that are faster, such as 74AC (what I used in POC V1) and 74ABT. For example, a 74ABT245's typical input to output prop time on 5 volts at 25° C is 2.2ns. The same value in a 74HC245 under the same operating conditions is 7ns.

The point is that 7 ns is fast enough, especially if you only need one logic layer.

Edit: for 65c02, read access time at 5V is 30ns. Take a 10ns SRAM, and there's still 20ns left over for the CPLD. When moving to 3V3, it becomes a very comfortable 60 ns.

[cbscpe]

Aslak3 wrote:

Quote:
Nothing against the Atmel CPLDs, but the last time I looked at them (some time ago), it was impossible to get a programmer for them that didn't cost an arm and a leg. With Xilinx, Altera, or Lattice parts, JTAG programmers cost under $50.


That was the main reason I was put of Atmel PLD parts as well. It's a shame, because their AT40K FPGAs sound quite nice. But in addition to the programmer problem, the tooling did not appear to be nice and integrated like it is with the Xlinix and Altera parts (I have no experience with Lattice, yet).

The Atmel PLD are only an issue when you want to use the JTAG pins as normal IO pins. As long as the JTAG pins are dedicated to the JTAG interface a normal JTAG programmer will do the job. Actually I'm doing exactly that. Currently I have set up a system with a ATF1504AS that does more or less all the GLUE logic job (as I did not have enough pins I had to add a GAL22V10 for further signals) and implements a 6502 system compatible with a Apple IIe. Also the system's ROM image is loaded via an AVR, using the blind load method (i.e. the AVR creates the clock via software and feeds the databus with the expected bytes). A ATmega328P is all you need and the ATmega328P also implements the PS/2 interface. It is similar to my ROMulus1st viewtopic.php?f=4&t=3458breadboard setup. However ROMulus1st only requires a GAL22V10 + 74AC00 as GLUE. The good thing is that the Atmel PLD are available and 5V devices.

The ATF1504AS is rather small to implement all the features jmp($FFFA) mentioned, my Apple IIe clone really goes to the limits of the CPLD. So I'm thinking about replacing the ATF1504S with a ATF1508AS, even though TQFP-100 is difficult to solder for me. TQFP-44 of the ATF1504AS on the other side is very easy to solder.

[jmp(FFFA)]

BigDumbDinosaur wrote:

If the only thing between the MPU and all other hardware are bus transceivers then all devices, including the CPLD, are seeing the same signals at the same time. When the CPLD becomes the bus transceiver, its innards are seeing signals slightly sooner that the outside world.

I agree with what you are saying here. I'm not convinced the timing problems would be insurmountable, but they could certainly become an issue. I've run into exactly this problem with my current test setup when my logic delays finally added up to the point where the memory stopped working. Interestingly, I didn't fix the problem by going to the faster logic families that you are in favor of -- I just adjusted the system clock to compensate for the extra delays.

This is another reason in favor of Arlet's suggestion to use an FPGA instead of a CPLD. Since most FPGAs have PLL blocks on board, you can create clocks signals with arbitrary phases. Thus if you have fixed delays introduced by logic, you can easily change their timing relative to clock edges. Obviously you are still limited by the total width of the various timing windows on the CPU, but I don't think that will often be an issue at speeds as high 8 MHz (fastest speed supported at 3.3 volts), and perhaps even 14 MHz would not be difficult to reach either.

[Aslak3]

cbscpe wrote:

The Atmel PLD are only an issue when you want to use the JTAG pins as normal IO pins. As long as the JTAG pins are dedicated to the JTAG interface a normal JTAG programmer will do the job. Actually I'm doing exactly that.

Well, that is the same as I've used both the XC9500 and Flex 10Ks, but with vendor specific programmers (or clones, in the case of Altera). I did not now the Atmel parts can be used with generic programmers though.

But what I really struggled with is the tooling. With both the Xilinx and Ateml PLDs, everything is nicely contained: HDL synthesis, simulation, programming etc. And free. It wasn't nearly so clear how to get started with the Atmel parts, so I basically gave up. I'd be interested to hear what software you use in your tooling.

[Arlet]

Quote:

This is another reason in favor of Arlet's suggestion to use an FPGA instead of a CPLD. Since most FPGAs have PLL blocks on board, you can create clocks signals with arbitrary phases.

Using multiple clocks may not even be necessary. What I did in my project was generate an internal 96 MHz clock, and divide it by 12 to generate the 8 MHz output clock for the 65C02. Starting at falling edge of PHI2 I would wait (internal) 4 cycles, and grab the address from the 6502 bus, and copy it to the SRAM address bus. Two cycles later, I would take the data from the SRAM bus, and write it to the 6502 bus, with a few cycles to spare. In the remaining 10/11 cycles the SRAM was free to be used by the FPGA.

[jmp(FFFA)]

Arlet wrote:

Sounds interesting. I'm kinda busy with other work right now, but starting next week, it should ease up a bit, so I could do some fun stuff again. The biggest problem I was struggling with is the FPGA pin count. Using a design where the FPGA sits between the CPU and the memory requires a lot of I/O pins, leaving very little for anything else (V1 had 11 I/O pins left on the FPGA). I don't know how many colours you want for the VGA, but potentially it could cost quite a few pins.

I'm not sure what you are using all of the I/O pins for, but if you aren't married to Xilinx FPGAs, here are a couple of non-BGA FPGAs to consider:

Lattice XP2: LFXP2-17E-5QN208C -- 146 I/O pins available in a 208-PQFP package
Altera Cyclone III: P3C16Q240C8 -- 160 I/O pins available in a 240-PQFP package

I like the way you set things up on V1 where you interleave access to fast SRAM between the CPU and other peripherals (e.g. video). A 25.175 MHz video clock (enough to support 640x480 -- I don't see much point in higher resolutions with an 8-bit processor) should still leave enough time for the 8 MHz 65C02/65C816 to access the SRAM with no wait states, and the FPGA can create an MMU which will give the 65C02 access to an arbitrarily large amount of memory. I don't know if there's any value in making the system clock a multiple of the video clock or just go ahead and create two clock domains. Probably the latter since it's no big deal to introduce pipelines of any reasonable size for video processing anyway.

Oh, and I would be happy with 12 bits for color (4-bit DACs). More would be nice, but returns diminish rapidly above 4-5 bits anyway.

Arlet wrote:

Adding more pins would require moving to BGA, which I'm not too excited about either. It requires a more expensive board, make assembly harder, and cost more.

Have a look at the two FPGAs above and let me know what you think. If you don't need more than 160 pins for what you're thinking of using it for, then perhaps there is no need to go to a BGA package. I don't expect that soldering the 240-PQFP package will be fun, however!