> For always_comb, there is no need for any explicit flushing mechanism. > For complex processes with multiple activation points, those aren't synthesizable anyways, so your scenario of "average designers writing RTL code and adding checks as they write" won't even apply. > If those designers use always_comb, they will automatically get the benefit of implicit flushing. I see... So always_comb will have implicit flushing, but other use cases will probably be by expert users anyway. I guess that does make sense. > I agree with Gordon that we should try to add explicit checks right now, while the iron is hot. That will avoid potential incompatibilities in the future when we try to retrofit the functionality. Also, I think we should add the "finite time pulse reject" consideration to the proposal, for the same reasons. It seems like we are very close, and I advocate pushing through to the end to see what comes out. Can you remind me again what it is you are referring to by "finite time pulse reject"? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Oct 17 15:22:46 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 17 2007 - 15:24:13 PDT