|
|
|
|
I heard that DMux works as reverse option for Mux.
But supposing we have the following Mux:
a = 1, b = 1, sel=0 -> output = 1
It doesn't matter which combination I create on DMux side, I will never be able to represent an output like a=1, b=1.
Basically I can't reproduce the output a=1, b=1 as shown in the video comparing Mux vs DMux
 Doesn't it mean that we might loose information when using Mux + DMux?
Or am I missing something?
|
|
|
sure you can... it entirely depends on the control bits.
looks at the second bit(s) going in. Those are a=1, b=1. Then look at the second bits coming out. Also a=1, b=1.
|
|
|
This post was updated on .
Mux and DMux work "reverse" only conceptually. Mux selects one of its inputs and ignores the others. DMux selects one of its outputs and feeds zeroes (or even "nothing") to the others.
This means that at any given moment the Mux "looses" the information stored in all but 1 of its inputs and you cannot restore this information from its output. But it is not designed to be able to do that. It's designed to select one of several inputs.
[EDIT]
As soon as I hit "Post Message", I saw what it might mean. It could work like that with the correct synchronization. Basically, the Mux and the DMux needs to be switched twice as fast as the Mux's inputs change. Even then the DMux will produce 1 at most in one of its outputs, so you'll need to put some additional circuitry to ignore the even half of the first output and the odd part of the second one.
Again, this is not what Mux and DMux are designed for. If you need this kind of processing there is a gate called Shift Register. It's used to implement serial communication.
[/EDIT]
|
|
|
There's no such combination like a=1 and b=1 on DMux truth table
|
|
|
Maybe I misunderstood the explanation from the video.
What I had understood is that you can send multiple messages through on single line of communication. In my head, that would work as some sort of serialisation process.
In the example mentioned in the video, it's said that you might have multiple videos being sent through the line, and then you redistribute them on the other end of the line.
But, if in one end, a=1, b=1 is coming in, but on the other end, a=1, b=0 is coming out then you lost information.
Perhaps Mux/Dmux is used for different applications?
Would be nice to know real world applications using them
|
|
|
yes there is...
a => 1 0 (1) 1 ................ 1 0 (1) 1
b => 0 1 (1) 0 ................ 0 1 (1) 0
^ ^
| |
going in, a=1, b=1 coming out, a=1, b=1
read the column pairs vertically from right to left... the bits are streaming in/out one at a time. The first pair of bit to go in, a=1, b=0, are also the same first pair of bits to come out, a=1, b=0. The second pair of bits to go in are, a=1, b=1. And the same pair to come out second. Because the same control bits are being used together.
Make sense?
|
|
|
think of it like two gear wheels coming together. Each wheel has its own bit of data to send to the other side, and the control bits force them to alternate such that they seeming mash together without colliding and stepping on each other, at the point of "contact". Then on the other side, they come out again as separate streams, the same as they went in.
|
|
|
xedover, I think you are trusting the picture too much here. Look at just DMux. It redirects its input to one of its outputs. All other outputs are zero. So there's no way to have both outputs of DMux be 1 at the same time.
|
|
|
no, no... just because you switch the output from one channel to the other, you are not changing the value of the other channel. That channel remains unchanged from its previous output until its next cycle.
The problem here is we are dealing with 4 cycles of data coming into the Mux, with 8 cycles of data coming in to the DMux. So what's not being shown here is dealing with the timing of the cycles. But that's really a different problem to solve.
But the concept is still the same, just like a zipper, we merge the two channels together with the Mux, then using the same control bits, separate them unchanged through the DMux
|
|
|
jonduarte wrote
Maybe I misunderstood the explanation from the video.
What I had understood is that you can send multiple messages through on single line of communication. In my head, that would work as some sort of serialisation process.
In the example mentioned in the video, it's said that you might have multiple videos being sent through the line, and then you redistribute them on the other end of the line.
But, if in one end, a=1, b=1 is coming in, but on the other end, a=1, b=0 is coming out then you lost information.
Perhaps Mux/Dmux is used for different applications?
Would be nice to know real world applications using them
I haven't watched the videos so I don't know the specifics. You could come up with something similar to the picture using Mux/DMux combination, but you would need additional things to make it work. As you mention correctly, the output of DMux cannot be a=1, b=1 at the same time.
Mux and DMux have a lot of practical usages and you'll use them in creating the HACK hardware. For example, the HACK CPU has a register A, which can take be assigned from 2 different places: either directly from a CPU input, or the result of a computation done in the ALU. You can't just put the two buses (sets of wires) in the input. Instead you can use add the in a Mux and select which input you really need. Mux is also known as Data Selector.
DMux is also very useful. For example, when writing in RAM you need to make only one of the RAM cells (or RAM registers) writable. You can use cascading DMuxes to achieve that.
|
|
|
well... now I'm going to have to set up some hardware to test it :)
but I think I see what you mean...
The other thing that's missing in this picture, is reading the values coming out on the 'a' and 'b' bus lines. The control bits for the Mux/DMux would also have to be used on the bus enable lines as well. The image is assuming that is all being taken care of -- its the general concept that they are trying to show
|
|
|
Mux and DMux are combinational circuits. If there are cycles, they happen outside of them. And when you switch the DMux control bit(s) the channels switches as well. Here is the comment from 01/DMux.hdl:
/**
* Demultiplexor:
* {a, b} = {in, 0} if sel == 0
* {0, in} if sel == 1
*/
As you can see, one of the outputs is equal to in and the other is always 0.
Logisim is a good visual tool you can use to play with these things.
|
|
Administrator
|
I think there are a couple of points you might be missing.
First, consider that the MUX also "loses" information. When it is outputting the signal from input A, it is ignoring what is present on input B (and vice versa, of course). So what really gets transmitted is just half of each signal. We really don't know what is happening during the other half -- we generally assume (or know because we know how the signals are being produced) that it is static during this time.
Second, on the output side, yes, the signal at each output is only tracking the input half of the time and is zero (in the case of the N2T DMux) the rest of the time. But that's fine when you consider that, in truth, we didn't know what it was that other half of the time any way.
Finally, if we DO know that the input signals are static even when they aren't selected (probably because both signals are registered at half the clock rate of the signal driving the Mux's select input), then we can reproduce this behavior at the output by simply sampling the DMux's outputs and registering the result with two DFFs.
|
|
|
WBahn wrote
I think there are a couple of points you might be missing.
I'm not sure how this is different from what I wrote. I said that 1) Mux is loosing information, because it's not designed to serialize all its inputs into its one output, and 2) it's possible to implement such scheme with additional gates.
Am I missing something?
|
|
|
Interesting. Thank you all for your information - I believe I understand now what's happening there.
|
|
|
ivant wrote
WBahn wrote
I think there are a couple of points you might be missing.
I'm not sure how this is different from what I wrote. I said that 1) Mux is loosing information, because it's not designed to serialize all its inputs into its one output, and 2) it's possible to implement such scheme with additional gates.
Am I missing something?
A Mux and Demux in real life also have a clock.. normally a clock ticks a counter which is your select lines.. so that the input is adding data and the other side is looking only for that data on the other end. the counter takes the clock pules and counts out the corresponding select lines as addresses.. in some system like a z80, parts of the address lines are used to address the select lines, and some times its a mix of IRQ signal and the data lines..
in anycase, with out a control of the select lines you would be correct, you loose data as it would be a race condition.
|
|
Locked
