Mixing AVRs, Xilinx CPLDs, and JTAG
I’ve been working on optimizing the Floppy Emu design in preparation for making a custom circuit board, and as always I’m faced with a dizzying number of choices and potential trade-offs. The design calls for a Xilinx XC9572XL CPLD along with an Atmel ATMEGA1284P AVR microcontroller, and I’ve belatedly realized that even the simple task of programming these chips will raise some problems.
Programming Connections
For starters, I don’t actually own a Xilinx JTAG programmer, and my Altera JTAG USB Blaster appears to be a single-purpose device, so I’ll have to purchase a new Xilinx programmer. Then I’ll have to cram both a 2×5 JTAG header (for the CPLD) and a 2×3 ISP header (for the AVR) into the board, which seems awkward and redundant. Is there a better way?
The ATMEGA1284P also supports JTAG programming, if you’re willing to give up use of four GPIO pins. I could use a single 2×5 JTAG connector, connect the two chips in a JTAG chain, and use JTAG to program both the microcontroller and the CPLD. But with what programmer? I don’t want to have to purchase a Xilinx JTAG programmer and the Altera AVR JTAG ICE Programmer. There must be a generic JTAG programmer that will work with them both, but I’m uncertain which one, and with what programming software.
Another option is to use the ATMEGA to program the CPLD somehow, by connecting the CPLD’s JTAG pins to GPIO pins on the ATMEGA. Then I’d only need a single 2×3 ISP connector for programming the ATMEGA, and could use the AVR ISP programmer that I already have. But I don’t relish trying to write a JTAG player for the microcontroller, and a brief search to see if something like that already exists didn’t turn up anything.
Voltage Levels and Clock Speeds
Initially I’d planned to run the ATMEGA with an external crystal at 16MHz. Unfortunately, to run at that speed requires a 5V supply, and everything else in the system will be using 3.3V, so level conversion will be required. Although it’s not a horrible problem, level conversion is one more headache that I’d prefer not to deal with. According to my squinting at the graphs in the datasheet, at 3.3V the ATMEGA should safely run at speeds up to 13.3MHz — call it 12MHz to pick a round number on the safe side. Or I could use the internal 8MHz oscillator, and dispense with the external crystal entirely, eliminating yet another part.
But in a system where I’m concerned that write performance may not be fast enough to keep up with the Mac, is it really a good idea to drop the clock speed from 16MHz to 12MHz or 8MHz? For that matter, why not increase the clock speed to the maximum of 20MHz? Or use a different chip like the ATXMEGA192, which has an internal 32MHz oscillator and runs at 3.3V?
The truth is I really don’t know what clock speed will be needed. I’m relatively confident that given a large RAM buffer for track data, reads will work at clock speeds of 8MHz or even lower. Writes are the concern– the Mac will pump out data sector by sector, with no flow control mechanism, so Floppy Emu must either keep up or fail. While the micrcontroller clock speed will clearly be important, the SPI clock speed used to communicate with the SD card is probably even more critical, and that can be varied independently. Furthermore, the reading I’ve done suggests that maximizing SD transfer rates has less to do with increasing the clock speed than with optimizing the transfer code, using multi-sector transfers where possible, and so forth. I’m not sure how well-optimized sdfat lib is in that respect. In the end, while it’s hard to argue against the “faster is better” sentiment, it’s unclear that a higher microcontroller clock speed is necessary or sufficient for making writes work.
Presently I’m leaning towards eliminating the level converter, running the microcontroller at 3.3V, and limiting the clock speed to 12MHz (or 8MHz with the internal oscillator). My reasoning is that the ATMEGA is likely to either be plenty fast enough to support writes, or not even remotely fast enough. Running at 5V with a level converter is only worthwhile if I believe the extra 66% speed bump going from 12MHz to 20MHz will be the difference between being too slow or just fast enough.
Read 6 comments and join the conversation6 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
The entire AT MEGA x8-series will happily run at 16 MHz with only 3.3 V, despite the fact that the datasheet says it will not. It is over-clocking, but it has proven very reliable none the less. I am pretty sure the 128 4 would work just as well.
If you are concerned with speed though, why not have a look at the ARM Coretex M3:s? They are available from many manufacturers and are relatively cheap, while at the same time offering quite a bit more power over the AVR:s.
Using something like the NXP LPC1343 would also give you full speed USB that can easily implement mass storage support (even for firmware updates). And, oh yeah, it runs at 72 MHz! 3.3 V. Dev boards are available to buy for 40 dollar or so. 48 pin LQFP chips in single quantities go for about 7 dollars.
That’s interesting it will overclock to 16 MHz at 3.3V. I guessed that might be the case, but I’m a little reluctant to rely on it. It’s probably worth a try though.
Good idea about the Cortex M3. I did a review of the STM32 Cortex M3 board last month: http://www.bigmessowires.com/2011/10/27/cortex-m3-for-dummies-stm32-discovery-board/ I’ve been hesitant to switch away from the ATMEGA series, since it would require learning a new mcu architecture, porting all my code (including SdFatLib), and possibly getting a new programming hardware too.
I think I really need to do some better timing calculations to determine what speed mcu is needed, before I go further.
If you go down the JTAG route the dangerous prototypes bus blaster should support programming ARMs and FPGAs, however I haven’t found any support for AVR programming, albeit, there is the AVR dragon of course. I’d also recommend the cortex M3 or even M0 series as they will both win over the AVR in performance. The ARM micros will also be cheaper, STM32 Cortex M3s in an LQFP package start at £1.50 and NXP have a nice LPC1754 with USB host/otg/device, 128 kB flash, 32 kB SRAM, ADC and DAC for £4.69.
When I used the Spartan3E we used to program it via JTAG at boot time, using GPIOs on the PPC based SOC. I remember being given some source to port. It was an “XSVF Player”.
I didn’t use it at the time but a quick google suggests that the XAPP058 appnote might be relevant.
We generated the XSVF file from the Xilinx desktop tools.
It also appears that the Bus Pirate can program Xilinx devices via JTAG (using the same appnote in fact):
http://dangerousprototypes.com/forum/viewtopic.php?f=51&t=1867
…and also AVRs:
http://dangerousprototypes.com/docs/Bus_Pirate_AVR_Programming
OpenOCD supports programming AVRs via JTAG http://openocd.sourceforge.net/ but it doesn’t seem to support programming Xilinx devices.
This Xilinx appnote might be helpful in setting up a scan chain and also for programming the CPLD from the micro using JTAG http://www.xilinx.com/support/documentation/application_notes/xapp058.pdf
More info on progamming Xilinx devices in Slave Serial Mode http://www.xilinx.com/support/documentation/application_notes/xapp502.pdf
The Xilinx XAPP058 tech note is a good lead. http://www.ethernut.de/en/xsvfexec/ has an optimized example, with an ATMEGA128 used to program a XC9536XL CPLD, so that approach looks promising. Then I’d only need an AVR ISP programming header for the microcontroller, and CPLD configuration files could be loaded from the SD card and applied by the ATMEGA. Sounds pretty good!