Ok, but any idea on how to turn off those warnings selectively? Right now, I get thousands of warnings, a tiny fraction of which ARE relevant. Since I do care about glitches on output pins (or on clock or async reset nets), I don't want to turn off all glitch warnings. Sean On Dec 18, 2007 11:25 PM, Herbert Graf wrote: > On Tue, 2007-12-18 at 14:41 -0500, Sean Breheny wrote: > > I already posted it to comp.lang.vhdl, with no responses yet. I'll try > > comp.arch.vhdl, too. Thanks. > > > > I have now tried a whole slew of different ways of doing it and they > > all result in a large number of glitch warnings. These warnings are > > actually on internal nodes (not the outputs). I'm beginning to think > > that these are needless warnings. I.e., of course there will be > > glitches on internal nodes since not all delays are matched, but that > > is OK. > > I was just about to say the same thing. > > It's perfectly normal in a synchronous design for the combinational > chunks to have "glitches". Every route and element has a slightly > different delay, so the output of a chunk of combinational logic will > "glitch" until everything reaches the "other side". > > This is nothing to worry about as long as the longest combinational > delay is no faster then your clock (minus of course setup times for the > synchronous elements). This is where the tools derive the "max speed" > number they deliver after finishing P&R. > > There are ways to "lessen" these issues, mostly in an effort to give > faster speeds. For example most synthesizers will reencode things like > state machines to take advantage of faster structures, i.e. grey coding, > or one hot coding. At 1MHz, you have nothing to worry about though. > > TTYL > -- > > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist