Complex port connection in Verilog - verilog

Please help to understand the following syntax of verilog port definition.
module same_port (.a(i), .b(i));
// Name ’i’ is declared inside themodule as a inout port.
// Names ’a’ and ’b’ are
// defined for port connections.
Is this connection legal?

Yes, this is legal. It looks like you took this example straight from section 23.2.2.1 of the standard (Non-ANSI style port declarations). As it says there you have two ports a and b which are both connected to internal net i. When you instantiate this module you can use named port connections to connect two different things to i:
same_port inst(.a(connection1), .b(connection2));
In the above instantiation, both connection1 and connection2 will be connected to inst.i.
Even though this is legal, I would advise against using it unless you have a good reason to. This is not very commonly used syntax and could cause confusion for someone else looking at your code. The only place I have seen this is in a verilog netlist automatically generated from an schematic.

Related

Assign value to only one bit in a vector module output

I have the following code and I get an error. I am trying to use only one bit out of the four lines in the inputs A, B, and the output, Y. To be clear, I do not want to use the AND operator, I want to use the AND module that I made.
AND_Gate_Quad_SN74AHCT08N and0(.A({3'bzzz,clk_disable}), .B({3'bzzz,clk}), .Y({3'bzzz,clk_buffer}));
What would be a good way to accomplish this?
An output port cannot be connected to numeric literal constant.
There at least three options I can think of
Do a simple connection and live with a port size mismatch warning .y(clk_buffer)
Declare as a 4-bit wire [3:0] clk_buffer and only use clk_buffer[0].
Create a 3-bit dummy_wire and use the connection .y({dummy_wire,clk_buffer}).

Bidirectional assignment in Systemverilog

I need to create mux block that works with inout pins.
My module has n inputs and n outputs, I want to be able to switch
between different outputs.
The problem that I am currently having is that I need to do that with
inout pins. So if my output pin is pulled down, the input pin of the
mux shall see that. This doesn't work with a common assign statement since
it will only write in one direction. I have tried an alias statement, which
works like a bidirectional assign, but I can not combine this with an if statement for the mux.
What I want to do:
alias net_out = (config) ? net1 : net2;
I have created an example on edaplayground
Thanks in advance,
Patrick
You can use the bidirectional tran primitives, which is exactly how one would implement this in MOS hardware.
tranif1(net_out, net1, config);
tranif0(net_out, net2, config);
If you are looking to do this in hardware, this has to be something your technology supports. Most FPGAs would not support this.
However, if this config signal was a parameter and not a variable, you could use the alias statement with a generate-if
if(config)
alias net_out = net1;
else
alias net_out = net2;

How to buffer a System Verilog interface

Just came across this issue and after doing a little reading, it seems that this isn't allowed in System Verilog, but it seems a little obtuse and I wonder if I am missing some easy workaround.
I have an interface that was defined as if_datapath. The interface does have some modports called sink, source and monitor and I am able to use the interface on modules without issue.
However, if I define a the interface within a module as nither sink, source or monitor:
if_datapath #(.EW(5),.DW(256),.SW(64),.QW(32)) dp_buf_0 (.clk(clk), .reset(reset));
I can use this to route my interface through hierarchy. But if instead of using it for routing, I write the following:
always # (posedge clk)
begin
dp_buf_0 <= dp_in; // Where dp_in is the same kind of
//interface as dp_buf_0
end
I get an error that says:
An instance name is not a legal lvalue [7.1(IEEE)].
So if I want to register my entire interface, I need to break out the individual parts? Tell me I am missing something here.
Interfaces and modules are just containers that create hierarchical name spaces for the items inside those containers. They also give you ways of making connections the signals within those containers. Interfaces give you a few more ways of making connections, and a modport is a construct that limits access to things inside the interface.
Interfaces are not data types, and interface instances are not variables, so you cannot perform the same kinds of operations that you would on a variable.
But you can define a struct as a data type, and then create a wire or variable using that data type. Then you can perform all the same operations that you could on a wire or variable.

Simple Questions to Verilog I can't seem to find answers to:

In a Verilog module, what is the proper terminology for arguments?
What does a variable default to when it's not defined?
A module in Verilog represents hierarchy that is only used for grouping objects by name and replicating those objects. When you run a simulation or synthesize to hardware, that hierarchy gets flattened. Ports of a module join two signal names together, and after flattening, there is only one signal with multiple names. So modules are structurally connected through ports.
The term argument is terminology from software that usually represents a object that gets copied or referenced when you procedurally call a routine like a function or task.
For your second question, if you refer to a variable without defining it, that is usually a compiler error. There is one exception to that for lazy engineers. If you refer to a undefined variable in a port connection, that variable is implicitly declared as a 1-bit wire. If nothing drives that wire, it has the default value 'z which is treated the same as 'x in any expression.
This feature was originally intended for automatically generated gate-level net-lists where every signal is a 1-bit wire, but causes many problems for RTL descriptions. We strongly recommend that use use the compiler directive `default_nettype none to prevent careless typos.
They are called ports . A Verilog module cannot be called like a function, as it is meant to represent a hardware module with input , output , bi-directional pins etc , so it can only be instanced. These instances can be connected to each other again via their ports. These ports bring in and take out data/value/signals into and out of the modules. Hence ports have direction associated with them. Unlike an arguments in a function which only passes on the value when the function is called , once a connection is made to a port ( via a wire/reg (register) / ...) any change to the connected variable is transferred to the module via the port automatically.
link to a module- port explanation.
http://www.asic-world.com/verilog/syntax2.html
Verilog does have functions and tasks which take arguments.
http://www.asic-world.com/verilog/task_func1.html
Uninitialized variables take on unknown value represented by "x" .
There are a few nuances to it
unconnected wire , tri will be tri-state represented by "z"
any 4 state logic - reg , integer , time will default to "x"
real type to 0 .

SystemVerilog port kind [net or variable]?

I need a clarification on SystemVerilog IEEE Std 1800-2012, ports section 23.2.2.3.
The LRM says when the port kind (net type or variable) is omitted on input port, it defaults to net type, but when the input port is of bit data type without specifying the port kind, does it infer to net type according to LRM?
A reply would be highly appreciated!
The port kind defaults to a net and you referenced, but 6.7.1 Net declarations with built-in net types says that net types are restricted to 4-state integral types. So you should get an error if you try to declare input bit instead of input var bit.
Note that earlier versions of the SystemVerilog LRM had the default port kind a variable when specifying a data type without a port kind. Some tools might not generate an error if they are not up to date.
"bit" only specifies the data type, not the net type, of a signal.
When you declare a port as "input bit foo", the tools are supposed to infer net type based on whatever `default_nettype is set to.
A number of verilog style guides have recommended "`default_nettype none" as a poor-mans linting tool to detect typos in net names. This breaks under systemverilog, in so far as it then starts requiring that everything be declared with both a net and a data type, like this:
input wire bit foo
Everybody hates that, so instead:
don't use "`default_nettype none"
use a real linting tool to do linting instead.

Resources