I am new in this field,
I don't know if they've been asked before.
I'm writing code by creating separate modules to get used to big projects.
I have no problems creating modules, but I don't know how to create a testbench.So I should write test bench according to main module.
but the main module was created with reference to 3 separate modules.
How should be testbench of the following code?
Can you help me with this code?
//location of the main program
module circuit1_main(A,sel_m,Q);
input [2:0]A;
input sel_m;
output Q;
wire clk_m,reset_m,ud_m,load_m;
wire [2:0]A;
wire sel_m;
wire Q;
wire internal1;
wire internal2;
wire internal3;
wire internal4;
circuit1_counter cnt1(.clk(clk_m),.reset(reset_m),
.en(1'b1),.ud(ud_m),.load(load_m),
.d(A),.cnt(internal1));
assign internal2 = ~internal1;
circuit1_mux mux1(.a(internal1),.b(internal2),
.sel(sel_m),.out(internal3));
circuit1_shiftreg shiftreg1(.clk(clk_m),.reset(reset_m),
.sin(internal3),.sout(internal4));
assign Q = internal4;
endmodule
I have some bad new for you: You can't really write a test-bench for your 'circuit1_main' as it is rather broken.
Your module has a number of internal signals: clk_m,reset_m,ud_m,load_m; which should all come from outside. They should all be input ports which you must drive from your test bench.
I suspect, from the usage of the name 'main' that you are more comfortable with using C, C++ or other standard programming language. It is very important to realise that writing HDL is rather different. I therefore suggest you have a look around at some existing HDL code.
I know that the internet is full of HDL examples of FIFOs, UARTS, Counters etc., but that test benches are few and far between, Here is one which has code and the test benches that come with them.
I would also suggest you do not split your code into modules which are very, very small: Your circuit1_mux would be one line of code: assign out = sel ? a : b ;1 Writing a module and connecting it up is ten times more work then using that single line of code and less confusing. Is out equal to a or to b when sel_m is high?
1Substituting your port name could make it `assign internal3 = sel_m ? internal1 : internal2; which make immediately clear to anybody that sel_m selects the internal1 case.
Related
In verilog for Cyclone 3 I want to declare a port where some pins are inputs and some are outputs, in many examples in web i see that a port is defined like
input wire [0:10]p;
but what to do if i need bit0 being an input of the IC, while others be an output. Tried like this and some other different variants, but every time i get errors from the compiler. Notice that IO[1] unused in code but present in "Assignment editor".
module main(
tx,
rx,
IO[0],
IO[2]
);
output wire tx;
input wire rx;
input wire IO[0];
output wire IO[2];
assign IO[2] = rx;
assign tx = IO[0];
endmodule
You can use a port_expression. This separates the name of the port from the signals (or expression of signals) connected to the port. You might recognize this syntax when creating a module instance, but it has always been available for a module declaration as well in Verilog
module m(input .rx(a[0]), output .tx(a[1]));
wire [1:0] a;
endmodule
module top;
wire a,b;
m m1(.rx(a),.tx(b));
endmodule
there is no way in verilog to declare different directions to different bits of a single vector port. The direction works on the whole declaration of a port. The only way to do it is to split the single port into multiple ports with different names, e.g.
module main(
output wire tx,
input wire rx,
output wire out,
input wire in
);
Then, when you instantiate it, you can define which bits goes where:
main inst(.tx(tx), .rx(rx), .out(IN[0]), .in(IN[2]);
Since the top level module is not instantiated per se, it doesn't seem using port expressions can work here.
One thing you should try is to change the name of the pins in the pin assignment file (.csv I think) you are loading into Quartus to program your fpga. Give the different pins different names there, e.g. not In[0] or In[1], but rather in0, in1 and so on.
Assume there are two different modules (first_module, second_module). Both of the modules are synchronized with clock signal. first_module has the following structure:
module first_module(
input clk,
input reset_n,
input in1,
output reg out1,
output reg out2
);
//******** some verilog codes *********
endmodule
And second_module has similar structure:
module second_module(
input clk,
input reset_n,
input in1,
input in2,
output reg out1
);
//******** some verilog codes *********
endmodule
And then there is a module called top_module which uses instances of both modules:
module top_module(
input clk,
input reset_n,
input insignal1,
input insignal2,
output outsignal1,
output outsignal2
);
first_module fm1(
.clk(clk),
.reset_n(reset_n),
.in1(insignal1),
.out1(outsignal1),
.out2(<connection1>) // to be connected to the connection2
);
second_module sm1(
.clk(clk),
.reset_n(reset_n),
.in1(insignal2),
.in2(<connection2>), // to be connected to the connection1
.out1(outsignal2)
);
endmodule
The aim is to connect connection1 to connection2. According to my knowledge (if it is correct), we can either declare a single wire (let its name be connection) and replace both <connection1> and <connection2> with it, or we can declare two distinct wires connection1 and connection2, then:
assign connection2 = connection1;
And connect them accordingly.
Are those two methods synthesized differently? If the answer is yes, I would be glad if you could explain how they are synthesized.
If the answer is no, can one of the methods be better than the other in different conditions? Not in terms of lines of code or simplicity, but in terms of synthesis.
Yes there is a difference. But not in your specific case.
Using a connection directly makes that is can be uni-directional or bi-directional depending on what the underlying ports in the module are.
But assign connection2 = connection1; is only uni-directional.
Thus between bi-directional ports should use direct connections or you should only use bi-directional Verilog constructs between them. The assign ... is not one of them.
But in you case the signal is uni-directional so it does not matter.
Note that modern FPGAs no longer have on-chip bi-directional buses. (At least I don't know one that has). Also in chip design on-chip buses are strongly discourage or outright forbidden by the manufacturers.
Therefore bi-directional signals are normally only present in the test-bench. As that does not get synthesized your question does not apply there.
Last but not least:
In HDL design I would strongly discourage from changing the name of a signal for no apparent reason. Having the same name throughout the design makes it easier to debug and trace your signals post-synthesis.
I am planning to make a snake game using the Altera DE2-115 and display it on LED Matrix
Something similar to this in the video http://www.youtube.com/watch?v=niQmNYPiPw0
but still i don't know how to start,any help?
You'll have choose between 2 implementation routes:
Using a soft processor (NIOS II)
Writing the game logic in a hardware description language ([System]Verilog or VHDL)
The former will likely be the fastest route to achieving the completed game assuming you have some software background already, however if your intention is to learn to use FPGAs then option 2 may be more beneficial. If you use a NIOS or other soft processor core you'll still need to create an FPGA image and interface to external peripherals.
To get started you'll want to look at some of the example designs that come with your board. You also need to fully understand the underlying physical interface to the LED Matrix display to determine how to drive it. You then want to start partitioning your design into sensible blocks - a block to drive the display, a block to handle user input, storage of state, the game logic itself etc. Try and break them down sufficiently to decide what the interfaces to communicate between the blocks are going to look like.
In terms of implementation, for option 1 you will probably make use of Altera's SoC development environment called Qsys. Again working from an existing example design as a starting point is probably the easiest way to get up-and-running quickly. With option 2 you need to pick a hardware description language ([System]Verilog or VHDL or MyHDL) and code away in your favourite editor.
When you start writing RTL code you'll need a mechanism to simulate it. I'd suggest writing block-level simulations for each of the blocks you write (ideally writing the tests based on your definitions of the interfaces before writing the RTL). Assuming you're on a budget you don't have many options: Altera bundles a free version of Modelsim with their Quartus tool, there's the open source options of the Icarus simulator if using verilog or GHDL for VHDL.
When each block largely works run it through the synthesis tool to check FPGA resource utilisation and timing closure (the maximum frequency the design can be clocked at). You probably don't care too much about the frequency implementing a game like snake but it's still good practice to be aware of how what you write translates into an FPGA implementation and the impact on timing.
You'll need to create a Quartus project to generate an FPGA bitfile - again working from an existing example design is the way to go. This will provide pin locations and clock input frequencies etc. You may need to write timing constraints to define the timing to your LED Matrix display depending on the interface.
Then all you have to do is figure out why it works in simulation but not on the FPGA ;)
Let's say you have a LED matrix like this:
To answer not your question, but your comment about " if u can at least show me how to make the blinking LED i will be grateful :)", we can do as this:
module blink (input wire clk, /* assuming a 50MHz clock in your trainer */
output wire anode, /* to be connected to RC7 */
output wire cathode); /* to be connected to RB7 */
reg [24:0] freqdiv = 25'h0000000;
always #(posedge clk)
freqdiv <= freqdiv + 1;
assign cathode = 1'b0;
assign anode = freqdiv[24];
endmodule
This will make the top left LED to blink at a rate of 1,4 blinks per second aproximately.
This other example will show a running dot across the matrix, left to right, top to down:
module runningdot (input wire clk, /* assuming a 50MHz clock in your trainer */
output wire [7:0] anodes, /* to be connected to RC0-7 */
output wire [7:0] cathodes); /* to be connected to RB0-7 */
reg [23:0] freqdiv = 24'h0000000;
always #(posedge clk)
freqdiv <= freqdiv + 1;
wire clkled = freqdiv[23];
reg [7:0] r_anodes = 8'b10000000;
reg [7:0] r_cathodes = 8'b01111111;
assign anodes = r_anodes;
assign cathodes = r_cathodes;
always #(posedge clkled) begin
r_anodes <= {r_anodes[0], r_anodes[7:1]}; /* shifts LED left to right */
if (r_anodes == 8'b00000001) /* when the last LED in a row is selected... */
r_cathodes <= {r_cathodes[0], r_cathodes[7:1]}; /* ...go to the next row */
end
endmodule
Your snake game, if using logic and not an embedded processor, is way much complicated than these examples, but it will use the same logic principles to drive the matrix.
I find that this happens too often in Verilog code:
wire my_module_output_1;
wire my_module_output_2;
wire my_module_output_3;
...
MyModule my_module(
.output_1(my_module_output_1),
.output_2(my_module_output_2),
.output_3(my_module_output_3),
...
);
MyOtherModule my_other_module(
.input_1(my_module_output_1),
.input_2(my_module_output_2),
.input_3(my_module_output_3),
...
);
What I wish I could do is:
MyModule my_module();
MyOtherModule my_other_module(
.input_1(my_module.output_1),
.input_2(my_module.output_2),
.input_3(my_module.output_3),
...
);
Is there any such way for me to achieve the same effect, i.e. to avoid having to repeat myself over and over again every time I need an output from some module wired somewhere?
Here are a few approaches you can use to reduce the amount of repetition.
The starting point
Here's a simple example that connects two sub-modules. As you noted in your question, there is a lot of repetition required to stitch them together.
module source(output A, output B);
assign A = 0;
assign B = 1;
endmodule
module sink(input A, input B);
initial begin
#1 $display("A=%0d B=%0d", A, B);
end
endmodule
module top();
wire A;
wire B;
source the_source(
.A(A),
.B(B)
);
sink the_sink(
.A(A),
.B(B)
);
endmodule
Using implicit wires
Verilog allows for wires to be declared implicitly. So, as shown below, you don't need to declare A and B as wires. If they appear in a port map, they will be implicitly declared. The only problem with this is that they are always declared as single-bit wires/nets. So while this works fine for single-bit signals, for buses the interconnect still needs to be explicitly declared.
// Verilog, implicit wires
module top();
source the_source(
.A(A),
.B(B)
);
sink the_sink(
.A(A),
.B(B)
);
endmodule
Using Verilog-Mode AUTOs
The Verilog-Mode emacs package can help tremendously in reducing the amount of typing required to stitch modules together. Here is the example from above using AUTOs.
Before expanding the AUTOs:
// Verilog, explicit connections using AUTOs
module top();
/*AUTOWIRE*/
source the_source (/*AUTOINST*/);
sink the_sink (/*AUTOINST*/);
endmodule
After expanding the AUTOs:
// Verilog, explicit using AUTOs
module top();
/*AUTOWIRE*/
// Beginning of automatic wires (for undeclared instantiated-module outputs)
wire A; // From the_source of source.v
wire B; // From the_source of source.v
// End of automatics
source the_source (/*AUTOINST*/
// Outputs
.A (A),
.B (B));
sink the_sink (/*AUTOINST*/
// Inputs
.A (A),
.B (B));
endmodule
As Brian pointed out in his answer, you don't need to use emacs to use Verilog-Mode. I also use Vim and use this Vim script to enable Verilog-Mode from within Vim.
SystemVerilog option
If you can use SystemVerilog, you can use the dot-star notation to connect ports by names. This is pretty handy but you still have to declare the wires for interconnects between peer modules.
// SystemVerilog, dot-star notation
module top();
wire A;
wire B;
source the_source(.*);
sink the_sink(.*);
endmodule
Are people still not using Verilog AUTOs everywhere?
http://www.veripool.org/wiki/verilog-mode/Verilog-mode-Help
In particular pay attention to the section on AUTOINST. This isn't going to solve all your problems but judicious use of AUTOs takes a lot of the tedium out of generating structural Verilog.
Don't mind that it's an Emacs node. I'm a vim guy myself but I just pipe my buffer through emacs with this mode loaded when I need my AUTOs updated.
I am writing Verilog code using Lattice Diamond for synthesis.
I have binary data in a text file which I want to use as input for my code.
At simulation level we can use $readmemb function to do it. How is this done at synthesis level?
I want to access data present in text file as an input for FPGA.
As suggested by Mr Martin Thompson(answers below) I have written a Verilog code to read data from a file.
Verilog code is given below:-
module rom(clock,reset,o0);
input clock,reset;
output o0;
reg ROM [0:0];
reg o0;
initial
$readmemb("rom.txt",ROM);
always #(negedge clock,negedge reset )
begin
if(reset==0)
begin
o0<=0;
end
else
begin
o0<=ROM[0];
end
end
endmodule
When I am running this code on fpga I am facing the problem below:-
If text file which I want to read have only one bit which is '1' then I am able to assign input output pins to clock,reset and ROM. But if I have one bit which is '0' or more than one bits data in text file I am unable to assign input pins(i.e clock,reset) and a warning is displayed:-
WARNING: IO buffer missing for top level port clock...logic will be discarded.
WARNING: IO buffer missing for top level port reset...logic will be discarded.
I am unable to understand why I am getting this warning and how I can resolve it.
One way is to build the data into the netlist that you have synthesised. You can initialise a read-only memory (ROM) with the data using $readmemb and then access that as a normal memory from within your device.
Here's an introduction to some memory initialisation methods:
http://myfpgablog.blogspot.co.uk/2011/12/memory-initialization-methods.html
And in here:
http://rijndael.ece.vt.edu/schaum/slides/ddii/lecture16.pdf
is an example of a file-initialised RAM on the second to last slide. If you want just a ROM, leave out the if (we) part.
Think of Simulation as an environment not a level. You should just be switching the DUT (Device Under Test) from the RTL code to the synthesised netlist, other than this nothing should change in your simulation environment.
From the block of code you have given it does not look like you are separating out the test and code for the fpga. You should not be trying to synthesise your test I would recommend splitting it between at least 2 separate modules, your test instantiating the code you want to place on the fpga. Pretty sure the $fwrite is also not synthesizable.
A simple test case might look like:
module testcase
//Variables here
reg reg_to_drive_data;
thing_to_test DUT (
.input_ports ( reg_to_drive_data )
.output_ports ()
...
);
//Test
initial begin
#1ns;
reg_to_drive_data = 0;
...
end
endmodule
Via includes, incdir or file lists the code for thing_to_test (DUT) is being pulled in to the simulation, change this to point to the synthesised version.
If what you are trying to do is initialise a ROM, and hold this data in a synthesised design Martin Thompson's answer covers the correct usage of $readmemb for this.