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
In the code for the Bitmapped Digits example, in the line where the green color is assigned
wire g = display_on && bits[xofs ^ 3'b111];
some of the values of the expression xofs ^ 3'b111 go out of the bounds of bits. This is because bits has a size of 5 bits and xofs ranges from 0 through 7. The result is the values of the last three indices are treated as 0, and are used to put some space between the various numbers. As far as I know, from Verilog's semantic, this is not the correct behavior. In fact if a value grater than 4, in place of xofs ^ 3'b111, is hard coded the editor complains.
I was wandering how is it possible that the code works as is? I think that it deserves a better explanation.
The text was updated successfully, but these errors were encountered:
In the code for the Bitmapped Digits example, in the line where the green color is assigned
some of the values of the expression
xofs ^ 3'b111
go out of the bounds ofbits
. This is becausebits
has a size of 5 bits andxofs
ranges from 0 through 7. The result is the values of the last three indices are treated as 0, and are used to put some space between the various numbers. As far as I know, from Verilog's semantic, this is not the correct behavior. In fact if a value grater than 4, in place ofxofs ^ 3'b111
, is hard coded the editor complains.I was wandering how is it possible that the code works as is? I think that it deserves a better explanation.
The text was updated successfully, but these errors were encountered: