interfacing cpld
in [Embedded]
|
Prev: New Microchip PIC32 Microcontrollers have Lots of Everything (2 CAN 2.0b, Ethernet, lots more)
Next: MSP430 core performance
From: -jg on 23 Nov 2009 17:28 On Nov 24, 10:37 am, Justas P <justas.pode...(a)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. 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
From: Rob Gaddi on 23 Nov 2009 17:55 On Mon, 23 Nov 2009 13:37:43 -0800 (PST) Justas P <justas.poderys(a)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
From: -jg on 23 Nov 2009 19:11 On Nov 24, 11:55 am, Rob Gaddi <rga...(a)technologyhighland.com> wrote: <snip> > 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. 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
From: Justas P on 24 Nov 2009 02:42 > 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.
From: -jg on 24 Nov 2009 04:29
On Nov 24, 8:42 pm, Justas P <justas.pode...(a)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 |