|
|
12
|
|
I'm having a comparison failure at line 12 in Mux8Way16 chip. I have tried all options I could think of.
Please help with some clue.
|
|
Administrator
|
Please put yourself in our shoes. Knowing that you have a comparison failure on line 12 gives us very little to go on. I know that your part passed the first ten tests and that, somehow for some reason, it failed the eleventh. I don't know what part of the eleventh test it failed. I don't know the first thing about your circuit.
How can I possibly come up with a useful clue for you?
Look at the inputs for that test. Look at the outputs that is should produce. Be sure that you understand and agree that those are the correct outputs. Look at the outputs that your part produced. Walk through your design step by step to see why it is producing those results. Then look for why it should have been doing in order to produce the correct result.
|
|
|
Thanks for your reply. I'm sorry if I have made it difficult for you to help.
Since I haven't fully understood the concept, I sometimes find it difficult to express myself and give details. And I also think it is absurd to copy paste the output I'm getting here as that may be tedious to read.
I have, however, made another post asking for help regarding DMux4way including Mux8Way16 which I copy paste its hdl code. I hope I was able to provide some useful information for you to come in in the post.
Thanks for your reply always.
Regards.
|
|
Administrator
|
Very often spending the time to find a way to express something we are unsure about has the effect of making a light click on and letting us see some of the key points that are causing us problems in such a way that we might be able to solve it ourselves. Happens very frequency.
I really don't know how you expect us to tell you why your output is producing the error you are getting when you won't show us what your output even is.
You don't have give us the full output, just the part relevant to the error.
For instance, you say you have a comparison failure on line 12. So take the .cmp file and make a copy of it (or bring it into an editor and change it, but don't save it!) and keep the first row and delete all of the lines except line 12 (and perhaps a line or two above it). Then do the same for the .out file (being sure to keep the same lines). Then post both here.
As an example, this might look something like:
Mux8Way16.cmp (last line is line 12)
| a | b | c | d | e | f | g | h | sel | out |
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111 | 0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 001 | 0010001101000101 |
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111 | 0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 010 | 0011010001010110 |
Mux8Way16.out (last line is line 12)
| a | b | c | d | e | f | g | h | sel | out |
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111 | 0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 001 | 0010001101000101 |
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111 | 0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 010 | 0110011110001001 |
Given this, it can quickly be seen that, with sel='010' that the comparison file is saying that the output should match input 'c' (which is correct), while the output file shows that it is matching input 'f'. But 'f' should be selected only when the sel input is '101'.
Do you see how much more information is available for us to use in trying to help you?
I don't see this as being an absurd thing to ask for, or receive.
You might also ask yourself how many bits the sel input is on a Mux4Way16 and whether or not you are providing sel inputs to it that are the proper width.
|
|
|
This post was updated on .
I appreciate your thorough explanation. It's very helpful and filled with much insight. I will ensure I do what you ask for.
To proceed, below is the Mux8Way16 cmp and out excerpts. Now at line 14.
Instead of matching up with e input pin when sel=100 it's matching with a input.
Mux8Way16 .cmp line 13 and 14
a b c d
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111
e f g h sel
|0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 011 |
|0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 100 |
out
0100010101100111 |
0101011001111000 |
Mux8Way16 .out
a b c d
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111 |
| 0001001000110100 | 0010001101000101 | 0011010001010110 | 0100010101100111 |
e f g h sel
0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 011 |
0101011001111000 | 0110011110001001 | 0111100010011010 | 1000100110101011 | 100 |
out
0100010101100111 |
0001001000110100 |
Thanks for your help.
|
|
Administrator
|
So now look at your code and walk it through, by hand, with sel = '100' and write down what all of the signals are.
Note that if an input to a chip is N-bits wide, then if you don't have N-bits connected to it you can get very strange behavior because the simulator doesn't know what the value of that signal is. The same, by the way, is true on a real chip, even to the extent of possibly destroying the chip.
|
|
|
The deepest my thought could go on this right now is that I have covered the entire width.
sel is set all the way from [0..0] to [1..1] which I think is the Nbits in the sel bus if I'm correct.
And, I'm using Mux4way16 which has in its implementation to run from [0..15] width bus.
I know for definite that something is wrong in my implementation and I might need to slightly tweak the hdl, but I can't just think of what that could be.
|
|
Administrator
|
But sel[0..0] is just a single bit -- it is the lowest order bit of 'sel'. What are you driving sel[1] with? Nothing! How does a Mux4Way16 behave if it's high order bit isn't driven by anything? I have no idea -- it is what is known as "undefined behavior".
|
|
|
But I have sel[0..1] which I think it stands for sel[1]. the following is the range of sels I have.
sel[0..0]=sel[0..0],
sel[0..0]=sel[0..0],
sel[0..1]=sel[0..1],
sel[0..1]=sel[0..1],
sel[1..1]=sel[1..1],
|
|
Administrator
|
Idrisadeniyi wrote
But I have sel[0..1] which I think it stands for sel[1]. the following is the range of sels I have.
sel[0..0]=sel[0..0],
sel[0..0]=sel[0..0],
sel[0..1]=sel[0..1],
sel[0..1]=sel[0..1],
sel[1..1]=sel[1..1],
The notation signal[a..b] means a signal consisting of bits 'a' through 'b' of the bus named 'signal'.
If 'sel' is a 2-bit bus, the sel[1] is the most significant bit and sel[0] is the least significant bit.
sel[0..0] is the same as sel[0].
sel[1..1] is the same as sel[1].
sel[0..1] is the same as sel (i.e., the entire bus).
|
|
|
I have corrected the sel's bit, but I'm still having problem with it. In fact, the output now took me back to No. 11 on the output. This is exhausting. May be whole thing is not just right. The following is my hdl.
Mux4Way16 (a=a, b=b, c=c, d=d, sel[0..0]=sel[0..0], out=w);
Mux4Way16 (a=e, b=f, c=g, d=h, sel[0..0]=sel[0..0], out=x);
Mux4Way16 (a=a, b=b, c=c, d=d, sel[1..1]=sel[1..1], out=y);
Mux4Way16 (a=e, b=f, c=g, d=h, sel[1..1]=sel[1..1], out=z);
Mux4Way16 (a=w, b=x, c=y, d=z, sel[0..1]=sel[0..1], out=out);
|
|
Administrator
|
Idrisadeniyi wrote
I have corrected the sel's bit, but I'm still having problem with it. In fact, the output now took me back to No. 11 on the output. This is exhausting. May be whole thing is not just right. The following is my hdl.
Mux4Way16 (a=a, b=b, c=c, d=d, sel[0..0]=sel[0..0], out=w);
Mux4Way16 (a=e, b=f, c=g, d=h, sel[0..0]=sel[0..0], out=x);
Mux4Way16 (a=a, b=b, c=c, d=d, sel[1..1]=sel[1..1], out=y);
Mux4Way16 (a=e, b=f, c=g, d=h, sel[1..1]=sel[1..1], out=z);
Mux4Way16 (a=w, b=x, c=y, d=z, sel[0..1]=sel[0..1], out=out);
Again, the 'sel' input on the Mux4Way16 is a TWO BIT signal. You need to drive it with a TWO BIT signal.
sel[0..0] and sel[1..1] are both ONE BIT signals. They are the same as just sel[0] and sel[1], respectively.
|
|
|
Ok. So am I suppose to have something like sel[00] [01]...[11]?
If so, anytime I have the left bit higher than the right, I get an error message: "The specified sub bus is not in the bus range" like this: sel[10] and [11].
|
|
Administrator
|
Idrisadeniyi wrote
Ok. So am I suppose to have something like sel[00] [01]...[11]?
If so, anytime I have the left bit higher than the right, I get an error message: "The specified sub bus is not in the bus range" like this: sel[10] and [11].
That's because you sel bus doesn't have a wire #10 or a wire #11.
It seems like you are confusing the values of the data on a signal and the wires that make up that signal.
Remember, the HDL code merely describes how wires are connected. Nothing more. NOTHING more.
Buses are nothing more than a collection of wires, number 0 through one less than the number of wires in the bus.
Let's make up a simple logic function and see how we would implement it.
CHIP MyChip
{
IN fred[16], sue[16];
OUT y[2];
PARTS:
Or16(a[0..7]=fred[4..11], a[8..15]=sue[1..8], b=fred, out[4]=y[0], out[13]=y[1]);
}
The Or16 gate has two 16-bit inputs and a 16-bit output.
The notation signal[number] means "Wire #<number> in the bus named <signal>".
So we have the following:
a[0] of the Or16 gate input is connected to fred[4] of the chip's input.
a[1] of the Or16 gate input is connected to fred[5] of the chip's input.
a[2] of the Or16 gate input is connected to fred[6] of the chip's input.
...
a[7] of the Or16 gate input is connected to fred[11] of the chip's input.
a[8] of the Or16 gate input is connected to sue[1] of the chip's input.
a[9] of the Or16 gate input is connected to sue[2] of the chip's input.
...
a[15] of the Or16 gate input is connected to sue[8] of the chip's input.
Since the 'b' input of the Or16 gate and 'Fred' are of the same width, they can be connected directly with the understanding that:
b[0] of the Or16 gate input is connected to fred[0].
b[1] of the Or16 gate input is connected to fred[1].
...
b[15] of the Or16 gate input is connected to fred[15].
There are several input wires, namely sue[0] and sue[9..15] that are not connected. That's fine.
The output consists of two wires and we need to connect them both. We are connecting one of them to one of the Or16 gate outputs and the other to a different one. We have fourteen other outputs from the Or16 that are not being used, which is fine.
out[4] of the Or16 gate output is connected to y[0] of the chip's output.
out[13] of the Or16 gate output is connected to y[1] of the chip's output.
|
|
|
Thanks for the explanation. It lets me understand it better.
However, there are still some elements of confusion. In the above example, fred[16] and sue[16] are both the input pins of the chip having 16bits or wires(if I am correct) each. And you connected both of them to the a and b pin of the Or16 gate on different wire numbers, if you will, but same width size. This is a kind of explicit connections. I thought wire numbers are all set by the script and sel is suppose to be the determinant for the out pin. If sel=00 out should ouput the a pin 16bits numbers and so on. All I have to do is connect the in pins to the part pins. I didn't know I will have to deal with individual bit and modify positions in the bus. I'm confused! do I need to know anything about how the bits in each pin changes or shift to the right or left?
In my case, this tend to be a little confusing. I am building an 8waychip which 4 of its input pins conforms with the chip I am using to build it. So, I'm unsure on how to connect the remaining 4 which are e to h. If I go with your example of a[0..7]=fred[4..11] and a[8..15=]sue[1..8] pins, I will have to modify the way I have connected e to h which goes like so :a=e, b=f, c=g, d=h. But I have no clue on how to go about this.
|
|
Administrator
|
Idrisadeniyi wrote
I thought wire numbers are all set by the script and sel is suppose to be the determinant for the out pin.
The value of the 'sel' input selects which data input is routed to the 'out' pin. That's the function you are trying to achieve. But you are the constructor of a chip that will behave like that. The simulator doesn't know or care about how what you construct behaves, it simply runs what you built.
You build a chip by taking wires and connecting this pin to that pin.
Consider the following chip:
CHIP Bubba
{
IN tom[6];
OUT sally[2];
PARTS:
Not(in = tom[4], out = lou, out = sally[1]);
Mux4Way(a = tom[2], b = tom[5], c = tom[0], d = tom[3], sel[1] = lou, sel[0] = tom[1], out = sally[0]);
}
Now lets see what happens when I run this chip:
Let's set tom = 101010
This means that:
If tom[5] = 1
If tom[4] = 0
If tom[3] = 1
If tom[2] = 0
If tom[1] = 1
If tom[0] = 0
Since tom[4] = 0, that means that lou = 1 and sally[1] = 1
The inputs to the Mux are sel[1] = 1 (because that's the signal on low) and sel[0] = 1 because that's the signal on tom[1]). That means that what ever is on input 'd', which is tom[3], will get sent to the output, which is connected to sally[0]. So sally[0] will be whatever is on tom[3], which is currently a 1, so sally[0] = 1.
Hence the final output is
sally = sally[1],sally[0] = 11
|
|
|
Thanks for the example. It really helps. Although, I'm still having a few issues with it, but I'm working hard to fix it myself.
I've moved on to work on subsequent chips. I need some help with DMux4. When sel=10, I want to connect pin c. But when I do so:a=c, both a and c will return same output resulting in a comparison failure error. I'm using Dmux gate to implement DMux4 chip, and c is not a pin Dmux. Please how do I tweak this?
 I have attached the image of my output. Thanks
|
|
Administrator
|
I have no idea without seeing your code and what you are doing?
Go ahead and post your code. We can delete it later.
|
|
|
Alright. below is the hdl:
CHIP DMux4Way {
IN in, sel[2];
OUT a, b, c, d;
PARTS:
// Put your code here:
And (a=in, b=in, out=lo);
DMux (in=in, sel=sel[0], a=a, b=b);
DMux (in=lo, sel=sel[0], a=x1, b=x2);
DMux (in=x1, sel=sel[1], a=c, b=z2);
}
|
|
Administrator
|
Idrisadeniyi wrote
Alright. below is the hdl:
CHIP DMux4Way {
IN in, sel[2];
OUT a, b, c, d;
PARTS:
// Put your code here:
And (a=in, b=in, out=lo);
DMux (in=in, sel=sel[0], a=a, b=b);
DMux (in=lo, sel=sel[0], a=x1, b=x2);
DMux (in=x1, sel=sel[1], a=c, b=z2);
}
Draw out the circuit. You have the 'in' signal going to both sides of an And gate. Any signal 'And'ed with itself is just the signal. So that And gate does nothing.
You aren't driving the 'd' output at all.
You are producing this 'x2' signal and doing nothing with it.
Think about what you are trying to do in terms of a car going down a road into a forest and at the other side of the forest are four roads coming out. In the forest are some forks and each fork has a light next to it. If the light is off, the car takes the left fork but if it is on the car takes the right fork. The forks are the Mux gates and the lights are controlled by the 'sel' input. Can you connect a few of these forks with roads in order to get the car to the desired exit road but using two switches to control the lights at the forks?
|
12
|
Locked
