2

I am trying to setup Cocotb as my verification environment. I have been looking at the examples, that are useful, but I am not sure about direction I should go.

My block can be seen as:

  • 4 busses in input
  • 1 clock and 1 reset as inputs
  • 2 busses in output

The output are the result of a combinational and sequential processing of the input signals.

The part I lack to go further is how to define correctly monitor for my inputs and output busses, that are (as far as I understand) not compliant with AvalonST

I looked at the examples provided with Cocotb, and what prevents me to get inspired is that the provided either:

  • have no monitor (like adder)
  • use AvalonST drivers (like endianswapper)

The questions I have at the moment are:

  • When looking at the mean example, I see that the person has defined its own StreamBusMonitor, and I should do the same in my understanding (to monitor my 4 inputs to feed my reference model). AM I correct?
  • I don't understand how the names of the signals are matched by the StreamBusMonitor I see the following line:
    dut_out = StreamBusMonitor(dut, "o", dut.clk)
    but I don't understand the purpose of the "o", and where in the StreamBusMonitor it is used. Could someone help me?
  • I haven't found any official Cocotb forum. Is there a more official place to ask my beginner questions about Cocotb than StackOverflow?

Thanks all for your help.

Joseph Glover
  • 330
  • 3
  • 11
user1654361
  • 359
  • 3
  • 11
  • You could ask this at that [Gitter channel](https://gitter.im/vhdl/General). You can also look into our 3 Cocotb testbenches provided in our [PoC-Library](https://github.com/VLSI-EDA/PoC?ts=2): [PoC.cache.par](https://github.com/VLSI-EDA/PoC/blob/master/tb/cache/cache_par_cocotb.py?ts=2), [PoC.sort.lur_cache](https://github.com/VLSI-EDA/PoC/blob/master/tb/sort/sort_lru_cache_cocotb.py?ts=2) or [PoC.sort.lru_list](https://github.com/VLSI-EDA/PoC/blob/master/tb/sort/sort_lru_list_cocotb.py?ts=2). – Paebbels Nov 23 '16 at 20:40
  • Yes you need to write your own `Monitor` and `Transaction` classes. – Paebbels Nov 23 '16 at 20:41

1 Answers1

1

The StreamBusMonitor is based on the BusMonitor class which is defined in cocotb/monitors/__init__.py

The beginning of the class definition looks like this:

class BusMonitor(Monitor):
    """
    Wrapper providing common functionality for monitoring busses
    """
    _signals = []
    _optional_signals = []

    def __init__(self, entity, name, clock, reset=None, reset_n=None,
                 callback=None, event=None):
        self.log = SimLog("cocotb.%s.%s" % (entity._name, name))
        self.entity = entity
        self.name = name
        self.clock = clock
        self.bus = Bus(self.entity, self.name, self._signals,
                       optional_signals=self._optional_signals)
        self._reset = reset
        self._reset_n = reset_n
        Monitor.__init__(self, callback=callback, event=event)

The "o" in the StreamBusMonitor constructor is the name argument. That is used in determining the full name of the signals when it's passed to the Bus constructor.

You're probably aware that a fairly sensible and common bus naming scheme is the bus protocol signal names with some unique identifier appended or prepended, like "i" for in, "o" for out, or 'axi_m' for an AXI master, etc. and that's exactly what cocotb assumes is going on.

The signals for the StreamBusMonitor are declared and override the BusMonitor's _signals and _optional_signals values. So the signals defined here:

class StreamBusMonitor(BusMonitor):
    """
    streaming bus monitor
    """
    _signals = ["valid", "data"]

essentially have the "o" attached to the name (prepend with _ joining the signals and the bus name is the default behavior as per cocotb/bus.py) to determine the bus signal names in the design, and the handle to the correct object in the design hierarchy is the entity argument.

Which makes sense, as the signals declared are those above, and the signals in the VHDL are:

  i_valid  : in  std_logic;
  i_data   : in  t_data_array(0 to BUS_WIDTH-1);
  o_valid  : out std_logic;
  o_data   : out t_data

As for a communication channel there is now a gitter channel:

https://gitter.im/cocotb

and a mailing list set up by LibreCores:

https://lists.librecores.org/listinfo/cocotb

jbaxter
  • 182
  • 10