Feature request - Support Creating groups/bus, unbounding bus
Subtasks:
Support unbounding: All bus (i.e., bit-vectors) should be able to expand or unbound to bits of that vector. The bits should be plotted below the original signal. I don't know which level should handle this. Should all bits of all bit-vectors be added to simDB, or can it be handled at the waveform-level? This is a typical CPU vs RAM problem. If we add all bit of all signals to simDB, it will require more than two times bigger RAM! This differs from the general virtual-bus because the radix is not relevant here.
Support signal group: Create a collapsable group. Using the groups, the signals remain distinct signals, but the user can collapse or hide them at once. This (signal groups) can be handled on waveform-level. It does not require touching the simDB.
Support virtual-bus: Signals can build up to a new signal, which will be shown as a new row in the waveform. (Eg.: If we have a 64-bit counter represented by two 32-bit variables, the two 32-bit variables should be concatenated to a 64-bit virtual bus.) This should be handled at the simDB level. This will result in that the radix handling of these virtual signals will be easy. Note that the path and hierarchy have no meaning here, while the "sub-signals" has to be referenced using virtual signals.
Support virtual-variables: Maybe a different feature: Add logical-combination of signals. Any combinational operation of any signals should be supported. Yes, this new virtual-variable should be added to simDB, not only to waveform. This is a more abstract virtual-bus.
I guess it would fall under virtual variables: have a way to display the differential voltage between two analog traces (e.g. in_p - in_n, or vdd - vss).
Feature request - Support Creating groups/bus, unbounding bus
Subtasks:
Support unbounding: All bus (i.e., bit-vectors) should be able to expand or unbound to bits of that vector. The bits should be plotted below the original signal. I don't know which level should handle this. Should all bits of all bit-vectors be added to simDB, or can it be handled at the waveform-level? This is a typical CPU vs RAM problem. If we add all bit of all signals to simDB, it will require more than two times bigger RAM! This differs from the general virtual-bus because the radix is not relevant here.
Support signal group: Create a collapsable group. Using the groups, the signals remain distinct signals, but the user can collapse or hide them at once. This (signal groups) can be handled on waveform-level. It does not require touching the simDB.
Support virtual-bus: Signals can build up to a new signal, which will be shown as a new row in the waveform. (Eg.: If we have a 64-bit counter represented by two 32-bit variables, the two 32-bit variables should be concatenated to a 64-bit virtual bus.) This should be handled at the simDB level. This will result in that the radix handling of these virtual signals will be easy. Note that the path and hierarchy have no meaning here, while the "sub-signals" has to be referenced using virtual signals.
Support virtual-variables: Maybe a different feature: Add logical-combination of signals. Any combinational operation of any signals should be supported. Yes, this new virtual-variable should be added to simDB, not only to waveform. This is a more abstract virtual-bus.