FPGARelated.com
Forums

Schematic Entry, Xilinx or Altera?

Started by Parkov January 4, 2006
Hi Jim.

As far as I can forsee, all that I would need are either Altera
EPM3032A/3064A's or Xilinx's XC9536/XC9576 both in 44pin packages.

If I went into a Boolean Equation Language, is ABEL or AHDL easier to
learn/use?  I can't seem to find any head to head comparisons.  Is
Xilinx going to continue support for ABEL for their CPLD's and is
Altera going to continue support for AHDL for theirs?  I know that
these are not practical languages for complex FPGA design, but that
doesn't need to be the issue.  Tks.

Parkov wrote:

> Hi Jim. > > As far as I can forsee, all that I would need are either Altera > EPM3032A/3064A's or Xilinx's XC9536/XC9576 both in 44pin packages.
Atmel's ATF1502 / 1504 would also be in that category. ( as would Lattice MACH4000 series ) Why not also the Coolrunner ?
> > If I went into a Boolean Equation Language, is ABEL or AHDL easier to > learn/use? I can't seem to find any head to head comparisons. Is > Xilinx going to continue support for ABEL for their CPLD's and is > Altera going to continue support for AHDL for theirs?
Good questions, someone in Xilinx / Altera / Lattice could answer that ? I do know from a 'tough' Xilinx.ABEL user, that Xilinx improved their ABEL flows, for CPLDs in recent releases - In their ABEL flow they now use (IIRC) VHDL as the 'back end' and ABEL as the front end. This allows them to hook-into timing simulation tools, but does loose ABEL's test vector generation ? (useful only on smaller packages) One they have that, of course, then 'continued support' is inherent, as the ABEL is only a front end. That can't have been trivial to do, so I was impressed - but it does indicate how much CPLD code is out there, in ABEL/Boolean EQN. In a similar vein, of using HDL's as 'back ends languages', see Jan Decaluwe's posting today of MyHDL : Python -> Verilog. -jg
Jim Granville wrote:
>> If I went into a Boolean Equation Language, is ABEL or AHDL easier to >> learn/use? I can't seem to find any head to head comparisons. Is >> Xilinx going to continue support for ABEL for their CPLD's and is >> Altera going to continue support for AHDL for theirs? > > > Good questions, someone in Xilinx / Altera / Lattice could answer that ?
Further to this, I went to the Lattice web site http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm It says "ispLEVER-Starter Primary Module (212 MB) This module is required to run the ispLEVER Starter software, and should be installed first. It includes the ispLEVER Project Navigator, and all the tools and device libraries you need to implement a design in Lattice's newest and most popular CPLD products. Note: This module supports ABEL, EDIF and Schematic design projects only. For Verilog or VHDL design project support, you must download one of the Synthesis modules listed below." ... Device Support FPGA: LatticeECP: ECP6 LatticeEC: All LatticeXP: XP3, XP6 CPLD: MachXO: All ispMACH 4000 ispXPLD 5000MX So, since MachXO is clearly in the "newest and most popular CPLD products" category, this web page is saying ABEL support for MachXO is there. Call me cynical, but I'd believe that more if a Lattice FAE was able to verify that ? -jg
Mike Treseler wrote:
> Austin Lesea wrote: > >> I would invest my time in learning a HDL: VHDL or Verilog. > > > Good advice, but allow several months. >
And frequent use. It isn't worth learning either one for a one-time deal. If he only does a CPLD once in a blue moon and doesn't use the HDL for anything else, he'll forget more than he remembers and will have to learn it all over again next time.
>But schematic entry oftem leads to non-registered designs, where you should >allow several month of debugging too...
I can't quite figure out what that means. It sounds like forgetting to put in FFs to hold the data. But why does that happen more often with schematics than when using a HDL? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
In the current release (ispLEVER v5.1) the MachXO device family does
require a Verilog HDL or VHDL synthesis front-end like Precision RTL or
Synplify. You can use the schematic editor, however, there's currently
no library for gate-level design so it's best used as a block-diagram
editor. In the design flow the schematic editor produces a structural
model that's read by logic synthesis. I use it today with the latest
FPGA families (including XO):to organize RTL modules or those modules
generated from IPexpress the module/IP core manager.

Meanwhile another option for someone who's trying to migrate a
74xx-class design is a 3rd party EDA schematic front-end like Aldec,
Altium (Protel), or Orcad which can also generate EDIF 2 0 0 or
structural HDL you can import into FPGA tools. Altium in particular is
focused on making this "board-level" design style easy.

Troy Scott
Lattice Semiconductor TME

Definitely Altera.

"Thomas Entner" <aon.912710880@aon.at> wrote in message 
news:43bc292b$0$16891$91cee783@newsreader01.highway.telekom.at...
>> I'm looking at doing some basic CPLD designs via Schematic Entry. Who >> has easier to learn/use schematic entry software, Xilinx or Altera? > > Altera > > Regards, > > Thomas >
troy.scott@latticesemi.com wrote:

> In the current release (ispLEVER v5.1) the MachXO device family does > require a Verilog HDL or VHDL synthesis front-end like Precision RTL or > Synplify. You can use the schematic editor, however, there's currently > no library for gate-level design so it's best used as a block-diagram > editor. In the design flow the schematic editor produces a structural > model that's read by logic synthesis. I use it today with the latest > FPGA families (including XO):to organize RTL modules or those modules > generated from IPexpress the module/IP core manager. > > Meanwhile another option for someone who's trying to migrate a > 74xx-class design is a 3rd party EDA schematic front-end like Aldec, > Altium (Protel), or Orcad which can also generate EDIF 2 0 0 or > structural HDL you can import into FPGA tools. Altium in particular is > focused on making this "board-level" design style easy. > > Troy Scott > Lattice Semiconductor TME
Thanks Troy - you might get them to change the WEB page, so someone who takes what it says, at face value, is not misled. i.e. make it clear that whilst MachXO is called a CPLD for sales, from a TOOL chain viewpoint, it is a FPGA : Presently, ABEL flow _excludes_ MachXO, but includes all "product term" CPLDs Do you know if Lattice plan to support ABEL flows for MachXO, to better tap into the CPLD user base ? -jg
On Wed, 4 Jan 2006 22:08:26 +0000 (UTC), Uwe Bonnes
<bon@hertz.ikp.physik.tu-darmstadt.de> wrote:

>Mike Treseler <mike_treseler@comcast.net> wrote: >> Austin Lesea wrote: > >> > I would invest my time in learning a HDL: VHDL or Verilog. > >> Good advice, but allow several months. > >But schematic entry oftem leads to non-registered designs, where you should >allow several month of debugging too...
Why? Logic is logic. We do lots of complex designs, state machines and all, in schematic form, and they come up in days or hours. John
John  Larkin <jjlarkin@highnotlandthistechnologypart.com> wrote:
> On Wed, 4 Jan 2006 22:08:26 +0000 (UTC), Uwe Bonnes > <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
> >Mike Treseler <mike_treseler@comcast.net> wrote: > >> Austin Lesea wrote: > > > >> > I would invest my time in learning a HDL: VHDL or Verilog. > > > >> Good advice, but allow several months. > > > >But schematic entry oftem leads to non-registered designs, where you should > >allow several month of debugging too...
> Why? Logic is logic. We do lots of complex designs, state machines and > all, in schematic form, and they come up in days or hours.
If you do registered designs and don't relay on some function having some definite delay, things will be fine. However many TTL designs are created different... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------