Merge different input/output types

[ialokim]

If one wants to look at a subcircuit on its own, it is essentially as easy as copying the subcircuits definition to the top level (replacing devices and connectors) in the json file. But due to the (somehow artificial) distinction between Input/Button/NumEntry and Output/Lamp/NumDisplay it gets more difficult if one wants to be able to simulate the circuit on manual inputs.

I would propose to move the logic to differentiate between different in/output types from yosys2digitaljs to digitaljs itself and merge the three in/output types respectively. The corresponding view class could then show different views depending on whether the in/output is inside a subcircuit (Input) or not as well as depending on the bit size (Button vs. NumEntry). This would also be another step towards #2.

[tilk]

Yes, I agree the distinction is completely artificial, and is dictated by the design of the UI. If you can create a nice solution, I'm willing to merge.

[ialokim]

Currently, all input and output gates have a propagation of zero (in fact, the input/outputSignals logic used elsewhere is ignored here completely; signals are set or shown directly without the circuit's enqueue/operation methods).

What is your opinion about this: Should we keep it the way it is now and essentially prohibit the use a bigger propagation delay at all for IO gates or should we adapt it so that a delay may be configurable (with the default value of 0)? Obviously the latter would cost some performance while simulating as there would be an extra step needed to "pipe" signals through IO gates.

[tilk]

This is by design. Inputs and outputs are basically a way to allow subcircuits to interact with the external circuit, and for the main circuit to interact with the outside world. As they correspond to wires, they are not really gates at all (like the grouping operations). Allowing delays on them could be confusing for the user, as (at this level of abstraction at least) there is no such thing as wire with a delay - this basically becomes an implicit buffer.

So, basically, if there is no benefit to changing the present behavior, I would prefer to keep it as it is now.

[JakubSzczerbinski]

As far as i understand this change makes devices of type: "Lamp", "Button", "NumEntry". "NumDisplay" obsolete. Shouldn't this be reflected in README by marking them as 'deprecated' or something similiar?

[tilk]

Yes, it should, thanks for noticing. Also, the examples should be updated.