Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • N netlist_simulator
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Paul Fournier
  • netlist_simulator
  • Wiki
  • Implementation

Implementation · Changes

Page history
Update Implementation authored Nov 07, 2020 by Paul Fournier's avatar Paul Fournier
Hide whitespace changes
Inline Side-by-side
Implementation.md
View page @ b1aa812e
......@@ -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
Clone repository
  • Functions
  • Implementation
  • Home