Course:CPSC312-2019/Circuit-solver

From UBC Wiki

What is the problem?

The problem that we want so solve is whether or not Prolog is a suitable language to simulate digital circuits. For our initial work, we will only consider digital circuits containing time independent structures (ie circuits without flip flops and clocks, just logic gates), and how we can simulate the values of wires in a digital circuit.

What is the something extra?

Our extra portion of this project is the creation of compound digital circuits from our base circuits. In particular we focused on creating different types of adders (half, full, multibit), subtractors (half, full, multibit), two bit comparators, and multiplexers. These blocks can be specified by the user, and our simulation will decompose them into their respective logic gates. This is helpful as an educational tool, as it will allow users to build up large circuits without worrying about intermediate wiring, in order to simulate useful circuits.

Additionally, we added an easy-to-use interface which will prompt users for input and guide them along the process of specifying and building a digital circuit. This aspect of our project allowed us to gain experience with string manipulation in Prolog and term creation via strings.

What did we learn from doing this?

Overall, we were successful in implementing this digital circuit simulator/solver as we were able to simulate the rudimentary gates (and, or, not, nand, nor, and xor) based on given input, which is in addition to building compound logic circuits like adders. We learned many things about prolog such as:

  • Prolog excels when code is written declaratively. There were many occasions where previous experience would lend us to developing an imperative solution; however, trying to do that in Prolog resulted in very messy code.
  • Loss of OO hierarchies makes code more repetitive at times. There were a few occurrences where having typing would help us as many of our functions are similar, this similarity could be extracted out. For example, we have many sim(...) predicates (one for each gate type) and they operate quite similarly, without diving into RDFs, there didn't seem to be an elegant way of re-using code.
  • Unlike most languages which require serialization/deserialization to retrieve objects from strings, Prolog is able to understand when a string can also be an atom. Specifically we were able to execute commands like term_string(Term, "fullAdder(a,b,c,...)") which would automatically cast this string to a fullAdder(...) term.

Overall, Prolog seems to be a suitable language for this task, as the majority of our issues revolved around code style, rather than functional aspects of our code. Furthermore, the Prologs use of clauses lends itself well to digital logic since it all boils down to boolean logic.

Links to code, etc.

https://github.com/BenjaminLang/cs312-project2