Trusster Forums » Topic: error occurs when running Teal sv in Questasim6.5c

Trusster Forums » Topic: error occurs when running Teal sv in Questasim6.5c http://forums.trusster.com/ Trusster Forums » Topic: error occurs when running Teal sv in Questasim6.5c en Thu, 09 Sep 2010 10:55:54 +0000 Mike Mintz on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-17 Thu, 18 Feb 2010 11:34:22 +0000 Mike Mintz 17@http://forums.trusster.com/ Hi Desperado, (Are you the same Desperado as on the Verification Guild?) Sorry for the delay in responding. Our normal notification system failed. SV certainly has the *required* features to allow verification to succeed. It's just not good at encouraging good programming practices and has lots of "sharp corners" in its language definition. By far, the primary wart on the SV language is the difficulty in separation of interface versus implementation. This is a staple of good languages since the 1970s. You can separate *most* symbols (data, methods, classes), but it requires significant work on the coders part. There are tons of glitches in this process like the poor definition of a forwarded class type, how prototypes can vary between declaration and definition, and the initialization of statics. A second major flaw is that SV is derived from Verilog. This brings a host of issues and encumbrances, but the main one is that Verilog is designed to build real physical entities. The ways that that warps a language design are numerous. Just look at compilation versus elaboration and what are the scope resolution rules for a.b . Now C++ is weaker in some regards, such as threading, 4/8 state computations and connection to the DUT, but these can be overcome with relative ease (i.e. Teal). A third major flaw is that it does not integrate well with c and c++. These are the two primary languages of software. Yes, I know about DPI and PLI, they are quite weak for real model integration. Here's a partial list of lesser flaws. I am just rattling them off in no particular order. C++ has the std namespace and the template library. This alone is a major piece of good work and provides a good base for both novice and expert programmers. Many books have been written on the Template Library and much though has gone into those templates/algorithms. I know and have used all of SVs container classes, but they are a weak shadow of the template library. Packages versus namespaces: There are two major faults. The first is that when you end a package, all the methods and classes must be fully defined. This breaks the separation of interface and implementation. Add to that the fact that the parser and language definition are weak and you end up with files like teal_vout_pre and teal_vout_post. Another fault is that the package cannot be added to in another file. This may seem silly, but I do not want everything associated with a specific functional area to be in one file. How would users add they own derivations and have them look like there are "inside" the package ? A small nit is the fact that a function cannot take time. Either that or methods should be allowed to return a value. C++ has automatic construction and destruction. This is of great use for managing entry/exit tasks, such a mutex sentries, scratch RAM allocation, and resource reservation. It is invaluable in these situations within a function with many return points. Now I realize SV has pointer management, but (1) this can be added to C++ easily using smart pointers, (2) is often not really an issue and (3) causes great confusion as to when to new and when to copy. The fact that the language does not support a copy constructor leaves us to write error prone and clumsy code (with down casts). C++ is known by millions of programmers and hundreds of books are available. SV has maybe 20 thousand programmers and a handful of books. The inheritance model if SV is very weak. It does not support protected or private inheritance or multiple inheritance. It's model of function resolution follows the pointer type which is just wrong. Parametrization versus templating: There is only a superficial comparison and SV has not real facility for meta-programming (templating). Good templating is critical to the design of good container classes and generic algorithms. We do a lot of similar things in verification, it's real hard to express this commonality. Now I realize this is used in perhaps only 1% of your code (with the major exception of container classes and algorithms) parameters in SV versus constants in c++: Just looking at the ability one has to specify constants for reusable code, SV is weak. There is still discussion as to whether there can be global parameters. The initialization of parameters is very weak compared to c++. Finally the type checking in parameters is weak. bind versus operator overloading: As far as I know, no vendor has implemented bin for the purpose of overloading mathematical operators. Sorry this post was so long; I just got going. To me SV is like playing a concert on a toy piano. Sure you can try, but your range, sound and general talent is limited to, well playing like a child. desperadoo on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-16 Mon, 08 Feb 2010 06:45:51 +0000 desperadoo 16@http://forums.trusster.com/ Hi All, Robert Ekendahl Wrote: ""This is why I think our C++ solutions is far superior. You get a mature language with tons of more features then SV and you don't have to go through all of these hoops to make it work across simulators."" Hi Robert, can you name a few features as you say, c++ has rich features than SV,,,,?? As SV language supports all what available to verify an RTL design, what extra do you require to verify the RTL design!!! Can you suggest some few major feature which you C++ solutions provide over the SV !! so that would be helpful to know about the same!! Thanks, Desperado --> Keen on Teal/Truss solutions Robert Ekendahl on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-9 Thu, 08 Oct 2009 08:42:06 +0000 Robert Ekendahl 9@http://forums.trusster.com/ Cool, I'm glad that it's working. We also found that our code was working up to 6.4 with MTI and this is an issue we have been going back and forth with them on. They are probably the closest to the LRM, but the LRM is bad and many standard coding practices cannot be used if you follow the LRM. VCS and others choose to ignore the LRM. Not sure that is good either. This is why I think our C++ solutions is far superior. You get a mature language with tons of more features then SV and you don't have to go through all of these hoops to make it work across simulators. Our C++ solution also avoids the pitfall that SystemC and it's templating mess. That all said, we have an exiting solution in the works where we merge Teal/Truss with SystemC. Hiding most of the ugliness of SystemC and allowing verification to be more efficient while still connecting in other SystemC IP blocks. I hope Mike will be ready to show this soon. hanibian on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-8 Wed, 07 Oct 2009 22:31:02 +0000 hanibian 8@http://forums.trusster.com/ Hi Mike and Robert, Thanks for your both replies. I can proceed the simulation after removing "= 0", although there are still some warnings. Yes, sv is still under developing and not all the features are supported by EDA vendors, even some features have been interpretated differently by different vendors, or by the same vendor in its different S/W versions. Anyway I believed this is not an error of Teal, since I ran it on VCS-2008.x and there's no warnings or errors. Thanks again for your efforts. Best regards, Hanibian Mike Mintz on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-7 Wed, 07 Oct 2009 16:29:12 +0000 Mike Mintz 7@http://forums.trusster.com/ Hi Hanibian, Sorry about that. Line 70 looks like this: int j = 0; Just remove the "= 0" and Teal will compile and run fine. Internally I am testing with 6.4b. I will go up to 6.5 now. We will re-release Teal soon. The SystemVerilog language is still in major evolution mode. This particular "feature" was discussed between me and the SV committee. I thought we had left it as a warning not an error, but I could have been mistaken. The other warnings you see on compile are also under debate. Take Care, Mike Robert Ekendahl on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-6 Wed, 07 Oct 2009 13:19:35 +0000 Robert Ekendahl 6@http://forums.trusster.com/ Thanks for bringing this to our attention Hanibian. We were not aware of this error as we currently do not use that combination of languages and tools. We're looking into the error now and will post an update as soon as possible. We should know more within a day or so. /Robert -updated for clarification hanibian on "error occurs when running Teal sv in Questasim6.5c" http://forums.trusster.com/topic/error-occurs-when-running-teal-sv-in-questasim65c#post-5 Tue, 06 Oct 2009 22:52:30 +0000 hanibian 5@http://forums.trusster.com/ Hi, I found some errors when I tried to simulate teal sv test in Questasim 6.5c. Can anyone help? Here is the log: QuestaSim vlog 6.5c Compiler 2009.08 Aug 27 2009 -- Compiling package teal ** Error: ../teal_vout_pre.sv(70): (vlog-2244) Initialization of 'j' requires that a lifetime (stati c/automatic) be specified. ** Warning: ../teal_vout_post.sv(40): (vlog-2217) No default specified for 'initial_show_level'. De fault must match the value specified in class at ../teal_vout.svh(99) for strict LRM compliance. ** Warning: ../teal_vout_post.sv(156): (vlog-2217) No default specified for 'also_to_screen'. Defau lt must match the value specified in class at ../teal_vout.svh(82) for strict LRM compliance. ** Warning: ../teal_dictionary.sv(71): (vlog-2217) No default specified for 'replace_existing'. Def ault must match the value specified in class at ../teal_dictionary.svh(47) for strict LRM compliance . ** Warning: ../teal_memory.sv(91): (vlog-2217) No default specified for 'size'. Default must match the value specified in class at ../teal_memory.svh(61) for strict LRM compliance. ** Warning: ../teal_memory.sv(115): (vlog-2217) No default specified for 'size'. Default must match the value specified in class at ../teal_memory.svh(62) for strict LRM compliance. -- Compiling program verification_top -- Importing package teal ** Warning: vout_test.sv(48): (vlog-2240) Treating stand-alone use of function 'show_debug_level' as an implicit VOID cast. ** Warning: vout_test.sv(52): (vlog-2240) Treating stand-alone use of function 'show_debug_level' as an implicit VOID cast. ** Warning: vout_test.sv(55): (vlog-2240) Treating stand-alone use of function 'show_debug_level' as an implicit VOID cast. ** Warning: vout_test.sv(58): (vlog-2240) Treating stand-alone use of function 'show_debug_level' as an implicit VOID cast. ** Warning: vout_test.sv(62): (vlog-2240) Treating stand-alone use of function 'show_debug_level' as an implicit VOID cast. -- Compiling module interfaces_dut -- Compiling module top