So who has used Lattice FPGAs recently?

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

Hi Pete,

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

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.

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,

has a comparision between A3P, EP1C and ECP1.

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.

{about Lattice}

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

Mart>

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

burns

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

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

I am using these comments (properly unattributed of course) to garner a complete set of free tools and competitive pricing ;)

Seriously, I appreciate the comments; it is only by knowing what you guys have gone through that I can make a logical decision here.

Cheers

PeteS