Honored Contributor
Honored ContributorDave,
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. :)
