Here I have a simple example below.
module A(o,clk,rst,i);
output o;
input i,clk,rst;
...
endmodule
and here is an interface class definition below.
interface my_if(input bit clk);
logic o,rst,i;
wire clk;
clocking cb#(posedge clk);
input o; // why input here ?
output i,rst; // why output here ?
endclocking
...
endinterface
My question is how to decide the signal inside cb is input or output ??
Thank you !
There are many uses of input/output in SystemVerilog, which can be confusing.
For ports, they the flow of data across a boundary. For a clocking block, they represent whether a signal is passively being sampled, or actively driven. Depending on the situation, it is perfectly reasonable to have a port declared as an output, and the same signal declared as a clocking block input.
Related
I would like to understand how tasks in System Verilog work. I thought that a task was just a way of naming and parametrising a bit of code that could otherwise appear enclosed between a begin and an end. However, the way that the parameters work is non-obvious.
Say I want to factor out instances of non-blocking assignments from a module. I might do something like the following, thus reaching the point where there are two instances of the same task that differ just in the parameters (ff_0 and ff_1).
module test_inlined;
bit clk;
int count = 0;
logic [7:0] x, y, z;
task automatic ff_0;
#(posedge clk);
y <= x;
endtask
task automatic ff_1; // really same task as ff_0 to within variable renaming
#(posedge clk);
z <= y;
endtask
always
ff_0;
always
ff_1;
always #(posedge clk)
$strobe("%d: x=%d, y=%d, z=%d", count, x, y, z);
always
#5 clk = !clk;
always #(posedge clk)
begin
x <= count;
count ++;
if (count > 20) $finish;
end
endmodule
It would be trivial to instead place the factored out assignments (aka flip-flops) into two instantiations of the same module, so it would make sense for it to be also possible to express the same functionality in terms of two instances of the same task.
The following does not work because out is supposedly automatic, or that is what Modelsim claims. I do not see why it would be since it is fairly obviously a reference to a static member of a module?
task automatic ff (ref logic [7:0] out, ref logic [7:0] inp, ref bit clk);
#(posedge clk);
out <= inp;
endtask
module test_broken;
bit clk;
int count = 0;
logic [7:0] x, y, z;
always
ff(y, x, clk);
always
ff(z, y, clk);
// .... same as before
endmodule
It does make sense that the tasks need to be automatic to use ref parameters because then there is no need to worry about their lifetime. It is less clear why only blocking assignments to an automatic variable would be allowed. It is not like there is any obvious need for auto variables to go away while there are pending non-blocking assignments?
How do I factor out non-blocking assignments into a task, please? Many thanks in advance.
The problem is that task cannot assume anything about the storage classification of the variable passed to it. The code generated for the task has to work for any kind of storage, so passing by ref has to take on the pessimistic set of restrictions.
If I have both alwas_comb and always_ff in a single module, which one executed first?.
for example, I have seen this code in a book but I am confused about the functionality. for example, if WE=0 what will be the value of Qout?
module SyncRAM #(parameter M = 4, N = 8)(output logic [N-1:0] Qout,
input logic [M-1:0] Address, input logic [N-1:0] Data, input logic clk, WE);
logic [N-1:0] mem [0:(1<<M)-1];
always_comb
Qout = mem[Address];
always_ff #(posedge clk)
if (~WE)
mem[Address] <= Data;
endmodule
Any help about the truth table of this code is appreciated,
regards
The specific answer to your question is that Qout will just track the value of mem[Address]. In other words, on the rising edge of the clock, if WE is 0, Qout will be driven with the value written to the memory. This is because the memory will behave like a bank of flip-flops, while the Qout output will behave as if it is directly connected to the Q output of a bank of flip-flops.
The order of the execution of the two always blocks is deterministic, because Qout is driven using a blocking assignment (=), whereas the memory is written to using a non-blocking assignment (<=). See the answer here for much more detail.
I use Xilinx system generator blocks in Matlab and i find the block black box wich can generate and simulate vhdl code. I programme a simple program in vhdl for port and,
--import std_logic from the IEEE library
library ieee;
use ieee.std_logic_1164.all;
--ENTITY DECLARATION: name, inputs, outputs
entity andGate is
port( A, B : in std_logic;
F : out std_logic);
end andGate;
--FUNCTIONAL DESCRIPTION: how the AND Gate works
architecture func of andGate is
begin
F <= A and B;
end func;
I simulate in xilinx with blackbox and i make simulation mode ISE Simulator because i use xilinx .
I apreciate any kind of help thanks :)
check your gateway in, you should select its output as Boolean
also, check the sampling time of the system, you should make all equal to 1
I been assigned to manually convert the below RTL into its structural equivalent. I don't understand how you'd convert it. What's the structural description for this code in verilog? What steps should I take?
module cou(
output reg [7:0] out,
input [7:0] in,
input iti,
input c,
input clock);
always #(posedge clock)
if (iti == 1)
out <= in;
else if (c == 1)
out <= out + 1;
endmodule
Here is the basic process:
always #(posedge clock) tells you you have positive-edge D-flip-flops without an asynchronous reset or set.
out is the only value being assigned within the always statment. The size of out tells you the number of flops needed.
Drawing a component level schematic diagram can help visualize the structural logic.
Now all that is needed to figure out is the combination logic to the flop's D pin. I'll give you a clue that it can be done using only muxes and an adder.
I am writing a test bench for Ripple counter using d flip flop. My program is compiling without errors, however, I get undefined result. How can I solve this problem?
Here is the code:
module RCounter;
reg d,d2,d3,d4,clk;
wire q,q2,q3,q4;
DFlipFlop a(d,q,clk);
DFlipFlop a1(d2,q2,q);
DFlipFlop a2(d3,q3,q2);
DFlipFlop a3(d4,q4,q3);
initial
begin
clk =1;
d=0;d2=0;d3=0;d4=0;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
end
always
begin
#2 assign clk = ~ clk;
end
endmodule
What am I doing wrong and how can I solve this?
What you have there is not a ripple counter, and it seems that you don't really understand the boundary between your testbench and your DUT (design under test, or in your case, the 'ripple counter').
What you have is a testbench that is simulating four independent flip flops. If you were simulating a ripple counter, you should have a module called something like 'RCounter', which is instanced inside something else called 'RCounter_TB'. The testbench should only drive the inputs (for a counter, clock and reset), it should not drive the d pins of the individual flops, as the connections between these flops is what you want to test.
Inside the ripple counter module, you define the wired connections between your flip flops. There should not be any # time delays inside this module, because a module does not have a concept of fixed time delays. If you want the d2 pin to be driven from ~q2, then you just assign it as such:
assign d2 = ~q2
Because in hardware, this is just a wire looping back from the output of ~q2 back to d2. It always exists, and it has no concept of time.
As to specifically why you're getting X's on your output, I'll guess that it comes from the flip flop design you posted in your last question.
module DFlipFlop(d,q,clk);
input d,clk;
output q;
assign q = clk?( (d==1)? 1:0) : q;
endmodule
This is not a flip flop, as there is no state retention here, it's just an assign statement with an infinite feedback loop, (you essentially just have a wire driving itself).
If you want to model a flip flop, you need to use an always #(posedge clk) block, to imply that you want some state retention. I'll leave it to you to look up how to use an always block to model a flip flop.