Re: [myhdl-list] High-level thinking: Using Python for rapid verification

[Chris H. <chr...@po...>]

Christopher Felton <chris.felton <at> gmail.com> writes:

>  From my perspective it was more of frustration, obviously
> they have some nice features (would be great to see these
> merged into MyHDL) but from the big picture I don't see
> anything the MyHDL doesn't support: provides an interface
> to the V* simulators and you can cosim with Python.

Yes, there is overlap in terms of functionality regarding the cosimulation
capabilities, however perhaps it's worth examining some differences
between Cocotb and MyHDL regarding cosim:


1. Cocotb embeds the Python interpreter into the simulation process.

In a tightly coupled environment like simulation where there are many
events, embedding the Python interpreter has better performance than separate
processes communicating via pipes.


2. Cocotb removes the requirement for any wrapper code

This is one of the significant motivating factors of Cocotb - to reduce the
amount of effort required to create a testbench.  You could argue that the
$from_myhdl and $to_myhdl wrappers are low effort, however having to write a
top-level wrapper is still a barrier.


3. Race conditions / delta cycles

MyHDL solution to this forces passive Verilog whereas Cocotb ties into the
simulator scheduler in a way that allows it to work in an entirely passive
way.  This allows Python coverage models or protocol checkers to be attached
to existing test infrastructure.


There are of course other differences between the projects, specifically that
Cocotb is really designed from the ground up for cosimulation with
VHDL/Verilog whereas the cosim capability of MyHDL is a subsection of a much
larger endeavour.


> > The part you're referring to is called the Generic Procedural Interface
> > (GPI), and it seems to be written in C.
> >
> 
> GPI?  I realize the interesting chunks are the C code (they
> actually did some ugly stuff in the Python side), I will
> need to put this at the end of my infinite "check-out" list
> and see if their C code can be merged with MyHDLs VPI code -
> at this point I don't know if it even makes sense?


GPI is the Generic Procedural Interface, a layer that we have created to
abstract away the underlying simulator implementation.   We have completed
layers for VPI and VHPI and are working on Mentor FLI.  We have only
implemented the functionality we require for Cocotb, however this also
probably comprises the same capabilities that MyHDL might require.  There
are Python bindings for the GPI layer exposed as a module called "simulator".

Obviously I think that MyHDL would benefit from re-using this code from Cocotb,
it's a non-trivial amount of work that addresses some of the areas that could
be improved in MyHDL.  The architecture of Cocotb is hopefully suitably
isolated that GPI and its Python bindings could be usefully used without the
other stuff.


> they actually did some ugly stuff in the Python side

We're always happy to receive feedback, can you elaborate further?  I know you
have previously expressed distaste for the overridden <= assignment, however
you'll be pleased to hear that this has been deprecated (though there is an
ongoing discussion on Github[1] if you want to contribute).  The only
remaining 'hack' that could be considered un-pythonic is the use of a special
exception to return values back from coroutines.  If there is a better way to
achieve this we'd be happy to hear more.

Thanks,

Chris

[1] https://github.com/potentialventures/cocotb/issues/119