Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for 'may-fire' semantics #86

Open
snowleopard opened this issue Aug 18, 2017 · 2 comments
Open

Add support for 'may-fire' semantics #86

snowleopard opened this issue Aug 18, 2017 · 2 comments

Comments

@snowleopard
Copy link
Member

As discussed in #83:

I attached the most permissive state graph for srHalfLatch. Here pink arcs have the 'may-fire' semantics for outputs, while the usual black ones correspond to usual 'must-fire' semantics.

The idea is that in states 100 and 011 the circuit must eventually do q+ and q- transitions, respectively. On the other hand, in states 110 and 111 the circuit may switch q but doesn't necessarily have to. If we remove the pink arcs, then we get @jrbeaumont's spec for srHalfLatch. If we forbid states 110 and 111 by restricting the environment we get my spec.

Unfortunately, without pink/may arcs we cannot have a fully permissive specification.

srhalflatch

Can we add support for may-fire semantics to Plato?

@snowleopard
Copy link
Member Author

snowleopard commented Aug 18, 2017

Note that there is a simple monoid on 'no/may/must` arcs:

data Dependency = No | May | Must deriving (Eq, Ord)

instance Monoid Dependency where
    mempty  = No
    mappend = max

That is, May combined with Must gives us Must, and No is the identity.

This means that one can start with a very permissive concept specification and later add a few Must dependencies in the environment that fully resolve the ambiguity leading to purely Must-ful specifications.

@snowleopard
Copy link
Member Author

snowleopard commented Aug 18, 2017

For another example of a circuit with 'may' dependencies is the WAIT element, see Figure 4 here:

http://homepages.cs.ncl.ac.uk/victor.khomenko/papers/waitx.pdf

Note that it is called 'optional' in the paper. Maybe this is a better term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant