Support signal splitting

[alexforencich]

In the case where multiple drivers and/or monitors need to be connected to different parts of the same signal or set of signals in a bus, it is necessary to support splitting signals in some way.

The main use-case for this is modules with parametrized port counts that use concatenated ports, for example in https://github.com/alexforencich/verilog-axis/blob/master/rtl/axis_switch.v where multiple input and output ports are all concatenated together and share the same top-level ports, like so:

input  wire [S_COUNT*DATA_WIDTH-1:0] s_axis_tdata,
input  wire [S_COUNT*KEEP_WIDTH-1:0] s_axis_tkeep,
input  wire [S_COUNT-1:0]            s_axis_tvalid,
output wire [S_COUNT-1:0]            s_axis_tready,
input  wire [S_COUNT-1:0]            s_axis_tlast,
input  wire [S_COUNT*ID_WIDTH-1:0]   s_axis_tid,
input  wire [S_COUNT*DEST_WIDTH-1:0] s_axis_tdest,
input  wire [S_COUNT*USER_WIDTH-1:0] s_axis_tuser,

In this case, it is necessary to connect S_COUNT AXI stream source modules to the same set of pins. Currently, cocotb permits selecting individual bits, but not blocks of bits, and only on some simulators.

I think there are perhaps two different ways to go about implementing this. One way is to support slice indexing on the signals themselves. But even selecting individual bits is currently rather simulator-dependent, so this might not be a good general solution. Another way is to implement some sort of SplitSignal helper object that provides several internal signal objects that can be connected to different simulation components, appropriately managing the flow of read and write data. In this case, reads of the internal signals can be translated into full-width reads on the original signal, and writes can perhaps be implemented as read-modify-write or similar. And then there can also be a SplitBus object or helper method that can match signals in the same way as a Bus object, but then produce one Bus object or similar for each of the concatenated ports.

[ktbarrett]

Another way is to implement some sort of SplitSignal helper object that provides several internal signal objects that can be connected to different simulation components, appropriately managing the flow of read and write data. In this case, reads of the internal signals can be translated into full-width reads on the original signal, and writes can perhaps be implemented as read-modify-write or similar.

This is the only path forward. The VPI/VHPI/FLI do not have any concept of slices. We could support slices at either the Python or the C++ level. Care would have to be taken of value change triggers as well.

[aroshanineshat]

@alexforencich I am implementing such functionality for ADC SSR buses. I wonder if you ended up writing such helper or there is any changes in Cocotb to support it?

[imphil]

No changes in cocotb have happened that would support such "virtual" sliced signals. But it looks to me like a desirable feature, so we're open for pull requests implementing that!

[alexforencich]

TBH, I think doing this properly may require some deeper adjustments in the cocotb object model.

Main thing that is necessary is the ability to create objects that are interchangeable with the simulation handle and hierarchy objects.

Being able to build up a new set of signals such that it can be handed off to a simulation model in place of a hierarchy object would be incredibly useful. This would effectively replace the Bus object in cocotb-bus, as you can simply build up a new hierarchy containing renamed/adjusted/virtual signals and hand this off transparently in place of a hierarchy object. Helper methods can easily be implemented to handle prefixes, indexes, splits/slices, etc. Not sure if doing this would need a common base class or other modifications, but the key point is that accessing signals and other components would use exactly the same semantics as proper simulation handles, at least for high-level python code.

Second is the ability to create virtual signals that exist only in cocotb, which are transparently interchangeable with simulation handles - the value can be set/read the same way, RisingEdge/FallingEdge work as expected, etc. Similar to how you might need to create some wires in the testbench to facilitate connections here and there. These virtual wires can be completely independent of the simulator, or they can drive/be driven by (potentially portions of) simulator signals.

With these couple of changes, it would be possible to create a "virtual" hierarchy object, containing "virtual" signals that mirror portions of the original signals. A simple helper function could automate this, returning a list of these "virtual" hierarchy objects. Then these "virtual" hierarchy objects could be passed to BFMs, as if they were simulation handles directly.

Now, I suppose another question is, how deep should this go? Should this be limited to python, or should this extend down to GPI such that things like GPI clocks and GPI BFMs can handle things? At some point, I want to investigate moving some of my AXI BFMs into GPI as this may make things more efficient, so if the split/virtual signals only work from Python then that would be a problem.