Hi,I'm new to systemverilog ..and using NCVLOG...and i'm trying interface my BFM modelled using classes with the interface (phy signals)...cadence is not supporting keyword virtual to do this...can anyone help me on how to do this....i want to keep my classes in a separate file...and the top module in a separate file....also have trouble calling the top module from program file....please help ASAP Cheers
virtual interfaces will be supported in IUS61, due to be released next month (April).
A workaround is to instantiate your interface and your class at the same level. In the class create a task that can receive a class or struct argument. Then you can collect the signals values from the interface into a class or struct and pass it into the class via the task.
You could also do this via a mailbox. You would pass the mailbox into the class similar to the virtual interface. Although mailboxes aren't natively supported yet (also supported in IUS61), there is a mailbox class that has the same functionality. You can get a copy at http://www.cdnusers.org/Forums/tabid/52/view/topic/forumid/66/postid/2739/Default.aspx.
Hi tpylant,Will the global class be supported in IUS6.1?Best regards,Davy
PHY signals can be declared in interfaces, this interface can be passed as an input to BFM. Declare BFM as a module. Instead of declaring classes alone in a file, declare them in a package and then import this package whereever required.Also, in the top module, use full hierarichal path to call a particular module.Cheers
We won't be supporting globals in the near term. However, you can easily duplicate this behavior using packages, which is a better programming style anyway. From IEEE1800 LRM 19.2, "SystemVerilog packages provide an additional mechanism for sharing parameters, data, type, task, function, sequence, and property declarations among multiple SystemVerilog modules, interfaces, and programs. Packages are explicitly named scopes appearing at the outermost level of the source text (at the same level as top-level modules and primitives). Types, variables, tasks, functions, sequences, and properties may be declared within a package. Such declarations may be referenced within modules, macromodules, interfaces, programs, and other packages by either import or fully resolved name. It is also possible to populate packages with parameters, variables, and nets. This may be useful for global items that are not conveniently passed down through the hierarchy."package globals; class test_c; rand bit a; endclassendpackageThen you can import the package wherever you need access to the package contents:module test; import globals::*; test_c item = new;endmoduleOr you can refer to the package items directly:module test; globals::test_c item = new;endmoduleTim
Hi tpylant,Thanks so much for the instant help!I understand. I used to encapsulate class in module(cannot re-use outside), and I will encapsulate class in package from now on.There are two questions: For I used to force (through Tcl) signals in Verilog, can I force variable in class instance in IUS? I am reading the uRM, but I'd like to wait for the Class-based version available. I notice the transaction layer is implemented by interface (maybe more intuitive for design engineer, but is not very good for verification engineer). Is there any article by Cadence tell us how to implement simple transaction layer by class in IUS(for example, how to pass transaction here and there by class), any recommendation methodology is welcome!Best regards,Davy
1) I cannot see the class hierarchy from TCL. Therefore, you can't deposit onto a class property. The only thing I can think of off the top of my head is to create local variables that you can deposit onto and then connect those variable to the corresponding class properties. Or if you're able, you can make the class properties static which would make them available to TCL (deposit class_name::prop = 0).2) Our class-based implementation of URM is just going into limited production. If you want to learn more about it, you will need to contact your local sales or AE. However, we have had a number of successes with our module-based implementation. As you noticed, it uses module and interfaces to construct the environment but takes advantage of classes for generating the data. This has proved successful because it is very quick to implement a solution (can put together an env for a block in 1-2 days) and easy for users comfortable with Verilog to understand and debug.Since you are already reading URM, I would suggest implementing the same methodology but using classes in place of modules, mailboxes instead of the BFM interface and a virtual interface for the DUT interface. That will give you a very simplistic example of how our URM class-based implementation will work. However, the base class libraries that come with URM will give you much more automation and power than that simple example.Tim
Hello tpylant,Thanks a lot for your suggestions!For 1), what's "I cannot see the class hierarchy from TCL" mean? Will the future IUS Tcl supports force signals in class instance directly? (You see, a lot of old verification methodology change the scenario through Tcl force)For 2), you mentioned in your previous post that we can put global variable to package. So can I put/instance all the Mailbox/queue which containing transactions into one package (I may call it Mailbox package). Thus all the transactor access the Mailbox package to put/get transactions. Do you think it is a good way?For uRM, I have write an email to the uRM group to request evaluate the class-based uRM. But they don't give me any response. But after read your explain, I think it is simple to write my version.Best regards,Davy
"I cannot see the class hierarchy from TCL" mean? Will the future IUS
Tcl supports >> force signals in class instance directly? (You see, a lot
of old verification methodology >> change the scenario through Tcl force)IMHO you better change that mindset and methodology - enabling TCL inherently means compromise on performance. With SV providing you enough constrained based generation, rely on it and wrap it using a good methodology say uRM (or VMM or anything - under the hood lot of things are common indeed). So why "force" class members to have a specifc value? In a VMM style thing I can do this easily in a test case as:program my_test_pgm; my_env env_0; initial begin : test env_0 = new(); env_0.build(); env_0.generator_0.class_to_be_changed = ; env_0.run(); end : testendprogram : my_test_pgmPoint is - you can achieve the same that you would get via force in a much more "standard" way than force. Another important thing - by relyhing on force you are having your TB tool specific - why do you want to do that?If your argument is "TCL" is run time - there are several WA for that, tools may give you better ways, for instance Specman has an excellent way of handling it and am sure NCSIM can extend that for SV in future. Finally - it is methodology than "can I do it", so adopt a good methodology with SV.My 2 cents!Ajeetha, CVCwww.noveldv.com
Hello Ajeetha,Thanks a lot for your suggestions! My workmates always ask for "force" and I have to ask it here though I know "force" is not a good style and hard to reuse.Since now we are under evaluation procedure of using SystemVerilog (And class-based uRM is not ready now), I have another question below. We know global variable can be put to package. So can I put/instance all the Mailbox/queue which containing transactions into one package (I may call it Transaction Mailbox package). Thus all the transactor access the Mailbox package to put/get transactions. I think it more easy for other SV newbie to understand. Do you think it is a good way?Any comments will be appreciated!Best regards,Davy
>> Thus all the transactor access the Mailbox package to put/get transactions. Well I don't believe one can truly "instantiate" a mailbox inside a package - though I may be wrong. Atleast not in a VHDL like package world.>> I think it more easy for other SV newbie to understand. Do you think it is a good way?No I would highly discourage such a methodology. For a plain Verilog user this sounds OK - but it means that you can't easily port block level to system level etc. A much better option is to architect your TB in layers and have every layer talk to each other via "mailbox" or channel/TLM Fifo etc.Take a look at VMM/AVM examples for some snippet. Maybe URM has some public domain examples to demo how they propose to do this, but I have not seen them.RegardsAjeetha, CVCwww.noveldv.com
Hello Ajeetha,To make other no OO background designer to be familiar with SV is a hard job. And I will turn to the examples you recommend.Best regards,Davy
Davy, >> To make other no OO background designer to be familiar with SV is a hard job I understand and am hearing similar message from local DV engineers on top of my own learning experience. I know it is not a viable option for you right now, however we at CVC are really specializing on exactly this topic - "Incremental adoption of SV", we have clear step-by-step guide to make the migration and at each step we can see/measure the benefit. We plan to roll this out in less than a month or so. Maybe we can do a webinar of some sorts to enable you being in China :-)I don't know the financial involved in hosting a webinar and I may seek an EDA Vendor help etc. I am still learning those non-technical skills to do them faster :-)RegardsAjeetha, CVCwww.noveldv.com
Hi Ajeetha,Looking forward to your webminar and myself also need the instruction of incremental adoption of SV :-)Best regards,Davy
Hi Davy,It would probably make sense for you to read the documentation on http://myipcm.cadence.comSV is just another language and like all languages there will be some constructs and applications that you will find easy and intuitive and other syntax/semantics will appear difficult.Like Ajeeta said its all about having the correct methodology for achieving your solutions, then you can implement the solution using constructs which make sense to you.Within the Universal Reuse Methodology there are already various styles of implementation for creating powerful reusuable components. If you are not very familiar with OO or simply dont want to stray too far from the style of constructs typically used by design engineers then I would suggest you choose the Designer Orientated: "Module Based with classes" implementation for your verification components.thanksAdiel
Hi Adiel,Thanks a lot for the information. It seems the IPCM6.1 document will come shortly. I will wait to see the Cadence Class-based methodology and decide whether to write solution by myself.Best regards,Davy