1. Home
  2. Embedded Programming
  3. Serial CPLD

Serial CPLD

We have a legacy design that uses a dominant bit serial bus protocol currently bit-banged by software in a micro-controller. Timing is such that the software is very sensitive to interrupt latency.

The new product will have an ARM9 or ARM11 micro running Linux at 400MHz, but the required interrupt latency for bit-banging the protocol is too much to expect of the heavier weight application/OS. Everything was previously done in an ISR.

Thus, we are considering moving that bit-banged serializer logic into a CPLD with an 8-bit bus interface.

The device will need to do things like clock recovery (1KHz), bus arbitration, collision detection, bit stuffing, CRC generation/checking, framing , and bus idle detection, in addition to the RX/TX serial conversions.

Obviously, low cost is a "good thing".

I usually don't do hardware myself, and my Programmable logic skills and component knowledge are ... rusty.

I'm looking for potential part suggestions, with low cost beinig the goal.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran
Loading thread data ...

Michael N. Moran schrieb:

if you only need process 1khz signal a ultra low cost mcu maybe better choice, there are plenty of them under 1.0 usd at that datarate the mcu solution is less expensive then CPLD

Antti

Reply to
Antti

I'm really looking to create a straight-forward 8-bit wide peripheral that has a software/register interface similar to a UART/USART.

thanks, mike

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

Some of the Xilinx Coolrunner II CPLD parts are pretty reasonable and have plenty of I/O. Of course being modern parts they have a core voltage of less than 2V.

Second the suggestion of considering a small 8-bit micro for this purpose. You could easily run out of flip-flops in a small CPLD and the app already runs fine on a micro. Current ones can probably run

2-10x faster yet.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

If my preliminary calculations are good, then I should only need about 22 I/O pins including a clock.

Low power is good. I neglected to mention that in my original post.

Perhaps, but I would really *like* to have a parallel interface to the main processor (4 address, 8 data, R/W, strobe and IRQ). In my mind, this simplifies the device driver. Or maybe I'm just spoiled ;-)

thanks, mike

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

1KHz, that's quite a low speed ?

A CPLD could be used, but at 1Khz it does not _have_ to be used. Low power candidates could be Atmel/Lattice/Xilinx, but these parts hike pin counts, as the macrocell count goes up, so whilst they are cheap on a per-pin basis, if you do not need the pins, they are less of a good fit.

What processor do you use now, that you have your proven code in ?

Most ARMxx devices have quite capable SPI ports, so I'd scrub the parallel UART idea, and shift to finding the smallest variant of your present uC, that has a SPI slave. Less work is always good :)

It is not uncommon to find the bigger CPUs are not up to the detailed IO tasks

Devices like the AT89LP21x, are very quick, sub $1, and have HW SPI and UART ports - so they would easily do the UART or SPIYourSpecailBus bridge, plus they have enough RAM to store small packets.

-jg

Reply to
Jim Granville

Are you sure the latency will be that bad? I don't know Linux nor ARM in such detail to be able to tell, but I do know that in my (DPS) domain IRQ latencies get actually lower with newer PPC parts. Just a matter of code which does not clog the system, i.e. never masks IRQ for more than a few instructions. I would guess that the Linux scheduler would be doing that as well, so you'll have to keep out just some offending device drivers etc. which may well be around.

If you have to go for a CPLD, the Coolrunner is by a good margin the "best" part on the market. I think they get as large as 512 cells, this should be enough to do it and they are really nearly zero power while not clocked; the only bad thing about them and the rest of the programmable logic is that you won't be given the programming details, you have to obediently use the manufacturers software to do for you what you want to do - and know about what it has done as much as it tells you, and keep as many secrets about your product as it wants to.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

Reply to
Didi

Hmmm, 22 I/O = 22 F/F on a small clpd.

One 8-bit output register is 8 FF and one output enable pin, shift register at least 8 FF and a clock input pin, that leaves 4 logic elements for the rest.

Does that about sum it up ??

donald

Reply to
Donald

22 I/O does not mean 22 FF. There is quite a bit in this serial link, from the OP's link:

Sounds like it cannot pause, so the whole packet might need handling inside the CPLD. Thus the suggesiton to use a uC. Now, if the clock was 1MHz, or 10MHz, then a CPLD will outclass the uC

-jg

Reply to
Jim Granville

What's to stop you having a parallel interface to a slave micro..? For strobe, substitute an interrupt input.

Reply to
Mike Harrison

Yup.

As I said in another posting, my I/O needs are less than 22 pins so ... yeah that's part of the puzzle.

The protocol does require a minimum 200K clock, to to implement, but you are correct that its clearly not for speed that I am considering a CPLD.

There have been several including H8 and PIC variants (not without "issues";).

The upper "layer" of the protocol, that must execute on the ARM processor, also has real-time constraints on responses that are sensitive to latencies that can be increased by packet buffering and serialization delays introduced in the interface between the two processors.

Yep.

Thank you for your input, but what I *really* want from this thread is not a design decision concerning the merits of an MCU vs CPLD design, but rather a discussion of the merits of various low cost CPLDs and specific part recommendations.

thank you, mike

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

the CPLD cost go up HUGE, as soon as you dont fit the second smallest one eg 64-72 MC

as soon 72MC are not enough then cheap FPGA is cheaper then next biggest CPLD, that is as soon CPLD price goes over 3USD

optimizing your serializer for smallish CPLD can be expensive in terms of time invested. if your budget tolerates 6USD part you can of course take the semi- cpld (MAX II, or machXO)

so its up to you to choose (and BOM budget) cheapest solution (0.50 USD) would be MCU connected to the main CPU over SPI second is 64/72MC cpld < 2.0USD

3rd Actel FPGA around 3.0 USD 4th MAX-II 6 usd 5th machXO 7 usd? ...

your choice

Antti

Reply to
Antti

That strobe/interrupt input idea is interesting. Thanks, I'll give it some thought.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

Time to show my ignorance. What is an MC? Macro Cell perhaps? I told you it has been a *long* time since my hardware days :-)

Thanks Antti. That is the kind of information that I'm looking to find.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

Answer to the first question ... not really :-) At the application layer (think Linux process), I need to parse the incoming packet, make a decision, and potentially put the response on the serial bus within 27ms. Much depends upon the complexity of the request processing, and leaving plenty of room for Linux context switching. The Linux application will have a pretty LCD and GUI that will, from time to time, be using a great deal of the ARM bandwidth. Missing the 27ms deadline will not cause any lives to be lost, or the system to crash, but it does violate the serial bus spec.

Ick. On a related note, I downloaded the Linux version of the Xilinx ISE yesterday to see what the environment was like. At my last gig, I modified an ISE "project" for a CPLD, and found the "IDE" clumsy at best. But then... I'm a "vi" fan-boy. I was disappointed to find that ABEL is not available on the Linux version :-(

So I'll either need to learn Verilog, VHDL, or do a schematic style entry (yuk). ABEL was once my close friend some 18-20 years ago.

The Coolrunner looked to be about right for my application, though. Thanks for the input.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

You may need to check that again before committing. I recently had a look at the Xilinx webpack and I don't think they support the Coolrunner by anything except ABEL. I may be wrong on that, my certainty is just good enough to issue a warning :-).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

Reply to
Didi

I've been using CoolRunners with the WebPack ISE and schematic entry for several years now. When I last did a new design with the CoolRunner, I think schematic entry, VHDL and ABEL were all supported.

Mark Borgerson

Reply to
Mark Borgerson

Were you using the Linux version of the WebPack ISE?

-- Michael N. Moran (h) 770 516 7918

5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144
formatting link

"So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Reply to
Michael N. Moran

Thanks for the warning.

OT I know, but is it possible to use command-line style tools to do the various compiling/fitting/simulation, etc. with these ISE tools? I hate IDE's ...

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

I had no problem using VHDL just last month. Hopefully nothing has changed since then. ;-)

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.