4 bit x 4 bit using look up table (rom)

verilog

This is an introductory level verilog course. I'm trying to generate a 8 bit output from 4 bit multiplied with 4 bit. Here is the code I have so far.

    // 4 bit x 4 bit operator
    module bit4x4Operator(
    input [3:0]A,        //this code works when A and B are switched to 7:0
    input [3:0]B,
    output [7:0]P
    );
    reg [7:0] ROM[0:224];
    integer i,k;

    initial 
    begin
      for (i = 0; i < 16; i = i+1)
           for (k = 0; k < 16; k = k + 1)
              begin
                  ROM [(i * k)] = (i * k);
              end
     end
     assign P = ROM[(A * B)];

      endmodule

So, the assignment has to be done implementing the ROM[], and this code runs and outputs correctly if the input bits are changed to 7:0, but I'm not sure why that works, and why it can't be the way it is now.

Best Answer

assign P = ROM[(A * B)]; should be assign P = ROM[{A,B}]; The curly brackets ({}) is used to concatenate the bits. The square brackets ([]) are for indexing.

For ROM [(i * k)] = (i * k); you will want ROM [{i[3:0],k[3:0]}] = (i * k);

i and k are integers (equivalent to reg signed [31:0]), so {i,k} would be 64 bits wide with i starting at bit 32. The [3:0] is range slice if the integers that are meaningful for this indexing.

Note: you do not want to redefine i and k as reg [3:0] as this will give you an infinite loop 15 + 1 is 0 for a 4-bit reg and always less than 16.

Related Solutions

Can someone help me complete this Verilog code for this sequential circuit

Actually, the structure of your verilog looks just fine. It's the details that are wrong, in a lot of places. Here are some:

reg [3:1] y2, y1, Y2, Y1

Yes, the missing semicolon throws the compiler off. More to the point, [3:1] tells it that each of these regs is three bits wide, but they're only one bit wide in the planning. Traditionally we use 0 for the least significant bit (such that the binary interpretation has weight 2^n at bit n). The parameter line would thus be [1:0], as it is you extend it to three bits wide.

always @(w,y2,y1)
always @(negedge Resetn, posedge Clock)

The sensitivity list is separated by or, not comma.

    case (y2)
        A: if (w)  Y2 = 0;
                   Y1 = 1;
           else    Y2 = 0;
                   Y1 = 0;

y2 in this case statement only matches one bit in your planning (three in the code, but that made less sense). You can concatenate bits using {y2,y1}; in fact, extending the case to case ({y2,y1,w}) will let you use case matches like {A,1'b0}: and remove the if statements entirely.

Secondly, you are trying to manage groups of statements (both assignments to Y2 and Y1) with if; doing so requires enclosing them with begin and end. Alternatively, you could make a wider assignment such as {Y2,Y1} <= B;, which ends up more readable as it can use your named states.

Thirdly, assignment using = can cause some confusion (it acts more like sequential languages, while <= doesn't modify the meaning of a reg within your always). In this case, it is fine as the block is fully combinatorial and does not depend on its own outputs.

Finally (for the case section), you can simply add more matches. You don't even need a default match, but it's probably convenient to use default to go to state A in this case.

always @(negedge Resetn, posedge Clock)
    if (Resetn == 0) //something :/
    else //something else :/

Something and something else would be register updates, such as {y2,y1} <= {Y2,Y1};. It is the clock edge sensitivity that turns the regs into flipflops.

Finally, since you should now understand what defines a reg width, why don't you make two bit wide regs named state and next_state to replace {y2,y1} and {Y2,Y1} respectively?

Veriog:How to pass a register to a module

Your conclusion is not correct. It doesn't matter to the hardware whether you use a reg or a wire, the issues you are discussing are part of the Verilog syntax.

The reason your design gets so much faster when you replace fooWire with a number is that your logic isn't really doing anything and it all gets optimized away. The assignment of fooWire to fooReg requires that signals actually propagate from one part of the chip to another, and that takes time. Changing the assignment of fooWire to fooWire+1 forces the tools to create a 32-bit adder and insert it in the delay path, so of course the design will get slower.

By the way, it's register, not registry.

Best Answer

Related Solutions

Can someone help me complete this Verilog code for this sequential circuit

Veriog:How to pass a register to a module

Related Topic