Replies: 2 comments
-
The comment was added by @nanavati , when the If we do try to tackle this, It's worth noting that method attributes are more complicated than rule attributes here. For a module with Rule attributes like |
Beta Was this translation helpful? Give feedback.
-
Thanks for the info, this is very helpful! It sounds like there is a lot of nuance and edge cases here that need to be handled carefully. |
Beta Was this translation helpful? Give feedback.
-
It seems that using
(* no_implicit_conditions *)
on a rule in a module with a gated clock:Fails to compile, since the gate on the clock is considered an implicit condition.
Similarly, the testsuite/bsc.codegen/rdy_en_pragmas/Test_AlwaysEnabled.bsv test fails (without using
-unsafe-always-ready
because the clock gate breaks the(* always_enabled *)
.I noticed in testsuite/bsc.codegen/rdy_en_pragmas/rdy_en_pragmas.exp a comment for Test_AlwaysEnabled.bsv saying:
I am not sure who wrote that (It seems that it was added pre-github), but I was wondering if anyone here had more information about what "
fix clock gating
" means in this context?My code relies heavily on
no_implicit_conditions
&always_enabled
(and other pragmas) as a sort of safety-net to prevent me from introducing unintended implicit conditions.Assuming @nanavati were to add support in classic for the clock gating pargmas like
gate_input_clocks
andclock_ancestors
(See #616), It seems that I would still need to give up onno_implicit_conditions
andalways_enabled
in my code.I was wondering if maybe "
fix clock gating
" had anything to do with makingno_implicit_conditions
into "no implicit conditions other than the clock gate" andalways_enabled
intoenabled when the clock gate is enabled
? Or is there some other "fix" being described?Beta Was this translation helpful? Give feedback.
All reactions