CPLD + µC with reasonably-priced tools?

Dealing with the multiple power supplies can be easy if you use some of the DC-DC modules that are on the market. We use Tyco Lynx series converters to generate the voltages for a Virtex-4FX and a Spartan-3E. They just need a few external components. A resister to adjust their output voltage, and some bulk decoupling capacitors. You can get them as through hole SIP modules, and I think that Mouser sells them.

There are multiple different ways of dealing with the 5V IO issues, it depends on what you are interfacing to.

Regards,

John McCaskill

Buy an evaluation board/development kit, probably that's the cheapest, and least effort. Some Xilinx options:

Virtex-4 Mini modules (hard PowerPC core): $250

Spartan-3 Starter kit (soft uBlaze core): $149

Regards,

Zoltan

Not an option, I'm afraid (otherwise it would by far be the easiest.) Unfortunately, the board needs to fit into a legacy system, which means a specific form factor, connector, and power supply (and the need to interface to 5 V TTL logic -- I think the system is actually old enough that it's real LSTTL buffers on the other side, not HCMOS.)

-hpa

How big is your form factor? I think it is still easier to make a motherboard for the Virtex-4 Mini module, and add a 5V TTL logic converter and the power supplies vs. designing a new board. I wouldn't worry about power supplies. That should be your smallest problem.

Other option is to put a small Spartan II and a uC (with external data bus support, e.g. Atmega), and use the dual-port ram inside Spartan to share memory between uC and Spartan.

The form factor is quite big -- 100x160 mm (Eurocard), so space is largely plentiful. The Virtex-4 mini module is quite expensive, though ($250), which is okay for a one-off but may be too much for an actual production run -- I would have to do the math on that.

I didn't realize that Spartan II was 5 V tolerant. I'm going to have to see if that is practical to combine with a microcontroller. Still needs dual power supplies, though If not, a 200,000-gate Spartan II apparently retails for $26 these days; that FPGA should be large enough to fit an 8- or 16-bit microcontroller core plus all the logic.

Anyone has any kind of idea how long Spartan II is likely to remain on the market?

-hpa

IIRC you can put a simple microblaze (32 bits) design into the Spartan- II, IF you don't need too much code space. But picoblaze (8 bit) can be done as well. Probably that would be the easiest solution, have a block ram in your FPGA logic, and map that RAM into uBlaze.

You need to define just how much the CPLD portion needs to DO.

- ie how many macrocells are needed How much memory is shared, and what bandwdith is needed ?

It is quite easy to set up shared memory access on a Microcontroller, with external RAM and a CPLD - choose a fast SRAM, and lock the CPLD access to the idle periods in the uC bus - that way, you emulate dual-port memory with cheap SRAM.

If the uC memory bandwidth are lower than the CPLD-memory, you could consider a SPI port into the CPLD, as that simplifies the PCB layout and opens more uC options.

-jg

A suggestion if you decide to go 8-bit with PicoBlaze. Nial Stewart has adapted the Picoblaze 2 (Virtex-2 version) for Spartan 2. This overcomes the extremely small (256 instruction) code space of the original PicoBlaze for Spartan 2. I have used this in the Spartan 2 200K gate part and it leaves most of the logic free for your other needs.

HTH, Gabor

PS here's the header from the Nial's perl script for converting instruction RAM from Virtex 2 to Spartan format:

# This is a Perl utility written to convert initialisation # definitions from Virtex Blockram (1024 x 18 bits) to SpartanII # Blockram (5 * 256 x 4 bits) format. # # This is to allow the bigger version of the Picoblaze processor # to be used with SpartanII devices. # # This is provided as is for general use without any guarantees or # warranties. # # =A9 Nial Stewart Developments 2003 #

Yes, I've pretty much independently come to the same conclusion. This is most likely the sanest option.

The next step is to prototype the CPLD code and see what kind of CPLD it can fit into.

The only potential concern with having the CPLD do the arbitration of the SRAM bus is needing too many I/O pins on the CPLD, but I'm sure that can be dealt with, too.

-hpa

H. Peter Anvin wrote: ...

Go with an FPGA. Some more external infrastructure needed, but much more possibilities...

regards:

good answer