I have a testbench declared as
module test_circuit
logic a,b,c;
logic y;
circuit UUT (.*); //what does this line mean?
initial begin
//something here
end
endmodule
I haven't found any tutorials which tell me what it means. I have looked at the language reference manual and it says it is a 'wildcard pattern', but doesn't go into enough detail.
Otherwise... it is difficult to search special character in any search engine, and results which I found seem to only be related to other languages.
It is actually described pretty extensively in the SystemVerilog LRM. Take a look at Section 23.3.2.4 Connecting module instances using wildcard named port connections (.*). Quoting the first part of this section:
SystemVerilog can implicitly instantiate ports using a .* wildcard syntax for all ports where the instance port name matches the connecting port name and their data types are equivalent. This eliminates the requirement to list any port where the name and type of the connecting declaration match the name and equivalent type of the instance port.
To reflect this onto your example: assume the module circuit has the ports a, b, y, and d.
You could connect them fully explicit as described in Section 23.3.2.2 in the LRM. This is necessary if the names or widths do not match:
circuit UUT
(.a (a),
.b (b),
.c (c),
.y (y));
You could also use implicit named port connections (Section 23.3.2.3 of the LRM):
circuit UUT
(.a,
.b,
.c,
.y);
However, the quickest way if you do not want to type out all ports is to make sure the names and types of the signals match through the hierarchy. Then, you can simply use wildcard named port connections:
circuit UUT
(.*);
Please keep in mind that this last method may make it hard to debug your RTL, since it becomes harder trace signals at a high level.
Bonus: In addition to the LRM, take a look at Sutherland & Mills paper Synthesizing SystemVerilog - Busting the Myth that SystemVerilog is only for Verification. Section 7 gives a great summary on the different types of port connections and on the advantages of dot-name and dot-star connections.
In addition to Silicon1602's answer, you can also do this, which means that variable aa is connected to port a and every other port is connected to variables of the same name:
circuit UUT
(.a(aa),
.*);
Related
In the documentation it is indicated, that cardinality() function is deprecated and should no longer be used. However, it is still used in the libraries such as ThermoSysPro.
e.g.
if (cardinality(C) == 0) then
some code
end if;
where C is FluidInlet or FluidOutlet
Could anyone give a simple example of how it could be replaced?
The usual solution is to make the connector conditional, and if enabled you require that it is connected.
For physical connectors you can see how heatports and support is handled in:
Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort
Modelica.Mechanics.Rotational.Interfaces.PartialElementaryOneFlangeAndSupport2
For control signals you can see how p_in, h_in etc are handled in
Modelica.Fluid.Sources.Boundary_pT
Modelica.Fluid.Sources.Boundary_ph
However, the connectors of ThermoSysPro belong in neither of those categories and that should ideally also be cleaned up.
The only thing I know, that could be used in this regard, is the connectorSizing annotation. It is described in the MLS chapter 18.7.
It is used a number of times in the Modelica Standard Library, e.g. in Modelica.Blocks.Math.MinMax via the parameter nu. When using it, the tool automatically sets the modifier for nu according to the number of connections to it.
parameter Integer nu(min=0) = 0 "Number of input connections"
annotation (Dialog(connectorSizing=true));
Modelica.Blocks.Interfaces.RealVectorInput u[nu];
In the example below, nu=2 is generated by Dymola automatically when creating a connection in the graphical layer. I have removed the graphical annotations, to make the code more readable.
model ExCS
Modelica.Blocks.Math.MinMax minMax(nu=2);
Modelica.Blocks.Sources.Sine sine(freqHz=6.28);
Modelica.Blocks.Sources.Constant const(k=0.5);
equation
connect(sine.y, minMax.u[1]);
connect(const.y, minMax.u[2]);
end ExCS;
The cardinality() operator is used in Modelica.Fluid.Sources.BaseClasses.PartialSource, and in a similar way in other fluid libraries (IBSPA, AixLib, Buildings, BuildingSystems and IDEAS), in the form
// Only one connection allowed to a port to avoid unwanted ideal mixing
for i in 1:nPorts loop
assert(cardinality(ports[i]) <= 1,"
each ports[i] of boundary shall at most be connected to one component.
If two or more connections are present, ideal mixing takes
place with these connections, which is usually not the intention
of the modeller. Increase nPorts to add an additional port.
");
end for;
I occasionally had models from users who somehow ended up with more than one connection to a ports[i]. How this happened was not clear, but I find the use of cardinality() useful to catch such situations, which otherwise can yield to mixing in the fluid port which the user did not intent and which are hard to detect.
I have a question on `default_nettype directive of SystemVerilog.
By default, the following code is ok.
module m1 (
input logic i1,
output logic o1
);
logic l1;
assign l1 = i1;
assign o1 = l1;
endmodule
However, when I change the default net type to none:
`default_nettype none
only i1 causes an error:
ERROR: [VRFC 10-1103] net type must be explicitly specified for i1 when default_nettype is none ...
My question is why only input logic i1 causes an error and requires explicit wire, but output logic o1 and logic l1 does not.
Verilog has too many implicit rules to accommodate lazy programmers (i.e. people who were interested in designing hardware, not writing software)
This error is explained in section 23.2.2.3 Rules for determining port kind, data type, and direction
For the first port in an ANSI style port list:
If the port kind is omitted:
For input and inout ports, the port shall default to a net of default net type. The default net type can be changed using the
`default_nettype compiler directive
This implicit 'net' port rule is the opposite of what is used when declaring output ports, and all other declarations outside of ports. The reason behind this is that input ports are an overwhelmingly majority of ports used in a module, and keeping ports connections as wires allows for port collapsing, which is more efficient for simulation.
This is the confusing part of SystemVerilog. Your code works on my simulator, that outputs a warning instead of an error.
If you dive enough in help messages you get that the "type" of the identifier (as in net versus var, opposing to "datatype" which is logic or whatever else) is context sensitive, and specifically input ports are by default nets, while output ports are by default variables. This means that with "default_nettype none" all your input ports are effectively not fully described, because the compiler does not know the resolution function for the net (you might want a wand, for example). Your output ports, being variables, need no resolution function and so no error is thrown there.
Since you cannot really connect the same port to more than one signal unless you really try to this seems redundant to me, but it might be needed due to net coercion rules for elaboration if the input net is driven by more than one assign elsewhere in the design.
My understanding is that "default_nettype none" is mostly used to ensure you do not have undeclared identifiers (leading to width mismatch due to single bit inference) and a port is declared, so you might check if your tool has the option of inferring a wire for ports anyway (again, my simulator outputs a warning and does this by default, and the synthesizer does not complain either).
Other than that, the only workaround I see is going for "default_nettype none" first thing after the ANSI port declaration and "default_nettype wire" last thing before endmodule, in every module.
We cannot do that, as per 1800-2017 22.8:
The directive `default_nettype controls the net type created for implicit net declarations (see 6.10). It can be used only outside design elements.
The reference for implicit net declaration is section 6.10 in IEEE 1800-2017, although following the mentioned sections from there seems to point to non-ANSI declarations only... you might need a deeper dive to fully understand the matter.
I have a module that is instantiated many times in other modules. Two of the inputs to this module are used very rarely, and to avoid code bloat I don't want to have to connect them in every instantiation. Is there a way to mark these two ports to the compiler to indicate they can be left unconnected?
eg.
module mymod(input logic foo, unused1, unused2, output logic out);
//...
endmodule
module top(...);
//...
mymod(.foo(1'b0));
endmodule
will not compile due to port mismatch errors. How can I change the code so unused1 and unused2 don't need to be connected?
Yes, you can specify a default value for a unconnected port (See 23.2.2.4 Default port values in the 1800-2017 LRM)
module mymod(input logic foo, unused1='0, unused2='0, output logic out);
//...
endmodule
Another option is to explicitly leave these ports unconnected when instantiating.
mymod(.foo(1'b0), .unused1(), .unused2() );
But in either case, your tool may have specific requirements with unconnected ports that you will have to deal with as they ask you to do.
in UVM e Reference document is written:
You can call read_reg_field or write_reg_field for registers whose fields
are defined as single_field_access (see “vr_ad_port_unit Syntax and Examples”).
...
For example:
write_reg_fields tx_mode_reg {.resv = 4; .dest = 2};
But there is no example for using read_reg_field...
Could you please explain how should it be used?
(I've tried the next code, but it gives compilation error:
some_var = read_reg_field my_reg_file.my_reg {.my_reg_field} )
Thank you for your help.
As far as I know there is no read_reg_fieds macro. If you want to do a read to a register and then save the value of a certain field, do this:
read_reg my_reg;
value = my_reg.my_reg_field;
Normally, when you read register, you read them completely. Reading only individual fields makes sense if your bus protocol allows narrow transfers (i.e. your data width is 32 bits, but you can do 16 bit transfers on it). I haven't seen such a thing implemented in vr_ad (could be there and I just don't know of it), but UVM RAL (the SystemVerilog register package) supports it.
Long story short, if you just care about getting your data from your DUT, using read_reg is enough.
When the Design Under Test is implemented in verilog or vhdl - you can read the register as a whole, you cannot "read just some of its fields".
A register is at a specific address, reading this register -> read from this address.
The quote of the spec about fields access is when the DUT is a SystemC model.
Connecting to SC models is done using ports. If the model defines a port for each field - you can read a field.
I defined an interface in system verilog and use bind statement to bind to internal RTL signals. I want to be able to force internal RTL signals through the interface. However, this is causing the RTL signal to go to 'x' if I don't force these signals explicitly, it seems bind to interface is having driving capability. I don't want RTL signal to change to 'x' when nothing is forcing it in this case, not sure what I am doing wrong here?
my code looks like this with DUT being the design:
interface myInf(
inout RTL_a,
inout RTL_b
);
bind DUT myInf myInf_inst(
.RTL_a(DUT.a),
.RTL_b(DUT.b)
);
bind DUT myDrv(myInf_inst);
where myDrv is a module which drives the ports on myInf.
In this case, DUT.a and DUT.b are internal RTL signals, they have their driver from design, but I want to be able to force them if needed. however, these signals becoming 'x' when I am just binding them to myInf without actually driving them.
The inout signals might be a non-net type. It is better to be explicit in the the declaration and define them as inout wire. Inside the interface, assign the nets to a logic and initialize the logics to z. A non-z value will apply a driver while a z will allow signals to drive. Example:
interface myInf(
inout wire RTL_a,
inout wire RTL_b
);
logic drv_a, drv_b;
initial {drv_a,drv_b} = 'z; // z means not driving
assign RTL_a = drv_a;
assign RTL_b = drv_b;
endinterface
There might be conflicting drivers, such as the normal drivers from the design. In this case you will need to override the driver. Assuming the signal being overrode is a net type, this is done by changing the assign statements to assign (supply1,suppl0) RTL_a = drv_a;. This is utilizing the Verilog concept of drive strength. Assigning to z will still all other drivers. Most nets are driven with a strength of strong1,strong0 which is weaker then supply1,supply0. Drive strength will not work for non-net types (e.g. logic & reg). These register/variable-types use a last-assignment-wins approach. Fore more on drive strength read IEEE Std 1800-2012 sections 28.11 through 28.15
Your sample code has some bugs. The pin connections for myInf_inst should use hierarchical references relative to its target scope. Unless there is an instance called DUT inside module DUT, then the DUT. should be omitted (See IEEE Std 1800-2012 § 23.11 Binding auxiliary code to scopes or instances). The bind statement for myDrv is missing an instance name. The code should be:
bind DUT myInf myInf_inst(
.RTL_a(a), // no DUT.
.RTL_b(b) // no DUT.
);
bind DUT myDrv myDrv_inst(myInf_inst);
sample code: http://www.edaplayground.com/x/2NG