register enable line usage in `case` block (verilog synthesis for altera cpld)

Question

I have the following in a verilog design aimed at an altera CPLD (currently targeting EPM240, although the target device isn't set in stone):

always @(posedge clk)
 if (we)
 begin
 case (rw_sel)
 3'd0: reg0 <= data_in;
 3'd1: reg1 <= data_in;
 ...
 endcase
 end

I assumed that this would synthesize a design where rw_sel was decoded into a number of different select lines, which would be 'and'ed with we, and then connected to the enable input of the register.

However, this isn't what has been done: examining the results in the RTL viewer, the we line has been connected directly to the enable inputs of every register, then the data input of each register is connected to a mux2 that selects from either the incoming data or the current value of the register.

Isn't this much less space-efficient than the design I was expecting? And if so, how can I persuade Quartus to generate the more efficient version?

Answer 1

Isn't this much less space-efficient than the design I was expecting?

No; it's actually better.

Consider the structure of the LE in the MAX II CPLD (from MAX II Architecture). I've highlighted an important detail:

enter image description here

The input to the register's clock enable does not pass through the LUT. It must be driven by one of the two clock enable signals which are shared across the LAB.

Your design would require each register to be implemented in a separate LAB, which will run you out of space very rapidly. The synthesizer's design allows each of the registers to be implemented within a single LE, probably all within a single LAB.

• Jules: Yes, I was just reading through the data sheet and came to the same conclusion. And not only that, but the mux it's using, which I was assuming would require a separate LE to implement, is actually a fixed part of the LE (shown in the top left of the schematic, on the data3 line into the LUT), so uses no resources at all to implement.
• user39382: Not quite. That's a configuration MUX -- its value can't be changed at runtime. Still, implementing a mux in the LUT is easy.