Define base primitives for digital back-end

manifold-lang / manifold-backend-digital

Digital circuits backend for Manifold

GNU General Public License v3.0

0 stars 1 forks source link

Define base primitives for digital back-end #3

Open mtrberzi opened 10 years ago

mtrberzi commented 10 years ago

Issue by mtrberzi Thursday Jul 03, 2014 at 16:37 GMT Originally opened as https://github.com/manifold-lang/manifold/issues/117

One point of contention will be how to represent these primitives in a way that the front-end can understand and that is compatible with how schematics are read.

I support keeping these separate from the back-end, in a JSON file similar to the schematic but that only defines node types/connection types/etc. The back-end would have a "hard-coded" representation of the types that it expects to see (and this could -- very possibly but not necessarily for our final demo -- result in automatic generation of this JSON file).

mtrberzi commented 10 years ago

Comment by mtrberzi Thursday Jul 03, 2014 at 22:46 GMT

The primitives are probably going to be the following:

Node types:

register (ports: in, out, clock, reset) (attributes: initial value, reset polarity, reset asynchronous, clock polarity)
and (ports: in0, in1, out)
or
not (ports: in, out) (optionally: nand, nor, xor, xnor)
inputPin (ports: out)
outputPin (ports: in)

Connection types:

digitalWire

Port types:

digitalIn
digitalOut

mtrberzi commented 10 years ago

Comment by lucaswoj Friday Jul 04, 2014 at 14:31 GMT

I'm ok with everything except the exact of these primitives. At the risk of sounding pedantic, all the abbreviations and different naming conventions make this look bad.

A few high level points:

Do we really need to indicate within identifiers that wires, ports, and pins are "digital"? I would think that everything in the digital backend would be digital. Either everything should be prefixed with "digital" (undesirable) or nothing should be.
Register ports could be named "in", "out", "clock", and reset
Do we have to indicate the arity of our and/or/not/xor gates? Can we assume 2 until we see the need to support higher arity gates?
not1 ports could be named "in" and "out"
digitalInputPin could be renamed to inputPin (same for digitalWire, digitalIn, digitalOut)

mtrberzi commented 10 years ago

Comment by mtrberzi Friday Jul 04, 2014 at 14:42 GMT

This was a rough outline, but I appreciate the feedback. I'll definitely pick better naming conventions in release, and update that comment accordingly.

mtrberzi commented 10 years ago

Comment by mtrberzi Friday Jul 04, 2014 at 14:50 GMT

The reason wires and ports are called "digital" is because of potential namespace clashes with, for example, mixed-signal circuits that have both digital and microfluidic inputs and outputs.

mtrberzi commented 10 years ago

Comment by mtrberzi Thursday Jul 10, 2014 at 14:43 GMT

Okay, I will provide JSON type definitions for these.