Lattice iCECube2 for iCE40 Devices

Discussion in 'VHDL' started by rickman, Jan 9, 2013.

  1. rickman

    rickman Guest

    How many have used the iCECube2 tool? I am just getting started with it
    and it seems to be less than optimal. It uses Synplify Pro for
    synthesis. I wrote code for a simple enabled up/down counter which I
    expect would use one LUT per bit. But it seems to be using two LUTs
    per. Instead of running the enable to the register, it is adding the
    enable into the logic to control whether the bit is inverted or not.
    This requires an extra input and so an extra LUT per bit. Here is the
    code involved.

    ....
    PORT (
    SysRst : in std_logic;
    RateHigh : in std_logic;
    RateEn : in std_logic;
    ....
    signal VFOclkout : std_logic;
    signal PhaseStepReg : signed (RESOLUTION - 1 downto 0);
    ....
    PROCESS (VFOclkout, SysRst) begin
    if (SysRst ='1') then
    PhaseStepReg <= to_signed(-VFOSTEPSIZE, RESOLUTION);
    elsif (rising_edge(VFOclkout)) then
    if (RateEn = '1') then
    if (RateHigh = '0') then
    PhaseStepReg <= PhaseStepReg + 1;
    else
    PhaseStepReg <= PhaseStepReg - 1;
    end if;
    end if;
    end if;
    end process;
    ....

    The output, PhaseStepReg, is used in another process. I can't see
    anything that would affect the synthesis of this counter.

    I'm wondering if there is something about the architecture of these
    parts that precludes an up/down counter in one LUT/bit. They use a
    single input on a register bank for all enables in common, but could
    that really make them use an extra bank of logic? I may simplify this
    code to just the up/down counter and send it off to support. So far I
    haven't gotten much from Lattice support other than the local FAE.
    Seems they are in a time zone about 12 hours off from mine.

    Rick
    rickman, Jan 9, 2013
    #1
    1. Advertising

  2. rickman

    GaborSzakacs Guest

    rickman wrote:
    > How many have used the iCECube2 tool? I am just getting started with it
    > and it seems to be less than optimal. It uses Synplify Pro for
    > synthesis. I wrote code for a simple enabled up/down counter which I
    > expect would use one LUT per bit. But it seems to be using two LUTs
    > per. Instead of running the enable to the register, it is adding the
    > enable into the logic to control whether the bit is inverted or not.
    > This requires an extra input and so an extra LUT per bit. Here is the
    > code involved.
    >
    > ...
    > PORT (
    > SysRst : in std_logic;
    > RateHigh : in std_logic;
    > RateEn : in std_logic;
    > ...
    > signal VFOclkout : std_logic;
    > signal PhaseStepReg : signed (RESOLUTION - 1 downto 0);
    > ...
    > PROCESS (VFOclkout, SysRst) begin
    > if (SysRst ='1') then
    > PhaseStepReg <= to_signed(-VFOSTEPSIZE, RESOLUTION);
    > elsif (rising_edge(VFOclkout)) then
    > if (RateEn = '1') then
    > if (RateHigh = '0') then
    > PhaseStepReg <= PhaseStepReg + 1;
    > else
    > PhaseStepReg <= PhaseStepReg - 1;
    > end if;
    > end if;
    > end if;
    > end process;
    > ...
    >
    > The output, PhaseStepReg, is used in another process. I can't see
    > anything that would affect the synthesis of this counter.
    >
    > I'm wondering if there is something about the architecture of these
    > parts that precludes an up/down counter in one LUT/bit. They use a
    > single input on a register bank for all enables in common, but could
    > that really make them use an extra bank of logic? I may simplify this
    > code to just the up/down counter and send it off to support. So far I
    > haven't gotten much from Lattice support other than the local FAE. Seems
    > they are in a time zone about 12 hours off from mine.
    >
    > Rick


    It's been a while since I used any Lattice tools, but I seem to remember
    that Synplify for Lattice has a compiler directive that encourages it
    to use a particular signal as a clock enable. In your case you could
    apply this to RateEn and see if it causes the synthesizer to recognize
    it as an enable to reduce the LUT count. That being said, I have not
    used the ICE series parts and there may still be another reason why
    the tools have not inferred clock enables.

    -- Gabor
    GaborSzakacs, Jan 10, 2013
    #2
    1. Advertising

  3. rickman

    rickman Guest

    On 1/10/2013 8:50 AM, GaborSzakacs wrote:
    > rickman wrote:
    >> How many have used the iCECube2 tool? I am just getting started with
    >> it and it seems to be less than optimal. It uses Synplify Pro for
    >> synthesis. I wrote code for a simple enabled up/down counter which I
    >> expect would use one LUT per bit. But it seems to be using two LUTs
    >> per. Instead of running the enable to the register, it is adding the
    >> enable into the logic to control whether the bit is inverted or not.
    >> This requires an extra input and so an extra LUT per bit. Here is the
    >> code involved.
    >>
    >> ...
    >> PORT (
    >> SysRst : in std_logic;
    >> RateHigh : in std_logic;
    >> RateEn : in std_logic;
    >> ...
    >> signal VFOclkout : std_logic;
    >> signal PhaseStepReg : signed (RESOLUTION - 1 downto 0);
    >> ...
    >> PROCESS (VFOclkout, SysRst) begin
    >> if (SysRst ='1') then
    >> PhaseStepReg <= to_signed(-VFOSTEPSIZE, RESOLUTION);
    >> elsif (rising_edge(VFOclkout)) then
    >> if (RateEn = '1') then
    >> if (RateHigh = '0') then
    >> PhaseStepReg <= PhaseStepReg + 1;
    >> else
    >> PhaseStepReg <= PhaseStepReg - 1;
    >> end if;
    >> end if;
    >> end if;
    >> end process;
    >> ...
    >>
    >> The output, PhaseStepReg, is used in another process. I can't see
    >> anything that would affect the synthesis of this counter.
    >>
    >> I'm wondering if there is something about the architecture of these
    >> parts that precludes an up/down counter in one LUT/bit. They use a
    >> single input on a register bank for all enables in common, but could
    >> that really make them use an extra bank of logic? I may simplify this
    >> code to just the up/down counter and send it off to support. So far I
    >> haven't gotten much from Lattice support other than the local FAE.
    >> Seems they are in a time zone about 12 hours off from mine.
    >>
    >> Rick

    >
    > It's been a while since I used any Lattice tools, but I seem to remember
    > that Synplify for Lattice has a compiler directive that encourages it
    > to use a particular signal as a clock enable. In your case you could
    > apply this to RateEn and see if it causes the synthesizer to recognize
    > it as an enable to reduce the LUT count. That being said, I have not
    > used the ICE series parts and there may still be another reason why
    > the tools have not inferred clock enables.
    >
    > -- Gabor


    Thanks for the reply. You might be right. A simple divide by two FF
    also uses the logic to implement an enable. I'll look into the
    directive. Seems rather retarded really. Most of the time the
    synthesizer will even add logic to the enable and with these tools it
    doesn't want to use the enable at all.

    I'll give the directive a try.

    I did put in a ticket for this and we'll see what they say. The iCE40
    parts started out with their own tools so it's hard to say what might
    have happened when they were brought over to Lattice.

    Rick
    rickman, Jan 10, 2013
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ALuPin
    Replies:
    8
    Views:
    666
    ALuPin
    Apr 28, 2005
  2. bart
    Replies:
    14
    Views:
    763
  3. Sean Durkin
    Replies:
    2
    Views:
    1,098
    Sean Durkin
    Sep 10, 2009
  4. Naveen Vaila

    "Windows CE Devices and Palm Devices Help Needed"

    Naveen Vaila, May 24, 2004, in forum: ASP .Net Mobile
    Replies:
    1
    Views:
    501
    Abraham Durairaj
    Jun 23, 2004
  5. littlegamer
    Replies:
    1
    Views:
    354
Loading...

Share This Page