Enhanced Dynamically Reconfigurable Systems Using CPLD/FPGA

[Arlet]

Updated github files. CPU is now connected to FPGA. There are still 14 pins free on the bottom for the FPGA, just enough for 12 bit VGA + HS/VS. The left side of the FPGA is for SPI/UART/USB/Audio.

[jmp(FFFA)]

Arlet wrote:

Updated github files. CPU is now connected to FPGA. There are still 14 pins free on the bottom for the FPGA, just enough for 12 bit VGA + HS/VS. The left side of the FPGA is for SPI/UART/USB/Audio.

Can we put a 4-bit R-2R DAC on the board and an analog VGA connector? That's just the connector, plus 24 0402 (1K/2K works nicely) resistors. Enough to connect up to most VGA displays.

I'll look at your schematics in more detail this evening and will let you know if I spot anything or if I have any other suggestions.

[cbscpe]

Aslak3 wrote:

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.

I use WinCUPL and ATMISP. When I decided to start with CPLD I started to use WinCUPL, even documentation is rather lacking it was the easiest to get familiar with and it has a small footprint in my Windows XP that just runs in a virtual machine. That's the drawback for using a Mac. The complexity of ATMELs CPLD is not very high (the ATF1508AS is the largest having only 128 Macrocells) and CUPL covers it nicely and it also covers GALs that I still use quite often. I would not recommend this setup as a start when your goal are more recent and more complex CPLDs or FPGAs as WinCUPL is definitively a dead-end and there will be no development whatsoever. But for my small projects it does the job.

[Arlet]

Yes, that was the plan, except instead of a R-2R ladder, I was planning to use 500-1000-2000-4000 Ohms. I don't think 1K/2K works, though. The R-2R ladder has an impedance of R, so combined with 75 Ohm impedance on the input that drops 3.3V to 230mV, which is a bit low. To avoid boutique values, I wanted to make 500 from 1K/1K parallel, the 2K from 1K/1K in series, and the 4K from 1K8+2K2 in series, for a combined 21 resistors for 4 bit RGB.

In addition to analog VGA, I wanted to add a ADV7391 PAL/NTSC encoder chip. It only needs 13 digital inputs, and produces various analog TV signals, including composite, component, rgb, and s-video. I was planning to reuse the VGA output pins on the FPGA for most of the interface.

[BigDumbDinosaur]

cbscpe wrote:

...WinCUPL is definitively a dead-end and there will be no development whatsoever. But for my small projects it does the job.

Atmel also offers a different package called "Pro Chip Designer" (PCD) which isn't free for the download like WinCUPL. However, as I understand it, PCD supports VHDL in addtion to CUPL, as well as schematic capture and better simulation tools. If I were producing commercial products with Atmel devices in them I would have gone with PCD, which, unlike WinCUPL, appears to be subject to ongoing development.

As you note, WinCUPL is okay for hobby CPLD aplications once you get familiar with its kinks.

[jmp(FFFA)]

Arlet wrote:

Yes, that was the plan, except instead of a R-2R ladder, I was planning to use 500-1000-2000-4000 Ohms. I don't think 1K/2K works, though. The R-2R ladder has an impedance of R, so combined with 75 Ohm impedance on the input that drops 3.3V to 230mV, which is a bit low. To avoid boutique values, I wanted to make 500 from 1K/1K parallel, the 2K from 1K/1K in series, and the 4K from 1K8+2K2 in series, for a combined 21 resistors for 4 bit RGB.

Please have a look at the Terasic DE1 board: http://www.terasic.com.tw/cgi-bin/page/ ... =165&No=83 It uses the R-2R ladder with 1K/2K resistors for the VGA output. You can download the CDROM image (~90 MB) with the schematic for free if you register there. I had one of these boards in the past before replacing it with a newer one and I can tell you that the VGA output worked OK with the older VGA monitors I used it with. However, I do see your concern about the voltage divider formed. This can be resolved for the cost of a quad op-amp chip with RRIO. Board space is almost insignificant with TSSOP or QFN packaging. I'll attach a schematic when I get home this evening.

Arlet wrote:

In addition to analog VGA, I wanted to add a ADV7391 PAL/NTSC encoder chip. It only needs 13 digital inputs, and produces various analog TV signals, including composite, component, rgb, and s-video. I was planning to reuse the VGA output pins on the FPGA for most of the interface.

OK. What do you have in mind to switch between the two outputs? Some kind of high speed bus switch driven by a dip switch or jumper (unless you have a spare GPIO pin on the FPGA)?

[Arlet]

jmp(FFFA) wrote:

OK. What do you have in mind to switch between the two outputs? Some kind of high speed bus switch driven by a dip switch or jumper (unless you have a spare GPIO pin on the FPGA)?

No, much simpler. Just connect them in parallel. When watching VGA, keep the ADV7391 chip in sleep mode. When using the TV outputs, just disconnect the VGA cable. The resistor stubs shouldn't matter.

Quote:

Please have a look at the Terasic DE1 board: http://www.terasic.com.tw/cgi-bin/page/ ... =165&No=83 It uses the R-2R ladder with 1K/2K resistors for the VGA output.

I found the schematics. It does have 1K and 2K resistor packs, but it doesn't use them in ladder configuration. Rather, it uses 1K/1K parallel, 1K, 2K, and 2K+2K in series.

By the way, in the schematics, I have connected the ABORTB pin of the 65C816, but I'm considering removing it again. It only sounds marginally useful, and I think the pin can be better used for something else. What do you think ?

[jmp(FFFA)]

This is what I was thinking of (one for each color channel):

4-bit DAC

(excuse the hastily drawn schematic)

It uses an R-2R ladder with the op-amp buffer. Gives an exact impedance match without fiddling with resistor values.

Edit: Link for the TSH74 op-amp datasheet: http://www.st.com/web/en/resource/techn ... 002283.pdf

[jmp(FFFA)]

Arlet wrote:

I found the schematics. It does have 1K and 2K resistor packs, but it doesn't use them in ladder configuration. Rather, it uses 1K/1K parallel, 1K, 2K, and 2K+2K in series.

Damn, not sure how I missed that, but you are absolutely right.

Arlet wrote:

By the way, in the schematics, I have connected the ABORTB pin of the 65C816, but I'm considering removing it again. It only sounds marginally useful, and I think the pin can be better used for something else. What do you think ?

I agree that it sounds only marginally useful today when it's cheap to add enough memory to fully populate the 65C816's address space anyway. If there is a competing use for the FPGA I/O that is compelling, then why not disconnect it.

[BigDumbDinosaur]

jmp(FFFA) wrote:

Arlet wrote:

By the way, in the schematics, I have connected the ABORTB pin of the 65C816, but I'm considering removing it again. It only sounds marginally useful, and I think the pin can be better used for something else. What do you think ?

I agree that it sounds only marginally useful today when it's cheap to add enough memory to fully populate the 65C816's address space anyway. If there is a competing use for the FPGA I/O that is compelling, then why not disconnect it.

ABORTB is useful for trapping memory access violations in a protected mode environment, as well as catching "privileged" instructions. If you don't connect it be sure to pull it up to Vcc.

[Arlet]

BigDumbDinosaur wrote:

ABORTB is useful for trapping memory access violations in a protected mode environment, as well as catching "privileged" instructions. If you don't connect it be sure to pull it up to Vcc.

It's also possible to generate such traps using the NMI pin, but then send the ABORT vector instead.

For now, I'll leave the ABORTB connected, until the pin is needed for a more useful function.

Some other questions:

What kind of power source do you want ? I was thinking about using a mini USB connector. A USB adapter provides a convenient source of 5V. Also, by adding a small FT230X chip on the board, and attaching it to the same USB connector, we can provide a serial port at the same time. A nice feature would be to use this serial port for debug or trace.

I addition to the USB/serial port, I wanted to add a second UART port on the board. Usually, I provide a 3 pin TTL level Molex connector, and use an external USB-serial converter cable. I make these cables myself, and I can sell one at cost. Alternatively, we can have a DB-9 connector with level converter on the board. What's your thought ?

I found another audio chip that looks interesting. The SSM2604. It's a combined chip for audio in/out, requiring only 5 pins for the digital interface, and 2 pins for the I2C control interface. The I2C bus can be shared with the PAL/NTSC chip, and possibly with some other I2C device.

[BigEd]

Please use micro USB not mini USB! It's a standard size for phone chargers (at least in Europe) and most people already have one or two.

[Arlet]

I know, but micro USB is so flimsy. I have a bunch of those phone chargers, and most have detachable cords so they are easily replaced by mini USB.

[jmp(FFFA)]

I agree with Arlet's choice to use a mini-USB over a micro-USB. The micro-USB connectors are not very durable and the connector is likely to come off the PC board after any less-than-gentle handling.

Regarding the rest of the design which I've just reviewed, here are a few thoughts:

• Power supplies -- in the interest of efficiency, and since they are so easy to use these days anyway, consider using a switching power supply instead of linear power supplies. This is especially appealing for battery operation where it will hugely increase battery life. I'll take the lead on this if you agree.
• Do you need a pullup on the RDY line (OD output on the 65C02)? Say, 2.2 k? It should be driven with OD too, or else through a resistor or diode to limit current.
• Does it ever make sense for an external device to have access to the IRQ or NMI lines separately from the FPGA? I know of a number of sensors that include not only an SPI or I2C interface but also an interrupt output pin for example. If they are slave devices, usually this is the only way they can initiate communications with the master.
• I'm fine with TTL level signaling for the UARTs. I just use those $5 Raspberry Pi debugging cables which are cheaper and simpler than implementing a full RS232 interface. If others prefer full RS232 support, I'm OK with that too.
• Can we have an external I2C interface on the device in addition to the SPI interface? A number of useful devices (sensors) only come in I2C flavors. I'd suggest 1.8k pullup resistors for this as well, which is the recommended value to use for 400 kHz rates at 3.3 volts. 0.1-inch (2.54mm) spaced header pins are fine for this type of interface.
• The audio codec you found sounds fine. 24 bits is massive overkill (and a joke on this kind of PC board where you'll never be able to take advantage of it anyway), but the lower 16 LSBs can be dropped by the FPGA to 6502 interface so it need not impact performance.
• It would be nice to have a reset button, an LED for power, and maybe a status LED somewhere as well. An argument could be made for a cheap 1-inch oLED display, but with a debug port on the USB cable as you have suggested, it's somewhat redundant.
• I assume you are planning full host mode support for the USB interface in order to allow more than just a keyboard to be connected (e.g. a keyboard, mouse, and external memory simultaneously)?

[Arlet]

• I don't mind using a switching power supply, so feel free to suggest something. On the v1 sandbox board, the currents were pretty low though. The LDOs barely get warm. Keep in mind we'll need 3.3V and 1.2V for the FPGA and 1.8V for the ADV7391.
• Pullup on the RDY has been added.
• External IRQ sounds reasonable. I propose to add a small expansion/IO connector with I2C, SPI, supply, and any free I/O pins, and add the IRQ to that.
• There's already a reset button for the FPGA, but we can have a separate one for the CPU, or attach a button to the FPGA for any user defined function. Another idea is to add a few shift registers, and add a bunch of leds and push buttons/toggle switches on the SPI bus.
• For the USB, I was planning a dual type "A" stacked connector, attached to FPGA. I don't have any HDL model or code written yet. So, yes, the hardware is ready to support USB host mode, but there's still a lot of work to do before it can actually do that. Support for USB hubs will be very low on my personal to-do list