Concurrency

[KLM]

I have run into something with your program that you should look into. The main strength of digital logic circuitry (hardware) is its operational concurrency. Software, on the other hand, is almost totally sequential in operation. This is one of the main strengths of hardware operation, but it is very difficult to emulate in software. Where this is especially a problem is with synchronous circuitry. Examples are counters, shift-registers and many types of state machines. Since you don't have specific synchronous devices such as JK Flip Flops assigned in your package, it is nearly impossible to handle these as concurrent devices automatically. I think you should have a way of assigning "time epochs" to devices, much as VHDL and Verilog do. Then the user can, at each point in time, assign all the necessary device outputs to a "before" or T-0 time, with the needed next device inputs being assigned to "after" or t-1 time points. In this way, one device output isn't changed automatically before the dependent input to the next device. Example: a shift register implemented with D Flip Flops, from left to right on the page operated properly, but when arranged from right-to-left, the behavior became bizarre. With counters, the behavior can be even more unpredictable - - apparently depending upon when the software (which is, within itself, totally sequential) assigns its action to take place. Put in these controls for grouping and sequencing operations and your package will be a lot more useful; and closer to the concurrent operational characteristics of hardware.

KLM

[admin]

Hi KLM,

Can you please be more specific on what you’ve found difficult or not properly working?
All the flip-flops in the real hardware are built from just the same logical elements, so in the program you should be able build them too. You can build different flip-flops that are synchronizing by front or rear front of the clock signal. So theoretically it should not be any problems running a few counters or shift registers in parallel.
If you have any particular problem with your circuit, can you please share it and we can look at it together.

Thank you,
Eugene

[KLM]

It is not a problem that I have but one that I have anticipated. I don't know how your program handles concurrency over multiple devices, but when many devices must operate concurrently it is important that none be handled by the software before any of the others, because the operation of those may well depend upon it (in its previous state). I have been attempting to demonstrate this using a fairly long but simple ring of flip Flops implementing a shift register - - but I haven't been able so far to get the anticipated malfunction to occur. (Murphy's law fails only when you attempt to demonstrate it.) I have attached my latest attempt. (It can run either with manual stepping or clock - - whichever one you connect.) I shall continue looking for a demonstrative example.

KLMhttp://www.logiccircuit.org/forum/posting.php? ... 448&t=2822#

[admin]

I see what you mean. So the evaluation of the state is happening in waves. The wave is started at the point that is changed: for example a button that is pressed or clock that is flipped. Then all the circuits that are directly connected to it will be evaluated then all the circuits that connected to them and so on until none of circuit is changing its state. Inside the wave the order of evaluation is random and in some cases a randomly chosen circuits are fall back to the next wave to simulate latency. Without this randomization many circuits will oscillate. How ironical is that in order to simulate a deterministic device you need to do it randomly.
So the bottom line is concurrency is taken care of in the simulation and so you don’t need to worry about it. However if you’ll see any glitches please let me know.

[KLM]

The main problem that I see is what happens when many inputs are effected by any one particular signal change (concurrency) - - in particular, from a clock. In the sample that I put together, this is a series of shift registers. No problem occurs if each register is handled after the one which it feeds, this means working back from the last to the first. This means that the simulation software must be able to determine where each device comes within a synchronous chain. This can get tricky, especially in the cases of closed loops and multiple paths.

Example; if shift register A feeds shift register B in a synchronous chain, then the clock, which goes to both cannot be taken to register A first, because its “initial” output is the one that B needs. In most cases, this can be solved by taking those at the “output” end first, and working backward, but it is not always this simple. Where do we start, for example, in a closed chain? Even worse, what if the signal chain branches? This would, it seems to me, require first mapping the connections from back forward, then handling the signal relations from the front backward, handling parallel branches simultaneously.

The best approach, however may be to leave the time relationships to the designer, who should know which would be dependent upon which. This is done by making a provision for the designer to designate which inputs will be handled by its input signals, from their conditions immediately “before the designated event” such as “rising clock”. In this case, all the designated inputs would be stored as they appear before the “event”, then when the event occurs, these stored values would be used - - effectively emulating concurrency. This solves the problem of all concurrent events, including “loop conditions” and branches.

KLM

[admin]

Your approach is exactly how it happens now. Designer connects clock signals to clock input of each flip-flop synchronizing them and letting previous changes propagate to outputs before the next clock signal comes. When the next clock comes all the outputs already settled to their stable state and so the inputs they are connected are ready to receive next state at the forward or rear front of the clock signal.
This is exactly how it happens in the real circuits.