I was trying to build and compile my design for an i2c - hdmi controller, however, when i first built the project, it was giving me the error:
Error (11802): Can't fit design in device. Modify your design to reduce resources, or choose a larger device...
Error: Quartus Prime Fitter was unsuccessful. 8 errors, 6 warnings
Error: Peak virtual memory: 5448 megabytes
As you would expect, i removed components (commented them out) until there was nothing left. Just Top level input and outputs and it still gives that error. I have tried restarting quartus as well as my whole computer with no success.
I may not be an expert at Quartus, but if there are no components, how is there anything to compile, let alone 5.5gb worth? What have i done wrong?
This is what my TLE looks like:
module MajorProject(
input[9:0] romAddress,
input clock50MHz,
output[31:0] romData,
//hdmi i2cStuffs
input Reset,
input HDMI_int,
output I2cClock, //is technically an inout
inout I2cDataLine,
//HDMI Stuff
output HDMI_TX_CLK,
output [23:0] HDMI_TX_D,
output HDMI_TX_DE,
output HDMI_TX_HS,
input HDMI_TX_INT,
output HDMI_TX_VS,
//Testing
output Ready ,
output [3:0] setupState,
output [4:0] sendingState
);
/*
HDMI_i2cController hdmiController(
.mainClock(clock50MHz),
.reset(Reset),
.i2cClock(I2cClock),
.i2cDataLine(I2cDataLine),
.HDMI_int(HDMI_int),
.ready(Ready),
.setupState(setupState),
.sendingState(sendingState)
);
*/
/*
charTable rom(
.address(romAddress),
.clock(clock50MHz), //in the real work, we want this to clock 8 times to get
the full dataset for a letter
.q(romData)
);
*/
endmodule
Yep #Vlad was on the right track. My TLE had 86 pins. For some reason even though they weren't being used and hadn't been assigned any pins. It threw an error because IF I was to connect them, the pin voltage was wrong (quartus gives default 2.5V the board required 3.3).
The Quartus compiler may do some pretty amazing things, but its still not very smart.
Related
I've been having trouble the last little while with a project that uses look up table arrays quite a bit and getting yosys to infer them as block ram. Yosys keeps thinking one or the other of my arrays should be implemented using logic cells.
example:
reg signed [11:0] dynamicBuffer [0:2047];
gets inferred as IceStorm LC and thus quickly overflows my logic cell budget.
Info: Device utilisation:
Info: ICESTORM_LC: 83524/ 7680 1087%
Info: ICESTORM_RAM: 18/ 32 56%
Info: SB_IO: 36/ 256 14%
Info: SB_GB: 8/ 8 100%
Info: ICESTORM_PLL: 2/ 2 100%
Info: SB_WARMBOOT: 0/ 1 0%
I've read that an array needs to have a registered output or Yosys does not see it as ram (is this true?) I've tried to rework things such that my arrays are ultimately routed to a register at each clock count. But I still cannot get it working. What is the right way of working with multiple arrays, copying them one to the other, and getting yosys to infer them as block ram? What do I need to avoid?
I've read that an array needs to have a registered output or Yosys does not see it as ram (is this true?)
Yes, its true. Only way I can make Yosys infer to BRAM is to make it an asynchronous BRAM with Input and Output. I took this from my VFD display controller project
module GRAM(
input R_CLK,
input W_CLK,
input [7:0]GRAM_IN,
output reg [7:0]GRAM_OUT,
input [11:0] GRAM_ADDR_R,
input [11:0] GRAM_ADDR_W,
input G_CE_W,
input G_CE_R);
reg [7:0] mem [3002:0];// change this to what you want.
initial mem[0] <= 255;// fill the first byte to let Yosys infer to BRAM.
always#(posedge R_CLK) begin// reading from RAM sync with reading clock.
if(G_CE_R)
GRAM_OUT <= mem[GRAM_ADDR_R];
end
always#(posedge W_CLK) begin// writing to RAM sync with writing clock.
if(G_CE_W)
mem[GRAM_ADDR_W] <= GRAM_IN;
end
endmodule// GRAM
Assuming you are using a for loop like in your last example, for loops in hardware do not run sequentially like in software but do the entire copy in one clock. You need to use a counter and a state machine for the copy, not a Verilog for loop.
The solution in this case was to implement an asynchronous fifo.
I was crossing clock domains when I connected the two modules so needed to synchronize reading and writing from the array. The lack of coordination between reads and writes to the array was causing yosys to infer that the array was not to be implemented as block ram.
Here is my code of top module and rom module. I don't find any error in this, but it is showing this error and I don't know why.
module top (clk,clr, ss, mosi,sck);
input clk;
input clr;
output ss;
output mosi;
output sck;
wire [10:0]address;
wire[7:0]data;
wire done,start,mclk,clk_out;
clock uut1(.clr(clr),.mclk(clk),.clk_out(clk_out));
ROM_Memory uut2(.address(address),.data(data));
ctrl uut3 (.clr(clr),.clk(clk_out),.address(address),.data(data),.start(start),.done(done));
spi uut4 (.clk(clk_out),.clr(clr),.data(data),.start(start),.done(done),.ss(ss),.mosi(mosi),.sck(sck));
endmodule
ROM module-
module ROM_Memory(address,data);
input [10:0] address;
output [7:0] data;
reg [7:0]ROM[0:1034];
initial begin
$readmemh("preeti.txt",ROM);
end
assign data = ROM[address];
endmodule
It is showing rest three modules in RTL schematic and simulation is also running fine.
Your top module serves as a framework to connect things one each other.
Your system seems to be a controller that reads a ROM and sends its contents thru SPI. The ROM is effectively connected in top, but your module only shows that there are a pair of buses (address and data) which ROM is connected to. We don't know if those buses are connected to somewhere else. They should be, but if ctrl or spi don't use address or data (because of a mispelled name, for example), the ROM will actually be connected to nowhere.
Add this to the beginning of every Verilog file in your design, so you can catch any error caused by a mispelled signal name:
`default_nettype none
Another cause of your ROM being disconnected from your design is that the file you provide to initialize it is not complete. If your ROM has 1035 cells, all of them must be initialized, or else, the synthesizer will throw away the ROM register, and hence, the complete ROM_Memory module will be thrown away as well.
To ensure that your ROM is totally initialized, modify your initial block to add these lines:
integer i;
initial begin
for (i=0;i<=1034;i=i+1) // Prefill all the ROM, so you can use an incomplete file later
ROM[i] = 8'h00;
$readmemh("preeti.txt",ROM); // Initialize up to 1035 cells from preeti.txt
end
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 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.
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.