You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for making this project. I have it working on a DE0-Nano - Cyclone IV - EP4CE22F17C6.
I changed the following: I used IP_TOOL_NAME "ALTPLL" for the clock so I had it divide down the 50Mhz to 2.5Mhz.
The project worked fine. I noticed that in the "always @()" blocks you are using "<=". It is my understand that in an "always @()" block only "=" should be used (?). In fact, the reference (Cummings) you mentioned says:
"Guideline #3: When modeling combinational logic with an always block, use blocking assignments"
So, I when through all the code and mass changed the "<=" to "=" in those "always @(*)" blocks. The result is: it sounds the same.
Also, in controller.v, I placed a "coeff_out = 0;" in the "always @(*)" to prevent a latch warning.
The text was updated successfully, but these errors were encountered:
Thanks for making this project. I have it working on a DE0-Nano - Cyclone IV - EP4CE22F17C6.
I changed the following: I used IP_TOOL_NAME "ALTPLL" for the clock so I had it divide down the 50Mhz to 2.5Mhz.
The project worked fine. I noticed that in the "always @()" blocks you are using "<=". It is my understand that in an "always @()" block only "=" should be used (?). In fact, the reference (Cummings) you mentioned says:
"Guideline #3: When modeling combinational logic with an always block, use blocking assignments"
So, I when through all the code and mass changed the "<=" to "=" in those "always @(*)" blocks. The result is: it sounds the same.
Also, in controller.v, I placed a "coeff_out = 0;" in the "always @(*)" to prevent a latch warning.
The text was updated successfully, but these errors were encountered: