I want to add a comment before CLOCK, RESET and ENABLE signals.
Is there a good collective term for these signals?
(
// ???
input CLOCK,
input RESET,
input ENABLE,
// Interconnect
output [15:0] ADDR,
...
);
With CPUs, we tend to describe there being 3 buses between the CPU and other components - the Address Bus, Data Bus and Control Bus.
Here, these seem to be Control signals, so that's what I'd go for.
Related
I want to create a RAM chip in verilog to learn how Verilog, modern chips like RAM and EEPROM allow reading and writing to the chip over a single address port and a single data port.(Data port being the input and output port)
I want to do the same thing in Verilog, and I think I need the inout type, but I don't know how it works.
I google it, but all RAM examples I can find have a separate data write and data read port.
Since the inout type requires both sides to be connected to a wire, I need to connect one wire from one side to a reg chosen by the address.(so no assign).But I don't know how to do that.
This is what I tried and doesn't work:
wire [7:0] a;
wire rw;// 0 if read, 1 if write
reg [7:0] mem [16];
initial begin
if (rw == 1) begin
#1 a = mem[0];// 0 would be the address wire, but excluding it for clarity
end
if (rw == 0) begin
#1 mem[0] = a;// 0 would be the address wire, but excluding it for clarity
end
end
Can anyone help?
Thanks
all RAM examples I can find have a separate data write and data read port.
The reason is a combination of two facts:
A true bi-directional data bus would requires tri-state drivers.
FPGA or ASIC chips no longer have on-chip tri-state drivers.
The only place where a bi-directional data is possible is at I/O where you have tri-state pads.
Thus internally everybody will use the two data buses as any real memory will have at its core a separate read-data and write-data bus. Then at the edge (at the pads) they will switch to bi-directional mode.
To write your own Verilog bi-directional bus you should use tri-state signal assignments. Something along the line of:
inout[7:0] data_bus,
// This assignment is inside the memory model:
// Driving the read data out of the memory device
assign data_bus = mem_read ? mem_read_data : 8'hzz;
// This assignment is outside the memory model
// Driving the write data into the memory device
assign data_bus = mem_read ? 8'hzz : external_driver;
I am able to use these default modules in xilinx schematic like M2_1 MUX, FD flipflop etc.
In verilog I can able to use only elementary gates like and, or ,not,xor etc.
But can I use these built-in Multiplexer (M2_1) or Flipflop(FD) in verilog?, because if I use behavioral code, there may be poor synthesis in synopsis or xilinx for some cases. Also I want to use system level design.
Please help me to solve this issue. Do I need to include any library to access this(built-in gates)?
Please provide me example codes. I want direct instantiation of these(Mux and Flipflop) in verilog just as and, or etc.
Yes you can use them in verilog. Xilinx provides user guides for how to do it (example for 7 series here)
The user guide that I've given link to provides an example for FDCE flip flop such as (page 131):
// FDCE:Single Data Rate D Flip-Flop with Asynchronous Clear and
// Clock Enable (posedge clk).
// 7 Series
// Xilinx HDL Libraries Guide, version 2012.2
FDCE #(
.INIT(1'b0)
// Initial value of register (1'b0 or 1'b1)
)
FDCE_inst
(
.Q(Q),
// 1-bit Data output
.C(C),
// 1-bit Clock input
.CE(CE),
// 1-bit Clock enable input
.CLR(CLR),
// 1-bit Asynchronous clear input
.D(D)
// 1-bit Data input
);
// End of FDCE_inst instantiation
The stick has a 12MHz oscillator on board. http://www.latticesemi.com/icestick
I have managed to write verilog code to divide this clock down and flash LEDs are 1Hz. (I am just starting to learn verilog.)
I believe that this FPGA will work at up to 133MHz.
Is there a way to generate a faster clock signal (in verilog) from the 12MHz oscillator?
Answer not yet tested.
Via https://www.reddit.com/r/yosys/comments/3yrq6d/are_plls_supported_on_the_icestick_hw/
From: https://github.com/SubProto/icestick-vga-test/blob/master/vga.v
wire clk;
SB_PLL40_CORE #(.FEEDBACK_PATH("SIMPLE"),
.PLLOUT_SELECT("GENCLK"),
.DIVR(4'b0001),
.DIVF(7'b1000010),
.DIVQ(3'b100),
.FILTER_RANGE(3'b001),
) uut (
.REFERENCECLK(pclk),
.PLLOUTCORE(clk),
.LOCK(D5),
.RESETB(1'b1),
.BYPASS(1'b0)
);
Also:
iCE40 sysCLOCK PLL
The iCE40 Phase Locked Loop (PLL) provides a variety of user-synthesizable clock frequencies, along with cus-
tom phase delays.The PLL in the iCE40 device can be configured and utilized with the help of software macros or
the PLL Module Generator. The PLL Module Generator utility helps users to quickly configure the desired settings
with the help of a GUI and generate Verilog code which configures the PLL macros. Figure 2 shows the iCE40 sys-
CLOCK PLL block diagram.
http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/IK/iCE40sysCLOCKPLLDesignandUsageGuide.pdf?document_id=47778
I have used a higher clock frequency to display a pong game in a VGA monitor using TinyFPGA BX. The TinyFPGA BX and the Lattice iCEstick are quite similar. Therefore, I would like to share my code. You may need to use the official Lattice software for an easier GUI (Graphical User Interface) configuration. https://www.latticesemi.com/software
module top(
input wire clk_16,
output USBPU
);
assign USBPU = 0; // drive USB pull-up resistor to '0' to disable USB
output wire;
SB_PLL40_CORE #(
.FEEDBACK_PATH("SIMPLE"),
.DIVR(4'b0000), // DIVR = 0
.DIVF(7'b0110001), // DIVF = 49
.DIVQ(3'b101), // DIVQ = 5
.FILTER_RANGE(3'b001) // FILTER_RANGE = 1
) uut (
.LOCK(locked),
.RESETB(1'b1),
.BYPASS(1'b0),
.REFERENCECLK(clk_16), // clk_16_MHz is the original clock
.PLLOUTCORE(clk) // clk is the modified clock with higher frequency
);
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 have a clock input to the fan-out buffer which drives LVDS input to the bottom edge of PLL input. There are two pins - AJ19 (active high) and a complementary AK19 pin (active low). I am only interested in AJ19, so my top level module looks like this:
module top(clk, ...);
...
endmodule
Here is my pinout for a clk:
set_instance_assignment -name IO_STANDARD LVDS -to clk
set_location_assignment PIN_AJ19 -to clk
set_location_assignment PIN_AK19 -to "clk(n)"
So far so good, but fitter is generating a very annoying warning that drives me crazy:
Warning (15714): Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details
Warning (176674): Following 1 pins are differential I/O pins but do not have their complement pins. Hence, the Fitter automatically created the complement pins.
Warning (176118): Pin "clk" is a differential I/O pin but does not have its complement pin. Hence, fitter automatically created the complement pin "clk(n)"
Altera's knowledge base suggested to actually define the clock as a pair (i.e. input wire [1:0] clk) to remove the warning. That doesn't quite help because then you get another warning, saying that input pin does not drive any logic.
I have tried to disable this warning using // altera message_off 176118. That results in error because "176118" is not a valid message ID.
Any suggestions on how to solve this problem?
See Altera "Designing with Low-Level Primitives User Guide" for primitive details and templates
http://www.altera.co.uk/literature/ug/ug_low_level.pdf
Example of wrapping top level block:
module top_wrap (
...
input wire refclk, input wire refclk_n,
);
// differential input buffers
wire int_refclk;
ALT_INBUF_DIFF inbuf_refclk (
.i (refclk),
.ibar (refclk_n),
.o(int_refclk),
);
top wrapped (
.refclk( int_refclk),
...
)
endmodule
To get rid of this, you need to create both signals, and then take them into an LVDS buffer component (I don't recall what Altera calls this component off the top of my head), the output of which will drive a "normal" internal signal that you can then use as you see fit.