I2C --> SPI or Parallel Port Concentrator

Correction. See below.

- Chris

I2C channels on the concentrator would be configured as slaves since I want the connected devices to be able to initiate transations.

channels

want

through

The AT94K05/10/40 FPSLIC contains

• a 25 MHz AVR RISC processor

• 5/10/40 k gate FPGA.

• A single large SRAM accessible by the FPGA and the AVR

• Multiple small 32 x 4 DPRAM configurable as 32 x 8 DPRAMs usable as receive FIFOs. On the 05 you have 12 usable DPRAMs or 6 FIFOs On the 10 You have 2 x so 12 FIFOs would fit. If you can live with a 32 x 4 FIFO, then you would definitely have enough for 16 channels.

If the FPSLIC AVR core is sufficient as the micro (20 MIPS) then you will not need the SPI at all.

All processing is done internally.

There is a coverification environment, so you can simulate both the AVR and the I2C slave macro.

Why use I2C? At 400 kbps it is pretty slow. If your datasource is a micro, then I would use a JTAG look alike interface. Signals = TDI,TDO,TMS,TCLK.

This controls two shift registers in the FPGA. First shift register is the address of the DPRAM Second shift register is the data word TMS is used to select the first, the second, and when both are filled the data word is written to the address pointed out by the address shift register.

Very simple reliable logic inside the FPGA, ans should have much higher transfer rate than I2C which is limited to 400 kbps. You should be able to run the TCLK at 6 MHz

-- Best Regards, Ulf Samuelsson. Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Nordic AB.

"Chris Graham" wrote in news:CWXFd.79093$Xk.59972@pd7tw3no:

This should be fairly straightforward with a small FPGA. We have been working with the Altera Cyclone EP1C3 which is the smallest FPGA that Altera sells. It would be more than adequate.

A PLD design would take lots of macrocells. You probably should avoid this approach since a very large PLD is a lot more expensive than a small FPGA.

--
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

Some options: a) Use tiny uC as i2c-spi bridges, and chain them. Advantage is easy to add more channels, & testing is very simple.

b) For CPLDs you are likely to hit RAM issues : if you want

16 remote-readable i2c slaves, then they will need dual port ram - and RAM is expensive in CPLDs [RAM is the most glaring omission on the MAX-II ] So that puts you into the smaller FPGA area - and there, neither speed nor logic are likely to be an issue. You can time-share dual port ram, to make it appear more-ported. Do you need instant-on ? What is MAX i2c speed ?

-jg

What about a FT2232 in host emulation mode, an address decoder and a handfull of PCF8584 8 bit to I2C controllers as USB solution?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

I'd like to have a single fast serial serial link to the host with no need for select lines, so this would not work for my appplication. A dedicated concentrator chip with support for up to say 8 I2C ports would be better.

Sound good. I'll look into a low end FPGA.

While the system was in use, all the channels would be on all the time.

Up to 400 kbps on each channel but some channels might be less - as little as 20kbps.

You do not have to use chip selects, you can also daisy-chain SPI devices, esp if they are all identical. Then the SPI runs at >> 16x the i2c speed.

Instant-on refers to the response from power up. Some FPGAs serial load, and some are faster to start. If that matters, it can influence the FPGA selection. - ie if a remote master, expects the slave to be alive/awake, and does not retry, then this may be an issue.

-jg