Cocotb: Overhaul of Driver + Monitor for Avalon-ST interface (w/ and w/o packets)

[nredd]

I use cocotb extensively at work, and have expanded on the classes AvalonST(BusMonitor), AvalonSTPkts(BusMonitor), AvalonST(ValidatedBusDriver), and AvalonSTPkts(ValidatedBusDriver) to (almost!) fully implement and update the parameterizability of the Avalon-ST interface for use with our internal TBs. The most recent spec is here (see ch 5); the current cocotb implementation is outdated. For the sake of being explicit, refer to Table 18--I'll be adding the logic associated with every property other than associatedClock, associatedReset, and beatsPerCycle for both packetized and non-packetized Avalon-ST interfaces. I will open a PR here once things are complete on my end :-)

JSYK, I'm making use of the transitions package to represent each interface as an FSM--I hope adding this dependency is no issue!

In reference to issue #864, I hope that this motivates a decision to retain the Avalon interface modules as core functionality--it really makes cocotb that much more accessible!

[ktbarrett]

A couple things:

• Welcome to cocotb! And thank you for updating the Avalon components!
• cocotb has zero runtime dependencies and I think this is a beneficial thing, adding a dependency for a non-essential component is not going to fly.
• The reasoning behind #864 is sound, cocotb is a cluster of technologies that enable one to write testbenches using Python. Defining a methodology on top of that (by defining Driver, Monitor, etc.) is out of scope and maintenance baggage. All of that stuff should move into another repository as we move to a more modular system.

Since you are interested, I might suggestion you petition to get an Avalon extension repo setup in this organization. Extensions should be able to have arbitrary runtime requirements.

[nredd]

I see—thanks for clarifying!

Does that mean that the drivers, monitors, and generators sub-packages are intended to be made extensions as well?

[ktbarrett]

I would like to, but I don't think there have been discussions on that yet.

[ktbarrett]

@eric-wieser It seems you are the one with the permissions to create new repos in the organization.

[nredd]

During development, it became clear that implementing e.g. a Driver for some arbitrarily complex hardware interface would be increasingly prohibitive--if not impossible--as complicated behaviors are included. This is especially true if one attempts to manually write the state machine associated with an interface.

That being said, I worked out and implemented a generalization of digital interfaces and their associated behavioral models which allows for formal model checking and the extraction of behavioral hierarchies (i.e. for HSMs). Briefly, we define a digital interface as a collection of signals, each with its own collection of user-provided attributes that are sufficient for formal specification + verification. A subset of these signals may be designated control signals, which may be ordered relative to one another to define a precedence-based control hierarchy whose structure is one-to-one with that of the (nested-state/hierarchical) behavioral model for the entire interface.

To make things more user-friendly, I added a decorator for attaching arbitrary context/state-dependent callbacks (called reactions) to models, and another to provide functions which access data during signal sampling (called filters). My intention is that this makes it very straightforward to define what are essentially BFMs in cocotb, and I have provided complete implementations of the Avalon Clock, Reset, and Streaming interfaces. I also added generalized Driver and Monitor implementations, and have made use of them within my own TBs.

Once I wrap, I'll fork this module for the sake of getting eyes on it (it's ~1500 lines at the moment), but I'd like for it to have a more permanent home e.g. cocotb/cocotbext-interfaces. @eric-wieser , should I create a separate issue for this?

[eric-wieser]

@nredd: I think the easiest thing for now would be for you to make nredd/cocotbext-interfaces or whatever you deem best (https://github.com/nredd/cocotbext-interfaces) - and then when we get around to it, we can pull a bunch of repos under the cocotb namespace all at once, and merge / split them as makes sense.

We can add a link to nredd/cocotbext-interfaces from our wiki page which lists extensions

[cmarqu]

Added the link to https://github.com/cocotb/cocotb/wiki/Further-Resources

[bluecmd]

@nredd Just a voice of support from me, an internet stranger. The Avalon drivers of cocotb are great and saves me so much headache and time. Improving them would be wonderful.

A positive thing about splitting to extensions is that that potentially means you can use extra libraries in those extensions, as it wouldn't polute the core framework. I'm not a maintainer, but if you'd still like to use your transitions library it might be an easier sell if it's an optional add-on to cocotb.

[nredd]

Totally agree--I've been building out a pipeline (targeting Intel FPGA) over the past few months and they have saved me an immense amount of time :slightly_smiling_face:

Unfortunately, it will be some months before I can give cocotbext-interfaces the love & care it deserves, so I'll close this down until then