0
\$\begingroup\$

as far as I know, when the items in case are not parallel

it would compose a priority routing network not the multiplexing network.

In other words, it should uses multiple 2-to-1 MUXs to represent priority in between the case items.

For example, below code has non-parallel case items 3'b11 and 3'b1??.

module non_parallel_but_full_case
(
  input wire [2:0] s,
  output reg y
);
  always @*
  //below case is not parallel but full case
    casez (s)
      3'b111: y = 1'b1;
      3'b1??: y = 1'b0;
      default: y = 1'b1;
    endcase
endmodule

Therefore, I've expected the synthesized circuit may have MUXs not the ROM.

However, when I tested the code in the vivado and its RTL description shows ROM not the MUX.

RTL descrption of the non-parallel but full case

Why the non-parallel case uses the ROM instead of the MUXs?

===================================================== Added question.

module decoder_2_4_if (
  input wire [1:0] a,
  input wire en,
  output reg [3:0] y
);

  always @*
    if (en == 1'b0)
      y = 4'b0000;
    else if (a == 2'b00)
      y = 4'b0001;
    else if (a == 2'b01)
      y = 4'b0010;
    else if (a == 2'b10)
      y = 4'b0100;
    else
      y = 4'b1000;
endmodule

The above code generates the multiple cascaded 2-to-1 MUXs.

However, the same logic implemented by the case statement uses the ROM.

module decoder_2_4_case (
  input wire [1:0] a,
  input wire en,
  output reg [3:0] y
);

  always @*
  case ({en,a})
    3'b000, 3'b001, 3'b010, 3'b011: y = 4'b000;
    3'b100: y = 4'b0001;
    3'b101: y = 4'b0010;
    3'b110: y = 4'b0100;
    3'b111: y = 4'b1000;
  endcase
endmodule

In two examples, the result can be statically determined, and it would mean that two modules could be implemented by the ROM.

Then why it generates the different schematics?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Why the non-parallel case uses the ROM instead of the MUXs?

Because that's the right thing to do here!

You feed in values, you get out static values. Classical case for ROM, or in the case of FPGAs, an elemental LUT.

A mux would need the same LUT to mux the right static signals. So, the mux solution for this static case is less efficient than just ROM.

In other words, it should uses multiple 2-to-1 MUXs to represent priority in between the case items.

I don't see a reason why.

Regarding your edit:

You implicitly define a priority order when doing your else if thing, so here, the synthesizer has no choice.

\$\endgroup\$
10
  • \$\begingroup\$ Thanks for your reply, but I still having a hard time to understand it. When I use the if statement, it utilizes multiple cascaded 2-to-1 MUXs, but when I use the non-parallel case, it uses the ROM. If my understanding is correct, a ROM stores the precalculated values and it is much faster than the composing the circuits like and or nand etc. So is that a reason why the ROM is used instead of the cascaded 2-to-1 MUXs in the above example? \$\endgroup\$
    – ruach
    Dec 17, 2017 at 13:02
  • \$\begingroup\$ By the way, out of curiosity, if case statements are converted to the ROM to be efficient, is that a reason why the verilog doesn't allow the >, < operators in the case items? \$\endgroup\$
    – ruach
    Dec 17, 2017 at 13:05
  • \$\begingroup\$ you're mixing things up. It's not used because it's faster, it's used because any other implementation would include the same LUT component. and: < is an arithmetic operator. you need to implement arithmetic logic to have it. So, you tell me how the combinatorial way to compare two 64bit variables looks like, and then you see why we don't do that. \$\endgroup\$ Dec 17, 2017 at 13:08
  • \$\begingroup\$ I am so sorry to bother you, as a dummy in FPGA area, I cannot understand your answer completely. What do you mean by any other implementation would include the same LUT component? And I just added one more related question. Could you please give me a little more help? I appreciate your help :D \$\endgroup\$
    – ruach
    Dec 17, 2017 at 13:21
  • \$\begingroup\$ So, how would you implement this using a MUX? You would have a) "constants" that you b) select with a mux setting. That mux setting is also a Look-Up Table (LUT), and those constants are often also implemented using LUTs. So, your MUX solution simply /contains/ a LUT, and hence, you can also directly use a LUT without having any disadvantage. \$\endgroup\$ Dec 17, 2017 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.