search

tuura / plato

A DSL for asynchronous circuits specification
Other
12 stars 2 forks source link

Refactor arc representation so AND and OR causality are more obvious. #69

Closed jrbeaumont closed 7 years ago

jrbeaumont commented 7 years ago

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. 

rise a ~> rise b = ([a+], b+)

OR causality is included using lists of transitions, i.e.

[rise a,  rise b] ~> rise c = ([a+, b+], c+)

This is not the clearest of representations, so we should refactor. A suggestion is:

arcs :: [Causality e]
data Causality e = AndCausality e e | OrCausality [e] e.

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.

snowleopard commented 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.

jrbeaumont commented 7 years ago

This is very true, if based on the type of a signal. It kills multiple birds with one stone

jrbeaumont commented 7 years ago

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?

snowleopard commented 7 years ago

You could probably come up with such an example, but I don't think I came across something like this in practice.

jrbeaumont commented 7 years ago

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.

jrbeaumont commented 7 years ago

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.

snowleopard commented 7 years ago

Agree, let's close this for now.