10

I'm looking for a multiplexer IC with 128:1 or more inputs (256 would be quite nice). I would have thought such a device would be quite common yet I'm having a tough time locating it. It could be that I'm looking at the wrong places but somehow I think I'm missing something - perhaps large input multiplexers are not used that often? If so, what is the alternative?

The max. I was able to find is the trusty ol' 74150 with 16 inputs.

I understand that I can build a large multiplexer by combining multiple 16 input mux - but I'm hoping for a more integrated solution.


I'm designing a circuit thats able to test for open and short circuits in an automotive wiring harness. A typical harness can contain 200 or so wires. Currently, the circuit uses 16 multiplexers to handle 128 wires.

The multiplexers are connected to a single 16-input multiplexer and that in turn is connected to a uC. Similarly, on the other end, there are 16 demultiplexers. The demultiplexers switch the wires onto a voltage. At the same time, this wire is switched onto one of the uC input via the mux.

If the wire is OK, the uC should see a high at its input. The uC then checks all the other wires. If any of them is high, it means there is a short between those two wires.

Note: this circuit was not designed by me. This was done in 2003. I am just looking to improve this circuit. Also note that none of the wiring harnesses contain a CAN data-bus or any other sort of bus. Its just simple wires for power and signals.

Here is a very rough block diagram that I quickly made just for this post. I hope this makes the problem clearer as English isn't my first language and I have trouble explaining things via text. Even though the diagram isn't very good, I hope it makes things better. The lines going side-ways into the demux and mux from the MCU are the address lines.

Note that one of the wires is split into 3. I made this intentionally to show that some connections are one-to-many and not just one-to-one. The most complex one I've seen is a wire split into 60 junctions. This is why the demux and mux have separate address lines. The demux could be at input no. 20 whereas the mux can switch between 20,21,22 etc. Check all the lines that are junctioned from line 20.

enter image description here

If you feel there is a better way to design this, please let me know.

Saad
  • 5,319
  • 12
  • 60
  • 93
  • Are you looking for 128:1 or for 128 times 2:1? – Majenko Sep 03 '11 at 15:22
  • 128:1. Sorry I forgot to mention. I apologize. – Saad Sep 03 '11 at 15:29
  • @saad My experience has shown that almost every time someone asks for that sort of thing, it is because they are doing something fundamentally wrong. I suggest stating what you are trying to accomplish, rather than what you think the solution is. That way we might be able to give you a better solution than cascading a bunch of 16:1 muxes. –  Sep 03 '11 at 17:33
  • @David Kessner, please see the edit. I actually did inquire about the design on this site a few weeks ago but little response. Would appreciate any form on input. – Saad Sep 03 '11 at 18:09
  • 1
    Depending upon how quickly, how often, and with how much notice one will be switching inputs, using cascaded multiplexers could greatly ease routing. Instead of having to route 256 signals to a single spot on the board, one could route 16 signals to each of 16 spots, route one signal from each of those spots to a 16-input chip, and route four shared signals to all of the multiplexers. Using one chip would in theory allow one to get any of the 256 signals from input to output with a single "gate delay" corresponding to two transistors in series (N-type for falling edge; P for rising), but... – supercat Sep 03 '11 at 18:45
  • ...the combined node capacitance of 256 N-channel drains and 256 P-channel drains all connected together would be pretty severe. Even if one wanted to minimize input-to-output delay, one could almost certainly achieve better performance by implementing the circuit using cascaded 16-input muxes. – supercat Sep 03 '11 at 18:50
  • Thats something I hadn't considered, supercat. Thanks a lot for the input. Speed is not a big concern so I will likely stick to the current solution. – Saad Sep 03 '11 at 18:54

6 Answers6

12

While a huge mux/demux will certainly work, connecting up a bunch of 16:1 muxes is a lot of work, and has some limitations that may or may not be an issue. The more conventional approach would be to use shift registers. Use a serial-in/parallel-out register for the "driving" end, and a parallel-in/serial-out for the receiving end. The nice thing about shift registers is that they can easily be daisy-chained to make a longer shift register. A 256-bit or even 1024 bit shift register isn't a problem at all. With some buffering, the serial stream can even be passed over a cable to another PCB (if that makes your thing easier to make).

There are many 8-bit shift register chips like the 74xx597, but a CPLD is MUCH better for this. But you don't need a giant 256+ pin CPLD. Instead, you can use several smaller CPLD's and chain them together. Although I haven't done the math, I'm fairly sure that using more small to medium size CPLD's would be cheaper than one large CPLD-- and you don't have to worry about BGA's.

This CPLD would be fairly Flip-Flop intensive. What this means is that a normal CPLD architecture (like what Xilinx uses) is not as good as something that is more FPGA-ish. Altera and Lattice both have CPLD's with lots more Flip-Flops per Dollar than what Xilinx has.

While you might not have a lot of experience with CPLD's, this design is very simple and the benefits of using a CPLD is huge. It would be very worth your time to learn how to program CPLD's for this.

Also, the advantages of using a shift register instead of a mux is not easy to see initially. Mostly you get a lot of flexibility in how you drive and sense the wires. You could even be testing several harnesses at one time (if you have enough shift registers). Everything you can test with muxes can be done with shift registers, but shift registers can do more. The one down side to shift registers is that it is slower, although it will still be faster than what you need (I.E., the guy connecting and disconnecting the harness will be much slower than the time to test with shift registers).

I should also say that even if you are using CPLD's, shift registers are still easier than muxes. The main thing is that they are smaller-- although to see the actual advantage/disadvantage you would have to actually do the design in both and see what size of CPLD you need. This is going to be fairly dependent on the type of CPLD architecture used, so any generalizations made with Xilinx won't apply to Altera.

Edit: Below is a little more detail on how to actually perform the test using shift registers...

For doing the test, you can ignore the fact that you are using shift registers and only consider that data is driven on the "driving end" and hopefully read on the "receiving end". How you got the data there and back (via serial) is largely irrelevant. What is important is that you can data that you can drive is completely arbitrary.

The data that you drive with is called the "test vectors". The data that you EXPECT TO READ is also part of the test vectors. If the cable is wired with a 1:1 relationship then you would expect the driving data and the receiving data to be the same as what you drive. If the cable is not 1:1, then it would obviously be different.

If you used a MUX based approach you are still using test vectors, but you have no control over the kind of test vector. With the Muxes, the pattern is called a "Walking Ones", or "Walking Zeros". Let's say that you have a 4-pin cable. With walking ones you would drive the following pattern: 0001, 0010, 0100, 1000. Walking zeros is the same, but inverted.

For a simple continuity test, walking ones/zeros works fairly well. Depending on how you cable is connected, there are other patterns that could be done to speed up the test or to test specific things. For example, if some pins can never be shorted against other pins then you can optimize the test pattern to not look at those cases and thus run faster. Dealing with something other than a walking-ones/zeros can get complicated on the software side of things to handle.

The ultimate method of generating test vectors is done for JTAG testing. JTAG, also called boundary scan, is a similar scheme for testing the connections between chips on a PCB (and between PCB's). Most BGA chips use JTAG. JTAG has shift registers in each chip that can be used to drive/read each pin. A complicated and expensive piece of software looks at the netlist for the PCB and will generate the test vectors. A sophisticated cable tester could do the same thing-- but that would be a lot of work.

Fortunately, for you, there is a MUCH EASIER way to generate the test vectors. Here's what you do... Connect a known good cable to the shift registers. Run a walking-zeros/ones pattern through the driving end. As you do this, record what is seen on the receiving end. On the simple level, you can just use that as your test vectors. When you connect a bad cable and do the same walking-ones/zeros, the data you receive won't match the data you previously recorded-- and therefore you know the cable is bad. This goes by several names, but all the names are some variation of the term "learning", like self-learning, or auto-learning.

So far, this easily handles the case where one pin on the driving end goes to more than one pin on the receiving end, but doesn't handle the other case where multiple pins on the driving end are connected together. For that you need some special stuff to prevent damage from bus contention, and all of your shift register pins should be bi-directional (I.E., function as both the driver and receiver). Here's what you do:

  1. Put a pull-down resistor on each pin. Something around 20K to 50k ohms should be fine.

  2. Put a series resistor between the CPLD and the cable. Something around 100 ohms. This is to help prevent damage from ESD and stuff. A 2700 pF cap to ground (on the CPLD pin side of the 100 ohm resistor) will also help with ESD.

  3. Program the CPLD so that it will only drive the signal high, never driving low. If your output data is a '0' then the CPLD will tri-state that pin and allow the pull-down resistor to bring the line low. In this way, if several CPLD pins are driving the same wire on the cable high then no damage will occur (because the CPLD won't also be driving the same wire low).

  4. Every pin is both a driver and receiver. So if you have a 256 pin cable then your shift registers will be 512 bits for the driver and 512 bits for the receiver. Driving and receiving can be done in the same CPLD, so the PCB complexity doesn't really change because of this. You will have 3 or 4 flip-flops per cable pin in this CPLD, so plan accordingly.

You then do the same walking-ones/zeros pattern while comparing the received data with what was previously recorded. But now it will handle all sorts of arbitrary connections within the wiring harness.

  • Thank you very much. I'm going to start reading up more regarding this right away. – Saad Sep 03 '11 at 18:59
  • I've been thinking about this. You said to use SIPO for the driving end and PISO for the rx. Now, if I understand correctly, I should SIPO to an output pin on the MCU and PISO on an input pin. Assuming the wires are all one to one, then I should send some data through the harness and if I receive that data back, then the wires pass the test. Is this a valid method? Furthermore, how should I modify this to handle lines which split into more than 1 on the receiving end? Is this what you were suggesting or am I completely off the track? – Saad Sep 03 '11 at 19:50
  • Thinking more on these lines - suppose we have 4 input wires and one of those (the 4th) splits into 2 wires. So we have 5 wires at the rx end. Suppose we shift out the bits 0101, if we receive back 01011 then we all wires are ok. But suppose the 3rd bit is high (01111), then we know that the 3rd wire is short-circuited. But this won't tell us which wire its short circuited with. Perhaps a better way would be to just let "1" ripple through the registers. So, at the start we have 1000 and we rec. 10000. Then 1 ripples through, and we get 0100 and 01000. Till we reach the last bit, 0001. – Saad Sep 03 '11 at 20:10
  • For this case we know we should receive 00011, as the last one is spliced into two. If there is a short on the 4th wire and we're sending 0010 then we'll rx 00111 - which we know is not correct and we can display an error specifying where the short circuit is. Does this method sound good to you? – Saad Sep 03 '11 at 20:10
  • @saad I updated my answer with much more detail to cover your comment. –  Sep 03 '11 at 20:54
  • wow. Thank you very much. I understand this a lot better now - just to confirm that I understand, the test vector method is similar to the 2nd method I described in my comments, right? I was just unfamiliar with the term test-vector. I think I fully understand unto the case where the driving end is signaling many. That case is simple enough to handle. Regarding bus-contention - this happens when a lot of inputs are trying to drive a pin - am I correct? While it seems easy to handle, I think its not even needed. – Saad Sep 03 '11 at 21:27
  • You see, the wiring harness is flexible enough that it can be reversed. This is the current practice in any case. But I DO think this would be a significant improvement. What I don't understand is, why does each pin need to be a driver and a receiver? Is it so that if there are many wires connected on the "driving end", the CPLD simply switches to receiving and drives the other end, which would be a single wire? I do apologize if I still don't understand. Its just the last few paragraphs that I found confusing. – Saad Sep 03 '11 at 21:31
  • Finally, regarding the CPLD. As I understand, this chip will contain the logic for the shift-registers. Rest of the logic, the self-learning from test-vectors this ought to be in a small MCU (which also needs to drive a display). The MCU can then in return drive the CPLD? – Saad Sep 03 '11 at 21:42
  • @saad Yes, similar to your 2nd method. I only mentioned walking-ones/zeros but there are many other patterns that can be used. Bus contention is when 2 or more drivers are driving the same wire. You need to handle the bus contention w/what I wrote in the answer if you ever have cables with lots of pins connected. For example, if your cable has pins 2, 7, and 11 on one end connected to pins 3, 5 and 12 on the other end. Yes, the CPLD would handle the shift register, but the MCU is the brains of it all. –  Sep 03 '11 at 23:06
  • Thanks a lot, David! I'm actually really excited about this project now! Thank you very much for giving me great advice. – Saad Sep 03 '11 at 23:17
  • Take a look at my answer for another shift-register-ish variant. – supercat Sep 05 '11 at 15:24
  • Wow this is a very well put together answer! – Earlz May 31 '12 at 06:17
7

I don't think there exist single chip solutions. They would be expensive because of the large number of I/Os and probably also because of the low demand. Most designs will cascade 8 or 16 input multiplexers.

If you really want a more integrated solution you'll have to look for a CPLD. There are CPLDs with more than 256 I/Os, like the Xilinx CoolRunner XC2C512, which is available in a BGA version with 270 user I/Os. Keep in mind that for a 256 input multiplexer you need an additional 8 inputs for the select signals, an output of course and maybe also an enable, so the 270 I/Os won't be too many.

You'll also have to keep in mind that your packaging will most likely be BGA; not sure if you'll like that. I haven't seen QFPs with around 300 pins yet anyway...

stevenvh
  • 145,145
  • 21
  • 455
  • 667
  • 2
    Thanks. I had the feeling this would be the case. I think I'll just stick to making a larger mux out of 16 input ones. – Saad Sep 03 '11 at 15:36
  • @saad - that would seem like your best bet, unless you grab a large (pin count, not gates/logic blocks) PLD as suggested (advantages are more efficient/size, actually very little experience with them or HDL would be needed, but the package would indeed be a pain - dev board?) – Oli Glaser Sep 03 '11 at 16:03
  • I actually have SOME experience with HDL and FPGAs (Handel-C - which was not pleasant to work with) through school. I've never worked on a CPLD though. But I've never really messed with a BGA package and it really does seem like a pain. EDIT: The XC2C512 is also available in PQFP - though I now wonder if someone with as little experience as mine in HDL and FPGAs can work such devices. It's also quite pricy - its worth £60 over at Farnell UK. – Saad Sep 03 '11 at 16:15
  • @saad - the PQFP has only 173 user I/Os. colleague of mine programmed his CPLD (simple application: address decoder) in [Abel](http://www.eng.tau.ac.il/~guy/Resa99/ABEL_manual.pdf), which from the look of it seems a lot simpler than VHDL or Verilog. Probably not as powerful as VHDL/Verilog, but that shouldn't be an issue for your application – stevenvh Sep 03 '11 at 17:00
  • @stevenvh: Abel is a little bit ugly in some ways, but specifying pin behaviors in terms of clocks and equations can sometimes be much more natural than writing things out more verbosely in VHDL or Verilog. I wonder why tools don't support a nicer equation-based language? – supercat Sep 05 '11 at 15:26
3

Although CPLD/FPGA seems the right idea for high pin-count, an automotive harness will typically be physically quite spread out, and the connectors moderately large, Therefore instead of fanning out from a high pin-count device to a large numberof connectors, a modular system with, say, 16 IOs on shift registers, interconnected by the low number of clock/shift lines may be more appropriate, and also very scaleable.
Something else to consider is for cable testing, you could use a resistor chain to apply, say, 16 voltages to 16 lines, and an analogue mux to check the voltage on each at the other end. This would detect opens and shorts, and be cheap.

mikeselectricstuff
  • 10,655
  • 33
  • 34
  • Do you mean to say I should implement the shift registers in 16-bit blocks on CLPDs? I most likely won't use a single large CPLD to do all the work. I want to avoid BGA packages and so will likely stick with the smaller CLPDs. At the moment, for every new wiring harness thats required a new "connecter board" is developed and this has all the connecters mounted on. These connecters are then in turn connected to the circuit I described in the above question. In the new system, we're going to keep this mechanism - what sort of problems will I face if I connect a large number of IOs on one chip? – Saad Sep 05 '11 at 15:22
1

Using a shift register to read lots of inputs is a nice pattern. Since David Kessner suggested using a CPLD, however, I would suggest another pattern. Suppose you want each CPLD to handle 32 inputs. Give each CPLD a shared clock input, an individual enable input, an enable output (which ties to the next chip's enable input), and a shared data output. Each chip has a five-bit counter and an overflow indicator. When the enable input is deasserted, clear the counter and overflow indicator. When the enable input is asserted but the overflow indicator isn't set, output the state of the input bit indicated by the counter. When a clock pulse is received and the chip is enabled and the counter hasn't overflowed, bump the counter. The overflow bit would feed the "enable" output. The net effect of all this logic is that one can get by needing only about 8 macrocells to handle 32 inputs. One may thus be able to fit within the CPLD other functions which are more compute-intensive or register-intensive but don't need much I/O.

If one has a CPLD with pin-keeper circuits, one may be able to use a similar approach for output, especially if there's a way to output the output from one macrocell to multiple pins (without having to spend a macrocell for each pin). The chip would have shared clock and data inputs, an enable input, and an enable output. Internally, it would need a five-bit counter, an extra copy of the bottom counter bit latched on the opposite clock edge from the first five, an overflow bit, and a shared data signal that would feed all the pins. Seven macrocells, plus however many were needed to copy the input data signal to all pins (the output-enable controls for the pins would serve as latch-enable).

One beautiful feature of this approach (which, btw, is frequently used in LCD drivers) is that one can have multiple data lines moving data in parallel and still only require a single daisy-chain wire between chips. It also allows one to eliminate a latching circuit from each input or output.

supercat
  • 45,939
  • 2
  • 84
  • 143
1

How does this sound for an idea, assuming that the largest group of pins that are supposed to be connected is e.g. 20 pins: use a bunch of open-collector shift-register LED-driver chips (one output per pin) each of which can sink at least 2mA; connect a 1K resistor from each pin to a common point, and use a circuit which source one volt at 20.1mA (it's fine if the voltage is higher when the current is lower, provided it's one volt at 20.1mA) and indicate whether an attempt is being made to draw more than that amount. For some cable configurations, it may be necessary to have a small number of "spare" pins which have the 1K resistors, but are not connected to the cable. It may be desirable to have a spare pin with a 1K resistor, one with a 500 ohm resistor (or two 2K's in parallel), one with a 250-ohm resistor (four 1K's in parallel), one with 125 ohms (eight 1K's in parallel).

To test the cable, formulate scenarios which should result in exactly twenty pins being pulled low, and scenarios which should result in exactly twenty-ones being pulled low (the spare pins may be useful for this) and confirm that the twenty-pin scenarios are not reported as using more than 20.5mA, but the 21-pin scenarios are.

Suppose, for example, that one has a cable harness which is supposed to connect 1-2, 3-4, 5-6, etc. up to 39-40. Check for shorts by picking various combinations of ten pairs of pins, and drive both pairs of each pin low. You'll be driving 20 pins low, and no pins should go low except the ones you're driving, so the current should always be under 20mA. If it goes over, something's shorted. If one can find any combination of ten pairs which doesn't read over-current, then one at a time turn off an active pair and turn on another pair, until something goes over-current; the last pair turned on is shorted to something it shouldn't be.

Check for opens by driving a spare pin low, and then picking various combinations of ten pairs, driving one pin from each pair (sometimes the odd one and sometimes the even one). If there are any opens, such action will result in less than 21 pins being driven low, and thus read under-current. If that occurs, then one-at-a-time, take each pair where one wire is driven and instead drive both. If that pushes the current reading over 20.1mA, that pair is open.

One could use a CPLD for this application, but a system like I described might be better. It could be further enhanced by adding circuitry to actually measure current (rather than simply producing an over/under indicator). Such measurement would allow one to set tolerance values for resistance.

supercat
  • 45,939
  • 2
  • 84
  • 143
1

Is this what you're looking for?

Maxwell 81840 - 128 channel multiplexer

clabacchio
  • 13,481
  • 4
  • 40
  • 80
Daniel
  • 334
  • 1
  • 5
  • 18
  • Probably not. This is an analogue multiplexer, though you probably can multiplex digital signals with it as well, if you keep an eye on the device's speed. Also this is a rad-hard device, will be expensive. – stevenvh May 31 '12 at 06:40
  • Welcome! Steven is right, it may not be the appropriate solution, but nice catch! Maybe add some description of the component below the link – clabacchio Jun 04 '12 at 08:16
  • Thanks clabacchio. I'm not sure how more detailed I can describe the component. I've never used it before nor do I have sufficient experience yet. – Daniel Jul 05 '12 at 15:49
  • sweeeeet chip :) I want to use one in a digital piano project, but if you can't find the price by just googling, you can't afford it! – Andrew Wagner Oct 02 '13 at 11:31