Design PAR in Stratix

Hi folks,

I have a very simple design that uses 3 LEs in Stratix when compiled
with either Quartus II 4.0 or Synplify. There must be something I
don't realize about the LE/routing architecture because I think it
should/could use only 1 LE (see design below). I would think the
design should connect the four terms to the 4 inputs of the LUT, feed
this LUT's output to the D-input of the register of the same LE, and
also connect the enable and reset of the register with the respective
inputs.

Here's what it does instead: Routes the 4 terms to its own LUT, then
ANDs the LUT's output with the enable input in a 2nd LE and fianlly
uses this result as the enable of the register in a 3rd LE. The
D-input of this register is tied to VCC. Seems very odd to me.

In Quartus, I turned on Optimize Area, Auto Packed Regs=Minimize, and
played with a few other options, to no avail. Setting the fmax
sufficiently high packed the design into 2 LEs but did it in a wierd
way. I'm curious why the design doesn't ever route into 1 LE?

-- Pete

library ieee;
use ieee.std_logic_1164.all;

entity test_4input is
       port (
         clk           : in std_logic;
         -- should go to LE's reset:
         rst_n         : in std_logic;
         ena           : in std_logic;
         -- four terms:
         a, b, c, d    : in std_logic;
         result        : out std_logic     );
end;

architecture rtl of test_4input is
       signal sig : std_logic;
begin

       process( clk, rst_n ) 
       begin
              if rst_n='0' then
                 sig    <= '0';
              elsif clk'event and clk='1' then
                 if ena='1' then
                       if (a xor b xor c xor d)='1' then
                             sig <= '1';
                       end if;
                 end if;
              end if;
       end process;

       result <= sig;
end;

Peter Sommerfeld wrote:
> Hi folks,
> 
> I have a very simple design that uses 3 LEs in Stratix when compiled
> with either Quartus II 4.0 or Synplify. There must be something I
> don't realize about the LE/routing architecture because I think it
> should/could use only 1 LE (see design below). I would think the
> design should connect the four terms to the 4 inputs of the LUT, feed
> this LUT's output to the D-input of the register of the same LE, and
> also connect the enable and reset of the register with the respective
> inputs.
> 
> Here's what it does instead: Routes the 4 terms to its own LUT, then
> ANDs the LUT's output with the enable input in a 2nd LE and fianlly
> uses this result as the enable of the register in a 3rd LE. The
> D-input of this register is tied to VCC. Seems very odd to me.

Howdy Peter,

It doesn't seem so odd to me since that is basically what the code is 
telling it to do.  The code fragment creates a latch that, once set, 
never clears until the reset happens.  This means that it can't use the 
D-input of the FF, and it also means that the control for the enable 
input has 5 inputs (requiring two LUTs).

So the only question in my mind is if the Stratix can't control the 
enable input of the FF from a LUT within the same LE, or the tools don't 
know how.

If you didn't mean to have a latch, you might put a "sig <= '0';" in 
there somewhere.  Or get rid of the inner-most if statement altogether.

Have fun,

    Marc

> In Quartus, I turned on Optimize Area, Auto Packed Regs=Minimize, and
> played with a few other options, to no avail. Setting the fmax
> sufficiently high packed the design into 2 LEs but did it in a wierd
> way. I'm curious why the design doesn't ever route into 1 LE?
> 
> -- Pete
> 
> library ieee;
> use ieee.std_logic_1164.all;
> 
> entity test_4input is
>        port (
>          clk           : in std_logic;
>          -- should go to LE's reset:
>          rst_n         : in std_logic;
>          ena           : in std_logic;
>          -- four terms:
>          a, b, c, d    : in std_logic;
>          result        : out std_logic     );
> end;
> 
> architecture rtl of test_4input is
>        signal sig : std_logic;
> begin
> 
>        process( clk, rst_n ) 
>        begin
>               if rst_n='0' then
>                  sig    <= '0';
>               elsif clk'event and clk='1' then
>                  if ena='1' then
>                        if (a xor b xor c xor d)='1' then
>                              sig <= '1';
>                        end if;
>                  end if;
>               end if;
>        end process;
> 
>        result <= sig;
> end;

Oops, never mind. I realized my mistake right after I posted.

-- Pete

petersommerfeld@hotmail.com (Peter Sommerfeld) wrote in message news:<5c4d983.0404270209.7a5a45a0@posting.google.com>...
> Hi folks,
> 
> I have a very simple design that uses 3 LEs in Stratix when compiled
> with either Quartus II 4.0 or Synplify. There must be something I
> don't realize about the LE/routing architecture because I think it
> should/could use only 1 LE (see design below). I would think the
> design should connect the four terms to the 4 inputs of the LUT, feed
> this LUT's output to the D-input of the register of the same LE, and
> also connect the enable and reset of the register with the respective
> inputs.
> 
> Here's what it does instead: Routes the 4 terms to its own LUT, then
> ANDs the LUT's output with the enable input in a 2nd LE and fianlly
> uses this result as the enable of the register in a 3rd LE. The
> D-input of this register is tied to VCC. Seems very odd to me.
> 
> In Quartus, I turned on Optimize Area, Auto Packed Regs=Minimize, and
> played with a few other options, to no avail. Setting the fmax
> sufficiently high packed the design into 2 LEs but did it in a wierd
> way. I'm curious why the design doesn't ever route into 1 LE?
> 
> -- Pete
> 
> library ieee;
> use ieee.std_logic_1164.all;
> 
> entity test_4input is
>        port (
>          clk           : in std_logic;
>          -- should go to LE's reset:
>          rst_n         : in std_logic;
>          ena           : in std_logic;
>          -- four terms:
>          a, b, c, d    : in std_logic;
>          result        : out std_logic     );
> end;
> 
> architecture rtl of test_4input is
>        signal sig : std_logic;
> begin
> 
>        process( clk, rst_n ) 
>        begin
>               if rst_n='0' then
>                  sig    <= '0';
>               elsif clk'event and clk='1' then
>                  if ena='1' then
>                        if (a xor b xor c xor d)='1' then
>                              sig <= '1';
>                        end if;
>                  end if;
>               end if;
>        end process;
> 
>        result <= sig;
> end;

petersommerfeld@hotmail.com (Peter Sommerfeld) writes:

I have only rudimentary synthesis experience, but let me try anyway...

> I'm curious why the design doesn't ever route into 1 LE?
>
> [...]
>               if rst_n='0' then
>                  sig    <= '0';
>               elsif clk'event and clk='1' then
>                  if ena='1' then
>                        if (a xor b xor c xor d)='1' then
>                              sig <= '1';
>                        end if;
>                  end if;
>               end if;
> [...]

'sig' is never set to '0', except when resetting.  Should it simply be

                  if ena='1' then
                    sig <= (a xor b xor c xor d);
                  end if;

Pete,

The way you've coded this, once the enable is active while the xor
equation is true, the flop will be set to "1" and ALWAYS remain "1",
unless the async reset goes active.  The flop retains a "1" regardless
of the state of the enable or the 4-input function.  Even if you
forced the tool to use the enable, it would still require a 5-input
function (two LEs) This function would be the 4-input equation or'd
with flop's current value.

When f = a xor b xor c xor d the following truth table represents your
function:

ena | f  | current | next
-------------------------
 0  | 0  |  0      | 0
 0  | 1  |  0      | 0
 1  | 0  |  0      | 0
 1  | 1  |  0      | 1
 X  | X  |  1      | 1
 

The functions are implemented in separate LEs, as Synplify has chosen
to use the flop's enable and in Stratix the enable cannot be driven
directly by the result of the associated LUT.

I don't think you've coded your intended functionallity.  If it's
coded as follows, it implements in a single LE using the clock enable
and the 4-input LUT.  In this case, the flop loads the result of the
xor equation when the enable is active and retains its current value
when the enable is inactive.

process( clk, rst_n ) 
  begin
    if rst_n='0' then
      sig    <= '0';
    elsif clk'event and clk='1' then
      if ena='1' then
        if (a xor b xor c xor d)='1' then
          sig <= '1';
        else
          sig <= '0';
        end if;
      end if;
    end if;
end process;

An alternative coding would be:

process( clk, rst_n ) 
  begin
    if rst_n='0' then
      sig    <= '0';
    elsif clk'event and clk='1' then
      if ena='1' then
        sig <= a xor b xor c xor d;
      end if;
    end if;
end process;

Bill

Hi Bill,

Yes my design did not match what I was describing. The other piece
that puzzled me was why the register was always in its own LE. And as
you say, the enable cannot be fed by the same LE's LUT, which I see
now in the Stratix handbook. It all makes sense now. Thanks.

-- Pete

incorrigible@comcast.net (Bill) wrote in message news:<680e8d30.0404270659.60099863@posting.google.com>...
> Pete,
> 
> The way you've coded this, once the enable is active while the xor
> equation is true, the flop will be set to "1" and ALWAYS remain "1",
> unless the async reset goes active.  The flop retains a "1" regardless
> of the state of the enable or the 4-input function.  Even if you
> forced the tool to use the enable, it would still require a 5-input
> function (two LEs) This function would be the 4-input equation or'd
> with flop's current value.
> 
> When f = a xor b xor c xor d the following truth table represents your
> function:
> 
> ena | f  | current | next
> -------------------------
>  0  | 0  |  0      | 0
>  0  | 1  |  0      | 0
>  1  | 0  |  0      | 0
>  1  | 1  |  0      | 1
>  X  | X  |  1      | 1
>  
> 
> The functions are implemented in separate LEs, as Synplify has chosen
> to use the flop's enable and in Stratix the enable cannot be driven
> directly by the result of the associated LUT.
> 
> I don't think you've coded your intended functionallity.  If it's
> coded as follows, it implements in a single LE using the clock enable
> and the 4-input LUT.  In this case, the flop loads the result of the
> xor equation when the enable is active and retains its current value
> when the enable is inactive.
> 
> process( clk, rst_n ) 
>   begin
>     if rst_n='0' then
>       sig    <= '0';
>     elsif clk'event and clk='1' then
>       if ena='1' then
>         if (a xor b xor c xor d)='1' then
>           sig <= '1';
>         else
>           sig <= '0';
>         end if;
>       end if;
>     end if;
> end process;
> 
> An alternative coding would be:
> 
> process( clk, rst_n ) 
>   begin
>     if rst_n='0' then
>       sig    <= '0';
>     elsif clk'event and clk='1' then
>       if ena='1' then
>         sig <= a xor b xor c xor d;
>       end if;
>     end if;
> end process;
> 
> Bill

petersommerfeld@hotmail.com (Peter Sommerfeld) wrote in message news:<5c4d983.0404271459.30275111@posting.google.com>...
> Hi Bill,
> 
> Yes my design did not match what I was describing. The other piece
> that puzzled me was why the register was always in its own LE. And as
> you say, the enable cannot be fed by the same LE's LUT, which I see
> now in the Stratix handbook. It all makes sense now. Thanks.
> 
> -- Pete

Hi Peter and Bill,

It's not quite right to say that the enable input of a register can't
be fed by the LUT in the same LE in Stratix.  There isn't a dedicated
connection from the LUT output to the enable input of the register,
but by using a local line, the LUT output can reach the LAB-wide clock
enable logic, which then can feed the register enable.

So the 2-input LUT in this design can pack into the same LE as the
register.  However, Quartus won't want to do that unless you set
AUTO_PACKED_REGISTERS_STRATIX to MINIMIZE_AREA, or you make a location
constraint to force it to happen.

Regards,

Vaughn
Altera