[Cocotb] Sharing tests between simulation & lab

Luke Darnell luke.darnell at broadcom.com
Thu Aug 31 09:44:13 CEST 2017


Jean-Marc,

We have a similar situation, where we have vanilla, non-cocotb python for
accessing our chip in multiple environments (lab, sim, ....).
And as you've noticed, using cocotb.external to call non-cocotb python code
from within cocotb, results in non-deterministic simulation results (since
the thread running the vanilla python isn't blocking the cocotb thread).

We've yet to find a solution to this one.

It's a minor irritation for us.
But the benefits of cocotb and the ability to reuse python code in the lab
and simulation, definitely out weigh the negatives.

Is there a particular need for your simulations to be deterministic?

We have a tcp server running in one of our simulations, that we can connect
and talk to, as if it was a chip in the lab.
The tcp server is blocking in cocotb, so maybe you could have your high
level code talk to a tcp server running in the simulation??

Luke

On Sat, Aug 26, 2017 at 6:44 AM, Jean-Marc Tremblay <
Jean-Marc.Tremblay at mdacorporation.com> wrote:

> Hi all,
>
>
>
> I’m trying to find a way to have deterministic tests in simulation using a
> mechanism similar than cocotb.external() function, but blocking. Let me
> explain why I’m trying to do this.
>
>
>
> In order to reuse our tests between the lab and simulation, we created a
> common high-level Python infrastructure that calls low-level functions
> (think read/write registers, etc.) based on the environment in use
> (lab/sim).
>
>
>
> The tests are calling the high-level infra functions, which internally
> calls the Python-cocotb low-level functions decorated with
> @cocotb.function. I’m in the process of preparing a better example, but
> here is how this is done in pseudo-code.
>
>
>
> I’ve tried to create my own external function without the use of the
> threading.Thread, but ran into a situation where the class
> function.__call__ would hang on self._event.wait().
>
>
>
> Is there a cleaner/ better way to do this?
>
>
>
> Thank you in advance,
>
> Jean-Marc
>
>
>
>
>
> *Python program* (test_prg.py - barely change)
>
> import cocotb
>
> global glog, gdut
>
>
>
> def execTestFile(filename):
>
>     execfile(filename)
>
>
>
> @cocotb.test()
>
> def test(dut):
>
>     global glog, gdut
>
>     gdut = dut
>
>     glog = dut._log
>
>     # setup env - not shown here
>
>     filename = os.path.join(os.getcwd() + "/../test_file.py")
>
>     *yield cocotb.external*(execTestFile)(filename)
>
>
>
> *Python test* (filename = test_file.py - many flavors + we don’t want
> yield nor cocotb references in them)
>
> from test_prg import glog
>
> from infra import sleep
>
>
>
> for i in range(0,100):
>
>     glog.info("oups, we are consuming time!: %d" % i)
>
>
>
> sleep(100)
>
>
>
> *Python infra* (infra.py - high-level infrastructure)
>
> import cocotb
>
> from test_prg import glog, gdut
>
>
>
> @cocotb.function
>
> def sleep(num_clk):
>
>     for i in range(0, num_clk):
>
>         yield cocotb.trigger.RisingEdge(dut.clk)
>
>         glog.info("oups, we are consuming time as expected: %d" % i)
>
>
>
> _______________________________________________
> cocotb mailing list
> cocotb at lists.librecores.org
> https://lists.librecores.org/listinfo/cocotb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/cocotb/attachments/20170831/e56a4661/attachment.html>


More information about the cocotb mailing list