Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 13700

Article: 13700
Subject: Re: Xilinx Foundation vs. Altera Max Plus II
From: bob elkind <eteam@aracnet.com>
Date: Fri, 18 Dec 1998 12:30:27 -0800
Links: << >>  << T >>  << A >>
Ray's post was excellent.  Let me add my 2 cents...

1.   I've used Xilinx 4K,  Lucent Orca2C, and Altera 6K/10K extensively.
      To a **First approximation**, the Xilinx and Orca technologies are
     very similar.  The Altera devices are very different.

2.   Xilinx and Orca devices are large sandboxes.  Reconfiguring output
      pins (or locking them down) is pretty easy to do, within limits, and
      that eases the worries about post-board-layout design additions.

3.   Altera FPGAs are constructed as an array of smaller sandboxes.
      If your design doesn't partition well amongst the subsections, you
      run the risk of
        a) not enough interconnect to route the design or
        b) a quantum decrease in operating frequency, due to interconnect delays.

I agree with Ray's assessment, datapath intensive design (esp DSPs) will
tend to be happier with Xilinx and Orca devices.  Random logic and smaller
datapaths will be happy in any of the devices.  The inefficiencies in any of
these products can, in general (but not always), be overcome with bigger
or faster grade parts.

4.  It's the tools, stupid!  You can become proficient in Max+II (Altera)
     **very** quickly.  That is a very compelling attribute!  If you are
    designing a part that someone else will have to maintain (i.e. a client),
   this is a very powerful weapon in the consultant's arsenal.  Also, if
   you don't use the tool often enough to become proficient and stay
   proficient, consider a less demanding toolset, like Max+2.

5.  Compile time.  You *can* configure a Xilinx or Orca design to
   eventually compile quickly, but this takes time, and major design
   changes generally mean several hours of compile time. (do 28
   compiles and keep the best 4 :=) ).   On the other hand, Max+2
   compiles (generally) in 5-10 minutes.  Instant gratification,
   fewer coffee breaks (and bathroom runs).

Summary:  For video processing, I stay with Orca or Xilinx.
  For interface logic design, and designs where I know the customer
  will want to maintain it,  I tend to use Altera, where I know I can
  get useable results more quickly.

****************************************************************
Bob Elkind                              mailto:eteam@aracnet.com
7118 SW Lee Road               part-time fax number:503.357.9001
Gaston, OR 97119           cell:503.709.1985   home:503.359.4903
****** Video processing, R&D, ASIC, FPGA design consulting *****


Article: 13701
Subject: Async Fifo Core or Macro for Xilinx FPGA
From: Richard Schwarz <aps@associatedpro.com>
Date: Fri, 18 Dec 1998 16:04:39 -0500
Links: << >>  << T >>  << A >>
I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to implemnt

into a XILINX 4000 series FPGA. I am using
VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade.

Is there anyone out there who can point me in the right direction for
this?

Thanks

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 13702
Subject: Problems with timing report using Synopsys FPGA compiler!!!
From: Mohsin Riaz <mohsin@engr.mun.ca>
Date: Fri, 18 Dec 1998 17:59:59 -0330
Links: << >>  << T >>  << A >>
Hi everybody!

I have implemented an encryption algorithm in hardware using FPGAs.I am 
faced with a problem. After optimizing my design using the Synopsys FPGA 
compiler, you are suppose to get the report_fpga and report_timing  
reports by typing in those commands in the command window. I am getting 
the right report for the number of CLBs used, but for the timing report, 
it only gives me the delay associated with the sequential part of my 
design. The design actually is made up of both sequential as well as the 
combinational logic. Moreover, the design is a hierarchical one.

I would really appreciate, if someone could help me in this respect!!!!

Thanx,

Mohsin Riaz
Computers & Communications Security Lab,
Faculty Of Engineering,
Memorial University Of Newfoundland,
Canada.

Article: 13703
Subject: Re: GSR
From: jerry english <jenglish@planetc.com>
Date: Fri, 18 Dec 1998 17:57:48 -0500
Links: << >>  << T >>  << A >>
Bob Sefton wrote:

> Is RESET a pad or an internal net? In Xilinx it has to be an
> internal net that has come in through a normal input buffer.
>
> You also have to use RESET to asynchronously clear or set ALL
> registers in the design or else GSR can't be used and won't be
> hooked up at all. Again in Xilinx, it's got to be all registers or
> none. I assume Orca is the same.
>
> Bob S.
>
> jerry english wrote:
> >
> > My tool set: FPGA Express 3.0, verilog, Orca Foundry 9.3.1. Target
> > device 3T80.
> >
> > I do the component instantiation
> >
> > GSR gsr0 (.GSR(RESET));
> >
> > Problem....GSR is not mapped. FPGA Express message indicates  it is in
> >
> > the edif netlist and an inspection of the netlist shows the GSR
> > component. When
> > the Orca mapper runs the resource report shows 0 of 1 GSR used. What
> > gives? I run the tutorial (they are always so simple) it uses the GSR
> > just fine.
> >
> > Anybody else have this kind of problem and if so what was the solution?
> >
> > Thanks
> > Jerry English

  Yes, RESET is an internal net. I use IRESET to an input buffer whose
output is RESET. I didn't think one had to explicitly use GSR in the
processes
or always block for the function to be implemented, that the  component
instantiation
of GSR was sufficient.

regards
Jerry

Article: 13704
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 18 Dec 1998 18:03:17 -0800
Links: << >>  << T >>  << A >>
Richard Schwarz wrote:

> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to
> implemnt
>
> into a XILINX 4000 series FPGA. I am using
> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade.
>  

The design approach will be heavily influendced by the required speed.
If both clocks are fully asynchronous and run at 80 MHz, it may be
beyond the reach of VHDL,
but the silicon can still do it.
At low clock rates, the design can be quite simple.

Peter Alfke, Xilinx Applications

Article: 13705
Subject: WTB: MPA1064DH FPGAs
From: Michal Jurewicz <michal@mytekdigital.com>
Date: 19 Dec 1998 03:34:54 GMT
Links: << >>  << T >>  << A >>
We are looking to buy some of these Motorola FPGA's (160PQFP) . If you
have surplus stock please contact Michal @ 212-2749191

Article: 13706
Subject: Re: GSR
From: Bob Sefton <rsefton@home.com>
Date: Sat, 19 Dec 1998 03:41:32 GMT
Links: << >>  << T >>  << A >>
> 
>   Yes, RESET is an internal net. I use IRESET to an input buffer whose
> output is RESET. I didn't think one had to explicitly use GSR in the
> processes
> or always block for the function to be implemented, that the  component
> instantiation
> of GSR was sufficient.
> 

You're right, with instantiation all you should have to do is hook
it up.

Article: 13707
Subject: Re: MP3 and FPGA's
From: jamie morken <foster@uvic.ca>
Date: Fri, 18 Dec 1998 21:37:29 -0800
Links: << >>  << T >>  << A >>
Steve,

I was thinking the same thing, I don't see why it wouldn't be
practical..

Jamie Morken

Steve wrote:

> Would it be practical to implement an MP3 decoder in an FPGA?
>
> Steve

Article: 13708
Subject: Re: Two questions
From: nhartl@aol.com (NHartl)
Date: 19 Dec 1998 13:27:39 GMT
Links: << >>  << T >>  << A >>
>
>I have two questions:
>
>1. I own Foundation 1.4, is there a way to upgrade it to 1.5 online?
Nope. Or at least not that I know of.
>2. Anyone had any experience using Aldec's Active-VHDL as a design-entry
>tool and call (from within the software) to Metamor/M1 to
>synthesize/implement his design?
Yup.  There are some example designs shipped with Active-V that document this
process.  It does work.

Have FUN!!!
Nick
P.S. I am back and I work for Avnet now.
>
>Thanks
>
>


Article: 13709
Subject: Re: Why doesn't Xilinx's simulator work?
From: nhartl@aol.com (NHartl)
Date: 19 Dec 1998 13:48:26 GMT
Links: << >>  << T >>  << A >>
>  "Joel Kolstad" <JKolstad@Electroglas.Com> wrote:
>> Well, it's probably me... but damn it... I'm running Foundation 1.5 here,
>> and getting the schematic capture portion of the package to talk to the
>> simulator is nearly impossible.  I'll tell it to simulate a macro, it'll
>> open up the simulator, and then I'll start adding probe points.  The
>> simulator COMPLETELY IGNORES the probe points I'm clicking on, when it
>> should be adding them to its own list.  I'll click over on the simulator
>and
>> add some signals, and schematic captures completely ignores what's been
>> added!  Better still, sometimes schematic capture won't even let me add any
>> probe points at all, just completely ignoring mouse clicks!
>>
>> You go ahead and step time in the simulator, and the signals listed do
>> reasonable things, but schematic just sits there with its probe points
>> displaying nothing at all.
>>
>> !@$!@#%^^#$
>>
>> OK, this doesn't happen 100% of the time.  On VERY RARE occasion it
>actually
>> works the way it should.  I can't believe this happens to all you other
>> people on a daily basis, or there'd be an angry mob outside of Xilinx HQ
>> threatening to burn the place down.  So what am I doing wrong?  The concept
>> seems really simple -- add a probe in schematic, and the simulator picks it
>> up, add a signal in simulator, and schematic should pick it up... right?
>>
>> ---Joel Kolstad
>>
Wow.  Never seen it.  Use Foundation all the time.  Cross probe alot, works
fine.  Of course it
only works in functional mode.  Are you doing timing?  If so see below.  One
other shot in the dark
question.  Is your schematic part of the project?  If not this could cause
problems.>
>Oh God! I am sitting here on a dreary Sunday afternoon, desparately looking
>for information describing a fix for EXACTLY THIS PROBLEM! However, I believe
>that I can add a little twist to the puzzle.  In my case, however, the
>simulator works in the functional mode and does NOT WORK in the timing mode. 
>What is more remarkable is the fact that the simulator does not even see the
>instance(s) that I am trying to probe in the timing mode.  What is MOST
>remarkable is the fact that no schematic implementation, no vhdl macro
>implementation, no nothing is either visible or simulatable (in the timing
>mode) for this section of the design! Joel? did you ever get an answer?
>
Slight problem.  Have you looked at the signals availible in the simulator
after a place and route?
If you do you will find that many of the signals in your schematic are no
longer present.  Why?  
Because during the mapping phase of place and route your logic is re-aranged to
fit inside of the
real world CLBs.  During this process many signals disappear due to
optimization.  I know in a perfect
world it would be possible to probe all signals that are part of your schematic
in the timing simulation.
But it is very hard to find a signal in a back annotated file that is no longer
there.

I only use the cross probing feature for functional simulation.  For timing
(when I do timing, there are many threads about the merits of timing
simulation.  I don't want to re-start them) I work only in the simulator
and do not even bother with the cross probe feature.


Article: 13710
Subject: Re: xilink Parallel cable III
From: nhartl@aol.com (NHartl)
Date: 19 Dec 1998 13:56:16 GMT
Links: << >>  << T >>  << A >>
>
>Somone know where i can find this cable.
>
>

In a Foundation Box

Article: 13711
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: Edward Moore <edmoore@edmoore.demon.co.uk>
Date: Sat, 19 Dec 1998 15:41:07 +0000
Links: << >>  << T >>  << A >>
In article <367B07C6.FC35BCA4@xilinx.com>, Peter Alfke
<peter@xilinx.com> writes
>Richard Schwarz wrote:
>
>> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to
>> implemnt
>>
>> into a XILINX 4000 series FPGA. I am using
>> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade.
>>  
>
>The design approach will be heavily influendced by the required speed.
>If both clocks are fully asynchronous and run at 80 MHz, it may be
>beyond the reach of VHDL,
>but the silicon can still do it.
>At low clock rates, the design can be quite simple.
>
>Peter Alfke, Xilinx Applications
>

Why is this beyond the reach of VHDL ?

And if it is, isn't a pity that Xilinx are going to abandon schematic entry ?

Or do you mean the fifo should be designed in EPIC ?

Please explain.
-- 
Edward Moore
Snell & Willcox Ltd

Article: 13712
Subject: Implementing an internal tri-state bus
From: "Ido Kleinman" <kleinn@REMOVETHIS.mail.biu.ac.il>
Date: Sat, 19 Dec 1998 18:23:16 +0200
Links: << >>  << T >>  << A >>
Hello,

I am using a Xilinx Spartan XCS30 device and trying to implement an internal
Tri-state bus (which the device supports, but ofcouse!) using VHDL.

I tried to implement two bidirectional registers which share the same
Data-Bus (without a multiplexer, just an internal TBUF) and seem to have
problems with that, it seems the data won't flow into the device and out
when I am using components which include inout ports, even when I
instanciated TBUFs inside them and applied inhibit_buf attributes on the
data-bus top-level. Ofcouse there are also IBUFs+BUFTs on the incoming
data-bus and OBUFTs on the way out...

Has anyone been more successful than I am at implementing internal 3-state
bus in a xilinx device using VHDL? I would be very happy to see some
fragments of code as this will help the most.

I would be most thankful if you could EMail me as I do not read these
newsgroup on a regular basis.
Thank you very much in advance.

--

Yours,

  -- Ido Kleinman.
  kleinn@REMOVETHIS.mail.biu.ac.il
 ** Please delete the "REMOVETHIS." substring to EMail me.






Article: 13713
Subject: Re: Atmel's PLD
From: Ray Andraka <randraka@ids.net>
Date: Sat, 19 Dec 1998 12:51:40 -0500
Links: << >>  << T >>  << A >>
What kind of trouble?  Which device?   I've never had any trouble with
any of Atmel's programmable logic; PALs or FPGAs.

sam wrote:

> Does anyone have trouble when use Atmel's PLD ?
> I will never use Atmel's PLD . It's too bad .



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13714
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: Ray Andraka <randraka@ids.net>
Date: Sat, 19 Dec 1998 12:57:19 -0500
Links: << >>  << T >>  << A >>


Edward Moore wrote:

> In article <367B07C6.FC35BCA4@xilinx.com>, Peter Alfke
> <peter@xilinx.com> writes
> >Richard Schwarz wrote:
> >
> >> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to
> >> implemnt
> >>
> >> into a XILINX 4000 series FPGA. I am using
> >> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade.
> >>
> >
> >The design approach will be heavily influendced by the required speed.
> >If both clocks are fully asynchronous and run at 80 MHz, it may be
> >beyond the reach of VHDL,
> >but the silicon can still do it.
> >At low clock rates, the design can be quite simple.
> >
> >Peter Alfke, Xilinx Applications
> >

It is very difficult to get this kind of performance in a synthesized design
(especially with the async clocks).  In cases like this it is much faster and
easier to just to do it in schematic the way you know it needs to be implemented
and be done with it.

>
>
> Why is this beyond the reach of VHDL ?
>
> And if it is, isn't a pity that Xilinx are going to abandon schematic entry ?
>

Touche!
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13715
Subject: Re: Fast *Industrial* 22V10?
From: jim granville <Jim.Granville@DesignTools.co.nz>
Date: Sun, 20 Dec 1998 10:27:29 +1300
Links: << >>  << T >>  << A >>
Rickman wrote:
> 
> Tim Forcer wrote:
> > Broadening the issue a bit, most of my design work is on relatively
> > small-scale designs.  In these applications I find it extremely
> > frustrating that, except for Phillips XPLA, there's been nothing really
> > new in not-many-pins devices for a very long time.  What I'd love to see
> > is a 16 pin IC, with at least two pins carrying clocking signals, and
> > ALL pins having versatile I/O macrocells.  Sort of 14V14.  Or maybe
> > 28V14 if every macrocell included a buried register.  A 20-pin version
> > would be 18V18/36V18.  But all developments these days are in Mega this
> > that and the other.  Certainly useful in a very wide range of
> > applications, but is the small-footprint IC really a dead market for new
> > programmable logic devices?
> >
> > --
> > Tim Forcer               tmf@ecs.soton.ac.uk
> 
> Tim, I remembered using a 22V10 type device with buried registers. I
> found it at http://www.atmel.com The ATV750B has a 22V10 structure along
> with an additional 10 buried registers. Comes in a 7.5 nS comm, 10 nS
> indust speed grade and 24 pin SOIC packages. I haven't used it in years
> (like maybe 10?) but they still seem to make it. It is not ISP, but
> rather UV eraseable.

 The FLASH ATF750 is due for sampling Q199.
This is the highest density 'small package' device, with multiple
clocks, 
separate OE, Toggle FlipFlops, and 10 buried registers ( call it a 22V20
if you like ).

 Tim is correct, I believe there is a need for smaller pincount devices,
the 150 mil SO16/DIP16 would seem a logical part, and resource to
replace 
a large chunk of all TTL grade MSI.
 Also the 20 / 24 pin device with 22i/o lines is a candidate. With care,
a single
die could do all jobs, and I am sure the company offering this family,
would get
a lot of column inches. By providing libraries for all the TTL devices
it can replace,
design ramp-up would be rapid. 


 SPLD have got price competitive with many application-specific parts,
and even FAST
TTL - they just need better resource mapping to sweep the field.

 - Jim Granville.

Article: 13716
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: Edward Moore <edmoore@edmoore.demon.co.uk>
Date: Sun, 20 Dec 1998 00:21:01 +0000
Links: << >>  << T >>  << A >>
responses re-arranged for clarity:

>> >Richard Schwarz wrote:
>> >
>> >> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to
>> >> implemnt
>> >>
>> >> into a XILINX 4000 series FPGA. I am using
>> >> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade.

and peter@xilinx.com replied:

>> >>
>> >
>> >The design approach will be heavily influendced by the required
speed.
>> >If both clocks are fully asynchronous and run at 80 MHz, it may be
>> >beyond the reach of VHDL,
>> >but the silicon can still do it.
>> >At low clock rates, the design can be quite simple.
>> >
>> >Peter Alfke, Xilinx Applications
>> >

to which i stepped in and mischievously asked:

>> Why is this beyond the reach of VHDL ?
>>
>> And if it is, isn't a pity that Xilinx are going to abandon schematic entry ?

then Ray Andraka <randraka@ids.net> wrote:

>It is very difficult to get this kind of performance in a synthesized design
>(especially with the async clocks).  In cases like this it is much faster and
>easier to just to do it in schematic the way you know it needs to be implemented
>and be done with it.

IMO one of the reasons why the schematic entry vs. HDL debate keeps
cropping up is statements like the above, which are originated by people
who either:

a) might have a vested interest in persuading people that they won't be
able to use a HDL for their designs

b) havn't tried using a HDL

c) have tried a HDL, but didn't do it properly

d) work for FPGA manufacurers and should perhaps know better.

At it's heart, the 'cant do it in a HDL' arguement seems to stem from a
confusion between inferred and instantiated HDL. No one is claiming that
a synthesiser can infer a a complete async fifo. But using instantited
components is a direct textual equivalant to schematic entry, so there
is no design element that can be placed on a schematic that can't be
included in a HDL design. Period. (as you Americans say).

I believe that the mixed inferred/instantiated method is used by most
experienced HDL designers. A designer might predominately infer logic,
but a some point will say to themselves 'it will be easier to just
instantiate this element and have done with it'.

My suggestion is that the bi-partisan postings should cease, and that
the gurus who reqularly offer excellent advice to people like Richard
Schwarz should stick to describing the elements of a design and how they
should be linked together, and take it for granted that some people will
draw their designs, and some will type them in. For example, offer
advice like, 

..... you're gonna need a dual port ram element, may be RLOC some things
together if you want it to go fast... etc, etc

-- 
Edward Moore
Snell & Willcox Ltd

PS. any connection between some parts of this reply and current political events
in a well-known super power is purely non-coincidental.

Article: 13717
Subject: Re: Atmel's PLD
From: rolavine@aol.com (Rolavine)
Date: 20 Dec 1998 01:49:55 GMT
Links: << >>  << T >>  << A >>
>Subject: Atmel's PLD
>From: "sam" <cong_sp@willnet.co.jp>
>Date: 12/13/98 8:31 PM Pacific Standard Time
>Message-id: <75fqvd$2pq$1@hustler.asahi-net.or.jp>
>
>Does anyone have trouble when use Atmel's PLD ?
>I will never use Atmel's PLD . It's too bad .
>
I've done dozens of designs with the ATV750 and ATV2500 parts. These parts work
very predictably. They have uniform structures, and consistent logic delays.
They do asychronous logic just fine, so you don't have to global clock
everything, and the logic array seems near glitch free. They can even do neat
things like registered feedback with combinatorial output. They are not noisy
as a lot of plds I've used, and have reasonable levels of ground bounce. 


Article: 13718
Subject: Re: Atmel's PLD
From: jonathan@canuck.com (Victor the Cleaner)
Date: 20 Dec 1998 06:10:32 GMT
Links: << >>  << T >>  << A >>
Rolavine (rolavine@aol.com) wrote:
: >Subject: Atmel's PLD
: >From: "sam" <cong_sp@willnet.co.jp>
: >Date: 12/13/98 8:31 PM Pacific Standard Time
: >Message-id: <75fqvd$2pq$1@hustler.asahi-net.or.jp>
: >
: >Does anyone have trouble when use Atmel's PLD ?
: >I will never use Atmel's PLD . It's too bad .

: I've done dozens of designs with the ATV750 and ATV2500 parts. These parts work
: very predictably. They have uniform structures, and consistent logic delays.
: They do asychronous logic just fine, so you don't have to global clock
: everything, and the logic array seems near glitch free. They can even do neat
: things like registered feedback with combinatorial output. They are not noisy
: as a lot of plds I've used, and have reasonable levels of ground bounce. 

I feel the same way.  I've been working with the 2500 for the last while,
and it's a great part.  The only limitation I've bumped into was the
single-product-term clock for each macrocell register, but that's not much
to complain about.

What don't you like?

Jonathan

--
    jonathan@canuck.com
 Canada Connect Corporation    | Jonathan |    Survival Research Laboratories
        Calgary, AB            |  Levine  |          San Francisco, CA
   403-705-2025, fax 2026                           vox/fax 415-641-8065

Article: 13719
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: Ray Andraka <randraka@ids.net>
Date: Sun, 20 Dec 1998 12:19:10 -0500
Links: << >>  << T >>  << A >>
> >It is very difficult to get this kind of performance in a synthesized design
> >(especially with the async clocks).  In cases like this it is much faster and
> >easier to just to do it in schematic the way you know it needs to be implemented
> >and be done with it.
>
> IMO one of the reasons why the schematic entry vs. HDL debate keeps
> cropping up is statements like the above, which are originated by people
> who either:
>
> a) might have a vested interest in persuading people that they won't be
> able to use a HDL for their designs
>
> b) havn't tried using a HDL
>
> c) have tried a HDL, but didn't do it properly
>
> d) work for FPGA manufacurers and should perhaps know better.
>
> At it's heart, the 'cant do it in a HDL' arguement seems to stem from a
> confusion between inferred and instantiated HDL. No one is claiming that
> a synthesiser can infer a a complete async fifo. But using instantited
> components is a direct textual equivalant to schematic entry, so there
> is no design element that can be placed on a schematic that can't be
> included in a HDL design. Period. (as you Americans say).
>
> I believe that the mixed inferred/instantiated method is used by most
> experienced HDL designers. A designer might predominately infer logic,
> but a some point will say to themselves 'it will be easier to just
> instantiate this element and have done with it'.
>
> My suggestion is that the bi-partisan postings should cease, and that
> the gurus who reqularly offer excellent advice to people like Richard
> Schwarz should stick to describing the elements of a design and how they
> should be linked together, and take it for granted that some people will
> draw their designs, and some will type them in. For example, offer
> advice like,
>
> ..... you're gonna need a dual port ram element, may be RLOC some things
> together if you want it to go fast... etc, etc
>

I didn't say it couldn't be done.  My point is that for something like this, it is
not worth trying to synthesize the design.   Structural HDL works quite well for
this, but when you are at that level I find that the design is easier to enter and to
understand as a schematic than as structural HDL, which might as well be a textual
netlist of the schematic.  Period.

Right now, I can complete a high performance design faster and more reliably using my
hierarchical schematic methodology than I can with an HDL.  Between June 97 and June
98 I did 33 FPGA designs, most of which were XC4025/28 -2 DSP datapath designs
running at data rates of 40+ MSPS, most were 70+% utilized and heavily floorplanned,
and all but one were done with schematics.  The HDL tools are improving rapidly, and
have come a long way in the past year or two.  I am looking forward to being able to
achieve the same level of success with HDLs, as that can only help my business grow.
With that in mind, I think I have a vested interest in seeing HDL tools become better
at providing the fine level of control over a design without sacrificing design time
to get there.
--
 -Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13720
Subject: Newbie's Xilinx core question
From: jonathan@canuck.com (Victor the Cleaner)
Date: 20 Dec 1998 18:15:41 GMT
Links: << >>  << T >>  << A >>
Greetings:

I'm making my toe-in-the-water, tentative investigations into moving
a prototyped design into an fpga, probably Xilinx.  Can any of this
group's regulars tell me what the licensing terms and (ballpark) price 
are for the third-party 16550 core that they supply?

It's Sunday, so please don't tell me to call a sales wonk.

Thanks much.

--
    jonathan@canuck.com
 Canada Connect Corporation    | Jonathan |    Survival Research Laboratories
        Calgary, AB            |  Levine  |          San Francisco, CA
   403-705-2025, fax 2026                           vox/fax 415-641-8065

Article: 13721
Subject: Re: Fast *Industrial* 22V10?
From: "Austin Franklin" <dark9room@altivista.net>
Date: 21 Dec 1998 06:16:00 GMT
Links: << >>  << T >>  << A >>
>  Tim is correct, I believe there is a need for smaller pincount devices,
> the 150 mil SO16/DIP16 would seem a logical part, and resource to
> replace 
> a large chunk of all TTL grade MSI.
>  Also the 20 / 24 pin device with 22i/o lines is a candidate. 

I agree, except the package can be a problem.  If you want to socket it,
the SMT SO devices don't have very friendly (if at all) sockets.  The
PLCC28 is certainly the easiest to socket....and though is taller (so what
for most applications) doesn't take up much more space than the SO24WB
does....

Austin Franklin
darkroom@ix.netcom.com

Article: 13722
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: "Austin Franklin" <dark9room@altivista.net>
Date: 21 Dec 1998 06:39:06 GMT
Links: << >>  << T >>  << A >>
<snip>

> >It is very difficult to get this kind of performance in a synthesized
design
> >(especially with the async clocks).  In cases like this it is much
faster and
> >easier to just to do it in schematic the way you know it needs to be
implemented
> >and be done with it.

Easier is the keyword here, not that it can't be done, but it IS easier and
faster to do in schematic, then to fight with the synthesis tools.  You
certainly can, structurally, create any design in VHDL that you can using a
schematic, but basically you are writing a netlist, instead of doing an
understandable design.  Second, floorplanning/placement is tougher with
HDLs than schematic.  In order to achieve the highest performance, you must
floorplan.

> IMO one of the reasons why the schematic entry vs. HDL debate keeps
> cropping up is statements like the above, which are originated by people
> who either:
> 
> a) might have a vested interest in persuading people that they won't be
> able to use a HDL for their designs

HDLs have their places.  Not the reason.

> b) havn't tried using a HDL

Have done a lot of HDL, not the reason.
 
> c) have tried a HDL, but didn't do it properly

Not the reason again.  Personally, I believe the problem is more with the
compiler and the documentation, than 'doing it properly'.  It can be a
guessing game trying to figure out what HDL code generates what logic....
 
> d) work for FPGA manufacurers and should perhaps know better.

Not that either...  In fact, a good part of my living is made from tool and
FPGA manufacturers convincing their clients to use HDLs to do designs.
 
> At it's heart, the 'cant do it in a HDL' arguement seems to stem from a
> confusion between inferred and instantiated HDL.

No confusion here about that either....

<snip>

> I believe that the mixed inferred/instantiated method is used by most
> experienced HDL designers. A designer might predominately infer logic,
> but a some point will say to themselves 'it will be easier to just
> instantiate this element and have done with it'.

Equally, it would have been easy to just do a schematic, and 'be done with
it'.  AND you can specify placement/floorplanning information very easily
on the schematic, both relative and/or absolute.

> My suggestion is that the bi-partisan postings should cease, and that
> the gurus who reqularly offer excellent advice to people like Richard
> Schwarz should stick to describing the elements of a design and how they
> should be linked together, and take it for granted that some people will
> draw their designs, and some will type them in. For example, offer
> advice like, 

I guess you find it hard to believe that some people have learned through
vast amounts of experience (and hundreds of FPGA designs with BOTH
schematic and HDL), have come to the conclusion that using schematics for
certain things is THE correct and best approach, currently?

Austin Franklin
darkroom@ix.netcom.com

Article: 13723
Subject: Re: Fast *Industrial* 22V10?
From: z80@ds2.com (Peter)
Date: Mon, 21 Dec 1998 08:28:29 GMT
Links: << >>  << T >>  << A >>

Always a problem with *SMT* programmable devices: one has to open the
sealed package, program them, reseal the original package, place the
programmed ones on the PCB & reflow (or place in another sealed
package if subcontracting the pick/place).

I wish there was a 22V10, zero-power (like Philips P3Z22V10) which was
ISP, programmable in-circuit via 3 pins. Then one could use a TSOP-28
version, or some other tiny package.

This is why I never liked the concept of *antifuse* FPGAs - the
logistics of using them in a *subcontracted* pick/place situation
(which is true for the vast majority of small firms) are very
difficult. Too many easily bent pins.

I use the PLCC28 22V10s too. It also does not need the special sealed
packaging/handling, because of its substantial package thickness.

>I agree, except the package can be a problem.  If you want to socket it,
>the SMT SO devices don't have very friendly (if at all) sockets.  The
>PLCC28 is certainly the easiest to socket....and though is taller (so what
>for most applications) doesn't take up much more space than the SO24WB
>does....


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13724
Subject: Re: Newbie's Xilinx core question
From: Alasdair MacLean <nojunk@gecm.com>
Date: Mon, 21 Dec 1998 09:08:45 +0000
Links: << >>  << T >>  << A >>
Victor the Cleaner wrote:
> 
> Greetings:
> 
> I'm making my toe-in-the-water, tentative investigations into moving
> a prototyped design into an fpga, probably Xilinx.  Can any of this
> group's regulars tell me what the licensing terms and (ballpark) price
> are for the third-party 16550 core that they supply?
> 
> It's Sunday, so please don't tell me to call a sales wonk.
> 
> Thanks much.
> 
> --
>     jonathan@canuck.com
>  Canada Connect Corporation    | Jonathan |    Survival Research Laboratories
>         Calgary, AB            |  Levine  |          San Francisco, CA
>    403-705-2025, fax 2026                           vox/fax 415-641-8065

CAST (who supply a 16550 UART core as part of the Xilinx AllianceCORE
offering) had prices on their web page at:

	http://www.cast-inc.com/info/pr/XilinxOct98.htm

I'm not sure if that's still there, but the price quoted was $6250 for
the core license. According to the data sheet it uses 493 CLBs.

-- 
Alasdair Maclean, Senior Development Engineer,
Marconi Electronic Systems,
Electro Optics Systems Division,
Building 1A, Room 1-11,
4 Ferry Road, Silverknowes,
Edinburgh, Scotland EH4 4AD
Tel: +44 (0)131 343 5711, Fax: +44 (0)131 343 5050
Email: replace "junk" with "alasdair.maclean" in the reply address.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search