Why does the fitter generate a counter with a reversed bit order?

[Altera_Forum]

Hi All, 

 I am working on a controller for a 32x32 RGB matrix using the DE0 Nano. So far I have successfully manage to display a still image using a pair of 2-port RAM modules to store the top and bottom half of the display.  The design uses three counters, one keeps track of the column data and LED on time, another keeps track of how many times the row is re-drawn to achieve an 8-bit resolution of brightness (24-bit colour) in a PWM fashion, and the final counter keeps track of the row. The counters are cascaded, starting with the column counter, then the PWM and finally the row counter:  http://www.alteraforum.com/forum/attachment.php?attachmentid=10245&stc=1    The first two counters, 7-bit and 8-bit, are inferred by the fitter as expected. However the 4-bit row counter is inferred with a reversed bit order, as shown in the following screenshot:   http://www.alteraforum.com/forum/attachment.php?attachmentid=10246&stc=1   The row counter needs to be connected to a physical 4-bit MUX on the 32x32 matrix. At the moment the design works fine if I connect the LSB of the MUX to the pin that joins the MSB of the row counter, i.e. in a reversed order, row_counter[0] to the D pin of the MUX and row_counter[3] to the A pin of the MUX. The codes for all the counters are very basic, and identical with the exception of the number of bits in each. Also the current code for the 4-bit counter has the carry flag removed, however this makes no difference to the bit order chosen by the fitter.   module counter_4( clk, counter_out ); input reg clk; output reg counter_out = 0; always @ (posedge clk) begin counter_out <= counter_out + 1; end endmodule   Although everything is working great, this feels like a bit of a 'work around' and I would like to understand why the fitter is reversing the bit order!  Many thanks  Simon

[Altera_Forum]

It doens't look like it is reversed. 

Your counters have Most significant bit at lowest number. i.e. row_counter_mod MSB is bit[0]. If you were to look at counter_out[3] logic combo you will find an inverter. This is the normal behavior of a counter which least significant bit toggles every clock(as it is inferred here).  I would infer counters in the opposite order to alleviate making it easy to talk about them as in this case, least significant bit of the counter register is actially most significant bit of the counter. ---------------------  module counter_4(  clk, counter_out  );  input reg clk; output reg [3:0] counter_out = 0;  always @ (posedge clk) begin   counter_out <= counter_out + 1;  end  endmodule ------------------

[Altera_Forum]

I neglected to mention I am using Quartus 13.1.0 on CentOS 6.6. I have since found another thread describing the same problem, seems to be a bug with Quartus 13.1  

 http://www.alteraforum.com/forum/showthread.php?t=43109

[Altera_Forum]

--- Quote Start ---  It doens't look like it is reversed. Your counters have Most significant bit at lowest number. i.e. row_counter_mod MSB is bit[0]. If you were to look at counter_out[3] logic combo you will find an inverter. This is the normal behavior of a counter which least significant bit toggles every clock(as it is inferred here).  I would infer counters in the opposite order to alleviate making it easy to talk about them as in this case, least significant bit of the counter register is actially most significant bit of the counter. ---------------------  module counter_4(  clk, counter_out  );  input reg clk; output reg [3:0] counter_out = 0;  always @ (posedge clk) begin   counter_out <= counter_out + 1;  end  endmodule ------------------  --- Quote End ---    Doh! Its always something simple! Cheers for your response, feeling pretty stupid right now! :oops: Yeh I did figure out that bit [3] had a single inverter, hence it would change state every cycle and act as the LSB. For some reason I thought that the other counters had been inferred the other way and row_counter was different, but on looking at the netlist viewer again, they have all been inferred in the same way, to match the endianness of the statement! Not quite sure why I adopted the [0:3] notation rather than [3:0], think I was following some SystemVerilog examples that were noted like that a while back. Maybe I need to put Quartus down for a bit and get an early night! ;)  http://www.alteraforum.com/forum/attachment.php?attachmentid=10293&stc=1