Hex Digit Display: Improve visualisation of High-Z input value

[edson-acordi]

Doing some tests with Hex digit display, I noted that if the data (4 bit) is in High-Z, display shows "H" instead of stay in adjusted "Off Color". It would be good if the Hex digit display works like the 7-segment display. Moreover, it would be nice to have the option "Active On High?" as the 7-segment display has.

[edson-acordi]

It is ok with the display showing "H". But the documentation explains that a floating or error signal, will display a dash ('-') instead of "H".

[maehne]

@edson-acordi: If there is an inconsistency between the implementation and documentation, then please leave this issue open so that it can be fixed.

[edson-acordi]

Hi Maehne, issue reopened to be fixed! Thank you!

[maehne]

@BFH-ktt1, @kevinawalsh, and @mbaillif: I confirm the inconsistency reported by @edson-acordi between implementation and documentation of the Hex Digit Display component. I guess fixing it in the implementation is least effort, but maybe displaying "H" instead of "-" is preferable? For me, "-" means Don't Care, but under certain conditions it might be mistaken to be a minus sign in front of a value. However, this case might be less likely for use cases of the Hex Digit Display. Anyway, "H" might be also mistaken to signify "Hexadecimal".

What do you think?

[MarcinOrlowski]

What about adding "High-Z" configurable color and then display "H" using it? As I agree, showing "H" in On color is confusing.

[maehne]

Why not simply use U (unassigned) instead of H? This wouldn't be ambiguous and consistent with the value shown at a output port?

[MarcinOrlowski]

This is already configurable in "Simulation" as "Unknown value character", however I do not thing "Z" is doable w/o confusing with "2". Also "Unconnected color:" is there already too:

From other hand, Hi-Z is not unknown...

PS: mind editing the subject here too?

[maehne]

I changed the title and added back the Documentation tag to remind us that documentation needs to get adjusted, too. After all, for the moment there's a mismatch between documented and actual behaviour.

[MarcinOrlowski]

Not sure which one:

I think "u" looks more like intentional shape than "U" that can be confused with "broken" zero

[maehne]

Personally, I would prefer capital 'U', as it would be consistent with the value shown on the port and the representation of uninitialized value in VHDL. High-Z outputs of a tristate buffer don't drive the connected signal to any value. So, it remains unknown if not driven by a different source. However, I could also live with a lower-case 'u'.

@BFH-ktt1, @edson-acordi, @davidhutchens, all: What's your opinion?

[MarcinOrlowski]

Alternatively we can stay fully blank which is also fine and quite logical as there's no data to display anyway. In fact this is behavior I'd personally expect having such physical device.

[maehne]

@MarcinOrlowski: Indeed, this would also be a logical behaviour.

[MarcinOrlowski]

I made this behavior partially configurable (in code ATM:) and currently display stays blank (no segment lit) if there's no valid input. I also changed the shape shown if HD is fed with value outside 0-15 range. We had "-" shown previously which can be misleading. Now it will show this: