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. I think buffering the signals would be good practice. 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 and CPLDs? 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 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.

--- Quote Start --- 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. ... 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 ... I think buffering the signals would be good practice. But what would be the best way to actually connect the PCBs together? --- Quote End --- There are two solutions; 1. Using JTAG to control all the boards. You want a single JTAG cable to control multiple boards, so you need a standard JTAG header on each board (the JTAG input connector), and then a buffer that drives TCK/TMS to the next board - that'll be a second JTAG header. The TDO bit on the CPLD will drive the TDI bit on the second JTAG header, and then you will want a jumper that selects the source for the TDO bit that drives the first JTAG header, either TDO from the second header if the board is in the middle of the daisy chain, or the TDO from the CPLD on that board, if it is the last in the chain. 2. SPI daisy chain. What if your environment is really noisy, and the JTAG scheme does not work? Be conservative. Connect SEL/SCK/MOSI signals to RS485/422 drivers and MISO to a receiver, and route the signals along with GND to a header. Again, you'll need two of these interfaces; one as an SPI master, and one as an SPI slave. The first board in the daisy chain could be controlled from JTAG, and the remainder can daisy chain via SPI. Since the RS485/422 drivers are operated in a fixed direction, you do not need to worry about bus turnaround, so you can leave them enabled. You could also use LVDS drivers/receivers for this application. This will be a robust solution for noisy environments. Cheers, Dave

I quite like the RS485 solution but I wonder if it's overkill. All the daughtercards will be located quite close. Still, I'd rather play it safe. --- Quote Start --- Connect SEL/SCK/MOSI signals to RS485/422 drivers and MISO to a receiver, and route the signals along with GND to a header. --- Quote End --- I followed you till this point but lost you at the next part --- Quote Start --- Again, you'll need two of these interfaces; one as an SPI master, and one as an SPI slave. The first board in the daisy chain could be controlled from JTAG, and the remainder can daisy chain via SPI. --- Quote End --- In your explanation, does MOSI come from the previous CPLD in the cascade or from the uC? If it comes straight from the uC, how does the contents of the first CPLD in the cascade "spill over" onto to the next one? I envisioned this as follows, but perhaps my solution is naive. Connect SEL, SCK, MOSI and MISO to the first CPLD. For the 2nd CPLD in the cascade, connect SEL, SCK (from the uC) but route Serial Out from the first shift register to it. This will be it's input. It should also have a Serial Out, which is connected to the first CPLD's Serial In. This allow the CPLDs contents to be read back in. All of these will be sent via RS485 which gives us greater noise immunity due to differential signaling. I'm quite bad with words, so here's a block diagram explaining what I meant (I omit the Rs485 in this) http://i.imgur.com/5ym70.png The above will only work for a Serial In Parallel Out shift register and not for a Parallel In Serial out shift register because the data cannot be read out from the last CPLD (and I need both). What I don't understand in your solution is that, if MOSI comes from the uC, how do the bits from the first CPLD spill over onto the next CPLD in the cascade?

--- Quote Start --- I quite like the RS485 solution but I wonder if it's overkill. All the daughtercards will be located quite close. Still, I'd rather play it safe. --- Quote End --- Its easy to put an RS485/422 driver/receiver footprint on a board, and assign differential pins to the header, but then also have a resistor that jumps the single-ended CPLD output onto the positive signal of the differential, you can also have a pull-down to gnd on the negative side of the differential too. That way you can load the board as LVCMOS output, or differential output. --- Quote Start --- ... lost you at the next part --- Quote End --- There's a couple of ways to implement the SPI version; you can have each CPLD have two SPI interfaces, a master and a slave (with each interface having sel/sck/mosi/miso), or you can do something like your diagram. In either case, each board should have some sort of unique address. Why? Well, there are two ways to use your board. 1) A big long shift-register. In this case, whenever SEL asserts, bits shift into the shift register, until SEL deasserts. Pretty simple to understand. 2) Each CPLD is an individually addressable entity Lets say you plan on cascading at most 16 boards. If you include a 4-bit DIP switch on the board, that DIP switch can be used to define a unique board ID that the CPLD can read. The SPI interface can then be defined to have a protocol that includes an address phase, a read/write indicator, and a data phase. The address phase of the transaction can contain the CPLD ID in the MSBs, and then the internal CPLD address in the LSBs. Eg., a 16-bit address would have the 4-bit ID followed by a 12-bit internal address. Each CPLD has an FSM that starts when SEL asserts, and then once the CPLD ID is shifted in, checks it, and then either determines it is selected, or not. The advantage of the latter scheme is that you can define your chain of CPLDs as an address map at the granularity of say 1-byte, so your read/write access time is much faster. There's no need to start with (2), but its always easier to plan for the future by including a DIP switch or footprints for resistor pull-downs (the pull-ups on the I/Os can be used to create a high by default). Cheers, Dave

--- Quote Start --- What I don't understand in your solution is that, if MOSI comes from the uC, how do the bits from the first CPLD spill over onto the next CPLD in the cascade? --- Quote End --- You can treat your SPI bus as a common bus with MOSI going to all the devices in parallel, and MISO coming from all in parallel. This is where the device ID would be useful, as only the selected device would drive the common MISO bus. Alternatively, you do the JTAG trick where the shift-register passes through all the devices and then loops back to the master. That'll provide the read-back function. Cheers, Dave

--- Quote Start --- You can treat your SPI bus as a common bus with MOSI going to all the devices in parallel, and MISO coming from all in parallel. This is where the device ID would be useful, as only the selected device would drive the common MISO bus. Alternatively, you do the JTAG trick where the shift-register passes through all the devices and then loops back to the master. That'll provide the read-back function. Cheers, Dave --- Quote End --- Do you mean like this, except that CS would also be common for all CPLDs? http://i.imgur.com/CaGEt.png If this is the case, then basically the uC will treat the CPLDs not as a giant shift register but really as multiple small ones. Let's assume I have 8 bit input vector 00001000. Let's further assume that my CPLDs can only implement 2 bit shift registers, so I need four of them. The output of the above test-vector is 10110001. The first CPLD is 10, second 11, third 00 and fourth 01. The uC will first address the 1st CPLD and read back it's contents. Then it will send the same instruction but instead of addressing the first one, it will address the 2nd one and so on. Is my understanding of this, at a high level, correct? If so, I quite like this. It's elegant, simple and robust. My only confusion now is regarding addresses of the CPLDs. You mention having a 4-bit DIP Switch that could be used as a board ID. How would know the uC know the value of each DIP Switch? I could see it working if its located on the main board. If the switch reads 12, the uC knows the total number of boards is 12 and their addresses start from 1 to 12. Is this what you meant? Also, why the need for 12-bit internal address for each CPLD? Will this be hard-coded in? Thank youvery much for all the help you've given me. It would have taken me months to get through any of this stuff. Please know your help is immensely appreciated.

Cascading CPLDs on different PCBs | Altera Community

23 Replies

Altera_Forum
Honored Contributor
14 years ago
This TI article is somewhat relevant to this discussion:

"Extending the SPI bus for long-distance communication"

http://www.ti.com/lit/an/slyt441/slyt441.pdf
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

But if feeding the clock to just one pin is ok, why does the CPLD have as much as 4 dedicated pins for the clock? Not that I'm complaining, just want to know.
--- Quote End ---

Many systems have more than one clock :)

Cheers,
Dave
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

You don't. Each CPLD synchronizes the serial data to its own clock domain. The I/Os would update on the rising-edge of the shift clock, as detected in the synchronized domain (within a couple of clocks of each oscillator), or you can use the serial clock to update it.
--- Quote End ---

Ah, so each daughter-board as it's own oscillator. I think I'll go with an oscillator then.

But if feeding the clock to just one pin is ok, why does the CPLD have as much as 4 dedicated pins for the clock? Not that I'm complaining, just want to know.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

1) Do I need to connect the oscillator to all 4 pins? The development board's schematic shows the oscillator being only connected to one pin.

--- Quote End ---
To one clk pin is fine.

--- Quote Start ---

2) What's the best way to send this clock source to the next PCB? LVDS I presume? I'm gonna go with a oscillator of 8 MHz or so.

--- Quote End ---
You don't. Each CPLD synchronizes the serial data to its own clock domain. The I/Os would update on the rising-edge of the shift clock, as detected in the synchronized domain (within a couple of clocks of each oscillator), or you can use the serial clock to update it.

--- Quote Start ---

3) Is it better to go with an oscillator or a crystal?
--- Quote End ---
I always use oscillators, since they 'just work'.

Cheers,
Dave
Altera_Forum
Honored Contributor
14 years ago
Dave,

You mentioned that I should have an external oscillator on the board that feeds the global clock network of the CPLDs via the GCLK pins.

My questions are:

1) Do I need to connect the oscillator to all 4 pins? The development board's schematic shows the oscillator being only connected to one pin.

2) What's the best way to send this clock source to the next PCB? LVDS I presume? I'm gonna go with a oscillator of 8 MHz or so.

3) Is it better to go with an oscillator or a crystal?
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

I agree with your philosophy 100%. Which is why, after some discussion with my colleagues, is there any inherent advantage to this "Parallel-SPI" approach over doing it like JTAG? We can still program the CPLD on the main board with advanced things later on (like checksum, etc.) This approach would eliminate the addressing, wouldn't it? We can just use two CS to select between the CPLDs intended for driving and those intended for receiving.

--- Quote End ---
The key to the board design is to keep as many options open as makes sense. The 'all CPLDs as one big shift-register' option is conceptually the simplest, while the 'each CPLD is individually addressable' is a little more complex, but more flexible. The difference between the two designs is a single wire (or perhaps a couple). So you layout the boards to support both options. Then implement one of them.

--- Quote Start ---

When I want to drive the test-vector into the driving CPLDs, I select CS1. If I want to receive the output vector, I select CS2. Essentially, I treat a chain of CPLDs as a single shift register. No need to mess with addressing (I think?)

--- Quote End ---
Yep, that is probably correct. Simulate it and see if it all works.

--- Quote Start ---

Will this work?
--- Quote End ---
Your block diagram does not reflect (your) reality. You said you would have two CPLDs per board, so draw it that way. Now, where do the master controls for the second board come from? Are they buffered and re-driven from the microcontroller, or from the CPLD? You show CS1 and CS2. So now they will be seen in common by the second board. Now when you do your shift sequence between the two boards, will it all work?

These are the types of questions you can answer by writing a couple of CPLD designs, tying them together into a 'board' design, and then cascading a couple of those 'boards' in a testbench. You then generate shift-register shifts, and check the I/O state after each shift. Once that all works, then you go back to your board design.

As far as I can tell, you should not have any trouble getting it to work. The key is not to jump into the PCB design, and then realize you've forgotten something. Get the system working in the simulator, and use that to fine tune the design.

Cheers,
Dave
Altera_Forum
Honored Contributor
14 years ago
Thanks, Dave. Going through your documents now.

I agree with your philosophy 100%. Which is why, after some discussion with my colleagues, is there any inherent advantage to this "Parallel-SPI" approach over doing it like JTAG? We can still program the CPLD on the main board with advanced things later on (like checksum, etc.) This approach would eliminate the addressing, wouldn't it? We can just use two CS to select between the CPLDs intended for driving and those intended for receiving. Here's what I mean:

When I want to drive the test-vector into the driving CPLDs, I select CS1. If I want to receive the output vector, I select CS2. Essentially, I treat a chain of CPLDs as a single shift register. No need to mess with addressing (I think?)

http://i.imgur.com/XjQk1.png

Will this work?
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

I'M now thinking of the format of an entire frame. Each module will have 74 test points. Let's assume it's just 72 bits and we get a nice round figure of 9 bytes.

So, we first send 2-bytes containing the address and then we send 9 bytes of data - obviously if the address doesn't match, the CPLD ignores anything sent afterwards. So essentially we have a 11 byte shift register.

--- Quote End ---
Yes. Look at the AD9956 document I gave you a link to. It can be similar to that.

--- Quote Start ---

However, how would the uC receive back the data from the CPLDs that specifically are meant for receiving the test-vectors? How about if I make the address 15-bit and make the LSB a Read/Write indicator? If this is 0, the CPLD will send the 9 bytes of data in its shift register. If it's 1, it will shift in new data that it receives just after this Read/Write bit.

--- Quote End ---
Now go and read the byteblaster interface ... it does something like this.

--- Quote Start ---

I know this is probably inefficient but I'm trying to start out small. As the devices will have a full SPI interface, I can easily upgrade the firmware as I get more experience with VHDL. I've been a C programmer for the past 10 years so VHDL still runs circles around my head.
--- Quote End ---
"Inefficient" is in the eye of the beholder.

My philosophy is "Get it working first, then get it 'right'". Sometimes 'right' is skipped, since 'working' is often good enough :)

Cheers,
Dave
Altera_Forum
Honored Contributor
14 years ago
I didn't realize the LSB is hard-wired. Of course it is, otherwise we'd need two switches. Sometimes I miss obvious things - sorry about that.

I'M now thinking of the format of an entire frame. Each module will have 74 test points. Let's assume it's just 72 bits and we get a nice round figure of 9 bytes.

So, we first send 2-bytes containing the address and then we send 9 bytes of data - obviously if the address doesn't match, the CPLD ignores anything sent afterwards. So essentially we have a 11 byte shift register. The CPLD, after receiving all 9 bytes of data can enable the outputs so that the test-vector appears at the output. This seems simple enough. The CPLD can transfer the data to another shift-register thats only meant for the output test-vector.

However, how would the uC receive back the data from the CPLDs that specifically are meant for receiving the test-vectors? How about if I make the address 15-bit and make the LSB a Read/Write indicator? If this is 0, the CPLD will send the 9 bytes of data in its shift register. If it's 1, it will shift in new data that it receives just after this Read/Write bit.

I know this is probably inefficient but I'm trying to start out small. As the devices will have a full SPI interface, I can easily upgrade the firmware as I get more experience with VHDL. I've been a C programmer for the past 10 years so VHDL still runs circles around my head.
Altera_Forum
Honored Contributor
14 years ago
Rather than using SPI to control the boards, you can also use an FTDI FT245 USB-to-FIFO component.

If your boards are all close together, then you would just have a USB cable to each board.

Each device would show up as a COM port. You can use the serial number in the FTDI chip to uniquely identify boards, which can in turn be used to create unique COM numbers or udev names under Linux.

You would still use a DIP switch in this case, as it allows the software to identify board 0, 1, 2, etc.

No microcontroller would be needed in this scheme.

I have an FTDI-to-Avalon-MM bridge that I've created ... I just haven't got around to documenting it yet ... you can use that code.

Cheers,
Dave

Forum Discussion

Cascading CPLDs on different PCBs

23 Replies

Recent Discussions

MT25Q512 Programming Issue When Connected to Cyclone 10CX150Y

Fail to enumerate RTile PCIe in the AVSTx8 configuration

Check COD for EP4CE15F23C8N

Thermal Model & Power Estimation for Agilex 7 - AGIB027R31B2I1V

ECCN Request - FPGA device (stratix3)