I wonder if the modules have any visibility into the hierarchy of the ports? Can the port hierarchy be printed out?
For a minimum working example, assume I have this:
module top ();
logic my_sig;
child ichild (.sig(my_sig));
endmodule : top
module child (input logic sig);
initial $display(/* SystemVerilog-Fu here */)
endmodule : child
I expect the $display to print top.my_sig -- or something that conveys my_sig name instead of just reading out the value. I looked into the DPI guide as well, but it doesn't seem to have any such facility.
Thanks in advance!
The DPI is for behavioral modeling interoperability between SystemVerilog and C. The VPI gives you the introspection you are looking for in from C. Also, many tools have a command line interface (find signals -ports in Modelsim/Questa without having to learn a complicated C API.
Explaining how to do this is too deep a discussion for SO. I suggest you read my DVCon 2016 paper on SystemVerilog introspection with examples here.
Related
I want to do something like this:
module BusinessLogicVersion_1(clk, rst, d, q);
// Erudite business logic goes here
endmodule
module BusinessLogicVersion_2(clk, rst, d, q);
// Different implementation of same interface.
endmodule
// Then, when instantiating the module that requires an implementation of whatever interface,
// I want to do something like this:
ModuleXyz #(
.business_logic(BusinessLogicVersion_2) // <--- Pass an implementation of an interface as parameter
) (.clk(clk), .rst(rst), ...);
I have tried to find ways to do this, and from what I've read SV does not allow it.
My question is:
Is there a technical reason why this shouldn't be possible?
Technically, nothing is technically impossible in software given enough time, space and money! StackOverflow is not the forum for why kinds of questions.
SystemVerilog has a different approaches that implements what you are looking for. One way is called a configuration (See section 33. Configuring the contents of a design in the IEEE 1800-2017 SystemVerilog LRM).
For your case, what you would do is compile different versions of same module name ModuleXyz into different libraries and then use either command line options or a config block that selects which version to be selected for different instances. I would look at the LRM for examples.
The other method is using a _generate construct to select different modules you want instantiated. See section 27. Generate constructs. This is simpler, but less flexible since you have to know upfront which versions are available.
case(VERSION):
1: BusinessLogicVersion_1 inst (clk, rst, d, q);
2: BusinessLogicVersion_2 inst (clk, rst, d, q);
default: $error("Version does not exist");
endcase
I assume you're trying to do some kind of dependency injection, where the modules you're passing in are supposed to be different strategies. Also, I see from your profile that you're familiar with C++, so I'll try to map what you're trying to do onto that language. (Beware of gross simplifications or not-so-accurate analogies.)
A SystemVerilog module is akin to a C++ class. By passing a module name to you ModuleXyz, you're trying to do something like pass a class as a function argument in C++. This isn't possible in that language either. You generally pass instances of classes.
In order to pass an instance of a class, you'd need to first construct it. This would mean passing it your desired constructor arguments. Your module has ports, which are conceptually similar to a class's constructor arguments. When you instantiate a module, you connect its ports.
In your example, I'm guessing you would like to pass in the type of module that ModuleXyz should instantiate inside. In C++ you would generally pass a factory object, which knows how to construct the object you need, with the constructor arguments you want. This pattern isn't possible with modules, as only "direct" instantiation is allowed.
As #dave_59 pointed out, switching out module types is done using configurations. It's sort of like doing dynamic loading of different shared libraries, to switch out the implementations.
If your simulator doesn't support configurations (as language constructs), it will usually provide compile switches that allow you to implement something similar. It will compile different versions of the module, but you will be able to choose which one gets "linked".
If you really, really need to use dependency injection, I'd suggest you try to migrate your code from trying to pass modules, to passing interfaces. It is possible to pass instances of those around. Just remember, that you'll be passing already constructed instances, not types.
Can somebody please educate me why we need DPI-C function import to do UVM specific functions like uvm_hdl_force or uvm_hdl_deposit even when force and deposit system verilog constructs exist? What extra flexibility does the C functions give with these regards?
Thanks in advance
There's no deposit functionality in SystemVerilog, only force. Although most tools give you deposit functionality, there is no standard way to deal with it. The DPI-C give you a tool independent method.
UVM REG gives you the ability to look-up registers by string name, and build paths from string hierarchies. Although there are ways of creating this functionality without resorting to the DPI/VPI, it's far easier to use the VPI.
If your DUT is VHDL, there is no standard for interoperability between standards with hierarchical references across language boundaries.
As I know, nowadays the 'reg' type in systemverilog can used in assign statement.
In old fashion, the assign statement does use the only the 'net' type.
So I want to know that what kind of the signals are should have to be the 'net' type in systemverilog?
Update1
From here, http://www.testbench.in/IF_01_INTERFACE.html
I can find a interface declaration.
interface intf #(parameter BW = 8)(input clk);
logic read, enable;
logic [BW -1 :0] addr,data;
endinterface :intf
At this here, I want to know that why the read and enable and addr and data signal are clared logic data type? Is there any reason? Why not used reg or wire?
A net is used when there are multiple drivers on a signal, usually in conjunction with a bi-directional port, and for designs at the switch level that require strength to operate. See http://go.mentor.com/wire-vs-reg for more details.
Regarding the usage of net Dave's answer pretty much covers it.
From the IEEE Std 1800-2012,
The keyword reg does not always accurately describe user intent, as it
could be perceived to imply a hardware register. The keyword logic is
a more descriptive term. logic and reg denote the same type.
More info on the usage of logic can be found in below links.
1) Morgans answer
2) Greg's answer
I have the following code, file c.sv:
virtual class C#(parameter W = 32); // line #2 where error message points
static function logic [W-1 : 0] f(input logic [W-1 : 0] in);
return ~in;
endfunction
endclass
I then call it from top.sv:
`include "c.sv"
module top(input wire [3:0] key, ouptut wire [3:0] led);
assign led = C#(4)::f(sw);
endmodule
In ModelSim 10.3d it works fine, but Quartus II x64 15.0.1 build 150 reports this error after Analysis & Synthesis:
Error (10170): Verilog HDL syntax error at c.sv(2) near text "virtual"; expecting a description
If I comment out inlcude "c.sv" and replace function call with a simple ~led then it works in the dev board.
What am I doing wrong?
Sadly, there is no way currently to support parameterised functions in Altera Quartus. You have the following courses of action available:
Raise a support ticket with Altera
Use a third-party synthesis tool and feed the netlist into Quartus
Re-factor your code to be less generic
Option 2 will of course involve forking out a non-trivial sum of money. Synopsys Design Compiler supports this construct, your mileage may vary with other tools.
For option 3 you could resort to macros, generated code or optional file compilation to achieve a similar result.
It's somewhat depressing that this capability isn't available to Altera FPGA users. For the benefit of the community please raise a ticket regardless of the course of action you choose. The more demand there is, the more likely Altera are to implement this feature.
There is some more discussion and prototyping of possible work-arounds that don't involve classes on the "Width independent functions" question.
A friend of mine needs to implement some statistical calculations in hardware.
She wants it to be accomplished using VHDL.
(cross my heart, I haven't written a line of code in VHDL and know nothing about its subtleties)
In particular, she needs a direct analogue of MATLAB's betainc function.
Is there a good package around for doing this?
Any hints on the implementation are also highly appreciated.
If it's not a good idea at all, please tell me about it as well.
Thanks a lot!
There isn't a core available that performs an incomplete beta function in the Xilinx toolset. I can't speak for the other toolsets available, although I would doubt that there is such a thing.
What Xilinx does offer is a set of signal processing blocks, like multipliers, adders and RAM Blocks (amongst other things, filters, FFTs), that can be used together to implement various custom signal transforms.
In order for this to be done, there needs to be a complete understanding of the inner workings of the transform to be applied.
A good first step is to implement the function "manually" in matlab as a proof of concept:
Instead of using the built-in function in matlab, your friend can try to implement the function just using fundamental operators like multipliers and adders.
The results can be compared with those produced by the built-in function for verification.
The concept can then be moved to VHDL using the building blocks that are provided.
Doing this for the incomplete beta function isn't something for the faint-hearted, but it can be done.
As far as I know there is no tool which allow interface of VHDL and matlab.
But interface of VHDL and C is fairly easy, so if you can implement your code(MATLAB's betainc function) in C then it can be done easily with FLI(foreign language interface).
If you are using modelsim below link can be helpful.
link
First of all a word of warning, if you haven't done any VHDL/FPGA work before, this is probably not the best place to start. With VHDL (and other HDL languages) you are basically describing hardware, rather than a sequential line of commands to execute on a processor (as you are with C/C++, etc.). You thus need a completely different skill- and mind-set when doing FPGA-development. Just because something can be written in VHDL, it doesn't mean that it actually can work in an FPGA chip (that it is synthesizable).
With that said, Xilinx (one of the major manufacturers of FPGA chips and development tools) does provide the System Generator package, which interfaces with Matlab and can automatically generate code for FPGA chips from this. I haven't used it myself, so I'm not at all sure if it's usable in your friend's case - but it's probably a good place to start.
The System Generator User guide (link is on the previously linked page) also provides a short introduction to FPGA chips in general, and in the context of using it with Matlab.
You COULD write it yourself. However, the incomplete beta function is an integral. For many values of the parameters (as long as both are greater than 1) it is fairly well behaved. However, when either parameter is less than 1, a singularity arises at an endpoint, making the problem a bit nasty. The point is, don't write it yourself unless you have a solid background in numerical analysis.
Anyway, there are surely many versions in C available. Netlib must have something, or look in Numerical Recipes. Or compile it from MATLAB. Then link it in as nav_jan suggests.
As an alternative to VHDL, you could use MyHDL to write and test your beta function - that can produce synthesisable (ie. can go into an FPGA chip) VHDL (or Verilog as you wish) out of the back end.
MyHDL is an extra set of modules on top of Python which allow hardware to be modelled, verified and generated. Python will be a much more familiar environment to write validation code in than VHDL (which is missing many of the abstract data types you might take for granted in a programming language).
The code under test will still have to be written with a "hardware mindset", but that is usually a smaller piece of code than the test environment, so in some ways less hassle than figuring out how to work around the verification limitations of VHDL.