Hi Everyone and thanks for checking out my new video! I'm really happy with this one! Phew! It has taken a month of prep and 3 recording attempts to get it exactly as I like it, but now I can happily say I've distilled my favourite state machine (and surrounding topics) into 30 min! Hope you enjoy!
Stacey, I just discovered your channel. It is full of incredibly good tips for writing clean HDL. This lesson in particular is pure gold. I'll highly recommend this channel with everyone I know (everyone that programs FPGA of course 😆)
Computations in always_comb blocks only consume power if the incoming data changes. Remember what it is: it is just a cloud of combinational gates. There is no activity unless the input to that changes. Thus, what really causes the power consumption is when there is an assignment in a clocked block (always_ff ). When that happens, then the contents of the flip flops might change and the downstream combinational logic will change. Does that make sense?
@@guest7329 If the updated value is being stored, then yes, that would consume a bit more power because this would cause the counter to keep counting. Remember these are electronic circuits. What eats power is switching from 0 to 1 or 1 to 0. If there was an if() or something else preventing the value from updating that would prevent this. However, the if() circuit would add more gates which might defeat the purpose. For something as small as this I would not worry, but changing large amounts of state often can be a worry.
Theoretically it would, but it would be negligible when looking at the design as a whole. If coding specifically for power usage (at the detriment of area, etc), it would be possible to add a gate on the counter that only counts in certain states. I usually try to size the counter appropriately (so that it is not unnecessarily big) to minimise resources. However I find that this design is particularly human-friendly, and that positive outweighs the negligible increase in power usage.
Hi, I don't use verilog much anymore. The only case would be if a client specifically requests it. For example if they have an existing module that needs to be modified and they want it to remain verilog.
@@hansktube I started consulting because I wanted to travel and work at the same time. I started consulting with 3 years of experience, which looking back probably wasn't enough. I started working on odesk (previously called upwork) doing small VHDL jobs, and worked my way up from there. Upwork isn't what it used to be, although I have still recently met some good clients on there. It's generally still ok to find clients on upwork for FPGA design because it's very difficult to fake FPGA skills, and the skills are still in demand. There are other websites too
My favorite statemachine is synchronous and not pseudo synchronous like your statemachine. The synthesized result is mostly the same, but one extra clock cycle per state. It’s my preferred method.
@@productivemonk5261 could be, but I also prefer multiple blocks. This separates the state change logic from the decision-making and output control. As Stacey says, this is way easier to understand (for others or yourself trying to remember what you did 6 months later). But, hey, if you have a different approach that works for you then go for it.
@@mn1233 Not sure what you mean by concurrency. Ultimately one/many is a style choice, so to objectively say many is better than one is difficult. Although the cliff cummings paper makes a good argument. Ultimately it is the designers choice. My goal with this video is to lay out why I choose many, and this style has served me well over the years.
@@mn1233 Separate islands creates parallel logic, hopefully all on the same clock. If asynchronous blocks you run risk of glitching and runts. Not good. It’s best to keep everything synchronized on one clock, for me it’s best to have everything centralized in one block (islands) so I don’t have to search around in another block. Harder to keep track of that way. Just my opinion. One place for one function. Never split functionality into separate blocks, makes it very hard for maintenance.
Hi Everyone and thanks for checking out my new video! I'm really happy with this one! Phew! It has taken a month of prep and 3 recording attempts to get it exactly as I like it, but now I can happily say I've distilled my favourite state machine (and surrounding topics) into 30 min! Hope you enjoy!
Stacey, I just discovered your channel. It is full of incredibly good tips for writing clean HDL. This lesson in particular is pure gold. I'll highly recommend this channel with everyone I know (everyone that programs FPGA of course 😆)
I came across your channel through Reddit so cool to see youre still active thanks for posting
Thanks for sharing. Loved your state_counter smart way of getting sequentiality into the combinational blocks.
Everyone should have a favorite state machine!
Thanks Stacey, educational as always.
Thanks Charles :)
Thank you Stacey! great video and I love the cliff cummings paper, sunburst papers for FIFO design and CDC are good too......😁
Amazing work as usual, thank u for the great effort 😊
I'm so happy to have found this channel! Thanks for your content!
As a colleague engineer I love your content
This video was so freaking good it was so clear and to the point thanks for this
amazing videos
Almost 10k subs. Catching fire!
Hello! Thanks for the video! Wouldn't be interested to do a video about ADC, FMC and how to use them? Thanks!
Great tutorial😊
does state_counter consume more energy because of state transitions (for counter value itself) for states that don't use it?
Computations in always_comb blocks only consume power if the incoming data changes.
Remember what it is: it is just a cloud of combinational gates. There is no activity unless the input to that changes.
Thus, what really causes the power consumption is when there is an assignment in a clocked block (always_ff ). When that happens, then the contents of the flip flops might change and the downstream combinational logic will change.
Does that make sense?
@@cccmmm1234 I meant "latching new values into counter register" in states where it not used
@@guest7329 If the updated value is being stored, then yes, that would consume a bit more power because this would cause the counter to keep counting.
Remember these are electronic circuits. What eats power is switching from 0 to 1 or 1 to 0.
If there was an if() or something else preventing the value from updating that would prevent this. However, the if() circuit would add more gates which might defeat the purpose.
For something as small as this I would not worry, but changing large amounts of state often can be a worry.
Theoretically it would, but it would be negligible when looking at the design as a whole. If coding specifically for power usage (at the detriment of area, etc), it would be possible to add a gate on the counter that only counts in certain states. I usually try to size the counter appropriately (so that it is not unnecessarily big) to minimise resources.
However I find that this design is particularly human-friendly, and that positive outweighs the negligible increase in power usage.
Hi Stacey.
I see you are using System Verilog here. Do you still use old-school verilog too? If so, when?
Hi, I don't use verilog much anymore. The only case would be if a client specifically requests it. For example if they have an existing module that needs to be modified and they want it to remain verilog.
@@FPGAsforBeginners Thanks.
@FPGAsforBeginners How did you become a consultant? It would be interesting to see a video with tips on how to get started as a consultant.
@@hansktube I started consulting because I wanted to travel and work at the same time. I started consulting with 3 years of experience, which looking back probably wasn't enough. I started working on odesk (previously called upwork) doing small VHDL jobs, and worked my way up from there. Upwork isn't what it used to be, although I have still recently met some good clients on there. It's generally still ok to find clients on upwork for FPGA design because it's very difficult to fake FPGA skills, and the skills are still in demand. There are other websites too
My favorite statemachine is synchronous and not pseudo synchronous like your statemachine. The synthesized result is mostly the same, but one extra clock cycle per state. It’s my preferred method.
Could be combined into one synchronous always block, don’t need three blocks.
@FpgasForBeginners - can you comment on concurrency of your islands?
@@productivemonk5261 could be, but I also prefer multiple blocks.
This separates the state change logic from the decision-making and output control. As Stacey says, this is way easier to understand (for others or yourself trying to remember what you did 6 months later).
But, hey, if you have a different approach that works for you then go for it.
@@mn1233 Not sure what you mean by concurrency. Ultimately one/many is a style choice, so to objectively say many is better than one is difficult. Although the cliff cummings paper makes a good argument. Ultimately it is the designers choice. My goal with this video is to lay out why I choose many, and this style has served me well over the years.
@@mn1233 Separate islands creates parallel logic, hopefully all on the same clock. If asynchronous blocks you run risk of glitching and runts. Not good. It’s best to keep everything synchronized on one clock, for me it’s best to have everything centralized in one block (islands) so I don’t have to search around in another block. Harder to keep track of that way. Just my opinion. One place for one function. Never split functionality into separate blocks, makes it very hard for maintenance.