fpgaverilog
module prizes(TESTSSD);
output reg [6:0]TESTSSD;
reg [1:0]equals;
always @(*) begin
equals = equals + 1;
case (equals)
0: TESTSSD = 7'b0000001;
1: TESTSSD = 7'b1001111;
2: TESTSSD = 7'b0010010;
3: TESTSSD = 7'b0000110;
4: TESTSSD = 7'b1001100;
default:TESTSSD = 7'b0000000;
endcase
end
endmodule
When I run the code above, I get a messed up looking 2 on the seven segment display; it is missing the middle part. What am I doing wrong?
The code you showed has a few problems:
You don't show how error_count is declared in the top-level module. If error_count is just declared as wire error_count;, you only have a single bit of your counter connected between the counter module and the lcd module.
You don't show how the counter is updated in the counter module. You could have a bug there that results in the counter never updating. Since it is initialized to 0, you'd always have a 0 output from the counter module.
You don't show any clock input to the counter module. If clock is not connected, error_counter will never be updated.
You say that lcd has a clock input, but you don't show that it actually does, and you don't show any code where it matters.
You don't show how your clock is generated. If there's no clock, the counter won't updated.
You don't show the complete input and output ports to either module. With your coding style it's easy to connect a wrong input to a wrong port. I much prefer to intantiate modules with the syntax like
counter counter1 ( .clk( clock ) , .error_count( error_count ) );
With this style, the order of naming the in's and out's in the instantiation doesn't matter.
You haven't shown any reset signal, but you probably have one. If the reset is stuck in the active state, probably the error_count won't ever increment.
Inouts are actually "wire" so you can't use any procedural/sequential assignments (where the left hand side must be a reg). Generally speaking:
A common approach is to have an "enable" signal for the output of your inout, and to drive to high impedance if the output is not enabled. In your case direction is playing that role.
So try this instead:
module test(
input clk, // The standard clock
input direction, // Direction of io, 1 = set output, 0 = read input
input data_in, // Data to send out when direction is 1
output data_out, // Result of input pin when direction is 0
inout io_port // The i/o port to send data through
);
reg a, b;
assign io_port = direction ? a : 1'bz;
assign data_out = b;
always @ (posedge clk)
begin
b <= io_port;
a <= data_in;
end
endmodule
The hardware corresponding to the above code would look something like this:
Best Answer
This means whenever any variable that appears on a right-hand side in the block changes, run the block.
This changes the variable
equals.So whenever
equalschanges, you incrementequals. Which meansequalschanges, which means you increment it again, and so on.So basically,
equalsjust keeps incrementing as fast as the hardware can make it happen.If you output this to a 7-segment display, you will just see the superposition of '0', '1', '2', and '3', flashing as quickly as the hardware can go. This will be much faster than your eye can follow. I don't know what it happens to look like, but if you say it looks like a '2', I believe you.
The usual way to do what you seem to want is to make
equalsincrement only when something special happens, like the edge of a slow-ish clock (like maybe 5 Hz at most for the display to be meaningful to the human eye); or only when some special event happens that you're trying to count.Edit
I should also add that, because of race conditions, if you implement this design in real hardware, it's likely that the output doesn't actually transition through all the states 0, 1, 2, 3, as expected, or that it doesn't do it in the order you expect.
For example if you're in the 2'b01 state, you expect to transition to 2'b10. But the signal to change bit 0 might propagate through more quickly than the signal to change bit 1, resulting in a glitch to the 2'b00 state. If that glitch lasts long enough, the circuit might go from there to the 2'b01 state again instead of to 2'b10. But that's just an example. What really happens depends on the transistor-level and wire-geometry level details of how the circuit is built.