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:
enum SignalFmt {
Unsigned(u8), // u8 {1,2,4}
Signed(u8), // u8 {1,2,4}
Hex(u8), // u8 {1,2,4}
Bool, // treats it as true/false
Binary(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:
enum SignalSize {
B, // byte
H, // halfword
W, // word
D, // double word
}
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:
enum SignalFmt {
U8,
U16,
U32,
I8,
I16,
I32,
HexU8,
HexU16,
HexU32,
Bool, // treats it as true/false
Binary(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.
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 theBinary
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.