Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Lattice iCECube2 for iCE40 Devices

Reply
Thread Tools

Lattice iCECube2 for iCE40 Devices

 
 
rickman
Guest
Posts: n/a
 
      01-09-2013
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
 
Reply With Quote
 
 
 
 
GaborSzakacs
Guest
Posts: n/a
 
      01-10-2013
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
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      01-10-2013
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ieee.math_real-support in Synplify for Lattice Sean Durkin VHDL 2 09-10-2009 02:47 PM
Lattice's Online Store Now Sells Silicon - No Minimum Order Quantity bart VHDL 14 06-15-2007 12:47 AM
Bug in DDR template in Lattice FPGAs ? ALuPin VHDL 8 04-28-2005 07:22 AM
Can security devices harm DVDs and electronic devices? curious@nospam.com DVD Video 12 03-02-2005 06:57 AM
"Windows CE Devices and Palm Devices Help Needed" Naveen Vaila ASP .Net Mobile 1 06-23-2004 10:12 AM



Advertisments