On Tue, Jan 19, 2010 at 10:42 PM, Lee Pike
Tom,
Is this a bug? The following program compiles, but the rule is scheduled at period 1 (rather than 0). I wouldn't have thought to have an assignment outside of an atom until another engineer here wrote it. In any event, I would have expected that the rule should have period 3.
Lee
example :: Atom () example = period 3 $ do
a <- word32 "a" 0
a <== 21
The top-most rule is implied with the compile command. This makes it appear as if the assignment doesn't belong to a rule, when if fact it belongs to the implicit top level rule. The top level rule always has a period of 1. Period constraints are only applied to sub-rules, not the current rule. This prevents ambiguous situations, such as: atom "something" $ do period 1 (a <== 1) -- Does 'something' execute every 1 or ... period 2 (b <== 2) -- 2 cycles? So in your example, 'period 3' has no sub rules that it applies to. -Tom
Tom, Ah, right.
The top-most rule is implied with the compile command. This makes it appear as if the assignment doesn't belong to a rule, when if fact it belongs to the implicit top level rule. The top level rule always has a period of 1.
Period constraints are only applied to sub-rules, not the current rule.
So to get the behavior I was expecting, I can name everything explicitly. Then the assignment will inherit the period:
example :: Atom () -- example = period 3 $ do example = period 3 $ atom "ex" $ do
a <- word32 "a" 0
a <== 21
Lee
participants (2)
-
Lee Pike -
Tom Hawkins