Electrical – Change array to individual outputs

verilog

I'm trying to design a synchronous sequential circuit to implement a tail light controller for a 1965 Ford Thunderbird using verilog as shown below (included with the state diagram).

I have the working code below:

module tail_lights
(
    input       clock,
    input       reset,
    input       left,
    input       right,
    input       haz,
    output reg [1:6] lights
);

  parameter idle = 6'b000000, //tail patterns as output-coded state assignments
            L3   = 6'b111000,
            L2   = 6'b011000,
            L1   = 6'b001000,
            R1   = 6'b000100,
            R2   = 6'b000110,
            R3   = 6'b000111,
            LR3  = 6'b111111;

always @ (posedge clock) //state memory
    if
      (reset) lights <= idle;   else
        case (lights)         // and next-state logic.
        idle : if      (haz || (left && right)) lights <= LR3;
          else if (left && ~haz && ~right)      lights <= L1;
          else if (right && ~haz && ~left)      lights <= R1;
               else lights <= idle;
        L1   : lights <= L2;
        L2   : lights <= L3;
        L3   : lights <= idle;
        R1   : lights <= R2;
        R2   : lights <= R3;
        R3   : lights <= idle;
        LR3  : lights <= idle;
          default : ;
        endcase
endmodule

I want to make it so that the module is has the output la, lb, lc, ra, rb, rc; instead of the [1:6] lights array I have.

I tried just having it be reg [1:6] lights then assign la = lights[1], lb = lights[2], etc. But that made the sequence run backwards (ie: left would run 111000, 011000, 001000 instead of 001000, 011000, 111000)

How can I fix this? Thanks in advance!

Here's the testbench, if needed:

module testbench;                
    reg         clock;      // Free running clock
    reg         reset;      // Active high reset
    reg         left;       // Input - left turn request
    reg         right;      // Input - right turn request
    reg         haz;        // Input - hazard request
    wire [1:6] lights;      // Output - lights display

    initial                 // Done once at start up 
    begin
        $dumpfile( "dump.vcd" );
        $dumpvars;

        clock = 0;          // Set initial values for inputs 
        reset = 0;
        left = 0;              
        right = 0;
        haz = 0;

        #1 reset = 1;
        #9 reset = 0;

        #20                         // Wait to make sure system is idle
        // Test left turn signal
            left = 1;
        #10 left = 0;

        #50                         // Wait to make sure signal stops
        // Test right turn signal
            right = 1;
        #10 right = 0;

        #50                         // Wait to make sure signal stops
        // Test hazard
            haz = 1;
        #50 haz = 0;

        #30                         // Wait to make sure signal stops
        // Test simultaneous left and right
            left = 1;
            right = 1;
        #50 left = 0;
            right = 0;

        #30                         // Wait to make sure signal stops
        // Test hazard priority over left
            left = 1;
            haz = 1;
        #50 left = 0;
            haz = 0;

        #30                         // Wait to make sure signal stops
        // Test hazard priority over right
            right = 1;
            haz = 1;
        #50 right = 0;
            haz = 0;

        #30                         // Wait to make sure signal stops
        // Test hazard NOT interrupting left signal
            left = 1;
        #10 left = 0;
            haz = 1;
        #30 haz = 0;

        #30                         // Wait to make sure signal stops
        // Test hazard NOT interrupting right signal
            right = 1;
        #10 right = 0;
            haz = 1;
        #30 haz = 0;

        #30 $finish;
    end

    always
        #5 clock = ~clock;
           // Instantiate module
    tail_lights    u1
    ( 
        .clock( clock ), 
        .reset( reset ),
        .left( left ), 
        .right( right ), 
        .haz( haz ), 
        .lights(lights)
    );

endmodule

Best Answer

In Verilog you should use zero indexing and bit ordering with the MSB on the left. For example you should have:

wire [5:0] lights;

The use of one indexing is not your issue, however using the wrong bit order is. Your constants do not match the order of your bus, and there is no requirement for Verilog synthesizers to flip the bits to match. As a result in the case statement your bits are getting reversed in the comparison.

If you want to use individual outputs, you can either do as you have tried with many assign statements, or you can simplify things with concatenation. For example:

wire [3:0] out;
assign {out_3, out_2, out_1, out_0} = out;

Related Solutions

Electronic – Unexpected Verilog warning re FPGA clock assignment

The warning is basically suggesting that you use an explicit clock primitive, which for whatever reason isn't inferred automatically by the tools.

There should be a reference for your particular FPGA that tells what primitives are available. For a Spartan3E, for example, Xilinx UG617 describes the BUFGCE primitive ("Global Clock Buffer with Clock Enable") and shows how to instantiate it. Other vendors will have similar documentation.

Your clock distortion is probably occurring because tristating an output line isn't something that can be done instantly. Whatever is being driven has both inductance and capacitance, so even if the driver could go high-Z in zero real time (which it can't), the driven network will continue to ring for some time. If that's a problem, you would need to find a way to ensure that the clock line is low, and has been for some time, before tristating it. All in all, there is probably a better way to accomplish your goal besides tristating a clock.

Electrical – register with enable signal, problem of understanding simulation results

In general, you should avoid having the inputs to any register change at the same instant as the active clock edge. In physical circuits, this could lead to metastability issues, and simulators give results that are confusing at best.

In this case, the clk, enable and d signals all changed at the same instant in the testbench, so by the time the Nbit_register module was evaluated, it "saw" the rising edge of clk with enable = 1 and d = 0xFFFFFFFF, so that is what it captured.

In a real circuit, the enable and d signals would likely have been driven by the clock themselves, and would have changed slightly after the clock edge. Even with a zero-delay simulation, this could have changed the order of evaluation in the simulator, giving very different results.

If you increase that first delay in your testbench slightly, you'll avoid this problem and get consistent results from the simulator.

initial
begin
    d = 32'hABCDEFF;
#5.1  enable = 1;
    d = 32'hFFFFFFFF;
#10 enable = 0;
    d = 32'hAAAAAAAA;        
end

EDIT: You say, "#5.1 and #10 work, but unfortunately @(posedge clock) gives the same result as #5"

Yes, this is not surprising. While this makes enable and d dependent on the clock, they are still effectively simultaneous, with the emphasis on "effectively".

Keep in mind that while the simulator is doing its best to present the illusion that it is evaluating change events in parallel, it is still fundamentally a software (sequential) program, and can only evaluate one statement at a time, creating an implicit ordering among events that are supposedly "simultaneous" (i.e., within the same simulation timestep). The actual ordering that occurs is "implementation dependent" — i.e., a crap shoot.

In this case, it is not at all surprising that the simulator processes the events in the following sequence:

At #5 clk goes from low to high, which triggers all events keyed on @posedge(clk).
The statements in the testbench module get evaluated next, setting enable high and setting d to 0xFFFFFFFF.
Then the statements in the Nbit_register module get evaluated, setting q to 0xFFFFFFFF.

In most situations, this implicit ordering of events does not matter very much at all. But when it does, you need to be aware of it, and take pains to explicitly specify the sequencing of events. Most simulators have the concept of "unit delays" (one simulation timestep) for gates and FFs, just to make sure that their outputs don't change simultaneously with their inputs. This is what allows structures like shift registers to work correctly.

EDIT #2: A related issue is that you used blocking assignment statements (= instead of the non-blocking <=) in your testbench. I found this reference that does a good job of explaining the significance of this.

Basically, blocking assignments take effect immediately, during the current simulation timestep, while non-blocking assignments don't take effect until after the timestep — i.e., after all change events triggered for the timestep have been evaluated.

If you had said

@(posedge clk)  enable <= 1;
    d <= 32'hFFFFFFFF;

then the assignments to enable and d would not have taken effect until after the assignment to q had been processed, and q would not have changed until the second clock edge.

Best Answer

Related Solutions

Electronic – Unexpected Verilog warning re FPGA clock assignment

Electrical – register with enable signal, problem of understanding simulation results

Related Topic