|
|
|
|
My ALU has passed the basic test, so I am assuming that means the functionality of the ALU works and the only thing left to do is to workout the zr and ng single bit outputs. I have implemented both of them, and the full test gets a comparison failure on line 14. When this happens the output is -2 which is incorrect since 0 - 1 should just be -1.
I do not know if this means the ALU itself is not working correctly or if it is the zr output, which at line 14 is outputting 1 since out is not 0 which is correct.
This is the code for my ALU. As mentioned before the ALU passes the basic test and the ng output seems to be correct since it will use the LSB of the output which will always be 1 if the output is < 0. I then tried to do the same for the zr output but did the exact opposite, without the zr output is gets a comparison failure at line 2.
// zx
Not16(in=x[0..15], out=notX1);
Add16(a=notX1, b=x[0..15], out=addX1);
Inc16(in=addX1, out=incOut1);
Mux16(a=x[0..15], b=incOut1, sel=zx, out=zxOut);
// nx
Not16(in=zxOut, out=notZX);
Mux16(a=zxOut, b=notZX, sel=nx, out=nxOut);
// zy
Not16(in=y[0..15], out=notY1);
Add16(a=notY1, b=y[0..15], out=addY1);
Inc16(in=addY1, out=incOut2);
Mux16(a=y[0..15], b=incOut2, sel=zy, out=zyOut);
// ny
Not16(in=zyOut, out=notZY);
Mux16(a=zyOut, b=notZY, sel=ny, out=nyOut);
// f
Add16(a=nxOut, b=nyOut, out=addOut1);
And16(a=nxOut, b=nyOut, out=andOut1);
Mux16(a=andOut1, b=addOut1, sel=f, out=fOut);
// no
Not16(in=fOut, out=notF);
Mux16(a=fOut, b=notF, sel=no, out=out[0..15], out[15]=lsb, out[0]=msb);
// Output
Mux(a=true, b=false, sel=msb, out=zr);
Mux(a=false, b=true, sel=lsb, out=ng);
An idea I keep having for the zr output is to use And16 to do the 16 bit equality comparison, using the value false as one of the inputs, and then somehow getting that 16 bit output into a 1 bit input for the Mux that outputs zr.
p.s. I would also like to apologise for how many questions I have asked on this forum. I am doing this completely on my own and do not want to view the solutions online, but when it gets past the 10-15 hour mark then I post on here since I cannot think of any other way to find the solution.
|
|
Administrator
|
This post was updated on .
nblackburn wrote
My ALU has passed the basic test, so I am assuming that means the functionality of the ALU works and the only thing left to do is to workout the zr and ng single bit outputs.
In general, this is a bad assumption. Except for the simplest gates, the tests are not exhaustive, so passing the tests only means that it passed all of the tests that happened to be tried, which is only a tiny fraction of all of the things that the part is supposed to do.
Consider that the ALU has two 16-bit inputs (for x and y) and a 6-bit control input. That's 38 bits of input, which is nearly 275 billion possible inputs that would need to be tried to completely test its functionality.
In practice, we try to develop tests that have a high likelihood of catching the most likely errors and to have enough of them so that we think it is probably unlikely that any likely error will not cause at least one test to fail. But designers make unlikely errors all the time, and catching those is a lot harder, requiring a lot more tests, and even then errors that have major consequences can slip by -- just as Intel about how hard it is to validate floating-point division logic.
I have implemented both of them, and the full test gets a comparison failure on line 14. When this happens the output is -2 which is incorrect since 0 - 1 should just be -1.
I do not know if this means the ALU itself is not working correctly or if it is the zr output, which at line 14 is outputting 1 since out is not 0 which is correct.
Sounds like you have two errors. Your ALU is not producing the correct numerical output for 0 - 1 and, separately from that, it is not producing the correct zr output. Remember, if zr=1, that means that the output IS zero. Your output is -2, so zr should be 0.
This is the code for my ALU. As mentioned before the ALU passes the basic test and the ng output seems to be correct since it will use the LSB of the output which will always be 1 if the output is < 0. I then tried to do the same for the zr output but did the exact opposite, without the zr output is gets a comparison failure at line 2.
This about this. If I give you a bunch of 16-bit values, what do YOU need to look at to determine if each of them is or is not exactly equal to zero.
If the msb is 1, that means that the value represented is negative.
But this does NOT mean that if the msb is 0 (i.e., NOT 1) that the value is zero. All it means is that the output is NOT negative.
// no
Not16(in=fOut, out=notF);
Mux16(a=fOut, b=notF, sel=no, out=out[0..15], out[15]=lsb, out[0]=msb);
// Output
Mux(a=true, b=false, sel=msb, out=zr);
Mux(a=false, b=true, sel=lsb, out=ng);
out[15] is the most-significant bit of the output.
out[0] is the least-significant bit of the output.
All the lsb of the output tells you is whether or not the value is even (if it's 0) or odd (if it's 1).
|
|
|
I dod not realise that the basic test only considered some of the things the part is meant to do. Thanks for pointing that out, I am going to start again.
|
|
Locked
