2
\$\begingroup\$

I'm designing a basic harness continuity checker based on shift registers implemented in Max V CPLDs. I'm aiming for a modular/extendable PCB design for the project as it has several benefits (cost, less complexity).

A uC communicates with my CPLDs using SPI. What I'm not sure about is how to best cascade these CPLDs in order to obtain a larger shift register. In a 144-pin TQFP, I only have 114 IO pins. Therefore, I can only implement a 114-bit Serial In Parallel Out or a Parallel In shift register. But by cascading these 114 IO devices I can obtain much larger shift registers.

However, I'd like to place these additional CPLDs on a different PCB. This has the advantage that I can simply extend the device when I need. On smaller harnesses, a single 114 test-point PCB will suffice. On larger ones, I can cascade. At the moment, the CPLD is really just a shift-register. But in the future I'm hoping to implement a state-machine that can possibly implement more functions, like checksum to verify the contents sent by the uC etc. But that's for later and all I know is that I'd just use SPI for communication.

As the CPLDs need SPI for communication, I am guessing that I need to pass these onto the cascading shift register i.e. each device will have a Serial Out (SO) pin. But it will also need to pass CLK, Chip Select and even a SI/MISO pin incase the uC needs to read back the shift register contents. Each CPLD will drive the next one in the chain by passing CLK, SO, CS.

I think buffering all the signals leaving the PCB would be necessary. But what would be the best way to actually connect the PCBs together? I suppose these really depends on the speed of operation. Fortunately, speed isn't an issue and therefore I'm operating at a very low frequency - just 62.5kHz. I'd like to be able to increase this, perhaps to 500kHz. I don't think I'll need any beyond that. At such frequencies, what's the best way to cascade PCBs?

Please note, I'm aware that I can purchase a large 324-pin device. I'm afraid, I can't really use that as there is no way to inspect BGAs here locally. So I'm sticking with TQFP packages.

I'm also aware that the topic, perhaps, mostly pertains to pcb-layout but I'm also hoping I can get some CPLD/FPGA centric advice here regarding what signals I need to send as I'm not so sure about that.

Would appreciate any responses.


Some more information based on Keven's answer:

The reason we feel daughter cards would benefit is most of the harnesses we assemble are have less than 70 wires. There are only 5 harnesses that have more than 250 wires. A single large circuit would be too costly. The reason the PCB would be large is because the mating connectors we use (62 pin D-Sub) are quite large physically.

So we thought of divinding the PCB by having a motherboard which houses the uC, LCD interface, CPLDs, SD Card, LED Controller etc. This would have about 62 or so test points.

The daughter card would also have 62 test points and it would only contain additional CPLDs and the connectors. This PCB would also be much smaller than the motherboard. The motherboard would be able to test 70% of our harnesses, with additional units allowing us to expand the test points when needed. Not only would this be cost-effective, it would also make the overall system much simpler. Chips, by themselves, are really cheap. The Max V 240Z that I'm using costs just $5. However, the cost for four-layer PCB is the limiting factor for us.

Each daughter-card would have connectors for programming the CPLDs and for connecting to the other PCBs. I don't feel programming each CPLD is much effort, especially because I won't really need to change any of the code. The uC won't even know the shift registers are cascaded... well, except, for the fact that I'd it to be able to sense the presence of additional PCBs so it knows the overall width. I think that shouldn't be too hard to do.

\$\endgroup\$
  • \$\begingroup\$ Cascading in full series does not seem necessary. You could have a central board that serves N x 114 I/O boards. Cost is very slightly higher than a full daisy chain system. \$\endgroup\$ – Russell McMahon Nov 16 '11 at 10:48
2
\$\begingroup\$

I'd like to place these additional CPLDs on a different PCB. This has the advantage that I can simply extend the device when I need. On smaller harnesses, a single 114 test-point PCB will suffice. On larger ones, I can cascade.

There are multiple levels of modularization which you can aim for. Where you want to stop depends on your specific use case. At the most basic level, the hardware must be designed such that you can select the number of modules in use after the design stage. The difficulty of changing the number of modules, space available, desired software complexity (and available space for software, especially on a CPLD) and the system cost will be key factors in your decision.

Hardware

The simplest and cheapest way to do this is to build one PCB, (You don't need multiple PCBs for modular design!) and put footprints for your desired maximum number of CPLDs on the PCB. If you need more IO, you can then solder down another CPLD. Obviously, this isn't something you'd want to do very often.

At the next stage, you'd want to build daughtercards so that you can more easily add and remove modules. You asked:

But what would be the best way to actually connect the PCBs together?

This depends on your system architecture and number of modules. If you know you'll never want more than, say, 3 modules at any one time, just put three connectors on the main board. These can be edge connectors, or stackable connectors, or whatever you like that doesn't require wires. If the number of sub-modules is too large to fit connectors for each on one PCB, then you should consider stacking (if your bus can handle the fanout of your maximum number of modules) or daisy-chaining (if you need to buffer the signal or vertical space is limited) the modules.

Plenty of connectors are designed for this purpose; check the "Board-to-Board" section of your favorite distributor or manufacturer, and many are designed for extremely low crosstalk and high frequency - 500kHz is nothing, unless you're using PTH 0.1" breakaway headers and have fast-changing signals (even then, you're probably OK). Check the mating strength of your connectors just to be sure, but if you only have a few pins, the footprint of your interconnection doesn't carry the stresses well, or the system will be subject to vibration, you'll need standoffs. It's often wise to design the interface in such a way that different modules can be designed to interface with the motherboard in the future. Pins are cheap, give yourself a couple spares just in case!

Software

If your number of modules supports it, you can simply add a slave select line for each module. This isn't really a software solution, but I wanted to mention it.

If you don't mind programming every CPLD differently, you could build the system such that the microcontroller sees it as one giant shift register (which you've suggested). If you added or removed a module, that module's address space would simply be wasted, and extra time would be used transmitting to addresses which don't exist. Each module would need to 'know' its address space, though, which would make programming the complete system a struggle.

A more versatile solution is to use software addressing to access each sub-module. In a 'programming mode' (perhaps a pushbutton on the module, or simply only connecting one at a time), you could assign the CPLD an address. By assigning each CPLD a different address, you could add or remove modules at will, and only have to adjust the activity of the microcontroller (which I presume to be easier to adjust than the CPLD).

My suggestion for this project

If a 324-pin device will solve all your foreseeable use cases, then the single-PCB method should work fine. The multiple-slave-select method would allow you to program all the CPLDs simultaneously with a single programmer. Sorry, but this project as described doesn't seem like a candidate for daughtercards.

\$\endgroup\$
  • \$\begingroup\$ Updated my question with some more information. Thank you VERY much for the answer. As it stands, it helped to know that 500kHz isn't hard to work with. \$\endgroup\$ – Saad Nov 16 '11 at 17:30
2
\$\begingroup\$

Other chips work just that way with SPI.

Except, they only pass on the serial data through an SDO pin.

Data is clocked into chip 1, and as it drops through the shift register it drops off the end and out of the SDO pin.

The SCK and SS signals are just routed to each chip - the chips don't need to 'pass them on' - just receive them from the µC.

For example, take a look at the DS1267 digital SPI potentiometer. Especially page 4 where it talks about cascading devices.

\$\endgroup\$
  • \$\begingroup\$ Yes. Didn't realize that... now I feel embarrassed. CS/SS will be the same as for all chips, right? \$\endgroup\$ – Saad Nov 16 '11 at 13:04
  • \$\begingroup\$ I'm sort of confused... you see, I want to address the entire cascaded line of CPLDs as a single shift register. So, is CS is active, that means all chips' SPI is active. And if so, as the CLK works, the CPLDs down the line will 'automatically' get the data from the previous ones. I don't feel the need to address each CPLD individually. So if I shift the contents 120 times, some of the bits will spill over automatically. Is my thinking on this correct or am I missing something? Thanks for the response. \$\endgroup\$ – Saad Nov 16 '11 at 15:47
  • 1
    \$\begingroup\$ You are quite correct in your thinking. It turns the whole thing into one big shift register. \$\endgroup\$ – Majenko Nov 16 '11 at 16:42
1
\$\begingroup\$

At your clock rates, you can run the spi into one device out back out of it to a daisy chain connector to the next.

But you can also just drive all of the devices in parallel, possibly using some buffer or line driver chips on the uC board.

In a simple design you would need one chip select for each SPI peripheral. But you can also use a single chip select for them all, and send a target address before the data. The boards could have address select dip switches, or you can just customize the CPLD file for each with its intended address.

Although probably not worth it unless very constrained, You can save an additional pin if you combine the SDO/SDI (MOSI/MISO) pin into a single bidirectional signal - you just have to design a protocol where talking and listening don't overlap (most often the data "written" during read clock cycles is ignored anyway) and if your uC's SPI perhipheral is very limited you might have to bit-bang it instead, though at your clock rate that still shouldn't be an issue.

\$\endgroup\$
  • \$\begingroup\$ Chris, how would the uC know the address that's on each dip switch? The CPLD would power and read from the DIP Switch. This is trivial because they're on the same board, but how would the uC know? \$\endgroup\$ – Saad Nov 17 '11 at 6:01
  • \$\begingroup\$ @Saad - you would have to tell the uC how many boards are present and the built-into-cpld-code or switch-chosen address of each. My premise is that code is cheap but hardware expensive, granted that is not always the case. \$\endgroup\$ – Chris Stratton Nov 17 '11 at 6:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.