|
|
|
|
Dear friends,
I came across a problem which is driving me crazy. I don't want to think of an unlikely bug, so there must be something I am missing (however silly it may be).
Let's say I am testing some basic chips: I have got in a folder "OK" the Mux8Way16 alone, and in a second folder "KO" the very same Mux8Way16 chip together with a couple of constitutive chips, that are Mux16 and Mux (actually, Mux8Way16 is made up of Mux16 chips only, and Mux16 is made up of Mux chips only).
As far as I understood, when I test the (single) chip in the OK folder, the HardwareSimulator employs the built-in version of the involved Mux16 chip to perform computations, while when I test the same Mux8Way16 chip in the KO folder, the HardwareSimulator employs the user-realized Mux16 and Mux chips inside the folder (and then the other necessary built-in chips to complete the computations starting from Mux).
If this is correct, I assume that if no test error is issued when testing on the OK folder, the Mux8Way16 chip should be correct, while if an error is issued while testing the same chip in the KO folder, then the problem should be related to the other user-realized chips (Mux and Mux16) included in the KO folder. Obviously I am using the same tst file to perform the test.
Now, it comes precisely the case that I described above, BUT it really appears that both the Mux16 and Mux chips included in the KO folder are correct too. In particular, the problem should rely on the Mux chip, but when I test the Mux chip its final outcome is successful. So it appears that the Mux chip passes its own test, but it contributes to invalidate the test of the Mux8Way16 chip (which is a correct chip). How is it possible? By the way, I know that the test files cannot be trusted (in general they are not complete), but that is not the case of the Mux chip where all the 8 possible input configurations are tested.
I hope I was able to clearly illustrate the scenario and I am looking forward for someone to provide some hints to figure out what I am missing.
Many thanks in advance!
--- longj_silver
PS:
I should also mention that the Mux8Way16 error is due to a specific evaluation (included in the test file) involving the following setup for one of its Mux16 part:
a = 2345
b = 4567
sel = 1
out = 4527
as well as (for another Mux16 part):
a = 6789
b = 89ab
sel = 1
out = 892b
Such outcomes are somewhat strange to be explained, but my real conundrum remains in the overall test process I described before, with the inexplicable involvement of the Mux chip.
|
|
Administrator
|
longj_silver wrote
I hope I was able to clearly illustrate the scenario and I am looking forward for someone to provide some hints to figure out what I am missing.
Many thanks in advance!
--- longj_silver
PS:
I should also mention that the Mux8Way16 error is due to a specific evaluation (included in the test file) involving the following setup for one of its Mux16 part:
a = 2345
b = 4567
sel = 1
out = 4527
as well as (for another Mux16 part):
a = 6789
b = 89ab
sel = 1
out = 892b
Such outcomes are somewhat strange to be explained, but my real conundrum remains in the overall test process I described before, with the inexplicable involvement of the Mux chip.
I don't think that you are missing anything; your analysis seems correct.
Note that both errors that you are seeing are single bit errors.
0x4567 -> 0x4527 is an error in bit 6, and
0x89AB -> 0x892B is in bit 7.
Since you say that this involves two different Mux16s, I'd look for an incorrect bus index in the 'b' input of your Mux16 involving bits 6 and 7.
If you can't spot it, email me your Mux*.hdl files and I'll see if I can spot it.
--Mark
|
|
|
Dear Mark,
at start I thought the problem could reside in Mux16 too. But I made some additional tests; in particular I put into the KO directory a Mux.hdl which is correct for sure (in order to substitute the original one), while leaving untouched the Mux16 file: the test of the Mux8Way16 was correct. This should confirm that the problem is related to Mux. Yet, that Mux file is able to pass its own test (and only 8 input configurations are sufficient for a complete verification).
Anyway, I am going to send you both the KO and OK folders by email: please note that the Mux8Way16.hdl file is the same inside both folders.
Cheers
|
|
|
Dear Mark,
I finally spotted the revealing hint which may throw light on the question.
Into the Mux chip there is one part which puckishly reports:
Or(a=v3,a=v4,out=k);
You will note that there is no specification for the "b" input, being the "a" input (erroneously) defined twice.
Now it seems that such an occurrence produces some unexpected side effects:
1)- no syntax error is issued, so the Hardware Simulator does accept such a misleading notation
2)- as a consequence of 1), computation is carried on, but I wonder which value the unspecified input ("b") is going to assume at each step
3)- after some trials I verified that (maybe as a consequence of 2)) the order of the test configurations affects the chip's behaviour. In fact, if you try and test the Mux chip with the following sequence:
[a = 1, b = 1, sel = 0]; [a = 1, b = 1, sel = 1]
the obtained results are correct ([out =1];[out = 1]). On the other hand, if you apply the following sequence:
[a = 0, b = 1, sel = 1]; [a = 1, b = 1, sel = 1]
the second test is not passed ([out =1];[out = 0]).
It happens that the first sequence is adopted in the test file for the Mux chip (so that it passes its own test), while the second sequence occurs in the test file for the Mux8Way16 (so that the Mux chip invalidates the test).
I hope everything is clear. That is my contribution, but I think I am missing some key aspect due to the doubt expressed in 2).
What do you think about?
Cheers,
--- longj_silver
|
|
Administrator
|
Good eyes, and even better analysis!
I was just beginning to look at the code you sent and saw that Mux was indeed causing the problem when I noticed this post.
longj_silver wrote
Or(a=v3,a=v4,out=k);
You will note that there is no specification for the "b" input, being the "a" input (erroneously) defined twice.
Now it seems that such an occurrence produces some unexpected side effects:
1)- no syntax error is issued, so the Hardware Simulator does accept such a misleading notation
Indeed, connecting one input to two outputs should be illegal.
2)- as a consequence of 1), computation is carried on, but I wonder which value the unspecified input ("b") is going to assume at each step
Inputs that are not connected appear to behave as if they are connected to 'false', but I don't think that behavior is specified anywhere. In the real world, you should always connect all inputs.
3)- after some trials I verified that (maybe as a consequence of 2)) the order of the test configurations affects the chip's behaviour. In fact, if you try and test the Mux chip with the following sequence:
[a = 1, b = 1, sel = 0]; [a = 1, b = 1, sel = 1]
the obtained results are correct ([out =1];[out = 1]). On the other hand, if you apply the following sequence:
[a = 0, b = 1, sel = 1]; [a = 1, b = 1, sel = 1]
the second test is not passed ([out =1];[out = 0]).
It happens that the first sequence is adopted in the test file for the Mux chip (so that it passes its own test), while the second sequence occurs in the test file for the Mux8Way16 (so that the Mux chip invalidates the test).
I don't know the internals of the Hardware simulator, but since it is software, it must be computing everything serially, so you get different values depending on evaluation order as you have determined. In your code, the output of that Or probably depends on whether 'v3' or 'v4' is computed last.
--Mark
|
|
|
Dear Mark,
many thanks for your comments; I read also your reply sent me by email.
As I wrote in some previous post of mine, I am proposing the Hack project to my students and I was not the author of the chip implementations I was discussing: this made the verification more complex and challenging.
Just like you said, I was also considering that undefined inputs may be assumed as "false", but there is still something I cannot figure out properly (I am not sure even about the value of the "a" input which is defined twice). Obviously, the inner realization of the Hardware Simulator is unknown to me.
Anyway, I stick to your observations concerning the illegality both of multi-defined and unconnected inputs: I was wondering if this can be assessed as a sort of bug.
I could open an issue in the forum section devoted to errata and bugs (if it may be of any help for someone - I don't know if this forum is attended by the nand2tetris staff) or I could contact Prof. Schocken with whom I already got in touch at the start of my journey to receive some teaching material - any suggestion about that?
Thank you very much.
--- longj_silver
|
|
Administrator
|
Java source code for the the simulators is available from the N2T site at
http://www.nand2tetris.org/software/nand2tetris-open-source-2.5.7.zipivant has updated the sources and has then buildable in Maven. See this forum post. Ivan's source would be a good place to start if you are interested in looking at the source and/or adding a "multiple connections to input" error message.
I'm not a Java programmer -- my specialty is embedded systems firmware which is about as far as you can get from Java programming. I've done a couple minor fixes to Ivan's code and sent them to him, but so far I've avoided learning about Java UI code.
I don't know of any official bug reporting/tracking system for the tools.
--Mark
|
|
|
Once again, thank you for your hints!
From the post I learn that a novel version has been released only a few months ago: it could convenient for me to take a look. (I am afraid I have adopted an earlier version and I am missing a number of enhancements.) A GitHub project is also referred.
Maybe those are the right guys and place to send a possible report.
Regards
---longj_silver
|
|
|
I just want to note that this is kind of a fork. It's not the official release, though the vast majority of the code is from the official source.
I'm trying to improve it in certain places, but I lately I can't seem to find enough free time to work on it.
Still, do report problems that you find and I'll try to resolve them.
--
Ivan
|
|
|
Hi Ivan, nice to meet you.
As concerning the release of software, I was pondering the possibility to inform the creators/maintainers of the original project about possible problems they could be interested in evaluating. Actually, I found this forum (where I had the opportunity to profit from some excellent hints from Mark), but I was unaware of connections with the original managers of the nand2tetris project.
I understand that you are spending your good will to improve the project by producing a fork. I praise you for such a useful initiative, unfortunately free time is an increasingly rare resource and I doubt I will be able to contribute by getting my hands dirty with coding. Should you be interested, however, the issue I spotted can be simply summed up by the sample part:
Or(a=v3,a=v4,out=k);
which appears to be accepted (and computed on) by the Hardware Simulator. As you notice, the "a" input of the Or chip is defined twice, while the definition of the "b" input is missing. That could be a standard occurrence in an overlooked implementation. I verified that the following computations MAY be affected by such a notation, producing unexpected results.
I was wondering if this is a bug or if there could be any reason to allow the user the chance to produce such an implementation: that was the subject of the last lines exchanged with Mark, and I think I am going to address the issue also to the managers of the nand2tetris project. Maybe in the meantime I could copy-and-paste this issue also into your GitHub project (if you agree with my analysis).
Cheers,
--- longj_silver
|
|
Locked
