Collin J. Doering
e634f0fbe4
Removed old nojs specific templates and updated "templates/default.html" and "templates/partials/nav.html" to support nojs. All pages now use relativized urls. Navigation pages (including blog paginated pages) are generated to "/" instead of "/pages/". Site now works when javascript is disabled. Unfortunately, it no longer works when javascript is enabled. This is due to the client side router but needs to be debugged further. Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
143 lines
8.9 KiB
Markdown
143 lines
8.9 KiB
Markdown
---
|
|
title: Computer From Scratch
|
|
author: Collin J. Doering
|
|
date: Jul 19, 2015
|
|
description: Building a computer from scratch using VHDL
|
|
tags: general, programming, hardware, nand-to-tetris
|
|
---
|
|
|
|
Recently I have had the pleasure of completing the course *Nand to Tetris* on
|
|
[Coursea](http://coursera.org). Firstly, I'd like to highly recommend it to anyone! I never
|
|
thought it would be possible for me to understand computers all the way down to the hardware
|
|
level (past assembly that is); *Nand to Tetris* has shown me otherwise! It has also inspired me
|
|
to pursue learning a real world hardware description language and attempt to implement the
|
|
*Hack* system on an [FPGA](https://en.wikipedia.org/wiki/Field-programmable_gate_array) (Field
|
|
Programmable Gate Array). In this article I will describe how the process is coming and the
|
|
what remains to be completed.
|
|
|
|
For the impatient, the repository is located [here][hack-git] and is documented
|
|
[here][hack-docs].
|
|
|
|
<!--more-->
|
|
|
|
After implementing the *Hack Computer System* in the hardware description language described by
|
|
the course, I wanted to explorer further. So after doing a little research, I found there were
|
|
two main industry strength hardware description languages,
|
|
[VHDL](https://en.wikipedia.org/wiki/VHDL) and
|
|
[Verilog](https://en.wikipedia.org/wiki/Verilog). I then set out to find open source
|
|
implementations of these languages. Happily I found [GHDL](http://ghdl.free.fr/) and
|
|
[Icarus Verilog](http://iverilog.icarus.com/) respectively. After briefly looking over both
|
|
languages and their open source implementations, I decided I would use VHDL because I'm a fan
|
|
of type systems and it is similar to the hardware description language given by the *Nand to
|
|
Tetris* course.
|
|
|
|
Now both *Icarus Verilog* and *GHDL* are unable to do *synthesis*. For those of you who are
|
|
unaware of what *synthesis* is, it refers to the process of taking a hardware description and
|
|
converting it into a format a FPGA can use. This is generally a bit file for JTAG programming
|
|
or a bin file for writing to the FPGA board's internal memory. To my dismay, FPGA's are
|
|
incredibly proprietary! Namely, the *synthesis* process can only be done using proprietary
|
|
tools. So initially I decided I would forgo thinking about how exactly I would get my
|
|
implementation on a FPGA but instead get the components of the system designed and verified
|
|
though simulation, which can be completed using all open source tools. Now, there is a
|
|
unsynthesizable subset of both VHDL and Verilog, so care needs to be taken to ensure that the
|
|
design doesn't utilize these parts as the end goal is to implement the *Hack Computer System*
|
|
on a FPGA. An exception to this is when a entity/module will only be used in simulation (Eg.
|
|
Reading a text file and emulating a ROM that contains the machine language instructions
|
|
specified in the file).
|
|
|
|
Following the materials given by the course, I then went on to implement the *Hack Computer
|
|
System* in VHDL. Currently, the project [resides here][hack-git] and has some
|
|
[accompanying documentation][hack-docs] which explain how things work, how to build the
|
|
project, and how to run a simulation. Please refer to the [documentation][hack-docs] for
|
|
complete instructions on building and using the [hack][hack-git] project and simulator.
|
|
|
|
Before going into detail on some of the design choices I made, I'd like to give an example of
|
|
setting up the simulator and running the default simulation of the top most unit,
|
|
`computer_tb`, which computes the first 25 Fibonacci numbers and puts them in RAM address' `0x3`
|
|
through `0x28`.
|
|
|
|
``` {.bash .code-term}
|
|
$ git clone http://git.rekahsoft.ca/hack
|
|
$ cd hack/src
|
|
$ ghdl -i --workdir=work *.vhdl
|
|
$ ghdl -m --workdir=work computer_tb.vhdl
|
|
$ ghdl -r computer_tb --stop-time=750ns --vcd=wave/vcd/computer-fib.vcd
|
|
$ vcd2fst wave/vcd/computer-fib.vcd wave/vcd/computer-fib.fst
|
|
```
|
|
|
|
First, clone the sources, then import and build them with `ghdl`. Finally run the simulation
|
|
using the default input program and output a vcd file to `src/wave/vcd/computer-fib.vcd` which
|
|
is then converted to a `fst` file using `vcd2fst` (`vcd2fst` is included with [GtkWave][]). Now
|
|
once the simulation has complete the *vcd* or *fst* file can be opened with a wave form viewer.
|
|
I recommend and have only tested with [GtkWave][]. To open the dump file open [GtkWave][] and
|
|
go to `File -> Open New Tab` (or `C-t`) and select the output file (in our case
|
|
`src/wave/vcd/computer-fib.fst`). I have provided pre-saved "views" for `computer_tb` (as well
|
|
as the other entities within the project) so that the signals of interest for the entity in
|
|
question don't need to be repopulated into the signals panel each time [GtkWave][] is opened.
|
|
To open the [GtkWave][] save file go to `File -> Read Save File` (or `C-o`) and select the
|
|
appropriate save file. In our case we will open `src/wave/gtkw/computer-fib.gtkw`.
|
|
|
|
Note running this simulation will take some time (likely longer then an hour) and will consume
|
|
lots of RAM and CPU and generate a large vcd dump (> 20 GB). By changing the length of time the
|
|
simulation runs for one can limit the size of the vcd dump, but the usage of the CPU and RAM
|
|
will remain the same. The large vcd dump file is unavoidable because *GHDL* records data for
|
|
all signals in the design and there's no way to filter its output until after the simulation
|
|
has run (using external tools). Hopefully at some point the developers of *GHDL* can fix this
|
|
oversight.
|
|
|
|
![[GtkWave][] displaying a simulation dump from *computer_tb* running
|
|
*src/asm/Fib.hack*](/files/images/gtkwave.png)
|
|
|
|
Using a
|
|
[generic property](http://www.doulos.com/knowhow/fpga/Setting_Generics_Parameters_for_Synthesis/)
|
|
`program_file`, a user is able to pass a text file containing *Hack Machine Language* to the
|
|
`computer_tb` unit using the `-g` switch to *GHDL* like so:
|
|
`-gprogram_file=path/to/program.hack`. If none is specified it defaults to
|
|
[src/asm/Fib.hack](http://git.rekahsoft.ca/hack/tree/src/asm/Fib.hack) (the corresponding *Hack
|
|
assembly* form is provided [here](http://git.rekahsoft.ca/hack/tree/src/asm/Fib.asm)). The
|
|
contents of the given `program_file` are used as the ROM data for the duration of the
|
|
simulation.
|
|
|
|
Unfortunately specifying generic properties when ghdl is invoked is only implemented in very
|
|
recent versions of *GHDL* (later then 2015-03-07; see
|
|
[ticket](http://sourceforge.net/p/ghdl-updates/tickets/37/?limit=25)). If you are running an
|
|
older version of *GHDL* then you must modify `src/computer_tb.vhdl` to specify the program you
|
|
want to run in the simulation. See the [documentation][hack-docs] for details.
|
|
|
|
![[GtkWave][] zoomed in to view approximately *100 ns* of signal
|
|
output](/files/images/gtkwave-closeup.png)
|
|
|
|
So now that we've seen a quick rundown of how to use the simulator to run *Hack* programs, lets
|
|
take a moment to review some of the deficiencies of the implementation. The most noticeable
|
|
issue is that the memory maps for the *SCREEN* and *KEYBOARD* are currently not implemented.
|
|
This is mainly because it is difficult to simulate keyboard input and video output in real
|
|
time. Note that programs that access the *SCREEN* and *KEYBOARD* memory maps will successfully
|
|
be executed during simulation, but any data sent to the screen will never be remembered and the
|
|
keyboard will always be inactive.
|
|
|
|
One method to implemented the *KEYBOARD* memory map is using a text file similar to the
|
|
technique employed in the ROM entity. This would work fine but wouldn't provide an interactive
|
|
user experience as I would prefer. Similarly for video output, the raw VGA signals or even
|
|
simpler yet, the values of the screen memory map could be dumped to file during the simulation
|
|
and then be processed after the fact by an external program to create a video or set of images
|
|
of the output. This again however, isn't a interactive experience.
|
|
|
|
An option I haven't mentioned is to have the simulation and an external program communicate
|
|
through a pipe or socket while the simulation is running. This would allow the external program
|
|
to send key presses to the simulation while also simultaneously decoding the output of the
|
|
screen output file in real time and displaying it as a video to the user; essentially creating
|
|
a VM for the *Hack* machine. This approach seems the most promising but is quite challenging to
|
|
implement, and likely will be quite slow. So I determined for the time being, my time would be
|
|
better spent focusing on completing the implementing on a *FPGA*, once I'm able to obtain one.
|
|
Though at some point I may explore this as it would allow an easy way for students to further
|
|
explore after completing the *Nand to Tetris* course.
|
|
|
|
Anyways, hope you enjoyed reading this post. I will post a few follow up articles once I'm able
|
|
to obtain a *FPGA* and complete the implementation (will a VGA screen and a PS2 or USB
|
|
keyboard). Also just to reintegrate, for those of those interested in the inner workings of a
|
|
computer, I highly recommend checking out the *Nand to Tetris* course.
|
|
|
|
[hack-git]: http://git.rekahsoft.ca/hack/
|
|
[hack-docs]: http://git.rekahsoft.ca/hack/about
|
|
[GtkWave]: http://gtkwave.sourceforge.net/
|