Where is teal/truss heading to (VHDL, SystemVerilog)?
Hi,
I was wondering where teal/truss is heading to?
In the blog at this page I read that there is a new book in queue about SystemVerilog. What does that mean in terms of using the framework? I assume it requires a simulator that supports SystemVerilog, not like the C++ approach that works for the verification part by itself and interacts over PLI with a Verilog simulator?
As SystemVerilog is getting more support by simulator vendors, will that put more emphasis on the SystemVerilog part of teal/truss as well? I mean, will we see the support of the C++ part reduce?
In the forum of the verification guild I read in a post of last year that there is some VHDL support planned. What is the status on that? Is that still a goal?
Thanks for the information.
Cheers,
Guenter
Comments
Directions!
Guenter,
Fair question. Our C++ and systemVerilog(SV) libraries are (currently) stand-alone and separate. Truss/Teal for C++ works through PLI and only needs a verilog simulator. Our SV version runs on MTI or Synopsys but requires the systemVerilog license option.
Both Mike and I prefer C++ over SV as it's a better known and mature language. I use truss/teal for C++ daily in my work as does other people so we will definitely continue to support it. In fact, we believe most people would be better of using our C++ solution then our SV version!
Our SV version was created because Mike was working in SystemVerilog and seems to create some interest. It was done to show how verification might be done in SV . The results are decent (but there are some hacks needed). We decided to rework our book to systemVerilog as we don't think there are many good independent systemVerilog books available, we hope we can change that. SV is still an immature language but it is getting better year-to-year.
We're still considering a VHDL port of Teal/Truss for C++. It wouldn't require that much work but we have so far had no concrete interest in it (need for it), and since we're both doing this on our free time we work at what we deem most needed or interesting at the moment. If you would like a VHDL port let us know and we'll work with you!
One problem is that there is two interfaces for VHDL supported by different vendors. VHPI is used by Synopsys, Cadence, and Aldec while MTI supports FLI. We would have to support both, but don't know which is the best to start with. Adding a second HDL probably requires that Teal support both at run-time. This can be done, but we would have to think about how to not grossly complicate Teal.
As a side note: We're currently playing around with the idea of a a Teal/TRUSS systemC implementation. That would both cover the warts of SystemC and provide a good verification framework. This systemC version will also be able to connect to VHDL simulators (as a side effect) so it could be our short term solution for VHDL.
Sincerely,
Robert
a year later...
Hi
OOP for verification sounds great, both from an academic and a practical point of view (it must surely beat rummaging through and 'reigning in' endless pages of HDL testbench code, as I did on my last contract)... it is a logical step in the convergence of hardware and 'software' design. Does your preference for C++ still hold today? I confess I am partial to it myself, having done some C/C++ in my software days...
You state that your C++ interface needs only a Verilog simulator... I would assume that it would also need a C++ compiler. At my last full-time job, we developed a VHDL/C cosimulation environment (using Microsoft C++ and MTI/FLI), with, if I recall correctly, the simulator linking to the compiled C code at load time... does your environment work in a similar way? Can I use e.g. the Active-HDL Student Edition to run your environment?
Is your initiative gaining acceptance among managers and tool administrators in the industry? If you are still interested in VHDL development, MTI seems to be a "signoff standard" for ASIC development, so perhaps FLI would be a good place to start (this does not reflect in any way on any of the other simulators that you've mentioned, but does reflect my 'experience bias' :-). VHDL is quite popular in some of the industries and geographical locations where I have worked. If there is time, I would like to lend a hand... but perhaps I shoud reread some of my C++ books (and read your book) first :-)
regards,
Sy
a year and a week later...
Hi Sy,
Yes I am still very much in favor of C++ for verification.
I believe that many engineers will come to OOP through SystemVerilog, but will soon realize that its limited, so they will then use C++.
As for how Teal hooks into Verilog, we decided not to use a run time mechanism directly under our control. I have created such systems in the past and found that it really confused people. So we do the "standard" pli/vpi mechanisms. Yes, you should be able to use Active HDL. We know the Aldec people well.
I am not sure how much the industry is following our "flag to C++". That's the funny thing about open source code. It's hard to tell how many people are actively using it. We get several questions a week about Teal and Truss installation though. And we should up about once a week on the verification guild.
As you said, verifying in c++ is the best way to interact with the software. I have used dpi in SystemVerilog and it's still a blood/brain barrier (i.e. hard to cross ;-).
As for VHDL, I'd love the help. I've been working on a Teal SystemC port, and that will hook into VHDL just fine. It's almost done (for mti).
Feel free to contact me mike <> trusster dot com.
Take care,
Mike
Mike, you mention that you
Mike, you mention that you are working on SystemC port, is this going to be PLI based integration or are you planning with native SystemC support comes with simulators?
Also when can we expect the relase of this, i would like to contribute for this work.
SystemC Land
Hi,
Yeah, I would love some help. I did not get as far as I wanted when on vacation two weeks ago. Ping me mike <> trusster.com and we can figure out how to set you up.
The port uses native systemc. I have two mechanisms to connect. The first is identical to the native c++ vreg, and uses a path. The second uses the standard sc_in<>, sc_out<> mechanisms of systemc.
But (!) no more directions or differences between in and out. Teal handles all this.
Also, Teal's at() and condition are unchanged (at the interface), but use systemc as the implementation. I wrote my own mutex because silly systemc's one cannot be created after elaboration.
So, I think this is a cool version of Teal because it uses systemC to interconnect and schedule, yet retains all of Teal's elegance.
Take care,
Mike
Thanks for the extensive
Thanks for the extensive reply Robert.
I intent to use teal/truss with C++ and Verilog, but was curious what the development will be and where to expect the limits. I have no need for VHDL at the moment.
Good to know that you are comitted to C++.