Is MAX V register itself really configurable as T or JK flip-flop to build a counter?

[Altera_Forum]

The MAX V CPLD handbook says: 'You can configure each LE's programmable register for D, T, JK, or SR operation.' 

 My question is:  How can I actually select between these operations of the LE-register when I instantiate the LE directly in architectural level,  and do I need to involve additional combinational logic to achieve a T / JK operation of the register instead of its default 'D' mode?  More info about my plan: I would like to implement a (loadable/settable) 8bit up-counter using only the register part of the LE, so I can use the 8 remaining LUTs for other purposes and maintain a great area efficiency...  (My reason is that the full design need to fit in the smallest 5M40Z, I need to utilize the chip very efficiently to fit in area and timing-constraints, so I want to use the least possible amount of resources for the counter. I seem to have full low-level control with 'maxv_lcell_register' simulation atom, but it has no parameter to describe the flip-flop type as JK or T, whatever. )  Thanks in advance, if anyone have an idea or hint, or maybe other tip for efficient counter-creation... (Or pointing out a better source of description of MAX V CPLD LE's architecture.)

[Altera_Forum]

I like your thinking. However... 

 How do you intend to implement an "8bit up-counter using only the register part of the le" without making use of the look-up table? Each register in your counter will need it in order to determine when to toggle the register. The combinatorial decode required in front of each register will be a function of the output states of one or more registers in your counter.  The CPLD can implement the D, T, JK, or SR operation by virtue of the fact it has the combinatorial decode available in the LE - i.e. it has to make use of the look-up table to do so.  Good luck in writing some concise, compact code! That'll keep your design small.  Cheers, Alex

[Altera_Forum]

To be hardware efficient, the finally implemented logic should take account of the MAX logic core topology, comprised of D-FFs driven by a 4-input LUT with fast carry chain (identical to Cyclone I - IV core). 

 According to my observations, the Quartus synthesis tool is quite efficient when implementing arithmetical problems (including counters), but not so good in some non-arithmetical cases. So it ususally won't need your hints for the counter. But it's worth a try. In any case you should compile a lpm_counter implementation for comparison.

[Altera_Forum]

Thanks for the fast answer. 

 @Alex: I forgot to mention, but of course I would experiment with a ripple binary counter (or from other aspect: freq.divider), which might be constructed from T/JK toggling flip-flops only, and probably with only 8 bits it could run at 100MHz clock-signal fed into the lowest bit. (Clock-to-output time in MAX V CPLD is around 0.5ns, 8 ripple-stages could add up to 4ns which is still comfortably inside the 10ns period, with around 4ns slack if setup-times and routing/LUT delays are considered too.) But if the case is that T and JK flipflops can only be made with LUT in the LE of MAX V (according to FvM), there's probably no point for a ripple-counter, as a simple synchronous adder/incrementer utilizing the LUT carry-select chain could be better... Anyway, I'll try to experiment a bit to get the most efficient way.

[Altera_Forum]

I share my idea which I came up with, maybe this can be useful for some people to save some LUTs in their design. 

I could make a 4bit down-counter without using any LUTs by converting the registers to T-flipflop with a feedback from their 'regout' outputs to their 'sclr' synchronous-clear inputs, which contains an inverter. To use the 'sclr'-inverter for toggling (and eventually counting), the 'sload' signal and 'datac' input must be high, so an inverter is created from the output of the register to its D input. ('datac' is useful to reset the counter when set to low, 'ena' can be used to enable/disable the counter.) This method seemed to work in gate-level simulation, but I haven't tried it on real hardware. Must work there too in my opinion, as no such tricks are involved which are related to temperature, etc. an example code:  module freqdiv (input clk, countenable, init_neg, output [4-1:0] divclk); genvar i; generate  for (i=0; i<4; i=i+1) begin : DIV  maxv_lcell# ( .operation_mode("normal"), .lut_mask("FFFF") )  divstage ( .regout(divclk), .clk( i ? divclk[i-1] : clk ), .ena(countenable), .datac(init_neg), .sload(1), .sclr(divclk), .aload(0),.aclr(0) );  end endgenerate  The problem with this approach that fast register-chain couldn't be utilized as every bit of the chain needed a distinct sclr which there are only one per LAB. So the LEs were placed by the fitter into adjacent left/right neighboring LEs (5M40Z could only allow 4 of them for some LAB-resource limitation reason), the delay between the division stages were 4..5ns despide DirectLink, so this circuit is useful for counters with lower frequency-requirement, or a frequency divisor, but not for fast (100MHz and so) counters, due to the ripple-chain's added-up propagation delays. The advantage is that the free LUTs can still be used for some additional logic/arithmetic/mux operations, saving some chip-resources... (LUT-mask above is 'FFFF', as an example, but it can be anything for the desired function, of course.)