Errata: @27:31 and @28:12: There are two (bad :) mistakes on Slide 14 1) (around time 27:31). The assignment to "count_en" is just plain wrong (thanks @juanjosemontessalinero3193 for correcting me on this - twice!). The assignment should, of course, be: assign count_en = (state == CNTUP) | (state == CNTDN); 2) (around time 28:12). The assignments to "next_count" should, of course, be blocking (=) and not non-blocking (
does RTL also stand for register transfer level other than just register transfer logic. Also where is that diagram from the one next to Reminder: What is RTL? with next_a and clk in it 1:39 P.S i'm only 19 and am just curious
@@redditstories2836 Sorry for the late reply (I only get new comments highlighted, so I missed this one as it was a reply to a comment). Yes, I guess the L in RTL should more accurately be "Level", but the meaning is the same. Anyway, it's probably one of the worst acronyms I know. I mean, the word "RTL" is great, but does anyone know what "Register-Transfer Level" means? Okay, I do explain the meaning in various lectures, but it took me years to actually comprehend the meaning of this phrase. "Synthesizeable HDL" is a much better name for this type of programming :)
In time 28:01, when you are showing the counter design. I think you don't need the count_en signal. you are already creating an external enable, saying that next_count = count if the state is not equal to CNTUP or CNTDN. Therefore, count is going to feedback to next_count when you are not in those states, and next_count is not going to change, so the signal count_en is redundant. I guess the synthetizer will mix both enables into one.
Yes, from a quick look, this indeed looks to be true. That said, the count_en helps gate the flip flops, which could potentially save power. Automatic clock gating should take care of this in any case, but this will explicitly make the synthesizer use an enable flop and/or apply the clock gating. Though most likely this will happen anyway. Good point! Thanks for noticing.
Hello Professor Adi, Thank you so much for posting such knowledgeful videos. I'm very much a beginner in the RTL, so could you suggest some resource where I can learn this more and expand my knowledge.
Hi Padmaj, Did you watch the lecture on Verilog (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-XfUOa2wudTs.html)? I think that is the place to start (well before watching this "more advanced" video). And after you've seen it and started to get your hands dirty, I think that Google is really a great resource for this, since many people have written great stuff, from tutorials to example code. Good luck!
I don't comprehend the expression assign count_en = (state == (CNTUP | CNTDN)) , as I see it you are only enabling the counter if the state is equal to the oring of both CNTUP and CNTDN. I think that is not the intended funcionality. I would do assign count_en = (state == CNTUP) | (state == CNTDN).
Hi Juan, You must pay attention to the entire command, since this is the so-called "ternary operator", which is basically a one-line "if-else" command. The command is asking: "If (the state is either CNTUP or CNTDN), then enable the counter, otherwise don't enable the counter" How? Because the condition is (state==(CNTUP|CNTDN)) --> This will return a '1' if we are in either of those states. If the condition is met, we return the statement that comes after the ?, in other words, return a '1'. Else (both CNTUP and CNTDN are zero), then we return the statement that comes after the :, in other words, return a '0'.
Hi Adi, thanks for answering. Sorry, but I believe that is not correct. You are first oring CNTUP and CNTDN and only then, you are comparing with state. For example CNTUP == 2'b01 and CNTDN = 2'b10, count_en only will be 1'b1 if state is equal to 2'b11, and the rest of the cases will be 1'b0.@@AdiTeman Moreover ,why would you use a mux with the ternary operator, instead of using directly the output of the comparator?
@@juanjosemontessalinero3193 Indeed, you are 100% right. I guess I answered your comment too hastily (and I wrote the slide without verifying it :). I have "an excuse", which is that I haven't looked at this slide for a long time :). I guess I read your comment wrong and thought you misunderstood something else and I was actually sure that this was from the code I have run many times in lectures. But following this comment, I see that you perfectly understood what you were writing and that this "fix" (...stick in the wheel...) was something I just "threw on the slide", while preparing this slide deck and not something I changed in the actual code and ran. It should, of course, be exactly as you suggested: assign count_en = (state == CNTUP) | (state == CNTDN); I will put this in the pinned errata. Thanks and sorry for my incorrect answer (and underestimating you!).
Thanks for the honest response.@@AdiTeman This lectures are a great help for all of us. I just wanted to confirm my understanding was right and help others to understand it. Thanks for your dedication and for you honesty. Kind regards!
Hello Professor, this lecture is wonderful and I think I learned a lot. I just have one doubt, in slide 14 "fixing the example from lecture". I prefer your bottom verilog coding style. However, I am not sure that under always @*, why we need to do next_count
Hi Yuhan, Indeed, this is a mistake in the slide that was actually already pointed out in the comments a while ago, and I forgot to pin a comment pointing the correction (I actually wanted to fix the video, but found out the RU-vid doesn't provide online tools, and I haven't had time to actually cut and reupload a fixed version). I have now added the pinned comment. (Just to clarify the nature of the mistake - I copied this code block from the original lecture and didn't fully edit/fix it. Of course, this is one of the things I am trying to emphasize in the lecture, so this was a pretty bad mistake on my part!) By the way, regarding your coding style - it is, of course, fine, but I prefer the coding style that I teach in the lecture. In other words, use an always@posedge for flip flop description and use an always@* for next_state calculation. I do not know if the synthesizer will ultimately provide the same output, but a direct mapping requires a more complex mux for your style (3 options vs. 2) and the direct instantiation of the flip flop may give the synthesizer trouble in application of automatic clock gating. In my opinion, this style is less "reader friendly", as well, but that is just a personal preference. In any case, I would hope that the synthesizer would fully optimize either option, but this is worth checking out.
Prof. I had an idea listening to you but don’t know if it’s good design practice. @28:35 is it right to directly code the IF ELSE block in always@* into the CASE block of the Next State Decoder logic? Secondly, if my suggestion above is okay it would mean two up counters and two down counter for cases CNTUP and CNTDN. But I could optimize this by performing resource sharing within the cases CNTUP and CNTDN, if I replace the counters with multiplexers then I could use one up counter and one down counter outside the case statement.
If I understand what you are asking then here is my answer. First of all, there are many ways to right the same thing, and as long as they are synthesizeable and functionally correct, then there's no problem to do it. Which way is best? Well, that depends, of course, and the way to find out would be to implement it and measure your metric (such as area, performance, power, etc.). That being said, I don't think there is much of a difference between what you are suggesting and the presented code. They would probably be Boolean equivalent and then the synthesis tool will hopefully find the best gate level representation. The main question is one of clarity. Which one is easier to read, maintain, verify, fix bugs. I like "wasting lines of code" to separate different parts and therefore make things a bit more simple and discrete. But you could put the "next_count" signal in the same CASE as the "next_state" signal and in some cases, or for some people, this would be a clearer solution.
The diagram at 13:24 showing the finish signal at latch shouldn't it have been start because the latch will enable at start state and the output remains the previous output.
Yes, I think you're right. Actually, this isn't a great diagram, since basically finished can only be a '1'. Only at startup (or reset...), we don't know what finished was previously and then it should hold the previous output, but this should really provide an 'X' as this is a clear error. But I think that you are correct, my diagram should have driven the latch enable with "state==START"
Just a quick question. @28:35 in the sequential block we don't have an 'else' statement. Are we intentionally inferring a latch here to hold the count value? or do we have to specify an else statement ?? Can you please clarify. Thank you.
Hi Vevasam, No, the problem of "latch inference" is related to combinatorial blocks. In other words, we don't want to accidentally infer a register (usually latch) when we are describing a combinatorial cloud. In this case, as you stated, we are talking about a sequential block, so the "no if without else" rule is not applicable. What we are describing here is a "async reset, load enabled DFF". In other words: - If there is a reset at any time - store the reset value - If there is not a reset then if there is a clock edge, store the D value if and only if the load enable is active What happens if the load enable is inactive? (i.e., what happens on the "else" condition that is not explicitly defined in the code?). Nothing. And nothing means "don't change the value" or "continue storing the previous value". In other words, "retain state" or "infer a register". This is a sequential block so that is exactly what we wanted. And in this case, there should be a standard cell that maps exactly to this description, so all is well.
Hi, I do not cover the practical use or the method of operation of logic simulators in the course. In fact, I don't cover any practical usage of tools. Possibly in the future, I will develop such content in collaboration with one or more of the EDA vendors.
