Cascading CPLDs on different PCBs

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[Altera_Forum]

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?

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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.

[Altera_Forum]

--- Quote Start ---  Do you mean like this, except that CS would also be common for all CPLDs?   --- Quote End ---  Right - just like if you had the components all on the same board.  As you see from your diagram, the difficulty is that you have to have a CS per device.  JTAG gets around this by cascading all the devices in a daisy chain - so you can do the same thing if you like.  I2C gets around this by having each device uniquely identified.  Dallas 1-Wire devices get around this by having a 64-bit unique ID.  So, you can leverage any of these methods - whichever happens to work for you.    --- Quote Start ---   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.   --- Quote End ---  Yes, that is correct. Your test system is composed of uniquely addressable devices.    --- Quote Start ---   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?   --- Quote End ---  You have to know what you are physically connecting to, i.e., the wires in the test harness, so you have to define what the board IDs connected to what are. You could define the DIP switch setting of 0000b as the first board, 0001b as the second board etc.  In our systems, we have Dallas 1-Wire ID EEPROMs at physical locations. When you plug a generic module (FPGA+microcontroller) in, the location EEPROM contents are read, and that defines the module location address.  In your case, when you plug the board in, you flip the DIP switches.    --- Quote Start ---   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?   --- Quote End ---  No. Its an address for decoding. If there is no board with the DIP switch set to 0000b, then there will be no response to an SPI transaction with the device ID bits set to 0000b, i.e., all the CPLDs decode the ID and find that its not them.  Go and read about how I2C devices work. This is sort of the same scheme, except that there is a unique line for output versus input data. The separate lines allow for differential drivers, rather than a common driver. You could in fact use I2C to implement your system too (isolators exist, and I2C is deploying in buildings single-ended, so its fairly robust).    --- Quote Start ---   Also, why the need for 12-bit internal address for each CPLD? Will this be hard-coded in?   --- Quote End ---  You'd need to define the SPI protocol so that your micro can address devices. You can define an address of 32-bits, but then you'd be wasting your time if you're only addressing a few hundred unique locations. So, you write the code with generics, but ultimately you need to synthesize with a fixed value.    --- Quote Start ---   Thank you very 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.  --- Quote End ---  You are more than welcome. Once you've figured out the approach you'd like to use, I'll review it for you. The nice thing about hardware languages is that it costs you nothing to build a system in simulation.  Cheers, Dave

[Altera_Forum]

Before you get too far along on the path of using CPLDs for each of your shift-registers, have you considered using actual shift-registers? 

 You could use a single CPLD to access multiple banks of shift-registers. Rather than cascading CPLD boards, you cascade the boards containing shift-registers.  I like using CPLDs (since you can add features), but if you're worried about cost, perhaps using a CPLD to interface to shift-registers should be considered.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   You have to know what you are physically connecting to, i.e., the wires in the test harness, so you have to define what the board IDs connected to what are. You could define the DIP switch setting of 0000b as the first board, 0001b as the second board etc.  --- Quote End ---    Ah, of course. So for a 4-bit switch, we'll have 16 board IDs already uniquely defined. 0000b through 1111b. So, suppose, there are 4 boards connected with the addresses: 0000b,0001b,0010b,0011b. As each board has a 74-bit shift register, we know the first board has test-locations 0 through 74, the second has 75 to 149 and on. All of this will be defined in the uC beforehand.  However, how would know uC know how many boards are connected? Or does it simply not matter? If there is no board with an address of 0100b, the uC receives no response.  OR  At startup, the uC can send a ping to all 16 addresses. So suppose it pings 0000b. If it receives no response, it knows there is no board connected there. It then pings 0001b, it the board pings back then the uC knows there is a board connected there.  I like this!!    --- Quote Start ---   Go and read about how I2C devices work. This is sort of the same scheme, except that there is a unique line for output versus input data. The separate lines allow for differential drivers, rather than a common driver. You could in fact use I2C to implement your system too (isolators exist, and I2C is deploying in buildings single-ended, so its fairly robust).  --- Quote End ---    Yes, as I was reading this thread I felt I2C might work better as it already has addresses in the protocol.    --- Quote Start ---   You'd need to define the SPI protocol so that your micro can address devices. You can define an address of 32-bits, but then you'd be wasting your time if you're only addressing a few hundred unique locations. So, you write the code with generics, but ultimately you need to synthesize with a fixed value.  --- Quote End ---    What I meant was, if each board will really ever contain 2 CPLDs (one for output and another for input), can the board ID not be used as the CPLD ID? We really don't have any plans for cascading more than 6 boards - each board having two CPLDs (o/p and i/p each).

[Altera_Forum]

Dave, 

 A couple more questions: the 12-bit internal address for CPLD, will this be same for every CPLD? So, the 4-bit Board ID + 12-bit CPLD Address identify a unique CPLD in the system?  I'm thinking of using LVDS drivers. I looked at some ICs and they look super easy to wire up! They use 3.3V and I have that on the system already.  Regarding actual shift registers... the 240Z Max V I'm using is just $5. I think that's reasonable. I just think it's better to have an expandable system and the features I can put in like having a checksum and edge-sync. are very worthwhile as they put in robustness.  One final question, should I have a separate "central" power supply? The boards could tap into the PSU for the required 1.8V and 3.3V.

[Altera_Forum]

--- Quote Start ---   Ah, of course. So for a 4-bit switch, we'll have 16 board IDs already uniquely defined. 0000b through 1111b. So, suppose, there are 4 boards connected with the addresses: 0000b,0001b,0010b,0011b. As each board has a 74-bit shift register, we know the first board has test-locations 0 through 74, the second has 75 to 149 and on. All of this will be defined in the uC beforehand.   --- Quote End ---  Right. Depending on how you want your device addressed. The 'local' address map of each CPLD could have fixed length registers, eg. 16-bits wide, so you can have some identification registers at address 0, 1, 2, 3, and then shift registers following that. Or, you can have variable length registers at each address, eg. once you address the shift-register, you need to generate an SPI transaction that fills the whole thing. The AD9956 PLL is an example of a device with variable length shifts to different addresses. Read this doc for an example of the controller design:  http://www.ovro.caltech.edu/~dwh/carma_board/ (http://www.ovro.caltech.edu/%7edwh/carma_board/) http://www.ovro.caltech.edu/~dwh/carma_board/ad9956_tests.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/ad9956_tests.pdf)    --- Quote Start ---   However, how would know uC know how many boards are connected? Or does it simply not matter? If there is no board with an address of 0100b, the uC receives no response.   --- Quote End ---  The test program should know how many boards are connected, and it can then go and check they exist. For example, the micro can go and read the CPLD image identification registers at address 0, 1, 2, 3, and make sure each responds with the correct info, eg., a version number, build timestamp, etc.     --- Quote Start ---    At startup, the uC can send a ping to all 16 addresses. So suppose it pings 0000b. If it receives no response, it knows there is no board connected there. It then pings 0001b, it the board pings back then the uC knows there is a board connected there.   --- Quote End ---   Right. It can do that and if it is expecting a board at address 0000b and does not find one, then it can report an error.  At some point in the system design, you have to tell the software what to expect to find, and then generate a warning when there is an inconsistency with what it finds.    --- Quote Start ---    Yes, as I was reading this thread I felt I2C might work better as it already has addresses in the protocol.   --- Quote End ---  The key is to realize that you can define a protocol. It really just comes down to whether your uC's I2C controller can do what you want, or the SPI controller, or GPIO pins.    --- Quote Start ---   What I meant was, if each board will really ever contain 2 CPLDs (one for output and another for input)   --- Quote End ---  Why would you need one for output and one for input? The pins are bidirectional, so both should have the outputs read-back. I guess you are referring to one as your driver into the harness (with read-back), and one at the end of the harness for read-back.    --- Quote Start ---   can the board ID not be used as the CPLD ID? We really don't have any plans for cascading more than 6 boards - each board having two CPLDs (o/p and i/p each).  --- Quote End ---  Sure, but in this case, you could have a 4-bit board ID, with 3-bits set by the DIP, and the LSB set by a pin on the CPLD, i.e., the first CPLD on the board has an LSB of 0 and the other 1.  Cheers, Dave

[Altera_Forum]

One more comment: 

 The CPLDs have embedded User Flash Memory (UFM). You can use that memory to store a unique serial number for each board/device on a board. Your micro can check that each board at each device ID has a unique serial number.  Cheers, Dave

[Altera_Forum]

Dave, 

 I really like the Dip Switch + Internal Address idea. Just so I understand, I'm gonna re-iterate a few things:  1) Each board will have a 4-bit DIP Switch. The first 3-bits identify the board and the LSB identifies weather the CPLD is meant for driving the test vector or receiving it.  2) These 4 bits combined with an 12-bit internal address form a 16-bit address for a CPLD in the system. Just one thing that I still am confused about: is this 12-bit internal address the same for every cpld? I have a I2C temperature sensor and it has an address of 16-bits. However, the LSB of that address we can clear or set by tying a pin to GND or Vcc. This would sorta be the same, wouldn't it? I'm asking because I would prefer not to have to tweak a CPLD's 12-bit ID in the VHDL code every time I program a new one. I'd prefer if its a constant and the same for every CPLD.  but as the code may be different for the CPLD that's meant for driving the harness than receiving, I can make the 12-bit address such that the last 4 bit identify weather the CPLD is meant for driving the test vector or receiving it. We use the LSB in the DIP as board ID but ignore the MSB bit. If the least four significant bits in the internal address are F, then we say the CPLD is meant for driving the test vector. If they say 0, we say that the CPLD is for receiving the test vector. So here's an example of an 15-bit address (15-bit because we ignore the MSB of the DIP Switch) of a CPLD that's meant for driving a test vector located on a board with the ID '3'.  011-11101100-1111b  For the CPLD on the same board but one meant for receiving the test vector, the address is:  011-11101100-0000b  Essentially, the format is:  BoardID - Internal Address - Driving/Receiving  (the dashes are there to help see clearly)  What do you think of this? We, if we want, can even give the CPLD meant for driving a separate CS line than the ones meant for receiving. This will eliminate all the need to differentie between the two when it comes to addresses. Yes, it would make it less flexible because we can't change via software what a CPLD is meant for (driving or receiving), but thats OK. Their role depends on the type of connecter they are connected to and so their role wasn't flexible to begin with.  3) We can make a simple requirement for the system. All the boards connected to the system must have board IDs in a sequence i.e. if we have 3 boards then the IDs should be 0000b,0001b,0010b. The IDs cannot skip - if they do, we generate an error. We can even put a 3-bit DIP switch on the board with the uC and this switch could set the total number of boards connected to the system. So if this switch reads 4, but there are only three boards connected, it can generate an error. The uC will check this by pinging each board ID from 0000b to 0011b. If 0011b does not respond, we know there is an error.  Having the board IDs in sequence will make things slightly easier. The board count will also help identify if there is something missing or not. I think it would make things less ambiguous. I hope this system made some sense. I think it would be robust. Do you see any significant drawbacks?  Regarding the hardware... I'm thinking of going with LVDS Drivers. They look super-easy to implement and the I really like the fact I can run them off 3.3V. If what I've described is good and then I think I will send the following lines to go to the daughterboards:  1) SCK 2) MISO 3) MOSI 4) CS for Driving CPLDs 5) CS for Recieving CPLDs 6) Ground  But since I'll be using LVDS, that means I'll send signals 1 to 5 through them - which equals a total of 10 wires + 1 for ground.  Thank you for the link. I'll study it. I've been studying the ByteBlaster you uploaded for me. Thanks for that, it has been a great help.  PS: You work in Radio Astronomy! Wow. I'm an amateur astrophotographer myself, in my spare time. :)

[Altera_Forum]

--- Quote Start ---   I really like the Dip Switch + Internal Address idea. Just so I understand, I'm gonna re-iterate a few things:  1) Each board will have a 4-bit DIP Switch. The first 3-bits identify the board and the LSB identifies weather the CPLD is meant for driving the test vector or receiving it.   --- Quote End ---  In the case of the two CPLDs, there would only be a 3-bit DIP switch (which both CPLDs see), and the LSB of the address is determined by a CPLD-specific pin - 0 on the first device, 1 on the second.    --- Quote Start ---   2) These 4 bits combined with an 12-bit internal address form a 16-bit address for a CPLD in the system. Just one thing that I still am confused about: is this 12-bit internal address the same for every cpld?   --- Quote End ---  The 4-MSBs of the address are determined by the DIP and hard-wired pin (0 or 1), and then remaining address bits are used to access the internals of the CPLD. If all the CPLDs contain the same design, then the 12-bits of address (or 20-bits, or whatever) would access the same design. Alternatively, your driver and receiver CPLDs could have different designs, but that same 12-bits would be accessing their internal memory maps.  Personally I would just create an SPI-to-Avalon-MM master. The 4-bits would be decoded by the master to determine if it was the target, and then the remaining address and data bits would be determined by the rest of the SPI transaction.    --- Quote Start ---   I have a I2C temperature sensor and it has an address of 16-bits. However, the LSB of that address we can clear or set by tying a pin to GND or Vcc. This would sorta be the same, wouldn't it?   --- Quote End ---  Right, the DIP switch and hard-wired pin (0 or 1) perform this same task; they allow you to take the same 'component' but uniquely identify it.    --- Quote Start ---   I'm asking because I would prefer not to have to tweak a CPLD's 12-bit ID in the VHDL code every time I program a new one. I'd prefer if its a constant and the same for every CPLD.   --- Quote End ---  You would either use identical designs in all CPLDs, or two unique designs for the two CPLDs on a board. The DIP switch would then define the boards uniquely (3-bit DIP allows 8 unique boards, 4-bit DIP allows 16 unique boards, etc.).    --- Quote Start ---    but as the code may be different for the CPLD that's meant for driving the harness than receiving, I can make the 12-bit address such that the last 4 bit identify weather the CPLD is meant for driving the test vector or receiving it.   --- Quote End ---   That's the task of the hard-wired pin.    --- Quote Start ---    Essentially, the format is: BoardID - Internal Address - Driving/Receiving   --- Quote End ---  Not quite. The CPLD identified is also a high address bit. Lets take your example of a board with ID of 3, a 1-bit CPLD identifier, and a 12-bit internal address. The first CPLD (0) has addresses of the form  011-0-xxxx_xxxx_xxxx  while the second CPLD (1) addresses are  011-1-xxxx_xxxx_xxxx  i.e., the format is BoardID-CPLDID-InternalAddress  The logic inside the CPLD, i.e., on the Avalon-MM bus inside the CPLD, sees the 12-bits of the LSBs, i.e., the xxxx_xxxx_xxxx bits. You can create an SOPC System/Qsys system that is unique to the driver and receiver boards. You would locate board identification registers at address 0 in both designs, and the uC would interrogate them to confirm the CPLDs are loaded correctly.    --- Quote Start ---   We, if we want, can even give the CPLD meant for driving a separate CS line than the ones meant for receiving.   --- Quote End ---  The two CPLDs are uniquely addressable. What they do it totally up to you.    --- Quote Start ---   3) We can make a simple requirement for the system. All the boards connected to the system must have board IDs in a sequence i.e. if we have 3 boards then the IDs should be 0000b,0001b,0010b. The IDs cannot skip - if they do, we generate an error. We can even put a 3-bit DIP switch on the board with the uC and this switch could set the total number of boards connected to the system. So if this switch reads 4, but there are only three boards connected, it can generate an error. The uC will check this by pinging each board ID from 0000b to 0011b. If 0011b does not respond, we know there is an error.   --- Quote End ---  Now you're getting the hang of it. You'll end up with a system that abides by rules/conventions, and the micro checks that those rules are followed before allowing testing to progress.    --- Quote Start ---   Regarding the hardware... I'm thinking of going with LVDS Drivers. They look super-easy to implement and the I really like the fact I can run them off 3.3V. If what I've described is good and then I think I will send the following lines to go to the daughterboards:  1) SCK 2) MISO 3) MOSI 4) CS for Driving CPLDs 5) CS for Recieving CPLDs 6) Ground   --- Quote End ---  You only need one CS. The hard-wired CPLD ID determines which will respond.    --- Quote Start ---   Thank you for the link. I'll study it. I've been studying the ByteBlaster you uploaded for me. Thanks for that, it has been a great help.   --- Quote End ---  That particular design does not need to decode to multiple boards, but it'll give you a starting point.    --- Quote Start ---   You work in Radio Astronomy! Wow. I'm an amateur astrophotographer myself, in my spare time. :)  --- Quote End ---  We have some pretty clear skies here. You're welcome to visit!  Cheers, Dave

[Altera_Forum]

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

[Altera_Forum]

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]

--- 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]

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]

--- 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]

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]

--- 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