Forums

interfacing cpld

Started by Justas P November 21, 2009
Hi there,

a newbie question, and I would be grateful for a response or at least
hint where to look(read) for information.

My problem is:
I have two synchronisation domains. One device (A) is running at a
2.048 frequency. Then there is a STM32 microcontroller (B) that is
using 8 MHz clock source. Dev A gives out NRZ data stream and accept
NRZ data stream. I want to send and receive data eg: A <-> B. To do
that I am planing to use CPLD to convert to/from parallel 8 bit data
to serial NRZ stream.

The question is how to organise data flow from CPLD to STM32. STM will
be running at 72 MHz so I don't want to waist cycles. My idea is that
once CPLD receives 8 bits of data from dev A, it copies data from
shift register to a register and raises an interrupt to STM (or use
internal counter), that data is ready (that would come at 2,048/8 =
256 KHz intervals, and that is perfect for me). But I can't figure out
a way how to use same data lines for both writing/reading? Is there a
better way than to mimic asynchronous memory interface with RDB/DSB
and WRB/RWB? Please keep in mind that I only have 2 memory addresses -
data to be transmitted and data to be read?

Thanks in advance!
Justin
On Nov 21, 2:06=A0pm, Justas P <justas.pode...@gmail.com> wrote:
> Hi there, > > a newbie question, and I would be grateful for a response or at least > hint where to look(read) for information. > > My problem is: > I have two synchronisation domains. One device (A) is running at a > 2.048 frequency. Then there is a STM32 microcontroller (B) that is > using 8 MHz clock source. Dev A gives out NRZ data stream and accept > NRZ data stream. I want to send and receive data eg: A <-> B. To do > that I am planing to use CPLD to convert to/from parallel 8 bit data > to serial NRZ stream. > > The question is how to organise data flow from CPLD to STM32. STM will > be running at 72 MHz so I don't want to waist cycles. My idea is that > once CPLD receives 8 bits of data from dev A, it copies data from > shift register to a register and raises an interrupt to STM (or use > internal counter), that data is ready (that would come at 2,048/8 =3D > 256 KHz intervals, and that is perfect for me). But I can't figure out > a way how to use same data lines for both writing/reading? Is there a > better way than to mimic asynchronous memory interface with RDB/DSB > and WRB/RWB? Please keep in mind that I only have 2 memory addresses - > data to be transmitted and data to be read? > > Thanks in advance! > Justin
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.
On Sat, 21 Nov 2009 14:06:51 -0800 (PST)
Justas P <justas.poderys@gmail.com> wrote:

> Hi there, > > a newbie question, and I would be grateful for a response or at least > hint where to look(read) for information. > > My problem is: > I have two synchronisation domains. One device (A) is running at a > 2.048 frequency. Then there is a STM32 microcontroller (B) that is > using 8 MHz clock source. Dev A gives out NRZ data stream and accept > NRZ data stream. I want to send and receive data eg: A <-> B. To do > that I am planing to use CPLD to convert to/from parallel 8 bit data > to serial NRZ stream. > > The question is how to organise data flow from CPLD to STM32. STM will > be running at 72 MHz so I don't want to waist cycles. My idea is that > once CPLD receives 8 bits of data from dev A, it copies data from > shift register to a register and raises an interrupt to STM (or use > internal counter), that data is ready (that would come at 2,048/8 = > 256 KHz intervals, and that is perfect for me). But I can't figure out > a way how to use same data lines for both writing/reading? Is there a > better way than to mimic asynchronous memory interface with RDB/DSB > and WRB/RWB? Please keep in mind that I only have 2 memory addresses - > data to be transmitted and data to be read? > > Thanks in advance! > Justin
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. -- Rob Gaddi, Highland Technology Email address is currently out of order
sOn Nov 22, 11:06=A0am, Justas P <justas.pode...@gmail.com> wrote:
> Hi there, > > a newbie question, and I would be grateful for a response or at least > hint where to look(read) for information. > > My problem is: > I have two synchronisation domains. One device (A) is running at a > 2.048 frequency. Then there is a STM32 microcontroller (B) that is > using 8 MHz clock source. Dev A gives out NRZ data stream and accept > NRZ data stream. I want to send and receive data eg: A <-> B. To do > that I am planing to use CPLD to convert to/from parallel 8 bit data > to serial NRZ stream. > > The question is how to organise data flow from CPLD to STM32. STM will > be running at 72 MHz so I don't want to waist cycles. My idea is that > once CPLD receives 8 bits of data from dev A, it copies data from > shift register to a register and raises an interrupt to STM (or use > internal counter), that data is ready (that would come at 2,048/8 =3D > 256 KHz intervals, and that is perfect for me). But I can't figure out > a way how to use same data lines for both writing/reading? Is there a > better way than to mimic asynchronous memory interface with RDB/DSB > and WRB/RWB? Please keep in mind that I only have 2 memory addresses - > data to be transmitted and data to be read? > > Thanks in advance! > Justin
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'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: +-----+ | dev | -- Serial data out1 (NRZ) | | --- Serial data out1 clock | | --- Serial data in1 (NRZ) | | --- Serial data in1 clock | | -- Serial data out2 (NRZ) | | --- Serial data out2 clock | | --- Serial data in2 (NRZ) +-----+ --- Serial data in2 clock 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 8bit wide bus to uC. Since I would do 1:8 deserializing, I would get interrupt from CPLD to take or put data at appx 4x256KHz. 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.
On Nov 24, 10:37=A0am, Justas P <justas.pode...@gmail.com> wrote:
> > 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: > > +-----+ > | dev | -- Serial data out1 (NRZ) > | =A0 =A0 =A0 | --- Serial data out1 clock > | =A0 =A0 =A0 | --- Serial data in1 (NRZ) > | =A0 =A0 =A0 | --- Serial data in1 clock > | =A0 =A0 =A0 | -- Serial data out2 (NRZ) > | =A0 =A0 =A0 | --- Serial data out2 clock > | =A0 =A0 =A0 | --- Serial data in2 (NRZ) > +-----+ --- Serial data in2 clock > > 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 > 8bit wide bus to uC. Since I would do 1:8 deserializing, I would get > interrupt from CPLD to take or put data at appx 4x256KHz. > > 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
On Mon, 23 Nov 2009 13:37:43 -0800 (PST)
Justas P <justas.poderys@gmail.com> wrote:

> > 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: > > +-----+ > | dev | -- Serial data out1 (NRZ) > | | --- Serial data out1 clock > | | --- Serial data in1 (NRZ) > | | --- Serial data in1 clock > | | -- Serial data out2 (NRZ) > | | --- Serial data out2 clock > | | --- Serial data in2 (NRZ) > +-----+ --- Serial data in2 clock > > 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 > 8bit wide bus to uC. Since I would do 1:8 deserializing, I would get > interrupt from CPLD to take or put data at appx 4x256KHz. > > 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.
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? -- Rob Gaddi, Highland Technology Email address is currently out of order
On Nov 24, 11:55=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote:
<snip>
>=A0If you found some > other, optimal solution, it would probably cost you closer to $3, > though what it would be doesn't come to mind.
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
> Who provides the 4 clocks ?
4 clocks are provided by a device - same one that receives or transmit data. It recover this clock signal from transmition line.
> Who is master and who is slave ?
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
> Are those 4 data streams concurrent, or might they > be concurrent ?
They are concurrent. This is full-duplex communication.
> What are the average, and peak data rates, over > all 4 channels ?
Data rate is constant with 1 bit per clock cycle, with clock running at 2,048 MHz.
On Nov 24, 8:42=A0pm, Justas P <justas.pode...@gmail.com> wrote:
> > Who provides the 4 clocks ? > > 4 clocks are provided by a device - same one that receives or transmit > data. It recover this clock signal from transmition line. > > > Who is master and who is slave ? > > 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
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
> > > Are those 4 data streams concurrent, or might they > > be concurrent ? > > They are concurrent. This is full-duplex communication.
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 2 error flags TxOverrun, RxOverrun)
> > What are the average, and peak data rates, over > > all 4 channels ? > > Data rate is constant with 1 bit per clock cycle, with clock running > at 2,048 MHz.
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