module top(
input [59:0] first,
input [59:0] second,
output out
);
wire [14:0] out_wire;
assign first[19:0]= 20'b1111111111111111111;
assign first[39:20]= 20'b0000000000000000000;
assign first[59:40]=20'b11001100110011001100;
.....
...
..
I am getting the error in the title when synthesizing if I include the assign statements. How do I initialize these 3 assignment values to first[59:0] properly?
The whole design is combinational.
You say
You want to inialise the values.
The whole design is combinational.
That is contradictory. Combinational signals always have a value assigned to them. you can't initialise them, not even with an initial statement.
Thirdly: Your first is an input.
If you want to assign a value to that it must be done outside the module. Thus you must make sure that whatever is driving your 'first' has the correct initial value. If that is a testbench you have to solve the problem there.
Related
module test #(parameter WIDTH = 4) (output wire [WIDTH-1:0] result, input wire input );
// synopsys template
assign result = {WIDTH{input}};
endmodule
In this code, {input} after WIDTH means what? In what way that affects the parameter?
The curly brackets, preceded by the parameter, are called the replication operator.
assign result = {WIDTH{input}};
makes WIDTH copies of the 1-bit input-signal and assigns it to the WIDTH-bit output signal result. This means that input does thus not affect the parameter like you suspected in your question. Rather, the parameter affects how many copies of input are made.
For future reference please also consult the SystemVerilog LRM. Simple syntax-related questions like yours can be easily looked up in that document. For example, take a look at Section 11.4.12.1 Replication operation in the document that I referenced.
I have a custom module in Verilog that takes several inputs and a few parameters.
module modA (
input inp1, input inp2, ... output out);
parameter my_addr;
...
endmodule
For various reasons associated with the specific hardware that I'm using, I need to create many instances of this module, each time with a different parameter (because my_addr corresponds to a specific location in memory that I am then accessing from the host). Moreover, I would like an easy way to access all of the outputs. I thought of doing something like
wire [9:0] outputs;
modA #(.my_addr) all_modA[9:0](.inp1(inp1), .inp2(inp2), .out(outputs));
So then I would have a vector of elements of all_modA, and the nth element of outputs would correspond to the nth instantiation of modA. That sounds like it would work well, except I need to pass a unique address to each instantiation. When I was just doing one instantiation at a time, it was quite easy to just define a parameter, but I don't see how I could pass a unique identifier each time.
Is there any way to accomplish this? The problem is, if I use a for loop, then I don't see how I can instantiate each modA with a unique identifier. If I don't use a for loop, then I'm not sure how to add a unique identifier.
You can use a generate block over here. Generate blocks are evaluated during elaboration of the design. They do not execute at simulation time and the result is determined before the simulation begins. Therefore, all expressions in generate schemes shall be constant expressions, deterministic at elaboration time.
Give different values to my_addr according to the requirement. Also, you can apply some label identifier to begin-end block. This as an optional feature for generate blocks, but very highly recommended. By doing so, a unique hierarchical path can be seen to every instance of modA is different for each module.
For your code, I have created a testbench that instantiates the module with changing value of my_addr and outputs bus driving the out signal.
module modA #(parameter int my_addr) (input inp1, input inp2,output out);
initial $display("%m: %d",my_addr);
endmodule
module top();
wire [9:0] outputs;
genvar i; // generate iterator
generate
for(i=0;i<9;i++) begin: some_identifier
// my_addr = i+1 for every module
modA #(.my_addr(i+1)) all_modA(.inp1(inp1), .inp2(inp2), .out(outputs[i])); // Multiple modules
end
endgenerate
endmodule
For more information, refer to IEEE 1800-2012 Section 27. Similar questions can be found here and here.
I am having a bit of trouble instantiating a module in verilog. I am using the Altera Quartus platform to develop and simulate the verilog code.
I have followed this example (among several others):
http://www.asic-world.com/verilog/verilog_one_day4.html
I have written a module (maximum) which finds the maximum between two signed inputs.
Another module I am developing is a systolic array for genetic sequence alignment. The details are not important, however when I try to instantiate a maximum module I get an error.
This is my code so far:
module maximum (a, b, out);
input signed [15:0] a;
input signed [15:0] b;
output reg signed [15:0] out;
always #* begin
if (a>b)
assign out = a;
else
assign out = b;
end
endmodule
and I instantiate in another module systolic_PE (all of this is in the same file seqalign.v)
maximum m0(.a(tempB), .b(diag), .out(tempA));
And I get the error :
'Verilog HDL syntax error at seqalign.v(139) near text "m0"; expecting
"<=" or "="'
I checked everything I have done so far, and I cant seem to see anything I have missed out on.. could anyone be kind enough to guide me?
Also on a side note:
Instantiation of a module in verilog
I was trying to instantiate my module in a if statement, so I tried outside of the if statement in a always #(posedge clk) block, and I get the error
HDL syntax error at seqalign.v(88) near text "("; expecting ";"
Looking over the code you posted in your comment, the issue is from instantiating your module inside your always #(posedge clk) block on line 70. You never instantiate modules inside of procedural blocks (always, initial, etc).
As Verilog is a Hardware Descriptive Language, you have to be in the mindset of designing hardware when writing your code. Module instantiation is like soldering a chip onto a PCB, at design time you either do it, or you dont, and that component stays there for all time. You dont say, well, I want this chip here some of the time, but take it off the PCB when the system gets into these states. In your code, you conditionally instantiate your module if state is 3. However, state changes over time. So that is akin to saying, when the register containing state reads 3, place down this chip into the system, otherwise, it doesnt exist and take it out. On a code level, think of instantiated modules as their own procedural blocks, just as you dont put always inside of other always, dont put modules in always blocks (of course, module definitions/declarations can have always blocks inside them).
Modules are persistent and compile time constant, so you can use generates to conditionally instantiate modules at compile time (ie, decide whether or not to include the module in the design when building the system). But in your code, you are conditionally instantiating at simulation time, which is not allowed as described above.
You can do one of two things to solve your problem. One would be to move your task from your submodule maximum into the systolic_PE module and use it to get the maximum of your variables tby calling it (line 123 would become something like tempA <= convert(.a(0), .b(diag+match)); with a and b added as inputs to your task). Or, instantiate the module outside the always block, but youll need to change your task to be a procedural block like you have in the actual post.
I just want to use some if else statement in verilog.
So I have to use always block.
integer count,index;
reg a=0;
always#(a) begin
a=1;
for(count=0;count<7;count=count+1) begin
index=4*count;
if((significand[index]==1'b0)&&(significand[index+1]==1'b0)&&
(significand[index+2]==1'b0) &&(significand[index+3]==1'b0))
lzero=lzero+1;
end
end
This code does make some sense now. I was able to get the correct simulation result, but I failed to get the correct synthesis on the board. Please help
This is a very typical problem with people who know how to program in C or C++ but forget that Verilog and VHDL are not the same as those.
EVERY signal line of Verilog code inside the ALWAYS block are 'executed' at the same time. The same goes with the combinatorial logic outside of the ALWAYS block.
In your code, both the
assign a=1'b1;
assign a=1'b0;
Will happen at the same time, no matter what.
The only way to change that is to put the last line inside your always block,after the end statement of the for loop.
One page that will give you some help on understanding the difference between C and Verilog is the page:EE-Times: The C Programmers Guide to Verilog
Neither assign 1'b1; nor assign 1'b0; are valid assignments. If you want to constantly drive some net with 1'b1, then you have to write something like assign myvar = 1'b1;.
Also, if your intent was to actually assign to a, then always block doesn't make sense since a is the only thing in its sensitivity list meaning that that block must be executed whenever a changes its value. Since a will essentially never change its value, that block should never be executed.
It is hard to help you out unless you provide a minimal working example demonstrating your problem. The only thing that I can recommend is to use ternary operator in assign right hand side statement. That way you can model a behavioural logic without using always block. For example:
assign a = (b == 1'b1 ? c : 1'b0);
Hope it helps.
UPDATE:
Your second code example is neither complete nor legal as well. You cannot have two combinatorial assignments for the same net.
However, a sensitivity list in always block is now a star, which is Verilog 2001 notation to include all right hand side operands into a sensitivity list automatically. In your case, the block will get executed every time significand or lzero changes.
Coming from a C++ background I'm starting to learn Verilog. This code describes four inputs going into two AND gates. The outputs from those two AND gates go into an OR gate. The output from the OR gate is the final output.
// a user-defined AND gate
module my_and2 (in, out);
input [1:0] in;
output out;
assign out = in[1]&in[0];
endmodule
// a user-defined OR gate
module my_or2 (in, out);
input [1:0] in;
output out;
assign out = in[1]|in[0];
endmodule
// the AND-OR logic built on top of the user-defined AND and OR gates
module and_or (in_top, out_top);
input [3:0] in_top;
output out_top;
wire [1:0] sig;
// instantiate the gate-level modules
my_and2 U1 (.in(in_top[3:2]),.out(sig[1]));
my_and2 U2 (.in(in_top[1:0]),.out(sig[0]));
my_or2 U3 (.in(sig),.out(out_top));
endmodule
The first two modules make sense to me. However, the last one doesn't. The first two modules have an assign statement at the end to set the value for the output variable. However, the last one doesn't. Why is that?
Verilog is 'event driven'. When writing verilog, think in terms of sensitivity lists.
In your example of the AND gate, you've the expression assign out = in[1]&in[0];. Your expression is said to be sensitive to in[0] and in[1]. This means that any time in[0] or in[1] change, the expression will be recomputed, and the value of out will be updated.
So in your toplevel module and_or, you're basically building a big tree of expressions that are sensitive to the outputs of the preceding expressions. This tree is, of course, built using the module connections. So a change in the value of one of the inputs to this toplevel module will ripple through all expressions in its 'logic cone'.
To drive the inputs you'll need higher level testbench module driving signals into your and_or module. This will supply inputs spaced out in time which will trigger the expressions in and below and_or. If not, your sim will have no events, so no expressions will trigger and the sim will time-out at 0ps because it is 'event starved'.
PS: for your AND gate expression, assign out = ∈ will work too... (reduction AND operator)
out_top is driven by the U3 instance output.
To put things simply, I like to think instantiation as just connecting wires.
Modules are blocks of digital circuits. You AND and OR gate modules are where magic happens. You already understand that part. By instantiating those modules, it's like you're connecting the input wires of your top level module with inputs of two blocks AND module. Then taking the outputs of them and taping them to the input wire sticking out of your OR block. And finally you're connecting the output of OR block to the output signal wire of top level.