Multiplexer - the bottleneck of the Prophet 600

Compared to a Z80 based Prophet 600 a unit with the Teensy++ 2.0 based firmware upgrade runs at much higher update frequency. Apart from new functions, it is foremost the resulting responsiveness and smoothness that makes the upgrade worthwhile. However, ultimately what can be done is limited by the hardware of the Prophet 600, notably the sample and hold logic for reading and setting voltages. In this small essay I want to focus on voltage setting. I explain the basic setup inside the Prophet 600 and the way the Teensy++ 2.0 based firmware deals with it. I also give a small heuristic overview of multiplexer variants that can be used in the Prophet 600. This might be useful for those owners who find that their instrument is glitchy and wonder what they can do. Maybe others also find it interesting just to better understand what's going on under the hood.

Even software needs to make a footprint in the analogue world ...

First, it is important to appreciate that when you run an analogue synthesizer using software you need to convert digital representations of values to real voltages which can then be applied to the analogue components. For example, in the Prophet 600 you have a software variable representing the filter cut-off frequency of a voice. It is a 16 bit variable, e.g. a chain of 16 bits (bit = can take the value 0 or 1) which can represent values from 0 and 65535. In the case of filter cut-off frequency this would be used to cover the range from zero cut-off to fully open filter in quite fine granularity. However, the CEM3372 filter chip of that voice requires a voltage between 0 and 5 volts at pin 15, not a 16 bit digital representation. So, like everybody else, the Prophet 600 has a so-called Digital Analog Converter (DAC) which takes digital values as input and outputs voltages. Just as a side note: the reverse process, e.g. conversion of voltages to digital values is pretty much using the same mechanism. In the Prophet 600 this happens when the software reads the position of the panel controls - while this is also an interesting topic, here we will only look at the process of setting voltage outputs.  

Multiplexer switchboard

Second, it is important to appreciate that a device like the Prophet 600 (like almost all devices which use similar functionalities) cannot have a separate DAC for each voltage. If you take input and output voltages together there are more than 60 control voltages floating around in a Prophet 600. Having separate DACs for each on would be far too expensive and it may easily double the weight of the instrument. Instead the Prophet 600 uses multiplexers. A multiplexer has several voltage outputs. It takes one single input voltage and a control function is used to select which output this voltage should be propagated to. After the output is set, the voltage is held until it is explicitly updated - this principle is called sample and hold. In this way one single DAC can be used for all control voltages.  

For its control voltages the Prophet 600 uses 4 multiplexer chips (type 4051) each having a selection of 8 outputs. The resulting 32 control voltages covered in this way are: 6 for oscillator A frequency, 6 for oscillator B frequency,  6 for filter cut-off frequency, 6 for voice amplitude (VCA) and then 8 more controls (pulse width A and B, volume A and B, resonance, cross-modulation amount, master volume and the level of external filter CV). Technical note: if you look at the schematics in the service manual for circuit board 4 the first 24 voltages are covered by the 3 multiplexers with component number 415-417 and the last 8 voltages are covered by the multiplexer 418. Note also, that while the first 24 voltages are voice specific, the latter 8 voltages are not - which is the reason why multitimbrality is impossible on the Prophet 600 hardware.

So the general idea of how voltages are set in the Prophet 600 should be more clear. One downside of the multiplexer approach is that you can only set one voltage at a time and so you need to set all voltages in cycle. Maybe at this point you begin suspecting where the "hardware limitations" of the Prophet 600 come from. Neither the DAC nor the multiplexer respond instantaneously - there is a component specific delay. Let's look at the process for setting one voltage:

1. Prepare the multiplexer for a voltage change so none of the outputs are affected
2. Set the input to the DAC to produce the voltage
3. Wait for a reasonable time so that the DAC voltage can rise to the desired value  
4. Select the output on the multiplexer to apply the voltage
5. Wait for a reasonable time with the selection active so that the output has time to adopt the input voltage precisely
6. Deselect the output on the multiplexer 

The Teensy++ 2.0 based firmware implements exactly that sequence. While in the old Z80 firmware it was the software execution that was the bottleneck, now it is the hardware. In fact, in the upgraded version GliGli implemented explicit wait cycles in between the steps above in order for the hardware to cope with the voltage and control changes. You may be surprised to hear that more than half of the computation time of the Teensy++ 2.0 is spent waiting! Still, the entire voltage control cycle (at least the 24 voice specific voltages) must be quick enough to achieve the nice and smooth 2kHz update rate - plus leaving enough time for processing note playing, user controls, MIDI input and display. 

Now, 2kHz is about the fastest that is possible. The maximum wait times that together still fit properly into the 0.5 millisecond length of one cycle already push the multiplexers and DAC to the limits. From experience with different Prophet 600 units and from incident reports it has become evident that it is the multiplexers, which are the real bottleneck. What happens if multiplexer delay times are too long, is that switching and/or voltage propagation is too slow and you may miss voltage updates, get remnants of one voltage being applied to the wrong output or the voltage has not had enough time to build fully. Typical results are glitches, in particular during pitch changes and intermittent wrong pitches. The problems may also be temperature dependent, manifesting themselves only after starting a cold unit. In one case one of the voices reproducibly failed to update completely due to a slow multiplexer, which worked fine in GliGli's 2015 version but not in the 2022 upgraded version.  

Are my multiplexers fast enough? Which ones should I choose?

Whether or not you are experiencing glitch problems on your Prophet 600, you should know that there are different options for multiplexers. Multiplexers are not expensive and changing them is not a problem with reasonable soldering skills. Your multiplexer chips may even be socketed in which case the replacement is a piece of cake. The location of the 4051 chips (components 415-417) on the board is shown below.

There are many variants of the type 4051 multiplexer on offer from different manufacturers. They are all compliant with same functional specification but they are different chips, partly also using different technology, and they have different characteristics including different delay times. From what I know most Prophet 600 were originally shipped with CD4051BE from Texas Instruments. I have heard of originals with a BU4051B by Rohm (for the less critical 418 multiplexer, though). It is almost certain that many more shipped varieties exist. The general idea is that ideally the firmware is programmed such that different multiplexer can cope with its speed, e.g. wait times are sufficient to accommodate even the most sleepy of 4051 chips. But from user reports and discussions, I found that this is not true. Some Prophet 600 units which I have seen and played or talked about with others had the multiplexers replaced by yet more variants of the 4051 chips, some of which were absolutely lame and created problems, so it's not clear why they were chosen in the first place. I have original CD4051BE chips and when I shortened the wait times in the software I managed to throw them off, which tells me that 4051 chips (at least for components 415 to 417) must not be slower than the CD4051BE.

Now here is a small comparison of 4051 variants (based on spec sheets, numbers are rough averages, just as an indication) and what I could conclude about them from cases I know of. Btw: "ns" means nanosecond, e.g. the unit of delay time.

• CD74HCT4051E (Texas Instruments): fast propagation (15ns) and fast switching (50ns). This is an excellent choice which in one case healed the problem of non-functional voice in the 2022 firmware upgrade (but that unit had the bad HD14051BP before, see below).
• MC74HC4051N (Motorola): fast propagation (15ns) and fast switching (65ns). This is also a very good choice.
• CD4051BE (Texas Instruments): fast propagation (20ns) but slow switching (>500ns). This is what I think was the Prophet 600 factory standard. It gets the job done.  
• BU4051B (Rohm): medium propagation (35ns) and slow switching (>350ns). Not a good choice, appears to be OK for component 418.
• HCF4051BE (STMicroelectronics): slow propagation (45ns) and slow switching (>500ns). Not ideal, can produce glitches.
• HD14051BP (Hitachi): slow propagation (55ns) and super slow switching (>1000ns). This is very slow and creates serious problems on later firmware versions.
• MC14051B (Motorola): very slow propagation (>60ns) and slow switching (>500ns). This is very slow in switching but somehow manages with only creating glitches. Not a good choice.

I hope this is useful. I you have some experience with multiplexers and you would like to add or correct something please feel free to comment!