> 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. :)
Definitely very usable as-is for prototyping. This project also has the benefit of being the only high-level VPI wrapper I've found who's maintainers haven't destroyed all of their work and disappeared off the face of the earth (*cough*APVM*cough*), so perhaps some more regular activity would stimulate community growth. > Interesting. I never realized temporal assertions are really FSMs. > Now it makes sense. I've always in my mind compared temporal assertions to regular expressions.. Both are just convenient ways of implying certain classes of FSMs. I bet with a little work, one could massage a regexp eval engine into an assertion eval one (you would still have to come up with a suitable assertion compiler). > Ah, I assume you mean Verilog code coverage? We already get Ruby code coverage via the RCov library. Yes, I mean the Verilog side. When doing constrained-random testing, you are often interested in knowing how much of the system's RTL has actually been excercised. > 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)? Set of nets. It has two uses, one is to make connecting up bundles of wires between modules easier and the other is to bind RTL code to Classes in such a way that the class doesn't actually know the hiearchical name of the pins it's driving. This second use allows for multiple instances of the same Bfm (pin-wiggle) class for example to be driving different pin-compatible logical interfaces on your DUT and is the one that I'm most interested in. > 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. I am not familiar with Darcs (or distributed source control in general) but I will install it and give it a go. I think I may just start by publishing some of the code I've been playing with as examples. I've got a simple transaction-based test enviroment based on a modified counter (added down-counting and loading) working. I'd like to clean it up a little bit (it's being bootstrapped from a unit test currently, I haven't dug deep enough into the internals to figure out how to remove this dependency) and perhaps attempt to integrate one of those ruby constraint solvers before posting it. --Mike
