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
As of now there is no defined way to determine the preferred formatting of Signals e.g., when displayed in a tooltip, or by the popup hover.
Potential solution.
We could define an enum:
enumSignalFmt{Unsigned(u8),// u8 {1,2,4}Signed(u8),// u8 {1,2,4}Hex(u8),// u8 {1,2,4} Bool,// treats it as true/falseBinary(Vec<(u8),Id)>)// u8 is the number of bits for each field, where Id is a string for the field name}
Then we can implement a helper that takes a Signal, and a SignalFmt and formats the signal accordingly.
Maybe the Binary is a bit OTT, and would likely take a lot of space, and would not align well in a table with the other formats, which are all compact.
In the model we associate each output to a SignalFmt.
Alternatively instead of the u8, we can have it structured:
But that sort of restricts to 32 bit architectures (though D could be used to express 64 bits, but signal is currently fixed to 32 bits in any case ...).
Another potential structure is to go with:
enumSignalFmt{U8,U16,U32,I8,I16,I32,HexU8,HexU16,HexU32,Bool,// treats it as true/falseBinary(u8)// just to set a limit to the number of bits}
Signals that have very specific implementation, like the register numbers 0..31 in MIPS will require side stepping this formatting, so its up to the component to use this extra info or not (when creating the popup/tooltip and internal View).
Any thoughts on this. We can discuss here in the issue and/or on discord.
The text was updated successfully, but these errors were encountered:
Problem.
As of now there is no defined way to determine the preferred formatting of
Signal
s e.g., when displayed in a tooltip, or by the popup hover.Potential solution.
We could define an enum:
Then we can implement a helper that takes a
Signal
, and aSignalFm
t and formats the signal accordingly.Maybe the
Binary
is a bit OTT, and would likely take a lot of space, and would not align well in a table with the other formats, which are all compact.In the model we associate each output to a
SignalFmt
.Alternatively instead of the
u8
, we can have it structured:But that sort of restricts to 32 bit architectures (though D could be used to express 64 bits, but signal is currently fixed to 32 bits in any case ...).
Another potential structure is to go with:
Signals that have very specific implementation, like the register numbers 0..31 in MIPS will require side stepping this formatting, so its up to the component to use this extra info or not (when creating the popup/tooltip and internal View).
Any thoughts on this. We can discuss here in the issue and/or on discord.
The text was updated successfully, but these errors were encountered: