RAM8 Script test pattern

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

RAM8 Script test pattern

gs99
The normal pattern that starts is like this: set, tick, output; tock, output;

Example:
(time 0+)
set in 0,
set load 0,
set address 0,
tick,
output;

(time 1)
tock,
output;

I didn't look at all lines, but the pattern starts with values being set in the "+ times" (e.g. 0+,1+).
Results are seen in the times that follow (e.g. 1,2).

(1) What is the value of doing tick output?  We need only the tock output, correct?
I tried this format which seems to work:
set in 0,
set load 0,
set address 0,
tick;
tock,
output;

set load 1,
tick;
tock,
output;


(2) What's the purpose of lines in this (different) format, that first appears in time 8?
set address 1,
eval,                      
output;

thanks
Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

cadet1620
Administrator
gs99 wrote
(1) What is the value of doing tick output?  We need only the tock output, correct?
I tried this format which seems to work:
It suppose the tick output might be useful for some sort of debugging, but I think of the clock as an event. In the real world the clock event occurs and the synchronous logic updates its output, then the combinational logic updates its value in a very noisy, glitchy, way and eventually settles to a stable value sometime before the next clock event.This settling time limits how fast the clock can run. The values between clock events aren't relevant.
(2) What's the purpose of lines in this (different) format, that first appears in time 8?
set address 1,
eval,                      
output;
The input side of RAM is synchronous--the input only changes the RAM's data when a clock occurs. The output side is asynchronous--whenever the address changes, the output data changes.

The tick/tocks are testing the input side, the evals are testing the output addressing.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

gs99
cadet1620 wrote
The input side of RAM is synchronous-- the input only changes the RAM's data when a clock occurs. The output side is asynchronous-- whenever the address changes, the output data changes.
I'm confused.
I couldn't find these terms in chapter 3:
"input side", "synchronous", "output side", "asynchronous"

I thought all of this was controlled by the clock - synchronous.

How do those terms relate to these lines in the script?
Example A.
set in 11111,
set load 1,
set address 3,
tick,
output;
tock,
output;

And how do they relate to these lines in the script?
Example B.
set address 1,
eval,                      
output;

What's the difference between "set address 3" in Example A and "set address 1" in Example B?
The main reason for setting the address is to change the contents of that memory, correct?
In a real computer, are things not being set within a clock cycle, as portrayed in Example A format?
The format of Example B seems to be "out of place".

cadet1620 wrote
The tick/tocks are testing the input side, the evals are testing the output addressing.
The RAM8.cmp file shows what the address should be after Example A.
Isn't that testing the "output addressing"?
Why are evals needed?

Another question. Figure 3.5 shows actions that occur in times (22-34).
The load bit is asserted in time 29, and the input of 527 is outed in the next time, 30.
But in these scripts, if "set load 1" in tick, the input is outed in tock.
But aren't tick and tock parts of the same time cycle?

Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

cadet1620
Administrator
gs99 wrote
cadet1620 wrote
The input side of RAM is synchronous-- the input only changes the RAM's data when a clock occurs. The output side is asynchronous-- whenever the address changes, the output data changes.
I'm confused.
I couldn't find these terms in chapter 3:
"input side", "synchronous", "output side", "asynchronous"

I thought all of this was controlled by the clock - synchronous.
Sorry, I should have said "combinational". You are correct that all the sequential logic in Nand2Tetris is synchronous. Asynchronous sequential logic is when you have feedback but no clocked storage elements like DFFs. Here's an example:
RS Latch
If you want to learn more about asynchronous circuits including how they are used to built a DFF, check out play-hooky.com. There's a lot of other interesting stuff on that site too.

By input side of the circuit I mean the logic between the chip inputs and the storage elements--the Registers. The output side is the logic between the storage elements and the chip output.

Since the input to the Registers can't be observed directly by the test, the only way to test the input circuitry is by clocking the chip so that the input is transferred (if it should be) to the output. Some aspects of the output circuit can be tested without clocking the chip. In particular, changing the address changes which Register's output should appear on the RAM8's output. That's what the evals are about.
How do those terms relate to these lines in the script?
Example A.
set in 11111,
set load 1,
set address 3,
tick,
output;
tock,
output;
This is testing that data gets stored in Register 3.
And how do they relate to these lines in the script?
Example B.
set address 1,
eval,                      
output;
This is testing that writing to some other Register did not affect Register 1.
What's the difference between "set address 3" in Example A and "set address 1" in Example B?
The main reason for setting the address is to change the contents of that memory, correct?
In a real computer, are things not being set within a clock cycle, as portrayed in Example A format?
The format of Example B seems to be "out of place".
Actually, there are greatly more reads from memory than there are writes.  During reads, clocking the Registers has no effect; the RAM is acting completely combinationally. Although the Hack computer clocks the memory for every instruction, most real world computers do not. Real world memory systems are extremely complex, well beyond what can be dealt with here.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

gs99
Thanks,
I see that setting the address not only does that; it also obtains the contents.
So the eval, output; represents a read operation?

And thanks for the link to play-hooky.com.
 
cadet1620 wrote
Since the input to the Registers can't be observed directly by the test
However, if line 1 in RAM8.tst is:
set in 2,
set address 3,
set load 1,
eval,
output;

RAM8.out has:
| time |   in   |load |address|  out   |
| 0      |      2 |  1  |   3       |      0  |

Doesn't that indicate that the input to the Register was observed by the test?

Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

cadet1620
Administrator
gs99 wrote
cadet1620 wrote
Since the input to the Registers can't be observed directly by the test
However, if line 1 in RAM8.tst is:
set in 2,
set address 3,
set load 1,
eval,
output;

RAM8.out has:
| time |   in   |load |address|  out   |
| 0      |      2 |  1  |   3       |      0  |

Doesn't that indicate that the input to the Register was observed by the test?
What is being displayed here is the in value to the RAM8. In a correctly wired RAM8, that is also the in for the Register that should be loaded, but the test can't directly verify that connection so it needs to clock the RAM8 and see what appears on the RAM8's out pin.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

gs99
Earlier you said regarding my Example B:
set address 1,
eval,                      
output;

“This is testing that writing to some other Register did not affect Register 1.”

The eval is not “clocking the RAM8”.
But doesn’t it show what appears on the RAM8’s out pin for Register 1?
That’s why it proves that changing another Register did not affect Register 1.
Reply | Threaded
Open this post in threaded view
|

Re: RAM8 Script test pattern

cadet1620
Administrator
gs99 wrote
Earlier you said regarding my Example B:
set address 1,
eval,                      
output;

“This is testing that writing to some other Register did not affect Register 1.”

The eval is not “clocking the RAM8”.
But doesn’t it show what appears on the RAM8’s out pin for Register 1?
That’s why it proves that changing another Register did not affect Register 1.
Yes, that is correct.

--Mark