interfacing cpld

You can do: device -> serial to parallel -> FIFO -> STM32 -> FIFO ->

parallel to serial -> device. Two to four levels FIFO should be enough to minimize interrupts for the STM32. If your micro can't process and store data fast enough, you have bigger problems anyway.

Use the CPLD as a UART, go into a dedicated UART peripheral on the STM? That gives you all your communications in two wires, one RX and one TX, and uses the state machine they've already built into the peripheral rather than your core clock cycles.

This is hard to decipher ? You say NRZ, but then say the 2nd uC runs at 2.048MHz and can accept data at 2,048/8 byte rate - That's 1 bit every clock, and it is rare for controllers to accept ANY serial stream at the SYSCLK rate. UARTS are /8 or /16, and SPI can get to /2 on some for master, but slave is usually slower again. Then you say 8Mhz and 72Mhz, so it is not easy to see that speeds you really mean, where.... ?

From a pure data flow angle, yes you can use a CPLD as a parallel to serial, and parallel-side you can use SRAM model (OE on read, is std SRAM direction control)

You may want to include a flag pathway, typically these are TxReady, RxNew, and TxWait. (depends a little on who is considered the master)

Or, if speed is vital, you can skip polling TxReady, and time-pace Sends, but here an 'Oops' sticky flag can be nice to add, to catch if this ever messes up.

I'd also look at the SSC/SPI speeds of both sides, and see if existing peripherals can be used : ie is the CPLD _really_ needed ?

I think, I might not have been really good at describing my problem. Yes, I would love to go with integrated uarts/SPIs in ARM uC, but a device that I want to connect to ARM outputs data like this:

Clock is 2,048MHz and all 4 clocks are independent. My idea is to feed these 8 lines into CPLD, serialize/deserialize them and then have a

Maybe I am missing something, but I don't see a way how to multiplex SPI's since uC have only 2 and CPLD with serializer/deserializer seems like the only option.

That's only slightly better..

Who provides the 4 clocks ? Who is master and who is slave ? Are those 4 data streams concurrent, or might they be concurrent ? What are the average, and peak data rates, over all 4 channels ?

A SPI mux is relatively simple, but it does assume you only want one 'link' active at a time.

-jg

Ahhh, slighly more sense is made. Answers from this point on will probably diverge based on the answers to two very important questions. A) How many of these are you ever going to make, and B) what's your time worth?

The reason I ask is that, while you may be able to squeeze what you're looking for into a CPLD, you may find yourself having to do some serious work to do so. When all is said and done on that approach, you may find that you need a pretty substantial CPLD, which aren't necessarily cheap.

On the other hand, Spartan 3A FPGAs start at about $7 for the tiniest ones. That may also need more flash than you've got available; add another buck for a dedicated serial flash for the S3A. Now you'd have plenty of logic available to talk to your target device, as simple as complex as you'd like, as well as gobs and gobs of memory to FIFO the data in both directions. You could have the FPGA communicate back to the ARM any way you'd like; the easiest may be to place it on an external memory bus with a few address lines and an interrupt pin.

The FPGA lets you dramatically, wildly overkill the problem. But you could write it as if you had infinite FPGA resources available in the chip since, as compared to the scope of the problem, you would. And for $8 on the BOM you could call the problem a day. If you found some other, optimal solution, it would probably cost you closer to $3, though what it would be doesn't come to mind.

So, how important is $5?

If the task cannot be done with a simpler-smart-mux (which will fit in a sub $2 CPLD), then another option is a device with many SPI ports.

Somewhat hidden in the fine print, on the Atmel XMega's is that their many USARTS can also run SPI mode. These start ~$2.40, so fit between CPLD and FPGA alternatives.

You would need to check the speed/buffer details, but such a device would manage concurrent data streams.

-jg

I would not say master or a slave. The device I am working with is just a line interface - it decodes data received on line and output it as serial data. Same way it receives serial data and transmit it to the line

They are concurrent. This is full-duplex communication.

Data rate is constant with 1 bit per clock cycle, with clock running at 2,048 MHz.

In SPI terms, Master is the originator of the clock. So your interface Rx Channel is a master, as it decodes the clock. The Tx may be a slave

That moves outside a simple SPI Mux, and into data buffering, which pushes up the CPLD size, At a minimum, you need a collecting register, and a buffer register, which is 64 MC min, and 2 buffers + 1 shifter per node is 96MC. Might fit into a 128 MCell device, like Atmel ATF1508RE ? (or XC2C128, or LC4128)

Memory map wise, this has to look like 2 x 8 bits, or 8+8 as 16 bit bus, with R/W choosing which cells to read.write. You will also likely need 2 signal flags : TxFree, RxRdy, and ideally

So the host uC needs to (on average) handle one byte every us. Every 4us it sends two bytes, and receives two bytes.

Rather than parallel on the host uC, you could look at Serial (SSC/ SPI) as that usually has fifos (unless there is some latency ceiling, you not not mentioned)

So a XMega with 5 spi ports, would do this, but needs care on the speed : 4.096Mbd is the duplex data rate, but not all bytes are valid, so a status/flag byte is needed as well.

So you might run at 8.192 duplex, to the host uC, and send 3 bytes every us, each way. (gives 25% slack time, to allow clock skews) (anything a margin above 6144 will be ok)

-jg