The delay specification in a CPLD is the maximum (i.e. worst case) pin-to-pin delay. That is, the maximum delay it takes for a signal "edge" to propagate from any pin to any other pin through the internal (combinational) logic.
Saying that a CPLD doesn't have a clock is misguided; you can use a pin as a clock input to feed sequential logic. Comparing it to a microcontroller is also not really suitable, since CPLDs implement hardware, not software.
The code you show is essentially a priority encoder.
That is, it has an input of many signals, and its output indicates which of those signals is set, giving priority to the left-most set signal if more than one is set.
However, I see conflicting definitions of the standard behavior for this circuit in the two places I checked.
According to Wikipedia, the standard priority encoder numbers its inputs from 1. That is, if the least significant input bit is set, it outputs 1, not 0. The Wikipedia priority encoder outputs 0 when none of the input bits are set.
Xilinx's XST User Guide (p. 80), however, defines a priority encoder closer to what you coded. The inputs are numbered from 0, so when the input's lsb is set it gives a 0 output. However, the Xilinx definition gives no spec for the output when all input bits are clear (Your code will output 3'd7).
The Xilinx user guide, of course, will determine what the Xilinx synthesis software is expecting. The main point is that a special directive (*priority_extract ="force"*)
is required for XST to recognize this structure and generate optimal synthesis results.
Here's Xilinx's recommended form for an 8-to-3 priority encoder:
(* priority_extract="force" *)
module v_priority_encoder_1 (sel, code);
input [7:0] sel;
output [2:0] code;
reg [2:0] code;
always @(sel)
begin
if (sel[0]) code = 3’b000;
else if (sel[1]) code = 3’b001;
else if (sel[2]) code = 3’b010;
else if (sel[3]) code = 3’b011;
else if (sel[4]) code = 3’b100;
else if (sel[5]) code = 3’b101;
else if (sel[6]) code = 3’b110;
else if (sel[7]) code = 3’b111;
else code = 3’bxxx;
end
endmodule
If you can rearrange your surrounding logic to let you use Xilinx's recommended coding style, that's probably the best way to get a better result.
I think you can get this by instantiating the Xilinx encoder module with
v_priority_encoder_1 pe_inst (.sel({~|{RL[6:0]}, RL[6:0]}), .code(rlever));
I've nor'ed together all bits of RL[6:0]
to get an 8th input bit that will trigger the 3'b111 output when all RL bits are low.
For the llever
logic, you can probably reduce the resource usage by making a modified encoder module, following the Xilinx template, but requiring only 7 input bits (your 6 bits of LL
plus an additional bit that goes high when the other 6 are all low).
Using this template assumes the version of ISE you have is using the XST synthesis engine. It seems like they change synthesis tools on every major rev of ISE, so check that the document I linked actually corresponds to your version of ISE. If not, check the recommended style in your documentation to see what your tool expects.
Best Answer
If all you want to do is combine two smaller arrays into a larger array of signals then it's best to use the concatenation operator:
With the above,
wire[5:3]
will be connected toLL
, andwire[2:0]
will be connected toRL
You can use it in any order like:
wire[5:0] tmp = {RL, LL];
Or even:
wire[5:0] tmp = {LL[0], RL, LL[2:1];
(you can see how this can be used to shift/rotate signals)
Still, I'm not sure why changing to the OR should use another 7 macrocells, it's possibly (probably) because the synthesis tool is inferring an adder with the + operator and the CPLD has an adder cell that it can use, as opposed to making the adder from a few gates.
How did you determine this? Did you check the technology schematic to see what's being created?
To help discover exactly what's happening, seeing the rest of your modules code would be helpful (also I can try it in ISE here)
EDIT - out of curiosity I wrote a small test module using the relevant bit of the above code. I tried synthesising (with default settings) for a Spartan-3A and the XC264A CPLD, with the
+
or the|
. Both terms produced identical results for the Spartan and the CPLD, both in the technology viewer and the place and route macrocell usage report.With this information, it looks like it must be something to do with the rest of the design and possibly the synthesis tool settings (optimisation, etc). The snippet above should just concatenate the two smaller signals into one larger one, so no logic should be necessary.