Honored ContributorI'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?
Honored Contributorin the second case you are inverting clock through combinatorial path.
This is no good forFPGAs, may be used in ASIC designHonored ContributorHello 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 youHonored ContributorIn 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|0I 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.Honored ContributorThanks all for the responses.
Honored ContributorHonored ContributorYes 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.
Honored Contributori 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
Honored ContributorSome previous threads related to the glitch problem:
http://www.alteraforum.com/forum/showthread.php?p=7144 http://www.alteraforum.com/forum/showthread.php?t=26151Honored ContributorI 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.
