So who has used Lattice FPGAs recently?

One of my vendors (reps, really) has expressed a desire to sell me 
Lattice devices based on low standby power, low cost, the usual gumph.

I am doing a major redesign of an existing unit and an FPGA seems to be 
the logical way to go for a lot of the stuff onboard. I have used 
devices from vendors A & X recently so I can reasonably compare their 
offerings in this context. I am not up to speed on Lattice.

So I have a question for those who have used the devices recently (in 
the last couple of years preferably)

1. Are the free tools as decent (after the learning curve) as the 
offerings from vendors A & X? (I do know there is no free version of 
Modelsim for the freely downloadable version. Are there ways around that 
  as I have a full Modelsim license)?

2. What's the typical equivalence of the logic cell to the other 
vendors? It's sometimes hard to compare the amount of logic so one can 
compare truly equivalent devices. If someone has implemented the same 
core and has numbers on usage, that would truly be an eye opener (but I 
won't be too disappointed if nobody has such a thing).

3. Are the tools reliable? (that's relative to the other vendors of course).

These are, of course, only the first questions before I even commit to 
_looking_ at a device; I just don't want to overload the thread.

Also note I am not looking for flames or icing; just honest opinions :)

Cheers

PeteS

"PeteS" <peter.smith8380@ntlworld.com> wrote in message 
news:xJ2bh.63556$r4.20296@newsfe3-gui.ntli.net...
> One of my vendors (reps, really) has expressed a desire to sell me Lattice 
> devices based on low standby power, low cost, the usual gumph.
>
> I am doing a major redesign of an existing unit and an FPGA seems to be 
> the logical way to go for a lot of the stuff onboard. I have used devices 
> from vendors A & X recently so I can reasonably compare their offerings in 
> this context. I am not up to speed on Lattice.
>
> So I have a question for those who have used the devices recently (in the 
> last couple of years preferably)
>
> 1. Are the free tools as decent (after the learning curve) as the 
> offerings from vendors A & X? (I do know there is no free version of 
> Modelsim for the freely downloadable version. Are there ways around that 
> as I have a full Modelsim license)?
>
> 2. What's the typical equivalence of the logic cell to the other vendors? 
> It's sometimes hard to compare the amount of logic so one can compare 
> truly equivalent devices. If someone has implemented the same core and has 
> numbers on usage, that would truly be an eye opener (but I won't be too 
> disappointed if nobody has such a thing).
>
> 3. Are the tools reliable? (that's relative to the other vendors of 
> course).
>
> These are, of course, only the first questions before I even commit to 
> _looking_ at a device; I just don't want to overload the thread.
>
> Also note I am not looking for flames or icing; just honest opinions :)
>
> Cheers
>
> PeteS

I'm really glad you asked this. I recently (1st quarter this year) decided 
to give Lattice a try after being in the X camp since the very first 64 
logic cell device. I moved over because I could get no sense out of the X 
distributor in the UK (there was only one but there is now annother so 
things may improve) and I just could not work out which devices were 
actually available and how much they would cost.

I had none of these problems with Lattice so I have designed in an ECP15E 
device. I have had no problems with the device and only very minor problems 
with the tools.

(I use AldecHDL as my primary simulator.)

My application is not leading edge, is very low volume and not very price 
sensitive so you might well come to a different conclusion in other 
circumstances.

So far I'm (very) happy.

Michael Kellett

www.mkesc.co.uk

Hi Pete,

We are investigating a port from A to L. Here is what I've learned so
far

> 1. Are the free tools as decent (after the learning curve) as the
> offerings from vendors A & X? (I do know there is no free version of
> Modelsim for the freely downloadable version. Are there ways around that
>   as I have a full Modelsim license)?

Not as good as A, not as bad as X. There are some problems with their
graphical flow. The java applications often die and stay in background
eating cpu and ram :(

I never start simulation from ispLever, so I cant help you with your
other question.


> 2. What's the typical equivalence of the logic cell to the other
> vendors? It's sometimes hard to compare the amount of logic so one can
> compare truly equivalent devices. If someone has implemented the same
> core and has numbers on usage, that would truly be an eye opener (but I
> won't be too disappointed if nobody has such a thing).

I think ECP2 is pretty equal to Spartan3, but a little faster. Only a
subset of cells can be used as SRL16. They also support fewer IO
standards, on the other hand ECP2M has SERDES.

I did a simple benchmark with few designs and the ECP2 almost always
got higher fmax and lower area that XC3S and EP2C.


BTW, www.fpga.ch has a comparision between A3P, EP1C and ECP1.

> 3. Are the tools reliable? (that's relative to the other vendors of course).

They use Synplify (and Precision) for synthesis. Not as good as Quartus
or XST, but it does the job. Might need some tweaking however when
inferring memories.

burn.sir@gmail.com writes:

{about Lattice}
> They use Synplify (and Precision) for synthesis. Not as good as Quartus
> or XST, but it does the job. Might need some tweaking however when
> inferring memories.
> 

Can you provide more details?  My experience to date has been that
Synplify is better than XST, especially on runtime, and almost all the
time on size & speed.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

I agree with Martin: Synplify is better than XST in runtime and QOR,
and if you have synplify-pro, the HDL analyst (RTL or gate level
schematic viewing) is much better than what XST has.

I don't have any experience with Quartus synthesis.

Andy


Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
> > They use Synplify (and Precision) for synthesis. Not as good as Quartus
> > or XST, but it does the job. Might need some tweaking however when
> > inferring memories.
> >
>
> Can you provide more details?  My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.conekt.net/electronics.html

Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
> > They use Synplify (and Precision) for synthesis. Not as good as Quartus
> > or XST, but it does the job. Might need some tweaking however when
> > inferring memories.
> >
>
> Can you provide more details?  My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin


Short answer: synplify _is_ better than XST, but its ECP2 technology
mapper is still a little immature.

burns

Martin Thompson wrote:
> burn.sir@gmail.com writes:
> 
> {about Lattice}
>> They use Synplify (and Precision) for synthesis. Not as good as Quartus
>> or XST, but it does the job. Might need some tweaking however when
>> inferring memories.
>>
> 
> Can you provide more details?  My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
> 
> Cheers,
> Martin
> 

Thanks for the answers, chaps.

I can now be a little more confident of using the devices. I have the 
time to do a migration (well, a clean new design as it happens) if I 
start now, and most of that extra time should (hopefully) be merely tool 
related.

I'll talk to my friendly vendor about pricing etc., tomorrow.

That doesn't mean I won't use the other brands; in this particular case 
it may make more sense to use brand L.

Cheers

PeteS

PeteS wrote:
> Martin Thompson wrote:
> > burn.sir@gmail.com writes:
> >
> > {about Lattice}
> >> They use Synplify (and Precision) for synthesis. Not as good as Quartus
> >> or XST, but it does the job. Might need some tweaking however when
> >> inferring memories.
> >>
> >
> > Can you provide more details?  My experience to date has been that
> > Synplify is better than XST, especially on runtime, and almost all the
> > time on size & speed.
> >
> > Cheers,
> > Martin
> >
>
> Thanks for the answers, chaps.
>
> I can now be a little more confident of using the devices. I have the
> time to do a migration (well, a clean new design as it happens) if I
> start now, and most of that extra time should (hopefully) be merely tool
> related.
>
> I'll talk to my friendly vendor about pricing etc., tomorrow.
>
> That doesn't mean I won't use the other brands; in this particular case
> it may make more sense to use brand L.
>
> Cheers
>
> PeteS

I've been using Xilinx parts for some time, and started using the ECP
series from Lattice recently.  So far there have been some bumps in
the implementation software (crash during P&R, timing anomalies),
but the latest tools version appears to be more solid.  There are still
issues with "TRACE" (timing analysis) and related clocks.  For instance
when I have a 200 MHz clock at 0 phase and another at 270 degrees,
I would expect a signal traveling from the 0 phase domain to the
270 degree domain to have 3/4 clock period or 3.75 nS from
clock edge to clock edge (less uncertainties, etc.).  TRACE seems
to think the signal should be allowed 1 3/4 periods or 8.75nS.
Additionally if I place a "MULTICYCLE" constraint from the 0
phase clock to the 270 degrees phase clock, it is ignored and
the 8.75nS constraint is still used.  In my case the 270 degree
clock is for output registers only, so I don't need a real
PERIOD constraint on it.  Thus I managed to trick the TRACE
tool into giving me the 3.75nS clock to clock path by setting
the PERIOD to 2.143nS on the 270 degree clock.  Strangely
the tools seem happy with this even though it should know that
the two clocks should be at the same frequency.

Also I've noticed the documentation is still a bit weak, but getting
better.  It's currently a mix of HTML and .pdf files.  Information on
library components is spread among a number of technical notes,
although a complete listing (without full details) is available for
each part series.

If you've worked with Xilinx you'll recognize the tool flow because
both tools were developed at NeoCAD.  Lattice's GUI has a lot
of similarity to ISE, with a process flow window.  It took me a
while to find out that not all settings in the flow can be reached
by right clicking an object and selecting properties.  TRACE
parameters are only available through the menu bar.

For programming, ispVM seems simpler to use than iMPACT.  Once
you get the hang of it you'll like the features like being able to have
more than one setup open at a time.

I can't really comment on Symplify vs. XST, because I'm only
working on new designs with Lattice, so I didn't really compare
apples to apples.  My gut feeling is that it's at least as good
as the recent release of XST, which is already much improved
over the version 6 XST.

If you don't already have a non-branded ModelSim seat, the
base tools (not free web version, but still inexpensive) come
with a Lattice-branded ModelSim license that doesn't have
the annoying slow-down you get with the X-brand license.
I'm assuming it nails you by stopping to work at some
design size, but I haven't run into that yet.

Finally I think you'll find that Lattice is very aggressive with
pricing.  Like I said we've been using Xilinx for some time
now, and we don't pay the web price for their parts.  Still
for the same functionality it seems Lattice can offer significant
savings over Xilinx.

Gabor wrote:
> PeteS wrote:
>> Martin Thompson wrote:
>>> burn.sir@gmail.com writes:
>>>
>>> {about Lattice}
>>>> They use Synplify (and Precision) for synthesis. Not as good as Quartus
>>>> or XST, but it does the job. Might need some tweaking however when
>>>> inferring memories.
>>>>
>>> Can you provide more details?  My experience to date has been that
>>> Synplify is better than XST, especially on runtime, and almost all the
>>> time on size & speed.
>>>
>>> Cheers,
>>> Martin
>>>
>> Thanks for the answers, chaps.
>>
>> I can now be a little more confident of using the devices. I have the
>> time to do a migration (well, a clean new design as it happens) if I
>> start now, and most of that extra time should (hopefully) be merely tool
>> related.
>>
>> I'll talk to my friendly vendor about pricing etc., tomorrow.
>>
>> That doesn't mean I won't use the other brands; in this particular case
>> it may make more sense to use brand L.
>>
>> Cheers
>>
>> PeteS
> 
> I've been using Xilinx parts for some time, and started using the ECP
> series from Lattice recently.  So far there have been some bumps in
> the implementation software (crash during P&R, timing anomalies),
> but the latest tools version appears to be more solid.  There are still
> issues with "TRACE" (timing analysis) and related clocks.  For instance
> when I have a 200 MHz clock at 0 phase and another at 270 degrees,
> I would expect a signal traveling from the 0 phase domain to the
> 270 degree domain to have 3/4 clock period or 3.75 nS from
> clock edge to clock edge (less uncertainties, etc.).  TRACE seems
> to think the signal should be allowed 1 3/4 periods or 8.75nS.
> Additionally if I place a "MULTICYCLE" constraint from the 0
> phase clock to the 270 degrees phase clock, it is ignored and
> the 8.75nS constraint is still used.  In my case the 270 degree
> clock is for output registers only, so I don't need a real
> PERIOD constraint on it.  Thus I managed to trick the TRACE
> tool into giving me the 3.75nS clock to clock path by setting
> the PERIOD to 2.143nS on the 270 degree clock.  Strangely
> the tools seem happy with this even though it should know that
> the two clocks should be at the same frequency.
> 
> Also I've noticed the documentation is still a bit weak, but getting
> better.  It's currently a mix of HTML and .pdf files.  Information on
> library components is spread among a number of technical notes,
> although a complete listing (without full details) is available for
> each part series.
> 
> If you've worked with Xilinx you'll recognize the tool flow because
> both tools were developed at NeoCAD.  Lattice's GUI has a lot
> of similarity to ISE, with a process flow window.  It took me a
> while to find out that not all settings in the flow can be reached
> by right clicking an object and selecting properties.  TRACE
> parameters are only available through the menu bar.
> 
> For programming, ispVM seems simpler to use than iMPACT.  Once
> you get the hang of it you'll like the features like being able to have
> more than one setup open at a time.
> 
> I can't really comment on Symplify vs. XST, because I'm only
> working on new designs with Lattice, so I didn't really compare
> apples to apples.  My gut feeling is that it's at least as good
> as the recent release of XST, which is already much improved
> over the version 6 XST.
> 
> If you don't already have a non-branded ModelSim seat, the
> base tools (not free web version, but still inexpensive) come
> with a Lattice-branded ModelSim license that doesn't have
> the annoying slow-down you get with the X-brand license.
> I'm assuming it nails you by stopping to work at some
> design size, but I haven't run into that yet.
> 
> Finally I think you'll find that Lattice is very aggressive with
> pricing.  Like I said we've been using Xilinx for some time
> now, and we don't pay the web price for their parts.  Still
> for the same functionality it seems Lattice can offer significant
> savings over Xilinx.
> 

Hi Gabor

That's _very_ useful feedback.

Thanks a lot!

Cheers

PeteS

PeteS wrote:

>
> Hi Gabor
>
> That's _very_ useful feedback.
>
> Thanks a lot!
>
> Cheers
>
> PeteS

Here's another tidbit that cost me a couple hours today.
Beware of the Global set/reset (under the hood) assignment.
In ispLEVER, the tools will pick the most commonly used
async reset in your design and use the global set/reset
routing unless you specify otherwise.  Then if you have
something that isn't specifically reset some other way,
it will be reset with this signal.

This includes any instantiated flip-flops, like the ones
you might use to create an internal synchonous-release
reset inside the part (ala the Xilinx 4 FDP method).  In
this case you can have a loop that holds the part in reset
forever.  To prevent it you need to either tell the tools not
to use the GSR routing resource, or specify for each
module that shouldn't use it GSR = "DISABLED".  In
Verilog something like:

// This flip-flop forms the internal reset, so it
// can't be asynchoronously reset by the GSR
// signal!
FD1P3AX intrn_rst_ff
(
  .D  (1'b1),
  .SP (1'b1),
  .CK (CPLD_REF_120),
  .Q  (internal_resn)
) /*synthesis GSR="DISABLED"*/;

Oh, yeah.  Did I mention the wonderful library element
names for flip-flop primitives?

Good Luck,
Gabor