tomstorey / discrete-nor-logic-clock Goto Github PK

I have optimized the 7-seg decoders following this workflow:

• make a spreadsheet with a truth table which is automatically transformed into
  • visual representations of the displays for all input combinations, all visible at once
  • a K-map for each output bit
• with the K-maps, find minimal NOR-expressions (will describe how elsewhere)
• click together the corresponding circuit in the free online version of logic.ly, test it, and re-iterate if necessary
• make screenshots

Now my questions are:

1. Are you OK with OpenOffice, and with keeping the spreadsheets in the repo?
2. logic.ly is nice for quickly trying out small things, and has nice visuals. However, to be honest, I don't think it's worth its current price. Particularly it cannot (AFAIK)
   a) automate the verification
   b) be used with a textual representation of the design, which, in turn, would enable true working-together on designs (including using the benefits of git)
   What else can be used?

As for 2) I am envisioning a text file that describes a particular circuit. This text can be written by hand or produced from formulas in a spreadsheet. It can also be interpreted, or evaluated to produce a mapping from input combinations to output combinations. This evaluation would ideally be possible within a spreadsheet.

Well, I've been thinking of (and already working on) writing my own - it's all Booleans anyways, right? You might already have spotted those "µ A -B C -D" labels in my screenshots.
My short-list of implementation languages was

• javascript: runs in browser, functional (good for writing a parser), TDD support
• Perl6: very well suited for a parser, TDD support
• OpenOffice Basic: can be used in spreadsheets

Well, I went with the third option because I really want to use it in the spreadsheets. ...And I kind of regret it now. There ought to be a way to use javascript for OpenOffice macros but I just couldn't get it to work, it's (Java) package-hell.
The thing is that you really need a parser so you can use mentioned concise lambda-like expression rather than a notation like "NOR(...)"; in addition you need to be able to define intermediate signals (ie. introduce shortcuts/abbreviations). I'm convinced that without that anything beyond trivial becomes unwieldy.

Now, BASIC is really, REALLY bad! But hey, that's kinda in the spirit - "from grounds up"... Additionlly, I seem to have gone in a particularly unfortunate direction with my implementation, ie unsuited for BASIC. I'll try to push it further a little bit more but I might have to start over.

What do you think?