search

hgomersall / Ovenbird

A tool for merging the MyHDL workflow with Vivado
BSD 3-Clause "New" or "Revised" License
19 stars 2 forks source link

Using Ovenbird #6

Open ABADY1000 opened 3 years ago

ABADY1000 commented 3 years ago

I write Verilog modules on Vivado and some of them are a little complex, so testing them on python will be great

When I saw your repository I was so glade and I hoped I could use it, but I found it hard to use the package, so, if you could write a short explanation about how to run Co-simulation in Vivado that will be really really great.

hgomersall commented 3 years ago

You are right, the documentation is a bit sparse. It really builds on Veriutils, which defines the usage. The SynchronousTest class is the entry point, and the API is reasonably well documented. I'll summarise this and then suggest how it might be useful for you...

Veriutils is actually fairly conceptually simple to use - If you have some block you want to test and some signals that are the interface to that block, then Veriutils will run two MyHDL versions of that in parallel and check consistency between them. That allows two main use cases (and others no doubt, I'm just not sure what they are):

  1. (the original use case) You can have one of the blocks that is a reference implementation of the block that uses all of Python's functions and so on to drive the signals and one of the blocks is the convertible device under test block.
  2. You can only use one block (the DUT specifically) and no reference and then you can detect at simulation time if the outputs are as expected (that is, you have blocks outside the DUT that do the checking, and raise test exceptions as needed). In this case, you pass the DUT in as both the reference and the DUT (so it checks against itself, which of course will always pass, but that's ok because the tests happen elsewhere).

The model broadly is one in which you pass a pair of factories (i.e. the blocks before you call them), along with a list of MyHDL signals that drive the block or are driven by the block (the argument args to SynchronousTest.__init_), and also a dictionary of what those signals are (the argument arg_types). The various types are defined in the API documentation. You must have a clock (only synchronous code is currently supported), but the rest can be anything. Typically, you'd have a collection of output signals and custom signals. output signals don't require much, it just instructs Veriutils to check those are what is needed. Custom signals are driven by custom_sources.

hgomersall commented 3 years ago

I sort of gave up writing the above in favour of an actual example in the Veriutils readme.

What Ovenbird does is add a replacement to SynchronousTest class that interacts with Vivado. The best way to see how it all works is to look at the examples directory. That actually uses the second bit of ovenbird, which is to provide a way of interacting with Vivado IP blocks.

hgomersall commented 3 years ago

The Vivado IP blocks are one way you might be able to interact with your existing code - if you package it up as an IP-XACT block using Vivado's tools, then you should be able to use it from Ovenbird. Honestly, that all might be a bit of a pain. Ovenbird is really designed for verification of MyHDL blocks, with conversion to VHDL or Verilog as part of that chain. I've looked into closer interaction with cocotb, but haven't had the time or the clear need (though I'm always keen for pull requests!).

Perhaps cocotb might be a better solution to what you need? In any case, I'm happy to help with any specific problems you have with either using Ovenbird, or modifying it to better fit your needs, in which case I'd be delighted to be able to merge that back in.