... | ... | @@ -21,12 +21,25 @@ There are two kinds of things to memorize during the simulation : |
|
|
|
|
|
These two are represented differently. 1. is represented via an environment type, with each identificator (of type `ident = string`) mapped to a value of type `Netlist_ast.value`, which represents either a single wire (`VBit of bool`) or a bus (`VBitArray of bool array`). This represents the current global context.
|
|
|
|
|
|
The memory blocks, 2., is represented in hashtables. There are three hashtables : `reg`, `ram` and `rom`. `reg` maps an `ident` to a `bool`, in a straightforward manner, as one would expect. On the other hand, `rom` and `ram` map an `ident` to another hashtable. For instance, let us call `r` an element of `ram`. `r` is a hashtable which is a fancy way to represent a perhaps mostly-empty array. If the RAM it represents has an address size of $`n`$ bits, it could store up to $`2^n`$
|
|
|
The memory blocks, 2., is represented in hashtables. There are three hashtables : `reg`, `ram` and `rom`. `reg` maps an `ident` to a `bool`, in a straightforward manner, as one would expect. On the other hand, `rom` and `ram` map an `ident` to another hashtable. For instance, let us call `r` an element of `ram`. `r` is a hashtable which is a fancy way to represent a perhaps mostly-empty array. If the RAM it represents has an address size of $`n`$ bits, it could store up to $`2^n`$, which is quite a lot, especially since most of it could be empty most of the time. That's why I settled on having a $`\sqrt{2^n} = 2^{\frac n 2}`$ sized `r`. The same applies for ROM.
|
|
|
|
|
|
# Input
|
|
|
|
|
|
See [the related doc](Functions#input) for details on the technical implementation.
|
|
|
|
|
|
At the beginning of each cycle, the simulator asks for input, which is at the core of the human-machine interface. In the long run, this could be used, for instance, as the result of mouse movement, controller input, keyboard presses, sensors, microphone, whatever you want that can be transmitted as a digital signal basically.
|
|
|
|
|
|
Currently, however, such, let's admit it, cool features, are out of question since the input's main function is to deprive the user of sleep by giving a new prompt for each bit. Of course, the user can still copy-paste its way through it.
|
|
|
|
|
|
## TODO :
|
|
|
- Change this damned input method to take bit-words as input for buses.
|
|
|
- Have a way to choose where the input comes from (file, user actions...)
|
|
|
|
|
|
# Computations
|
|
|
|
|
|
See the (functions doc)[Functions] for details on every function.
|
|
|
|
|
|
The basic idea for the computation is just to follow what each gate instructs us to do. `c = AND a b` ? Then in OCaml, this is translated as `c=a && b`. Then the result of this calculation is put in memory in the environment.
|
|
|
Whenever a gate made sense, I implemented it : for buses, wires, wires and buses, buses composed of one wire...
|
|
|
|
|
|
# Output |
|
|
\ No newline at end of file |