Is this cocotb from Python? about pycocotb

[ydnatag]

Hello! I think pycocotb as an abstraction layer for hw emulation which allows you to test software without the hardware. I was studying the architecture of COCOTB and it's not possible run it in native python. The cocotb's simulator scheduler (python) is launched by the simulator in the "start simulator handler". Because of that, i decided to communicate the application with the simulation using ZMQ. The configuration is taken from a yaml file. Here is an example: https://github.com/andresdemski/pycocotb/blob/master/test/simulation/test.py I started with the UART because it's the simplest peripheral. Now i'm thinking how can i develop an AXI master device and share a memory between simulator and app (without sending data with ZMQ) like when you use a DMA in an FPGA. Answering your question: Yes, I need a lot of help and time. It will be great if we can discuss the software architecture. Thanks you. -- Andrés

[Nic30]

I did not study cocotb much but I see that the verilator can build a simulator of a circuit and this c-library can be dynamically loaded and used.

[ydnatag]

you are right, but you need to develop a simulation scheduler and interfaces for interacting with it. i'm using COCOTB as backend because it solves those problems. Maybe in a future it could be a great approach.

I really want to try verilator, i heard that the performance is many times better than iverilog.

[Nic30]

• Scheduler is not a problem (I already have one).

• Simulator interface is the problem. It is not hard to write python module as a wrapper for it but it is complicated to run paralell simulations due usage of static variables. (And parallel sim is "must have".)

I can not compare iverilog and verilator because I did not used it for the same thing. And as you expect complex sim. is always slow....

[Nic30]

Now i'm thinking how can i develop an AXI master device and share a memory between simulator and app (without sending data with ZMQ) like when you use a DMA in an FPGA.

3 years back I developed AXI-3/4 DPDK DMA. I have used framework which now contains something like cocotb. It works great but native c is simply faster for simulation than python.

[ydnatag]

Do you evaluate dockerizing the simulations for running them in parallel?

[Nic30]

Not yet. I used multiprocessing or MPI. But I am using the docker for web etc.

[ydnatag]

Now i'm thinking how can i develop an AXI master device and share a memory between simulator and app (without sending data with ZMQ) like when you use a DMA in an FPGA.

3 years back I developed AXI-3/4 DPDK DMA. I have used framework which now contains something like cocotb. It works great but native c is simply faster for simulation than python.

Have you got an example of that?

[Nic30]

Example of DMA or simulation or simulation speed?

[ydnatag]

DMA

[Nic30]

Do you have a skype/discord/steam/google acount and a microphone?

[Nic30]

I do have, but I am not sure about licensing. Maybe It can go opensource but I do not know.
It is highly configurable multichannel DMA I remember 1K FF 1.5K LUT (2ch, 64b, 4 trans overlap )@156.25MHz on zynq 7020.
Verificated and used.

[ydnatag]

Today i'm too busy. I can't have a meeting right now.
I'm interested in the verification.
I developed a simple DMA for DDR performance measurement (5ch@128b@110MHz on Zynq Ultrascale), it works but i'm not "happy" with the simulation and software verification.
My google account is [email protected]

[Nic30]

Ok tomorrow, I have maybe something better for you. Small DMA engines which can be easily programmed for the test. I also have some performance testers which I have used back then. But they are written in Vivado HLS.

[ydnatag]

I want to be able to emulate hardware for testing projects like:
https://github.com/ikwzm/ZynqMP-FPGA-Linux-Example-2-UltraZed

[Nic30]

If you want to test performance of AXI interfaces and DDR controller it can not be emulated.
If you do not need performance testing it is possible.

Also I have library which can bypass the access into the hardware over ehternet If you need it. I partially implemented python warapper but it is not done yet.

[Nic30]

I just added Python <-> Verilator interface to my fork of you project. Simulation is running and not-array signals can be read/written and it behaves as expected.
Next step is:

• port of corutine runner (cocotb-like simulation API)
• examples, install file, continues integration, coverage

I think the first step will take ~4h but I will have time at the end of the next week if everything goes well.

[ydnatag]

Hi Nic30, I was too busy last month.
I've been reading your approach and i have a question: How are you going to wait events with the verilator api? (for example, wait time, rising edge of a signal, sequence start)

The work that you are doing is really good. If you add event handlers for verilator simulation, it should allow to add verilator to cocotb as backend.

[Nic30]

Hello,

there is a calendar queue managed by python where it is possible to wait time of for edge on IO signal.
I think I did not pushed it to my fork of your repo yet. Think of it as a simulation of DUT inside of simulation of IO communication (which is test itself).
And there is an another trick. As this simulator uses delta-step paradigm there are sub steps (there is ReadOnly in cocotb, other names are combinational/sequential update done) By splitting the simulation in such a steps it is possible to use clock signals generated form DUT for synchronization.

For calendar queue (and top level simulator) I was using https://simpy.readthedocs.io/ but it turned out to be slow and it is really like 300 lines which were used so I implemented it on my own.

Currently I am crushed by deadlines for papers and project and my health status.
If everything goes well I will be able to finish the simulator and I will integrate it into HWT framework to test it at the end of this month.

[Nic30]

Hello,

I do have working prototype of Python <-> Verilator API in my fork.
But I see that the content of this repository changed a lot maybe it would be better if I create new repo for it.
Also if you are still interested please do you have time to discuss the library from user experience point of view?

[ydnatag]

Hello Nic!
I saw your fork and... its better and bigger than mine lol. I was focus in test reutilization (Using testbenches in HWs tests) without QEMU or other tool, just python and an HDL simulator.

I'm interesting but i haven't got time right now (work, girlfriend and other problems). Maybe the next month we can talk about this. Is it ok? Give me some time, I want to understand your implementation to contribute (If you have a graph, it can help me).

I have read that cocotb (https://lists.librecores.org/pipermail/cocotb/2018-October/000032.html) is going to be restructured and splited in many other projects/extensions. Maybe, the interaction with verilator could be part of the cocotb core.

I have a question, which is the difference between your implementation and current cocotb? (discarding not-makefiles and verilator support)

[Nic30]

Give me some time, I want to understand your implementation to contribute (If you have a graph, it can help me).

Plan is:

1. fix problems with c++11 and gcc-5 for travis build
2. simple doc (framework itself is quite simple, it's just obfuscated by code generating)
3. port agent for handshaked, bram, SPI, uart from hwtLib.
4. talk with cocootb community about integration

Problems are:

• 15.1. internal paper deadline about packet classification and HBM
• exams
• I have meson-build based make for Verilator, It works much better than autotools but I think that Verilator author would not like it as it is quite big change.

pycocotb vs cocotb

• dynamically generated simulation processes (coroutines)

  • allows to automatically generate specific objects (UVM interface agents) for communication with DUT interfaces (= testbench can be interface independent)

• simulation as python object

  • allows to easily run parallel / distributed / composite simulations
  • works with all python libraries without any extra care (can use python test frameworks)

• multiple signal update in one simulation step

  • faster simulation

• support for pre-event events (for example pre rising edge of signal)

  • simplifies writing of agents which are driven by clocks generated from DUT