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)
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)?
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).
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 :)
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.
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.
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.
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?