I have my first verilog assignment due in a few days and for whatever reason these concepts are escaping me. I don't think I'm thinking in terms of parallelism and hardware or something.
My question is that I have to and a few switches and buttons together using wires and turn on 3 LEDs in array of 7. I'm pretty sure I know how to do the computational logic, but I can't figure out how to use assign and wire to properly turn on all 3 LEDs without writing 3 separate lines. It feels wrong to do:
assign Led[0] = output;
assign Led[1] = output;
assign Led[2] = output;
Also, it's weird because there are 7 LEDs on the board and I'm picking on LEDs 0,2,4.
Can someone walk me through how this is supposed to work the proper way? We don't have a textbook and I've been reading the basics online, but I just can't seem to figure out how this is supposed to work. Thanks!
Edit: This is my current code, but I am getting errors that say nothing is "driven". What gives?
module Lab2_1(input [5:0] sw, input btns, output [7:0] Led );
wire [2:0] leds;
wand out;
assign leds = {Led[0], Led[2], Led[4]};
and U1 (out, sw[0], sw[1]);
and U2 (out,~sw[2],~sw[3]);
xor U3 (out,sw[4],sw[5]);
assign out = btns;
assign leds[2:0] = {3{out}};
endmodule
Errors:
ERROR:PhysDesignRules:368 - The signal <Led<3>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<4>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<5>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<6>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<7>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<0>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<1>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <Led<2>_OBUF> is incomplete. The signal
is not driven by any source pin in the design.
ERROR:PhysDesignRules:10 - The network <Led<3>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<4>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<5>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<6>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<7>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<0>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<1>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <Led<2>_OBUF> is completely unrouted.
ERROR:Bitgen:25 - DRC detected 16 errors and 0 warnings. Please see the
previously displayed individual error or warning messages for more details.
What you have already seems perfectly fine, though if you wanted to do it in one line you could use a concatenation and or replication operators to assign multiple bits of Led. Both these statements are equivalent to your code sample:
assign Led[2:0] = {output, output, output};
or
assign Led[2:0] = {3{output}};
I don't know if these are any better or more proper than what you already have, but just writing them to show some examples of what is possible to do.
=== EDIT ===
You're getting errors because you're not driving any of the bits of Led.
This looks backward: assign leds = {Led[0], Led[2], Led[4]};
Led is the output of the module, so it should be assigned to, meaning it should be on the left hand side of the equal, so I would guess this should look like assign {Led[0], Led[2], Led[4]} = leds;
Your module has an 8-bit Led output, but you're only assigning 3 bits of it. You should assign the other 5 bits to either constant 1 or 0.
Related
Referring to my earlier question here, I've been utilizing tri-states to work with a common bus. I still appear to have some implementation issues.
The tri-states use this type of code:
assign io [width-1:0] = (re)?rd_out [width-1:0]:{width{1'bz}};
Synthesis and translation goes well. No warnings or errors I wasn't expecting (I was expecting some since this is only a trial run and most of the components don't do anything and will hence be left unconnected). But when I actually try to implement it, all busses (there are three) output a 1111111111111111, or a -1, as converted by my binary to BCD converter. I checked if it really the case by instructing the control matrix to halt if the instruction received on the bus is -1, and it did halt.
The warning I receive for the tri-state being converted to logic is:
Xst:2040 - Unit Neptune_I: 16 multi-source signals are replaced by logic (pull-up yes)
Xst:2042 - Unit alu: 16 internal tristates are replaced by logic (pull-up yes):
And so on. Neptune_I is the top module, and I believe the multi-source signals it's referring to are the busses.
I have a doubt whether the pull-up yes is the root of this problem. Is it simply pulling everything up, causing it to be -1 all the time? But this does not make sense to me, because when the tri-state is activated, the signal should be controlled by whatever entity it is supposed to be controlled by.
I would like to take the time to replace the code with logic instead of the tri-states, but I'm unsure how to proceed.
Any help would be appreciated.
Are these signals going off-chip? Or are they internal to your FPGA? If the answer is the latter, you need to change your code. Modern FPGAs (like Spartan 6) no longer support internal tri-state buffers. They only exist for off-chip signals.
You need to write all of you internal code to avoid tri-state buffers. Create dedicated paths between components, no bidirectional interfaces.
I've been coding a 16-bit RISC microprocessor in Verilog, and I've hit yet another hurdle. After the code writing task was over, I tried to synthesize it. Found a couple of accidental mistakes and I fixed them. Then boom, massive error.
The design comprises of four 16-bit common buses. For some reason, I'm getting a multiple driver error for these buses from the synthesis tool.
The architecture of the computer is inspired by and is almost exactly the same as the Magic-1 by Bill Buzzbee, excluding the Page Table mechanism. Here's Bill's schematics PDF: Click Here. Scroll down to page 7 for the architecture.
The control matrix is responsible for handling when the buses and driven, and I am absolutely sure that there is only one driver for each bus at any given instance. I was wondering whether this could be the problem, since the synthesis tool probably doesn't know this.
Tri-state statements enable writing to a bus, for example:
assign io [width-1:0] = (re)?rd_out [width-1:0]:0; // Assign IO Port the value of memory at address add if re is true.
EDIT: I forgot to mention, the io port is bidirectional (inout) and is simply connected to the bus. This piece of code is from the RAM, single port. All other registers other than the RAM have separate input and output ports.
The control matrix updates a 30-bit state every negative edge, for example:
state [29:0] <= 30'b100000000010000000000000100000; // Initiate RAM Read, Read ALU, Write PC, Update Instruction Register (ins_reg).
The control matrix is rather small, since I only coded one instruction to test out the design before I spent time on coding the rest.
Unfortunately, it's illogical to copy-paste the entire code over here.
I've been pondering over this for quite a few days now, and pointing me over to the right direction would be much appreciated.
When re is low, the assign statement should be floating (driving Zs).
// enable ? driving : floating
assign io [width-1:0] = (re) ? rd_out [width-1:0] : {width{1'bz}};
If it is driving any other value then the synthesizer will treat is as a mux and not a tri-state. This is where the conflicting driver message come from.
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 found the following piece of code in the internet , while searching for good FIFO design. From the linkSVN Code FIFO -Author Clifford E. Cummings . I did some research , I was not able to figure out why there are three pointers in the design ?I can read the code but what am I missing ?
module sync_r2w #(parameter ADDRSIZE = 4)
(output reg [ADDRSIZE:0] wq2_rptr,
input [ADDRSIZE:0] rptr,
input wclk, wrst_n);
reg [ADDRSIZE:0] wq1_rptr;
always #(posedge wclk or negedge wrst_n)
if (!wrst_n) {wq2_rptr,wq1_rptr} <= 0;
else {wq2_rptr,wq1_rptr} <= {wq1_rptr,rptr};
endmodule
module sync_w2r #(parameter ADDRSIZE = 4)
(output reg [ADDRSIZE:0] rq2_wptr,
input [ADDRSIZE:0] wptr,
input rclk, rrst_n);
reg [ADDRSIZE:0] rq1_wptr;
always #(posedge rclk or negedge rrst_n)
if (!rrst_n) {rq2_wptr,rq1_wptr} <= 0;
else {rq2_wptr,rq1_wptr} <= {rq1_wptr,wptr};
endmodule
What you are looking at here is what's called a dual rank synchronizer. As you mentioned this is an asynchronous FIFO. This means that the read and write sides of the FIFO are not on the same clock domain.
As you know flip-flops need to have setup and hold timing requirements met in order to function properly. When you drive a signal from one clock domain to the other there is no way to guarantee this requirements in the general case.
When you violate these requirements FFs go into what is called a 'meta-stable' state where there are indeterminate for a small time and then (more or less) randomly go to 1 or 0. They do this though (and this is important) in much less than one clock cycle.
That's why the two layers of flops here. The first has a chance of going meta-stable but should resolve in time to be captured cleanly by the 2nd set of flops.
This on it's own is not enough to pass a multi-bit value (the address pointer) across clock domains. If more than one bit is changing at the same time then you can't be sure that the transition will be clean on the other side. So what you'll see often in these situations is that the FIFO pointers will by gray coded. This means that each increment of the counter changes at most one bit at a time.
e.g. Rather than 00 -> 01 -> 10 -> 11 -> 00 ... it will be 00 -> 01 -> 11 -> 10 -> 00 ...
Clock domain crossing is a deep and subtle subject. Even experienced designers very often mess them up without careful thought.
BTW ordinary Verilog simulations will not show anything about what I just described in a zero-delay sim. You need to do back annotated SDF simulations with real timing models.
In this example, the address is passed through the shift register in order for it to be delayed by one clock cycle. There could have been more “pointers” in order to delay the output even more.
Generally, it is easier to understand what is going on and why if you simulate the design and look at the waveform.
Also, here are some good FIFO implementations you can look at:
Xilinx FIFO Generator IP Core
Altera's single/double-clock FIFOs
OpenCores Generic FIFOs
Hope it helps. Good Luck!
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.