Mikhail Ravkine wrote: > I spent last weekend playing around RubyVPI (using GPLCVER as > simulator) and you've done an excellent job in disguising all of > the VPI uglyness with nice, usable classes.
Thank you. > I wanted to ask you, exactly what are the goals of this project? So far, my goals have been to allow (1) rapid prototyping and (2) directed testing (using standard software testing libraries such as xUnit and RSpec) of Verilog modules in a very high level language. In my view, this project has successfully accomplished these goals and is currently undergoing a phase of slow growth and periodic refinement. So, now is a good time to steer the project in new directions. :) > I am interesting in building a fully open verification enviroment > that would at least be feature-compatible with current > SystemVerilog implementations. > > Ruby gives us Classes for free, that's the most major feature of > SV already. > > Currently missing features are: > > - constraints (although I see there are several ruby-based > constraint solvers available, I have not yet explored them) > > - assertions (I am referring to SVA, a temporal assertion > language that models assertion FSMs .. May be difficult to > implement, but perhaps something similar can be developed with a > more ruby-like syntax) Interesting. I never realized temporal assertions are really FSMs. Now it makes sense. > - functional coverage (For interesting signals/buses, define > "bins" with ranges of values. Anytime bus value changes, > increment appropriate bin.. At the end of simulation, you can see > how many times interesting values were hit. Should be > straight-forward to implement) > > - code coverage (I believe this has to be implemented in the > simulator) Ah, I assume you mean Verilog code coverage? We already get Ruby code coverage via the RCov library. > - interfaces (probably impossible in RTL without simulator > support, but may be possible in some form inside verif > enviroment) By interface, do you mean the set of nets in a Verilog module declaration? Or do you mean a high-level communication pathway between two modules (like a FIFO with receiver-is-busy handshaking)? > I work in the industry (I'm an ASIC Verification Engineer, coming > from Mentor and Cadence tools mostly but I've used all of the big > 3), and I think a verification enviroment that implements the > above in a free way would go a long way towards both lowering > costs in professional situations and allowing hobbyists access to > professional-level tools. Excellent! I would be happy to work with you to extend this project into a more general verification environment to fulfill the goals you mentioned above. Please check out the project source code from the Darcs repository. At present, the repository set-up is not very friendly for multiple developers to publish changes. So, for the time being, you'll have to e-mail me patches (using darcs send) and I'll have to publish them manually. If this becomes a bottleneck, I'll migrate from Darcs to Git so that we can all directly publish patches to the repository. Cheers.
