![]() This could aid you if the conditional statement for the count_in was rather complex. ![]() ![]() When you look at a sim, you can see what count_in looks like prior to the rising edge of the clk. Now you could see the same with the first bit of code, however IMO it's not as clear. I can easily see (as well as anyone else looking at the code) that I would expect a MUX for the reset or addition of count based on the reset_count_val, with a final MUX for gating the count based on the enable signal. I know that "count_in" is being setup prior to the posedge of clk. It does however split up the circuit in a way that allows me to easier see what happens on each clock edge. The above I would agree is more typing, and to some, more difficult to read. Or I would do this (which is what I would personally do): //Combinational PathĪssign count_in = enable ? ((count = reset_count_val) ? 4'd0 : count_in + 4'd1) : 4'd0 If((count = reset_count_val) || (~enable)) count <= 0 I could do this (which I tend to see from people who have a strong software and/or FPGA background) always clk or posedge reset) begin ![]() Say I have a counter that I want to reset on a certain value. It's hard for me to give a great example of something bad versus something I would call good, but here is a stab at it. This segregation usually aids in initial design, brain->rtl->synthesis (what you think you're making is actually what is synthesized), CDC evaluation for multiclock designs, verification, and other things as well. I generally will separate sequential and combinational as much as possible until it results in too much code (which is usually rare, and possibly an indication of a poor design), or when something just makes more sense (which again is rare, but happens). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |