... module stuff, ports etc.
reg [3:0] fib_lfsr = 4'b0001;
// this implements the given picture.
always @ ( posedge clk ) fib_lfsr <= {fib_lfsr[2:0], fib_lfsr[3] ^ fib_lfsr[2]};
...whatever else you want to do...
What are they trying to teach engineering students!? So many of the students learning Verilog seem to use antiquated syntax and everything is built up of low level gates and master-slave flip flop designs. :-(
I saw simple examples like this in the various Verilog books I own when I picked up Verilog to do my work, but I've never seen anyone actually use this type of coding to implement anything.
This could easily be written in 1 line of behavioral code:
Code:... module stuff, ports etc. reg [3:0] fib_lfsr = 4'b0001; // this implements the given picture. always @ ( posedge clk ) fib_lfsr <= {fib_lfsr[2:0], fib_lfsr[3] ^ fib_lfsr[2]}; ...whatever else you want to do...
So are you a hobbyist? If so learn Verilog like I did (not in school).
I picked up the book "The Verilog Hardware Desciption Language" by Thomas/Moorby and read it cover to cover. This was back in 1995 so it was the only Verilog book that I could find. Now I have a couple of others and the LRM to refer to. A book on testbench development can be very useful too.
What are they trying to teach engineering students!? So many of the students learning Verilog seem to use antiquated syntax and everything is built up of low level gates and master-slave flip flop designs. :-(
I saw simple examples like this in the various Verilog books I own when I picked up Verilog to do my work, but I've never seen anyone actually use this type of coding to implement anything.
This could easily be written in 1 line of behavioral code:
Code:... module stuff, ports etc. reg [3:0] fib_lfsr = 4'b0001; // this implements the given picture. always @ ( posedge clk ) fib_lfsr <= {fib_lfsr[2:0], fib_lfsr[3] ^ fib_lfsr[2]}; ...whatever else you want to do...
module LFSR4bit (KEY0, LEDG, HEX0);
input KEY0;
output [3:0] LEDG;
output [0:6] HEX0;
reg [3:0] Q = 4'b0001;
always @ ( posedge KEY0 )
Q <= {Q[2:0], Q[3]^Q[2]};
assign LEDG = Q;
QtoHEX Q0 (Q, HEX0);
endmodule
module QtoHEX (Q, HEX);
input [3:0] Q;
output reg [0:6] HEX;
always begin
case (Q)
0:HEX=7'b0000001;
1:HEX=7'b1001111;
2:HEX=7'b0010010;
3:HEX=7'b0000110;
4:HEX=7'b1001100;
5:HEX=7'b0100100;
6:HEX=7'b0100000;
7:HEX=7'b0001111;
8:HEX=7'b0000000;
9:HEX=7'b0001100;
10:HEX=7'b0001000;
11:HEX=7'b1100000;
12:HEX=7'b0110001;
13:HEX=7'b1000010;
14:HEX=7'b0110000;
15:HEX=7'b0111000;
endcase
end
endmodule
How is KEY generated... please, please, don't tell me it's a non-debounced switch on the board. ;-)
You should use an actual clock for the registers not a signal from some switch. As the "switch" input is probably assigned to a non-clock pin the tools are probably routing the "clock" on general interconnect. So you've probably got some horrendous skew in the clock and are probably "loosing" bits when it tries to shift.
Take a look at your timing report....I hope you entered some timing constraints.
1. I'd first add a clock to the design.
2. debounce the switch using the clock to generate a nice clean enable pulse
3. run the LFSR on the clock and use the enable pulse to clock enable the registers.
It's a clock key , here's the "clocks" section under timing analysis
Clock name Type Period Frequency Rise Fall
KEY0 Base 1.000 1000.0 MHz 0.000 0.500
Uh? 1000 MHz????
That's 1 GHz....I don't think you're going to find any FPGAs that run that fast.
I was hoping it wasn't some bouncy key...
Like I said use a real clock I'm sure the DE2 has a user clock of some sort probably 50 MHz or 125 MHz or something.
Use the 50 MHz clock to debounce the switch and generate an edge detect pulse, which you can use as your enable to the LSFR registers, which are clocked using that 50 MHz oscillator clock.
It's probably showing 8 because it's cycling so fast through all counts... you need to add an enable to the shift register. operated by an edge detection pulse from the KEY input.
module temp (
output [3:0] q,
input enable,
input clk
);
reg [3:0] lfsr = 4'b0001;
always @ (posedge clk) begin
lfsr <= enable ? {lfsr[2:0], ^lfsr[3:2]} : lfsr;
end
assign q = lfsr;
endmodule
The following code:
Code:module temp ( output [3:0] q, input enable, input clk ); reg [3:0] lfsr = 4'b0001; always @ (posedge clk) begin lfsr <= enable ? {lfsr[2:0], ^lfsr[3:2]} : lfsr; end assign q = lfsr; endmodule
produces the following waveform...
View attachment 86994
As this cycles correctly, I'm not sure why switching the shift direction fixes your design.
module LFSR4bit (KEY, LEDG, HEX0);
input [1:0] KEY;
output [3:0] LEDG;
output [0:6] HEX0;
reg [0:3] Q = 4'b0001;
always @ ( posedge KEY[0] )
Q <= {Q[3]^Q[2], Q[0:2]};
assign LEDG = Q;
QtoHEX Q0 (Q, HEX0);
endmodule
module QtoHEX (Q, HEX);
input [0:3] Q;
output reg [0:6] HEX;
always begin
case (Q)
0:HEX=7'b0000001;
1:HEX=7'b1001111;
2:HEX=7'b0010010;
3:HEX=7'b0000110;
4:HEX=7'b1001100;
5:HEX=7'b0100100;
6:HEX=7'b0100000;
7:HEX=7'b0001111;
8:HEX=7'b0000000;
9:HEX=7'b0001100;
10:HEX=7'b0001000;
11:HEX=7'b1100000;
12:HEX=7'b0110001;
13:HEX=7'b1000010;
14:HEX=7'b0110000;
15:HEX=7'b0111000;
endcase
end
endmodule
Code:reg [0:3] Q = 4'b0001; always @ ( posedge KEY[0] ) Q <= {Q[3]^Q[2], Q[0:2]};
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?