@posedge vs @negedge

[Altera_Forum]

I'm looking over some demo code, trying to teach myself Verilog. At one place I see: 

 always@(posedge CLK)  and elsewhere I find:  assign CLK_n = ~CLK; always@(negedge CLK_n)  It would seem to me that the later is an oddly complicated way to say the same as the former. I assume I'm missing something here and there's an excellent reason for doing it this way. Can someone enlighten me?

[Altera_Forum]

in the second case you are inverting clock through combinatorial path. 

This is no good forFPGAs, may be used in ASIC design

[Altera_Forum]

Hello Kaz.. 

 I believe in the second case, an explicit inverter gate will get placed after the clock source to generate the inverted clock? And this, depending on the frequency of the clock and the propagation delay through the gate could be a problem right?  But I do not see a reason why should it be good for ASICs as well. Perhaps if you could enlighten us as to what makes it bad design for FPGAs and will do for ASICs it would be great ..  Keen to hear from you

[Altera_Forum]

In the latter case the two inverters will probably be optimized away anyway so we come back to the first set up. I agree it's just a more complicated way of saying the same thing. 

 Now for the combinatorial clock problem: the main problem is that FPGAs don't use gates, but look up tables. When you do an inverter, inside the FPGA you will use one input and one output from one LUT to perform the function. The rest of the LUT isn't used, but for optimization reasons, the mapper/fitter may decide to add another logic function in the same LUT, using other inputs and outputs. Lets say the LUT is now used to do two inverters. The LUT's truth table is rather simple: A|B||X|Y -+-++-+- 0|0||1|1 0|1||1|0 1|0||0|1 1|1||0|0 Now lets say A is your clock signal, and B is something different. If B changes, then X, the inverted A, is supposed to stay the same. But in practise, as you are switching the LUT from one state to the other, during the transition all the LUT outputs can temporarily take any value, before the LUT stabilizes to it's new state. This isn't a problem with regular registers, as those glitches happen outside clock edges. But for a clock signal, if you have a glitch on the X output after a change on B, this glitch could be seen as a clock edge for some registers, causing lots of trouble in the design. You don't have this problem with ASICs because when you want to invert a signal... you use an inverter ;)

[Altera_Forum]

I generally agree about the glitch problems of LUT. In the special case, I'm not clear which specific FPGA family your example is referring to. The two LUT outputs scenario seems to apply to Stratix family. There LUT's are comprised of smaller 3 and 4 input blocks internally and there's no reason to assume, that input signals assigned to different inputs are interacting in the said way. As far as I remember, it's generally expecting that LUTs don't generate glitches with a single input changing. 

 It's also suggested to take a look at the real device hardware when discussing about clock inversion. Doing so reveals, that inversion of control signals, e.g. clocks, is a LAB-wide feature with all Altera FPGA families. Unless you are using constructs like gated clocks or clock dividers, LUTs never come in touch with the clock path.

[Altera_Forum]

Thanks all for the responses.

[Altera_Forum]

--- Quote Start ---  Hello Kaz..  I believe in the second case, an explicit inverter gate will get placed after the clock source to generate the inverted clock? And this, depending on the frequency of the clock and the propagation delay through the gate could be a problem right?  But I do not see a reason why should it be good for ASICs as well. Perhaps if you could enlighten us as to what makes it bad design for FPGAs and will do for ASICs it would be great ..  Keen to hear from you  --- Quote End ---    ASIC designers decide their own cells and routing, to them gating clock is "usual" practice. FPGAs have prefabricated dense routing and this means clock signal could get delayed in the routing mess. The remedy is that fpgas have their clock routing separate from anything else.  By the way many many ASIC engineers are losing their jobs and moving to fpga jobs but unfortunately there is some bias, they think fpga case is subset of the asic superset hence they join excited only to face serious difficulties.

[Altera_Forum]

Yes I may not have chosen the best example, trying to oversimplify it. As for the fact that there is no glitch when only one LUT input changes, it is indeed a generally accepted fact but I'm not sure it was ever said officially by Altera. IIRC only Xilinx told that, so I prefer not relying on it.

[Altera_Forum]

i think i've heard no glitch with 1 input changing from Altera officially. not sure if it was on the web or in an SR

[Altera_Forum]

Some previous threads related to the glitch problem: 

http://www.alteraforum.com/forum/showthread.php?p=7144 http://www.alteraforum.com/forum/showthread.php?t=26151

[Altera_Forum]

I actually did a search on the word "glitch" yesterday in Altera's knowledgebase and didn't find anything relevant. It seems that the two kdb entries you referred to in your first thread have since been removed by Altera. 

I'm not saying here there aren't conditions where you will never have glitches, I'm just saying it's hard to find an official guarantee from the manufacturer that it will always be that way on all FPGAs.

[Altera_Forum]

Yes, that's the same conclusion I came to about 4 years ago. I still think, that plausibility reasons suggest no glitches for a single changing LUT input.