Re: [myhdl-list] Verilator as a backend to myhdl?
Brought to you by:
jandecaluwe
From: Lane B. <la...@ub...> - 2010-10-07 21:38:08
|
> Hi myhdl developers, > > I am new to the mailing list. So I am not sure if this issue has already > been discussed. I tried searching the mailing list archive, but didn't > find > anything similar. > > My question is: has anyone attempted to use a verilated C model (from > wilson > snyder's verilator) as the backend simulator for myhdl through some sort > of > python-to-C foreign language interface? > > The motivation behind this is that I would like to combine the high-level > programming power of python (and myhdl) with the speed of verilator. I > could > use co-sim w/ icarus or cver, but I find that cosimulation time is > prohibitively slow. Commercial simulator (we use modelsim) are acceptably > fast, but we have a limited number of licenses, and we can't afford to use > them to run regressions. > > Any thoughts / comments would be much appreciated. > > Thanks, > Terry > My normal flow these days has become to wrap verilated code up as a python C extension module so that I can use python to generate stimulus and control the flow. It is quite nice, especially when used with numpy and nose. With numpy you can get fast numerical analysis and with nose you get a nice test framework. It is quite easy to do once you know how to write a python extension module. It takes a little bit of time to understand how to write an extension module, but knowing how to write C extension modules for python is well worth the effort beyond just wrapping verilated code. I wrap things all the time when I need access in python something written in C. Furthermore, using this approach, you can develop high level stuff in python and then if it is too slow, push whatever makes sense down into the C extension module to speed it up as necessary. Flow control, checking a bit for pass or fail, etc. is typically not a bottle neck and is quite nice to do it python. Even things like generating sin waves, comparing memory buffers for equality, etc, is not a bottle neck in python (especially if you use numpy). |