Added two additional VHDL units 'src/ROM.vhdl' and
"src/computer_tb.vhdl", both of which are only meant for simulation
purposes. The ROM unit loads a text file specified by the generic property
"program_file" and acts as a 32K ROM addressed by its line
number (starting with zero). The computer_tb unit puts everything
together (cpu, ROM, and ram16k) and allows the user to pass a program
file via a generic property. This program file must contain less than
65535 lines containing 16 zeros or ones (eg. Something generated by the
assembler given for the Nand to Tetris course).
The directory "src/asm" was added containing a couple test programs in
both hack assembly and in hack machine language. Additionally, various
gtkwave save files (in 'src/wave/gtkw') were added for use with each
hack program given, as well as two template gtkwave save files for use
with new programs.
See the README.md file for more details on running simulations with
computer_tb, as well as various other details.
TODO: implement memory maps for screen and keyboard and handle VGA
output
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Added generic "freq" to clock entity to allow choice of the frequency of
clock that will be generated. Remember, this entity is for simulation
purposes only!
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Finished testing the cpu implementation. The test data from the nand to
tetris course was modified slightly to fit different timing in this
simulation. Specifically, every two rows given in the test data refer to
part way though the 'low' part of the clock cycle, then the 'high' part
of the cycle respectively. To keep things simple all synchronous test
benches in this project have set sample inputs, waited 25 ps then
checked the given sample output; then the simulation is paused for the
remaining cycle (750 ps); this makes for a cycle period of 1 ns. Setting and
testing the given test data all happens before the clock goes 'high' and
thus each row in the test data given in the test bench refers to the
same time. Thus if some piece of data is stored in cycle 'a' then in
cycle 'a + 1' that data is guarantied to be in place.
Example: Consider this simple hack assembly program.
@3 // 0000000000000011
D=A // 1110110000010000
D=D+A // 1110000010010000
This program can is executed as follows (ignoring reading from ROM):
Load 3 into register A in time step 1 (doesn't get synchronized until
the clock goes 'high', so A will not be read as 3 until the next time step).
Set D=A=3 in time step 2, similarly to the first step, this value will
not be synchronized until the following time step.
Finally set D=D+A=3+3, which again, won't appear in the D register until
the following time step.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
For a jump to occur the current instruction must be a c-instruction and
the jump condition must hold true. Before this commit the former was forgotten.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
The port assignment for the cpu_alu was incorrect. It was set to be the
output of register A but it should be either the output of register A or
inM depending on bit 'a' of the instruction. This corresponds to the
output signal of mux16_1 (which is memtoALU).
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
The test bench 'cpu_tb.vhdl' currently fails for almost all inputs. Though from
analysis of the vcd output, everything seems to be working correctly. It
seems that the compare data from the nand to tetris course for
synchronized circuits/chips does not behave nicely with this simulation
because it assumes two clock cycles is one discreet time
unit (tick-tock) whereas in this simulation every pulse of the
clock (1 ns period) acts as a single discreet time unit. This however
still needs to be investigated and also is an issue in the
implementation of 'pc_tb.vhdl'.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Contains vhdl code and test benches for the following chips:
- adder
- add16
- alu
- dff
- dbit
- dregister
- dmux
- dmux4way
- dmux8way
- mux
- mux16
- mux4way16
- mux8way16
- pc
- ram8
- ram64
- ram512
- ram4k
- ram16k
For simulation of sequential chips, a clock must be used; this is
implemented as 'src/clock.vhdl' with accompanying test bench
'src/clock_tb.vhdl'.
'src/wave/gktw' contains gtkwave save files for viewing the output of
the various test benches.
The 'schematics' directory contains schematics of the various
chips (incomplete).
Things not yet completed:
- weird issue with 'src/pc_tb.vhdl'; that is, the test data from the
"nand to tetris" course doesn't fit the simulation but the simulation
appears to be correct (by inspection).
- cpu chip
- build system (currently things can built by hand using ghdl as
follows)
To build the various chips and their respective test benches, use ghdl
like so:
$ cd src
$ ghdl -i --workdir=work *.vhdl
$ ghdl -m --workdir=work <chip_name>_tb
$ ghdl -r <chip_name>_tb --vcd=wave/vcd/<chip_name>.vcd
You can then view the wave output file in
'src/wave/vcd/<chip_name>.vcd'.
Collin J. Doering