-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Factor out resource "sevenseg". #17
Comments
BTW 7-segment displays are a common learning exercise for beginner HDL coders. It would be good to have good support for them and to not make it too easy.... |
I'm assuming we've left the realm of "not make it too easy" for beginners once |
Logical high means LED is lit.
Optional, the downstream code can check it with
The enable signal is called
Yes. |
With the expectation that "display_9seg", "display_14seg" and "display_16seg" will be forthcoming. There are no provisions in this resource itself for multiplexing the display. It is expected that on boards with multiplexed displays, an additional resource "display_7seg_ctrl" will be provided, and it would have either an n-bit signal "sel" (binary encoded) or an n-bit signal "en" (one-hot encoded). (This may be revisited in the future.) Fixes #17.
Differences between various 7SDs:
0
controls one digit, and1
controls the other seems morecommon when only two digits are present (fairly common setup). Otherwise, one-hot is used.
Potential
Subsignal
naming scheme:a
,b
, ...g
,dp
for decimal point (if present)en{0, 1, 2}
en
be handled in naming. Should there be a difference?Boards using it right now
None! But Mercury will (for the baseboard peripheral that is normally attached to it), and in omigen, the naming scheme was inconsistent. So I want to fix this before it becomes a problem.
The text was updated successfully, but these errors were encountered: