Hi Mike,
I am a new comer to the open source field for verification.
I have previously used Vera and its RVM methodology. I was really happy with the way the project terned out.
I was comparing the RVM and truss features briefly.
It seems very similar. However, I had a question questions on missing features and the timeline of its roadmap if under development.
1. Virtual ports in Vera. They were very useful for reusability. Do we have something similar ?
2. Random Constraint solver
3. Functional coverage
Can you please comment on the same. Sorry if its on the website and I missed them.
Maybe we can make a small document noting difference b/w RVM (similar such methodologies) and truss. This will give a new adopter more confidence in the infrastructure that you provide.
Thanks again for your efforts.
-Shamik
#1 by mike on April 1, 2008 - 9:45 am
Hi Shamik,
Welcome to the open source community!
Vera and RVM are a good combination. I have used them myself. Teal n Truss are similar, but RVM is a bit more constraining and bigger. Teal n Truss follow the open source model, which is very careful about what requirements they put on users.
Let me answer your specific questions and then talk about the timeline of Teal n Truss development. I will address the C++ version of Teal n Truss. Let me know if you want to discuss the systemverilog version.
>1. Virtual ports in Vera. They were very useful for reusability. Do we have something similar ?
Yes, Teal has the concept of vreg. A vreg is, by definition, the virtual register into the HDL. Just like vera, you enter a string path and the connection is made. Unlike vera, the bit width is set by the HDL. But for all intents and purposes the assignment and referencing of a vreg acts like an async access in vera.
>2. Random Constraint solver
Nope, we will not do one of these. The SCV one from SystemC is a decent solution and can run with Teal. We feel however that constraint solvers are not the right direction for verification.
>3. Functional coverage
This is a weak link in all verification systems today (and yes I have used the vera and Systemverilog ones extensively). This is the favorite discussion topic of Robert and I. We have even prototyped a few language neutral solutions, but are not happy with them. The ideal solution will connect randomization, coverage and visualization. Verification Engineers (and their managers) need to be able to plan what should be covered, look at what has been covered and easily direct the simulation to cover new ground. This is not a trivial task. We are always looking for new ideas to explore.
So that’s a hint at where we are going with Teal n Truss. But the short term roadmap is to release Teal n Truss on top of systemC. SystemC is a good interconnect to both verilog and vhdl. Another short term goal it to release the cadence SystemVerilog Teal n Truss version.
But the longer term is to solve the coverage/randomization/visualization problem. Also, we will go in the direction that the open source community wants. So feel free to suggest improvements!
Take care,
Mike
#2 by skvalia on April 2, 2008 - 10:55 am
Hi Mike,
Thanks for the answers.
May I ask the reason of moving away from constraint solvers. I understand that people are looking at ways to link the constraint solver with coverage model for efficient verification. Even methods for test grading are used.
What is your thinking.
Thank you for your efforts.
-Shamik
#3 by mike on April 2, 2008 - 2:18 pm
Hi Shamik,
I am not sure we have enough beers to fully discuss my views, but let me try without beer
I have used constraint solvers for many years now, in Specman, Vera, SystemC and Systemverilog. I have come to a philosophical decision that, as a sub-language, they are undesirable. They are very non-intuitive, and a priesthood soon develops (those who create and those who use).
Now as for using them in practice. At first, they seem like a great thing. Then as your system gets more complicated, they start to get messy. Then, different groups want to reuse you code, but do not like your constraints. So you subclass, but soon that gets all messy. I have spent hours debugging constraint solver failures.
So you break up each constraint into their own class, or named constraint. Again, that works for a while, but its very hard to design constraints that do not have a domain (often chip) bias. When you go to the next chip, they are not appropriate.
Eventually, I realized that the constraint system really warped the architecture. Then it dawned on me that the constraints system needs to be orthogonal (not related to) the class hierarchy. Further, I realized that the very yin of OOP, which is data encapsulation and type inheritance, is conflicting with the yang of knob like control of constraints.
In the end, I realize that range based constraints is all I should ever need. Anything more complicated, and it should be expressed in procedural code and then transformed into a temporally imposed range. That’s pretty much what the solvers are doing anyway.
One last point. I also firmly believe that the constraints system (in any form) must be coordinated with the randomization system, the coverage system, and the plan. Anything less is a large amount of extra work.
Does that help explain why no constraint language/solver?
Take care,
Mike