Flex10k - LE optimization?

Altera_Forum · ‎10-31-2013

Hi!

Aside from cranking all the settings up, is there any tribal knowledge / best practices about LE optimization for ye olde flex10k? One odd thing I found, as mentioned earlier somewhere, was that my LE count actually went down when I increased the number of states by one (and therefore crossed over from 4- to 5-bits for my state field).

Are there any others? I.e. is it cheaper in terms of LE to check for zero rather than doing a compare? In this particular example, counting down and checking for zero changed the RTL from a comparator to an n-bit OR.

Note that because I'm using ancient tech I can't use the Latest Greatest Optimizer-2000(tm) of the current Quartus suite and am relegated to using 9.something.

-Mux

Altera_Forum · ‎11-01-2013

Use an lpm_counter configured for down mode (this ensures that fast carry chains are used, and the compare with zero comes for free).

Here's an example ...


-- Altera LPM components
library lpm;
use lpm.lpm_components.all;
...
    -- Bit counter
    bit_d <= to_slv(BIT_VALUE, BIT_WIDTH);
    u3: lpm_counter
        generic map (
            LPM_WIDTH     => BIT_WIDTH,
            LPM_DIRECTION => "DOWN"
        )
        port map (
            -- Simulation-only output (suppress Quartus II warning)
            --
            -- altera translate_off
            q      => bit_q,
            -- altera translate_on
            aclr   => rst,
            clock  => clk,
            sload  => bit_load,
            cnt_en => bit_en,
            cout   => bit_done,
            data   => bit_d
        );

The carry-out, i.e., done indicator, is the zero comparison - it asserts when the count-down counter reaches zero.

Cheers,

Dave

Altera_Forum · ‎11-01-2013

Thanks Dave!

I'll give that a whirl. I take it the compiler doesn't recognize this by default when you create a counter? I'll see how much of a difference it makes for my VGA driver which currently comes in somewhere around 40LE's or thereabouts just for the timing-chain / sync- and blank generation. Of course, if I use down counters I'll need to invert them at some point so we'll see how much space that takes :-)

Cheers!

-Mux

Altera_Forum · ‎11-01-2013

--- Quote Start ---

I take it the compiler doesn't recognize this by default when you create a counter?

--- Quote End ---

The counter function typically gets detected ok, its the detection of zero that often causes a comparator to be created, rather than inferring the use of the carry-out.

Try it and see, i.e., use the lpm_counter and carry-out, and then code the same using one of Altera's recommended templates. Post what you find :)

Cheers,

Dave

Altera_Forum · ‎11-01-2013

Actually, years (make that decades) ago when I was designing stuff with 74xx161 counters I'd use the carry-out as a load, so you'd 'shift' the range towards the end of the counter rather than the beginning. For example, rather than using a 10-bit counter and compare with 799, you'd use the carry to load the value to 1024-799, which shifts the range from 200-1023 and what is probably what I'll be using here as well.. Just means you've got to shift your sync / addressing around a bit :-)

I'll keep you guys posted!

-Mux

Altera_Forum · ‎11-04-2013

Spent some time re-writing modules and managed to fit my entire design with 2% to spare :-) The VGA timing chain itself benefited greatly, saving 20 LE's just by switching over to lpm_counters up counters. The cout is great as it now serves as a load as well as an enable for the vertical timing. Note that you pay 1 LE for the additional cout and sload signal but despite that, it's all good!

Having just scored a bunch of EPM7064's on eBay, I'll probably break out the address/io decoding and some other stuff, but still... lpm functions are your friend if you're tight on space!

Thanks Dave!

-Mux

Altera_Forum · ‎11-04-2013

--- Quote Start ---

Thanks Dave!

--- Quote End ---

Glad to hear it helped!

Cheers,

Dave