How do I specify weak feedback inverter in Verilog - verilog

I have a normal inverter IV1(.in(a), .out(b)) driven by a controlled inverter IV0(.c(ctrl),.in(d),.out(a)). For IV0, When ctrl is 1, output is driven. Otherwise, it is left floating.
In the meantime, there is a weak feedback inverter IVW(.in(b), .out(a)).
The value of node a is driven by IV0 when ctrl is 1. When ctrl is 0, node a is driven by weak feedback inverter.
When IV0 drives node a, weak feedback inverter IVW is driving node a as well. If they drive node a to different values, verilog will produce X.
How can I write this in verilog?
original answer
module buf(input d,ctrl, output b);
reg a,b;
always # (d or ctrl) begin
if(ctrl==1) begin
a=~d;
b=~a;
end
else begin
a=~b;
b=~a;
end
end
endmodule
commented by Morgan
This will not work the same way after synthesis as your current RTL
simulation. You really need to use always #* to ensure RTL and gate
level will match.

To specify a weak inverter:
not (weak1,weak0) u0 (out0,in1);
For more info.
IV0(.c(ctrl), .in(d), .out(a)); //out is z when crtl==0
IV1( .in(a), .out(b));
IVW( .in(b), .out(a)); //out has weak drive
When ctrl is 1 we only really have this in play :
IV1( .in(a), .out(b));
IVW( .in(b), .out(a));
This is a timing loop likely resulting in an unstable oscilator.

Related

what is the real meaning of #10 verilog testbench?

I am new in verilog programming. So I was trying to explore the meaning of simple MUX code. In the test bench, It is observed there are multiple " #10 "s.
what is the purpose of this line?
Also please explain the need of defining inputs as "reg" and output simply as "wires"
I have added the snapshot for reference.
Thanks in advance.
Vt
It adds 10 units of time delay before executing the statement.
#always(clock.posedge) begin
#10
c = a + b
end
The above example adds a and b after 10 units of delay from posedge of clock
#10 determines the time delay before the operation.
"reg" and "wire" are data types ,to know the detail difference between different data types refer :
Verilog HDL: A Guide to Digital Design and Synthesis
By Samir Palnitkar

Snake game using FPGA (ALTERA)

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.

Flip flop with load/set, reset, clk, and input

I'm not looking for a hardware language description of the flip flop, but the logic gate level to implement.
In verilog, the equivalent I'm looking for is:
always#(posedge clk or negedge reset) begin
if(~reset)
Q <= 1'b0;
else if(~load)
Q <= D;
end
I've looked at: http://reviseomatic.org/help/e-flip-flop/4013%20D-Type%20Flip%20Flop.php
and
http://www.csee.umbc.edu/~squire/images/dff.jpg
the problem with the above implementation is that after I set a value to Q (D=0,Q=0,load=0) with load(set in picture) = 0, then when i set load high load = 1 on the next clk cycle, i get (D=x,Q=1,load=1). In order words, changing load from true to false will change the value of Q, but I want Q to hold it's previous value.
What is a flip flop that would hold it's value on Q after it has been set and enable is set high?
You should try looking up a mux flop.
It has a mux in front of the standard d-type and connects it input to output when load is not selected.
Your problem is that 'synchronous load enable' is not the same as 'asynchronous set'. Your Verilog code shows a F/F with an async reset, and a synchronous load enable. Your first (reviseomatic) reference is just nonsense - ignore it. It attempts (wrongly) to describe a 4013, which doesn't have a load enable. I haven't looked at the second reference in detail, but it looks like a conventional latch-based implementation of a F/F with async active-low set and reset.
You can implement flops in several ways:
For a CMOS transmission-gate flop implementation, see the NXP
datasheet for a 4013
For latch-based TTL, see the
datasheet for a 7474
The old TI databooks used to show flop
implementations using async feedback circuits.
For the synchronous load control part, look at Morgan's mux link.

Asynchronous FIFO Design

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!

what is the best way to exchange 2 registers in Verilog

i know several ways to exchange 2 registers :
using 3 xors, using register, using multiplexer, etc...
how can we make conditional exchange, it should take as less code as possible and work as fast as possible
Tripple-XOR is a software trick used to exchange register values on a sequential machine where a direct register exchange instruction (eg. x86 XCHG) is not available. The XOR instructions cannot be executed concurrently as they each depend on the previous output, so it takes three instruction cycles.
With Verilog you are describing hardware, so you exchange two register's values in a single cycle by assignment. This will infer a load path for both registers from each other's output.
if (swap) begin
a <= b;
b <= a;
end
You mention multiplexers - only if there is another load path, multiplexers and control logic will be instantiated as required, eg. some swap/increment device would have multiplexers since a can be loaded with either b or a+1.
if (swap) begin
a <= b;
b <= a;
end else begin
a <= a+1;
end
The simple way is probably best in Verilog - just assign them to each other using non-blocking assignments
a <= b;
b <= a;
The synthesizer will do the right thing.
a <= b;
b <= a;
That's all you need to do.

Resources