Closed jrbeaumont closed 7 years ago
Another potential benefit of this approach is that is allows to introduce other constructors:
data OrderConstraint a = AndCausality e e | OrCausality [e] e | TimingAssumption e e ...
In general, OrderConstraint
may be a better name, as it captures not only causality, but other things.
This is very true, if based on the type of a signal. It kills multiple birds with one stone
A question though. What about OR causality with timing assumption, for example, input a
or input b
transitioning high can cause input c
to transition high.
Is this feasible?
You could probably come up with such an example, but I don't think I came across something like this in practice.
That's what I was thinking. I don't think it's such a thing practically, it may be theoretically. In the event that such a timing assumption is found, we can add it in, but for now OR causality will cover it.
We have changed the causality representation again (#75). This issue may therefore be closable. However, it is still possible to refactor this representation into something that may include assumptions etc, but we can cross this bridge at a later date.
In summary, I suggest we close this issue.
Agree, let's close this for now.
Currently, we represent all arcs as
arcs = [([e],e)]
.AND causality is included in this list by using a single item list for the cause transitions, i.e.
OR causality is included using lists of transitions, i.e.
This is not the clearest of representations, so we should refactor. A suggestion is:
Here,
AndCausality
is simply the cause and effect transitions,OrCausality
is the list of possible causes for the effect. We can still use this with the Cartesian Product to produce a correct STG/FSM.