I am new in Verilog and I am trying to implement single precision floating point addition-subtraction using verilog. I am getting an error which I am unable to correct. Can anyone please help me?
module addModule(Rs,Re,Rm,As,Ae,Am,Bs,Be,Bm);
//Declarations of ports
Rs,Re,Rm;
As,Bs;
input [7:0] Ae,Be;
input [22:0] Am,Bm;
reg [7:0] Re;
reg [22:0] Rm;
reg Rs;
//wire declarations.
wire [23:-1] C;
assign C[-1] = 0;
wire [23:1] sum;
//variable declaration.
genvar count;
always #(*)
begin
//Add two mantissas.
if ((As^Bs)==0)
begin
generate //getting error here "Syntax error near "generate"."
for(count=0;count<24;count=count+1)
begin
add add_1(.c_out(C[count]),.sum(sum[count]),.in1(tempAm[count]),.in2(tempBm[count]),.c_in(C[count-1]));
end
endgenerate //syntax error near "endgenerate"
end
else
begin
generate //Syntax error near "generate".
for(count=0;count<24;count=count+1)
begin
subtract sub_1(.c_out(C[count]),.dif(sum[count]),.in1(tempAm[count]),.in2(tempBm[count]),.c_in(C[count]));
end
endgenerate //Syntax error near "endgenerate".
end
end
endmodule
Thanks in advance. :)
In Verilog, when you are instantiating a module, that means you are adding extra hardware to the board.
This hardware must be added before simulation starts(i.e. at compile time). Here, you can not add/remove hardware at each clock pulse.
Once instantiated, the module is executed/checked for each timestamp of simulation, till the end.
So to execute any module, just instantiate it, providing the clk and other required inputs to it, and add the always block in the sub-module itself.
Once the hardware is instantiated, it shall be executed according to the logic inside it, for entire life time.
Here you are instantiating module at wrong place. The use of generate block must be done outside any procedural blocks.
// generate outside any other blocks
generate
for(count=0;count<24;count=count+1)
begin
add add_1(.c_out(C[count]),.sum(sum[count]),.in1(tempAm[count]),.in2(tempBm[count]),.c_in(C[count-1]));
end
endgenerate
always #(*)
begin
// Other stuff here.
end
If you want to manipulate input signals of the subtract sub_1 module, simply manipulate C,sum and other variables declared in addModule module. Since they are connected, the change shall reflect in subtract sub_1 module too.
For more information on generate block, refer Module Instantiation, Generate block example and a similar question links.
Related
The following code gives output ("fact") 1 irrespective of the input. What is the error?
module Factorial_calc(n, fact);
input [5:0] n;
output reg [64:0] fact;
reg [5:0] i;
initial
begin
i=n;
fact=1;
end
always #(*)
begin
while(i>0)
begin
fact=i*fact;
i=i-1;
end
end
Verilog will not stop you from assign a reg to a net's value within an initial block, but you are extremely unlikely to get the result you expect.
An initial block runs ones at time 0. The net may not have the intended value before it is assigned to the reg. By design, Verilog allows for non-determinism of the evaluation order of procedural blocks and contentious assignments within the same phase of a time-step. Verilog's evaluation order can be controlled by event dependency. initial blocks do not not event dependencies, so it will always be evaluated as soon as possible. Nets will have dependencies (unless they are assigned to constants) so the typically are evaluated later.
The minimum change to get your code to work is to move the content of the initial block to inside the always block above the while statement. This will update i every time input n changes and reset fact before it is updated in the while loop.
always #(*)
begin
i = n; // <-- local sample
fact = 1; // local reset
while(i>0)
begin
fact=i*fact;
i=i-1;
end
end
This will work for simulation, but it cannot synthesize because it used a while statement.
I came to know that we can use assign statements in procedural blocks(like in always), what will be the difference in using "assign" inside always block and outside it(in concern with synthesized circuit). I mean when it is absolutely necessary to use assign in always?
Never, assign keyword is for continuous assignment and it will generate combinatorial logic at synthesis. In fact, you can obtain the assign behaviour with an always block:
wire test;
//At all times, test equals input
assign test = input;
Is equivalent to:
reg test;
//Each time input changes(with the always#*), test takes its value
always#*
test = input;
In always blocks, you should only use non-blocking assignment('<=') which are procedural assignments. Using blocking assignment is possible, however, you have to be sure to do what you want.
From this thread:
Two rules to live by that I know of no exceptions:
Always use blocking assignments for combinatorial or level-sensitive code, as well a clock assignments
Always use non-blocking assignments for variables that are written on a clock edge, and read on the same clock edge in another process.
assign and corresponding deassign (in always blocks) are also called 'procedural continuous assighment' can be used in always blocks for specific purposes. In most cases this is non-synthesizable and I had never ran across its use.
an example:
reg in1, in2, out;
reg [1:0] select;
always #* begin
case (select)
2'b01: assign out = in1;
2'b10: assign out = in2;
2'b11: deassign out;
endcase // case (select)
end
general recommendateion -- do not use it.
I'm using Verilog for programming a FPGA.
I have my top module and I would like to call a Task which contains an always block.
The Task is a routine for serializing a byte in UART. (inputs: baudrate_clk, bytetosend ; output: TxD which is the physical output pin)
module serial();
task serial;
input baudrate;
input [7:0] data;
output TxD;
reg [3:0] state;
begin
always #(posedge baudrate) begin
case(state)
// ...
endcase
end
end
always #(state[2:0]) begin
case(state[2:0])
// ...
endcase
end
assign TxD ...
end
endtask
endmodule
I get a unexpected token: 'always' at the first always, always #(posedge baudrate) begin
I read Task could include wait, posedge etc...
If I cannot use Taks, what can I use for this purpose ?
Thank you.
Either your task should be a module or you should use a loop inside your task. It's difficult to see your design intent, but it looks to me that you needed a module in this case, not a task.
Tasks contain sequential code, just like an always block does. A task is just another place to put the kind of code that can go inside an always block. It makes no sense to put an always block inside a task.
I have a module temp1 in verilog say as below,-
module temp1;
---
---
---
endmodule
I want to call this module instance from other module temp2. However, I want to this laways at the positive edge of the clock-
module temp2(clk);
input clk;
always #(posedge clk)
temp1 t1;
endmodule
This gives me syntax error. It seems I should not call any module from within the always block. Is it true that we cannot create instance of a module from within the always block? If yes, how can I do this in some other way as I have to call temp1 only when at the posedge of the clock?
In verilog, when you are instantiating a module, that means you are adding extra hardware to the board.
This hardware must be added before simulation starts(i.e. at compile time). Here, you can not add/remove hardware at each clock pulse.
Once instantiated, the module is executed/checked for each timestamp of simulation, till the end.
So to execute any module, just instantiate it, providing the clk and other required inputs to it, and add the always block in the sub-module itself.
module temp2(clk);
input clk;
temp1 t1(clk); // note the input port clk here
endmodule
module temp(input clk);
always #(posedge clk)
begin
// ...
end
endmodule
Verilog provides a generate block for creating multiple instances of the same module.
genvar i; // note special genvar type, used in generate block
generate
for(i=0;i<5;i++)
temp t1[i]; // create 5 instances of temp module
endgenerate
Side Note:
You may have mixed the understanding about module instantiation and calling of task/function. Module is a static entity while task/function can be dynamic ones. As you showed, if temp is a task, then the above call is valid.
task temp;
// ...
endtask: temp
module temp2(clk);
input clk;
always #(posedge clk)
temp1(); // task/function temp
endmodule
More information on instantiation can be obtained from Verilog Module Instantiation, Instantiating Modules and Primitives, Structural Modelling links.
I'm trying to design this state machine in verilog:
I was have:
`timescale 1ns/1ns
module labEightMachine(y, x,clk,clr)
output y;
input [1:2] x;
input clk, clr;
reg [1:2] q;
reg y;
reg nX;
always # (posedge clk)
begin
if(clr)
{q}<=2'b00;
else
q<= {nX}
end
always #(y,x)
begin
if(q==2'b00)
if(x==2'b00)
q<=2'b00;
else
q<=2'b01;
y<=1;
if(q==2'b01)
if((x==2'b00)||(x==2'b01))
q<=2'b00;
y<=0;
else
q<=2'b11;
y<=0;
if(q==2'b11)
if(x==2'b10)
q<=2'b10;
y<=1;
else
q<=2'b00;
y<=0;
if(q==2'b10)
q<=2'b00;
y<=0;
end
endmodule
If any one could help by telling me where it is incorrect, that would be greatly appreciated. The state machines confuse me and I'm not sure that I am reassigning everything correctly.
Applying stimulus is always a better way to check your code. Leaving the syntax errors of semi-colons/begin-end and all that, a couple of immediate logical errors I can see are as below.
The declaration reg nX declares a variable of single bit width. On the contrary, q is declared as reg [1:2] q, of two bits width.
Secondly,q is driven from two always blocks. If clr is LOW, then q is driven by nX. While, nX is never driven by any signal. So, the output will be x majority of times (leaving those race-conditions). Multiple driver issues.
Thirdly, it would be better to use if--else if--else ladder instead of multiple ifs. This will make the next_state logic clear.
A better FSM, might have two always blocks and one output logic block. One for sequential logic and other for combinational logic. Sequential block is used to update the current_state value by the next_state value. While, a combinational block is used to update the next state value according to inputs. The output logic must either have a separate block of continuous assignments or a procedural block.
Also, it might be convenient to use a case statement for next_state logic. This will be useful when too many states are interacting with each other in a single FSM. Using default in case statement is inevitable.
For further information on efficient FSM coding styles, refer to CummingsSNUG1998SJ_FSM paper and CummingsSNUG2000Boston_FSM paper.