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 24300

Article: 24300
Subject: Re: foundation 2.1i problems
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 03 Aug 2000 07:29:53 GMT
Links: << >>  << T >>  << A >>
In article <8m7u19$qq2$1@nnrp1.deja.com>,
  clean_living@my-deja.com wrote:
> I have a design that I inherited from a foundation 2.1i sp1 user.
> Whenever I fix something in one module, something else breaks that
> was working before.  I'm using 2.1i sp5.  The local xilinx rep thinks
> the problem is the result of the way the designer copied design files
> rather than use the library manager.
>
> Has anyone else had a similar problem?  What did you do to fix it.
>
> -Sue R.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

You did not explain what exactly does not work, but I assume you have a
top level scematics and some HDL modules.

IMHO you could convert (export) your scematics to HDL and create a new
project only in HDL.
In HDL you have a much better control about the relations between your
modules.

Hope this helps a little bit
    Klaus

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24301
Subject: Re: models of digital ICs
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 3 Aug 2000 07:33:49 GMT
Links: << >>  << T >>  << A >>
ytou might want to check out the Free Model Foundation:
http://www.vhdl.org/vi/fmf/ 

or the Hamburg University Archive:
http://tech-www.informatik.uni-hamburg.de/vhdl/vhdl.html

I'm not sure if they have what you're looking for.

Also, IC vendors often have models of their own parts.


-Kent

lamb_baa@hotmail.com (Eric L) wrote in
>Are there any archives of digital ICs available? 

<snip>

>Thanks
>eric
Article: 24302
Subject: Re: QuickLogic PCI/FPGA chip (QL5064)...experiences?
From: Zoltan Kocsi <root@127.0.0.1>
Date: 03 Aug 2000 17:36:14 +1000
Links: << >>  << T >>  << A >>
steve (Steve Rencontre) writes:

> I've been thinking about QuickLogic, but past experience with Actel has 
> put me off OTP technologies.

What was the problem ? 
We use Actels and had no problems with them.

Regards,

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 24303
Subject: Re: GPIO board for Avnet Virtex Development system ?
From: Starry Hung <starry@hotpop3.com>
Date: Thu, 03 Aug 2000 16:13:33 +0800
Links: << >>  << T >>  << A >>
Yes, they are GPIO from the FPGA, but the socket is hard to find, at least in
my area. I would recommend to use the PCI reverser and using the PCI pins (if
you don't use the PCI.) for adding your components.

- starry.

"K. Orthner" wrote:

> This is just an educated (?) guess, but I would assume that GPIO simply
> stands for General Purpoose I/O, and isn't really a bus, per se.  I would
> think that it's just a bunch of wires running from the FPGA out to a
> connector that easily allows you to connect other things, be it boards,
> chips, or otherwise.
>
> -Kent
>
> muzaffer@kal.st (Muzaffer Kal) wrote:
> >I have an Avnet Virtex Development Board. This has a bus interface
> >which they call GPIO. Does anyone know if there are any boards which
> >plug into this GPIO to add some chips? Basically I am looking for a
> >board which would let me do some wire-wrap or soldering area.
> >
> >thanks,
> >
> >Muzaffer
> >
> >

Article: 24304
Subject: Re: 8251A USART
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 03 Aug 2000 09:57:28 GMT
Links: << >>  << T >>  << A >>
On Wed, 2 Aug 2000 22:15:45 -0400, "Geoffrey G. Rochat"
<geoff@pkworks.com> wrote:

>"The Verilog Hardware Description Language", 2nd Ed., by Donald E.
>Thomas and Philip R. Moorby, 1995, Kluwer Academic Publishers, ISBN
>0-7923-9523-9, uses an 8251 design as an example.

The book isn't bad, but I wouldn't recommend buying it. You can get
the 8251A source bits from:

http://www.angelfire.com/in/verilogfaq/moorby.html

I don't know if it's legal or not, and I don't know of a VHDL source.

Evan
Article: 24305
Subject: Re: Well, it finally happenned
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 03 Aug 2000 09:58:52 GMT
Links: << >>  << T >>  << A >>
On Tue, 01 Aug 2000 13:43:35 GMT, s_clubb@NOSPAMnetcomuk.co.uk (Stuart
Clubb) wrote:

>After the long suppositions and wondering "will they, wont they, can
>they, cant they?", we finally see an IPO filing from Synplicity.
>
>You can read the filing with all the juicy financial detail through
>www.ipo.com. Once you've read it (and deciphered it?), as informed
>observers of the synthesis market space (Exemplar/Synopsys/Synplicity
>etc.) tell me:
>
>On balance, would you invest?
>
>Cheers
>Stuart
>An employee of Saros Technology:
>Model Technology, Exemplar Logic, TransEDA, Renoir.
>www.saros.co.uk

Or see the EEtimes article at:

http://www.eoenabled.com/edtn/out.asp?n=33586385&i=synplicity&a=EET&url=http%3A%2F%2Fwww%2Eeet%2Ecom%2Fstory%2FOEG20000726S0025&title=Synplicity+makes+IPO+bid

for the short story. Synplicity describes itself as a "provider of
software products for Internet infrastructure, including
next-generation networking and communications equipment and various
electronic devices." 

This reminds me of the South Sea bubble company that advertised itself
as being on a "great undertaking, not to be disclosed". Surely there
aren't still people around who are stupid enough to invest in
something just because the word 'Internet' appears in the offer?

Certify's getting some good press, and Synplicity seems to be ahead of
the game on FPGA physical synthesis. My money is on everyone moving to
physical synthesis over the next few years, and FPGAs taking an
increasing slice of the ASIC market, so it might be worhtwhile putting
a few beads in. On the other hand, the short-term prospects may depend
very much on what Xilinx decides to do with XST, so I may just hang on
to those beads...

Evan
Article: 24306
Subject: Re: tbuf
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 03 Aug 2000 09:59:44 GMT
Links: << >>  << T >>  << A >>
On Mon, 31 Jul 2000 16:39:23 GMT, erika_uk@my-deja.com wrote:

>hey,
>
>what are the advantages and disadvantages from using TBUFs( e.g : for
>multiplixer purpose )
>
>anticipated thanks
>
>--Erika

+ potentially better for large muxes, in some cases
+ synth tools can generally recode combinatorially if there's a
problem

- potentially difficult to move to an ASIC process
- may force use of an asynchronous reset
- potentially very slow
- can cause placement problems: as a (xilinx) rule, you will probably
want your logic blocks arranged vertically, but a bus line implemented
with tristates will run horizontally.

The speed issue now seems to be historical. 4K TBUFs got *very* slow
with larger devices, but Virtex TBUFs are relatively fast and the
speed appears to be independent of device size. This is apparently
because there aren't actually any tristate buffers on Virtex; they're
actually implemented as combinatorial muxes and just pretend to be
tristates.

As a rule, I'd say forget it. TBUFs are fine for small FPGAs, where
you have to use every trick you can to squeeze performance out of
them. For 'big' devices, the issues are completely different - design
management, timing closure, getting a design done in a reasonable
timescale. I'd say the days of the TBUF are numbered (at least until
someone gives us the 10GHz 100-CLB FPGA, then we can start all over
again...)

Evan

Article: 24307
Subject: Re: 8251A USART
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Thu, 03 Aug 2000 12:11:18 +0100
Links: << >>  << T >>  << A >>

I agree that the XCV50 is too much for this applicatiopn, but the
board will be used for teaching, and it's important for us to have
some extra space in the FPGA in order to use it in different labs.
In addition, it's important to have a long life board. We don't need
a board to use just for a couple of years.

The problem of using, for example, an XC4010XL FPGA is the cost:

> XC4010XL-09PC84C (10K gates, 244 CLBs) - 24 units - US$109.00 / unit
>
> XCV50-4BG256C (50K gates, 384 CLBs) - 24 units - US$55.40 / unit
>

I couldn't find at http://www.optimagic.com a board suitable for
our design. We need something very simple and cheap. Basically, we
need a board with an FPGA, a serial PROM socket, an RS-232 connector,
a MAX232 chip, and prototyping area. At the moment I'm using an
XS40 board from Xess Corporation (donated by Xilinx) to develop
the prototype.

The surface mount package may be a problem. I'll investigate some
alternatives.

Thanks

Eduardo.

Dave Vanden Bout wrote:
> 
> > My design will have, basically, an 8251 and a manchester
> > encoder/decoder. It'll be used to teach concepts of data
> > communications to undergraduate students. We're considering
> > the use of the same board (with the same FPGA) to implement
> > different UARTs and USARTs. Do you think the Xilinx XCV50
> > FPGA is a good option? We're going to build 30 kits and the
> > cost of the FPGAs (XCV50) + serial PROMs will be something
> > around US$1,500.00. Is it the best option for this design?
> > Is there a less expensive solution?
> 
> The XCV50 is overkill for just an 8251 and a Manchester encoder/decoder,
> but it makes sense if you want to work with a current FPGA family.  The
> older Xilinx XC4000 family will also suit your application.
> 
> Remember that the XCV50 only comes in a surface mount package so you will
> need to build a PCB to hold it.  You will spend several times your $1500
> building and supporting the lab infrastructure that surrounds the FPGA and
> serial PROM.  You might want to check the list of FPGA boards at
> www.optimagic.com to see if there is a one that will suit your needs.
> 
> >
> >
> > Thanks
> >
> > Eduardo.
> >
> > Peter Alfke wrote:
> > >
> > > Eduardo Augusto Bezerra wrote:
> > >
> > > > Hi
> > > >
> > > > Does anybody know the price of a synthesizable 8251A core? I'm also
> > > > looking for a Manchester encoder/decoder. Is there a place where I
> > > > can find these cores for free? I'll decide which FPGA to use in my
> > > > design as soon as I find the cores.
> > > >
> > >
> > > A Manchester encoder is trivial, essentially an XOR.
> > > A Manchester decoder is described in the Xilinx XCell magazine in
> > > 1995.
> > > The design uses only three XC3000 or XC4000 or Spartan CLBs.
> > >
> > > http://www.xilinx.com/xcell/xl17/xl17-30.pdf
> > >
> > > Peter Alfke, Xilinx Applications
> >
> > --
> > Eduardo Augusto Bezerra
> > Space Science Centre
> > School of Engineering and Information Technology
> > University of Sussex
> > Brighton, BN1 9QT
> > England, UK
> >
> > Phones: +44 (0)1273 877086 or +44 (0)700 5568783
> > Fax: +44 (0)1273 678399
> > EIT II, room 4B11
> >
> > *** UK ***
> > mailto:E.A.Bezerra@sussex.ac.uk - http://www.sussex.ac.uk/~tapu9
> > Space Group's web site: http://www.sussex.ac.uk/engg/research/space
> > *** Brasil ***
> > mailto:eduardob@inf.pucrs.br - http://www.inf.pucrs.br/~eduardob
> > GAPH's web site: http://www.inf.pucrs.br/~gaph
> > *** ACM ***
> > mailto:eduardob@acm.org
> 
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||

--
Eduardo Augusto Bezerra
Space Science Centre
School of Engineering and Information Technology
University of Sussex
Brighton, BN1 9QT
England, UK

Phones: +44 (0)1273 877086 or +44 (0)700 5568783
Fax: +44 (0)1273 678399
EIT II, room 4B11

*** UK ***
mailto:E.A.Bezerra@sussex.ac.uk - http://www.sussex.ac.uk/~tapu9
Space Group's web site: http://www.sussex.ac.uk/engg/research/space
*** Brasil ***
mailto:eduardob@inf.pucrs.br - http://www.inf.pucrs.br/~eduardob
GAPH's web site: http://www.inf.pucrs.br/~gaph
*** ACM ***
mailto:eduardob@acm.org
Article: 24308
Subject: tutorial on configurable system-on-chip design is available
From: Dave Vanden Bout <devb@xess.com>
Date: Thu, 03 Aug 2000 08:07:45 -0400
Links: << >>  << T >>  << A >>
XESS Corp. is releasing the sixth section of its "myCSoC" tutorial for
free downloading at http://www.xess.com/myCSoC-CDROM.html.  We will
release a new section each week.

Each section describes a design example for the Triscend configurable
system-on-chip device (CSoC).  The Triscend TE505 CSoC integrates an
8051 microcontroller core with a programmable logic array to create a
chip whose software and hardware are both reprogrammable.  The tutorial
examples show how the Triscend FastChip development software is used to
configure the TE505's programmable logic into peripheral functions that
cooperate with the microcontroller core.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
Article: 24309
Subject: Re: Who needs all those printed ac parameters?
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Thu, 03 Aug 2000 12:35:56 +0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
>    Part 1.1    Type: Plain Text (text/plain)
>            Encoding: 7bit
Grumble ... I hate that kind of messages.
(cut...paste)

"I have a 30-year tradition of fighting for complete IC
documentation. But that started when the parts were simple, and the
designers worked with pencil and paper.
Today, nobody designs with pencil and paper, the parts are very
complex, and the software accurately computes any on-chip delay for
you, using hundreds of "atomic" incremental values, carefully
derived from extensive measurements, and carried forward with
picosecond accuracy.

What benefit is there in publishing a select subset of these values
in the data sheet, necessarily excluding most routing delays ?
"

It is still useful for order of magnitude comparisons.
Still the data sheets don't tell you how slow your FPGA
logic compares with raw gates.
picosecond accuracy!? Does that include 10% margin for
things like power supply ripple,clock jitter,and the  phase
of the moon. 

While it not Practical to design using pencil and paper,
I think we have lost something by having designs so complex
that knowbody really knows just what is in the hardware.
The one advantage of pencil and paper is what you see is what
you get. FPGA hardware is real black box inside, and don't
like black boxes,black holes,or block hole diodes or software
with out source.

Ben.
Ps what little FPGA design I have done I find in many cases
the much of the logic FPGA block goes to waste because the #of inputs
to a block is limited.I need a 9 input and gate - 3 blocks. A 4:1 multiplexer -
3 blocks.Actel's logic blocks are not as in/out bound as the other companies
bocks, but fewer the blocks used the better.I like anti-fuse as it is one less
chip. I would have to be able to do FPGA's logic programing by hand,not because
it easier but because I can SEE just what the chip is doing.

-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
 http://www.jetnet.ab.ca/users/bfranchuk/index.html
Article: 24310
Subject: Re: QuickLogic PCI/FPGA chip (QL5064)...experiences?
From: "Austin Franklin" <austin@d44arkroom.com>
Date: 3 Aug 2000 13:36:59 GMT
Links: << >>  << T >>  << A >>
Thanks, have you actually used this chip?


Mark Korsloot <markk@alcom.nl> wrote in article
<39880AE9.305845C9@alcom.nl>...
> Galileo Technology has standard 64-bit 66MHz PCI Interface chips (eg.
> GT64121).
> 
> See www.galileot.com
> 
> Mark
> 
> Austin Franklin wrote:
> > 
> > I have a design that currently uses a PLX 9080, and I need to move it
to a
> > 64 bit and/or 66MHz PCI interface...  PLX does not currently offer a
> > solution, that I can find...neither does AMCC.  Any suggestions for off
the
> > shelf chips to do this, or any experience with the QuickLogic QL5064
> > interface chip?
> > 
> > Thanks!
> 
> 
Article: 24311
Subject: Re: tbuf
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 03 Aug 2000 10:11:37 -0400
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote:
> 
> On Mon, 31 Jul 2000 16:39:23 GMT, erika_uk@my-deja.com wrote:
> 
> >hey,
> >
> >what are the advantages and disadvantages from using TBUFs( e.g : for
> >multiplixer purpose )
> >
> >anticipated thanks
> >
> >--Erika
> 
> + potentially better for large muxes, in some cases
> + synth tools can generally recode combinatorially if there's a
> problem
> 
> - potentially difficult to move to an ASIC process
> - may force use of an asynchronous reset
> - potentially very slow
> - can cause placement problems: as a (xilinx) rule, you will probably
> want your logic blocks arranged vertically, but a bus line implemented
> with tristates will run horizontally.
> 
> The speed issue now seems to be historical. 4K TBUFs got *very* slow
> with larger devices, but Virtex TBUFs are relatively fast and the
> speed appears to be independent of device size. This is apparently
> because there aren't actually any tristate buffers on Virtex; they're
> actually implemented as combinatorial muxes and just pretend to be
> tristates.
> 
> As a rule, I'd say forget it. TBUFs are fine for small FPGAs, where
> you have to use every trick you can to squeeze performance out of
> them. For 'big' devices, the issues are completely different - design
> management, timing closure, getting a design done in a reasonable
> timescale. I'd say the days of the TBUF are numbered (at least until
> someone gives us the 10GHz 100-CLB FPGA, then we can start all over
> again...)
> 
> Evan

I would quibble with the last two disadvantages you mention. In many
cases the speed will be fine since it does not slow as appreciably with
size compared to a LUT mux. I doubt that the tbufs are really muxes, but
I can't say for sure. Of course it can't be pipelined for speed the way
a LUT solution can. 

The placement issue is often perfect for placement. If you are muxing
many registers onto a wide bus, then the registers will be vertically
arranged and the mux *should* be horizontal. Of course if you are muxing
one wide register to a single signal the arrangement is not good. A
barrel shifter still works out since it has to be a 2D array. The input
data lines run diagonal, the enables run vertical and the output data is
horizontal. This is what I used and it had no problems routing at all. 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24312
Subject: Re: foundation 2.1i problems
From: sriley <sueriley@my-deja.com>
Date: Thu, 03 Aug 2000 14:23:55 GMT
Links: << >>  << T >>  << A >>
In article <8mb71e$8v8$1@nnrp1.deja.com>,
  Klaus Falser <kfalser@durst.it> wrote:
> In article <8m7u19$qq2$1@nnrp1.deja.com>,

>
> You did not explain what exactly does not work, but I assume you have
a
> top level scematics and some HDL modules.
>
> IMHO you could convert (export) your scematics to HDL and create a
new
> project only in HDL.
> In HDL you have a much better control about the relations between
your
> modules.
>
> Hope this helps a little bit
>     Klaus
>
Thanks Klaus.  Let me clear this up.  The project is schematic capture.
There are no hdl modules.  One module, a bit error rate test (bert),
was ported over from another fpga design.  The design works in the
other fpga.  There are two instantiations of the bert.  The bert uses
an m2_1 mux in the incoming serial data path.

While bert1 works bert2 will not.  I fix bert2 by deleting the mux and
reinstantiating it.  This fixes the problem and bert2 now works,
however, bert1 now fails.

I have considered the following:

1.)  a library problem for the 2-1 mux
2.)  the next-higher level in the hierarchy is not correct
3.)  the software is not properly configuring the fpga
4.)  the fpga needs to be replaced
5.)  the schematic capture tool is not working properly
6.)  the implemenation tool is not working properly

I have concluded the following:

1.)  all the other instantiations of the m2_1 work properly.  This is
     not a library problem.
2.)  The hierarchy has been reviewed many, many times.  I have triple
     checked signal & pin names, their spelling and verified signal
     connectivity by "selecting the entire net" and "dragging" the
     mux around to see if the nets drag as well.  I have also used
     these techniques at all levels of the hierarchy.  The schematic
     appears to be intact.
3.)  The software does not change from implementation to
     implementation. At least that's what the software guy claims ;-)
4.)  I have duplicated the problem on many different boards.
5.)  This is still questionable.  I can see from the map report that
     the mux is being optimized out.  Yet the schematic shows all
     the proper connections to the mux.  I have seen the mapper delete
     muxes -  if the inputs are present but the select line(s) are left
     floating.  This is not the case here.
6.)  I can't isolate the problem to the implementation tool until I can
     verify the schematic capture tool is working properly.  Xilinx
     tech support suggested running a post-par timing sim on the
     circuit.  They feel if the circuit simulates properly after par,
     the .ncd file good and the implementation is correct.  This would
     validate the schematic capture tool as well.  The simulation
     worked!

So what's the difference between the simulation the the real-life
application?  Good question.  I'll find out.  Also,  could this be a
problem with limitations of my machine?  I am running on a 200MHz
pentium, NT and 96M ram.  The device is a spartan 20xl and is only
being 35% utilized.

Thanks in advance,

-Sue


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24313
Subject: Re: 32-input AND and 100-input OR - can I do it fast?
From: "Eric Pearson" <ecp@focus-systems.nospam.on.ca>
Date: Thu, 3 Aug 2000 10:25:37 -0400
Links: << >>  << T >>  << A >>
Hi Ken...

Sounds to me like you should be looking at PLDs, which
can be thought of as a large number of wide input AND gates feeding a
number of wide input OR gates, with all intersections programable.

I am aware of common 5nsec CMOS PLDs, and seem to remember a
Galium Arsenide PLD, but a visit to the vitesse web site didn't reveal
anything.

Good luck in your hunt

Eric Pearson



Ken Christensen wrote in message <8ma4e0$62v$1@news.usf.edu>...
>Hello, FPGA's are not my area. so, my apologies if this is a really stupid
>(or textbook) question.  What size AND and OR arrays are available in
>existing devices?  If I want arrays of 32 input ANDs and 100 input ORs, can
>I do this in *two-levels*?  If so, what is the gate delay of the 32 input
>AND and 100 input OR?  I want to implement some rather complex two-level
>logic equations with delay of less than 1 nanosecond. is this achievable
>with FPGA technology?  If yes, which technology/vendor?  If not with
FPGA's,
>how could I implement this?
>
>Thank you!
>
>
>Ken Christensen
>===============================================================
>=  Kenneth J. Christensen (Assistant Professor)
>=  Department of Computer Science and Engineering
>=  University of South Florida
>=  (813) 974-4761
>=  http://www.csee.usf.edu/~christen
>===============================================================
>
>


Article: 24314
Subject: Re: 8251A USART
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 03 Aug 2000 10:29:31 -0400
Links: << >>  << T >>  << A >>
Eduardo Augusto Bezerra wrote:
> 
> I agree that the XCV50 is too much for this applicatiopn, but the
> board will be used for teaching, and it's important for us to have
> some extra space in the FPGA in order to use it in different labs.
> In addition, it's important to have a long life board. We don't need
> a board to use just for a couple of years.

If you are building a board, then you can use the surface mount packages
just fine. TQFPs can be hand soldered if you have a little skill (I
don't, but many do). 

The new Spartan II is functionally the same as the Virtex parts and come
in sizes from 15 K gates (vendor gates) to 200 K gates. The cost is very
low on this line. I would suggest either the TQ 144 pin package or the
PQ 208 pin package depending on how many IOs you think you will need in
the future. 

I would also suggest that you leave off the PROM socket. The PROMs are
not terribly cheap parts and for education, you will likely want to just
download directly from the development station. You can either use the
serial port, the parallel port or an X-checker cable. Either a CPLD or a
small simple single chip micro will do the programming very nicely. I
think you may not need any logic if you use the PC parallel port. 

But as others have suggested, check for an existing product. There is no
point in designing your own when others are available and likely
cheaper. 

There was a ad in this newsgroup from a company in Austraila (IIRC) that
had a board for under $100. I don't think you can build you own this
cheaply. 

 
> The problem of using, for example, an XC4010XL FPGA is the cost:
> 
> > XC4010XL-09PC84C (10K gates, 244 CLBs) - 24 units - US$109.00 / unit
> >
> > XCV50-4BG256C (50K gates, 384 CLBs) - 24 units - US$55.40 / unit
> >
> 
> I couldn't find at http://www.optimagic.com a board suitable for
> our design. We need something very simple and cheap. Basically, we
> need a board with an FPGA, a serial PROM socket, an RS-232 connector,
> a MAX232 chip, and prototyping area. At the moment I'm using an
> XS40 board from Xess Corporation (donated by Xilinx) to develop
> the prototype.
> 
> The surface mount package may be a problem. I'll investigate some
> alternatives.
> 
> Thanks
> 
> Eduardo.
 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24315
Subject: Re: 8251A USART
From: Nicolas Matringe <nicolas@dotcom.fr>
Date: Thu, 03 Aug 2000 17:02:10 +0200
Links: << >>  << T >>  << A >>
rickman a écrit :

> The new Spartan II is functionally the same as the Virtex parts and
> come in sizes from 15 K gates (vendor gates) to 200 K gates. The cost
> is very low on this line. I would suggest either the TQ 144 pin
> package or the PQ 208 pin package depending on how many IOs you think
> you will need in the future.

The problem (at the moment) is that they are REALLY hard to find because
they're not in full production yet. However, if your board (talking to
Eduardo, here) can wait a bit, I'd recommend SpartanII (but I'd order
them now)

-- 
Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FRANCE
Fax +33 1 46 67 51 01      http://www.dotcom.fr/
Article: 24316
Subject: PWM implementation suggested sought for Spartan FPGA
From: George Pontis <geo@z9.antispam.com>
Date: Thu, 3 Aug 2000 09:51:06 -0700
Links: << >>  << T >>  << A >>
Hello FPGA users,

Can someone suggest a good approach for implementing PWM modulation in a 
Spartan-XL FPGA ? The goal is to generate a 200KHz carrier with 10KHz 
PWM; the input clock at 40MHz should be ample. The output will be aplied 
to a half-H power driver and filtered. I also need to be able to control 
the amplitude of the 10KHz component at a slow rate.

My thought for a possible approach is to build a small lookup table in a 
dual-port RAM block. An external CPU would compute the pulse widths 
appropriate for the desired 10KHz amplitude, then download the table into 
FPGA RAM. Then FPGA hardware cycles through the table, generating pulses 
of the appropriate width every 5us. A table of 20 entries with even 4 bit 
resolution seems reasonable.

Is there some whiz-bang approach that makes better sense than the obvious 
one I've suggested ? Any thoughts on resource usage ?

Your comments would be most welcome.

Thanks,
George Pontis

(Please edit return address if replying by email.)
Article: 24317
Subject: Re: QuickLogic PCI/FPGA chip (QL5064)...experiences?
From: steve (Steve Rencontre)
Date: Thu, 3 Aug 2000 19:12 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <398894A9.3E02E759@GoodWare.com>, Wayne@GoodWare.com (Wayne) 
wrote:

> 
> I've been using QuickLogic for about a year now and have had good luck 
> with
> them. What sort of problems did you have with Actel ?

Not Actel per se, but OTP. It's not so bad if you have a PLCC chip that 
you can socket easily, but the burn/chuck cycle is still an expensive pain 
in development. Higher-density packages are just not practical unless you 
are pretty certain that your first version will be near-as-dammit the 
final one.

There may be some projects where the FPGA functionality is completely and 
accurately specified in advance, and the simulation is absolutely correct 
and exhaustive, but I've yet to see one. A big problem I've always had, 
and I don't expect it to go away any time soon, is that the documentation 
for the surrounding circuitry is /never/ sufficient to simulate it with 
100% confidence.

Now having said that, it should be qualified by the fact that I mostly use 
FPGAs as glue and peripherals. If I was making standalone functional 
blocks, I'd have a lot more control of my destiny and might feel 
differently.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>

Article: 24318
Subject: Re: 32-input AND and 100-input OR - can I do it fast?
From: steve (Steve Rencontre)
Date: Thu, 3 Aug 2000 19:12 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <8ma4e0$62v$1@news.usf.edu>, christen@csee.usf.edu (Ken 
Christensen) wrote:

> Hello, FPGA's are not my area. so, my apologies if this is a really 
> stupid
> (or textbook) question.  What size AND and OR arrays are available in
> existing devices?  If I want arrays of 32 input ANDs and 100 input ORs, 
> can
> I do this in *two-levels*?  If so, what is the gate delay of the 32 
> input
> AND and 100 input OR?  I want to implement some rather complex two-level
> logic equations with delay of less than 1 nanosecond. is this achievable
> with FPGA technology?  If yes, which technology/vendor?  If not with 
> FPGA's,
> how could I implement this?

Large sum-of-products arrays are really the more the domain of PLDs than 
FPGAs, although the dividing lines are pretty blurred. Some Altera and 
Xilinx devices have embedded RAM arrays which can be used to implement 
wide logic functions, but 1ns is pushing things to put it mildly!

When you say 'gate' delay, I presume you mean pin-pin, rather than 
within-chip propagation. If so, I don't think even simple 22V10 chips can 
run that fast, let alone anything with the complexity you want.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>

Article: 24319
Subject: Re: Viewlogic Licencing
From: husby@fnal.gov (Don Husby)
Date: Thu, 03 Aug 2000 19:01:08 GMT
Links: << >>  << T >>  << A >>
Philip Freidin <philip@fliptronics.com> wrote:
> Which would work only if you knew how to generate the security number
> on the K line. I have no idea how to calculate it.

Last time I checked, you could give every file the same K-line since
Viewlogic no longer checks the name on the K-line against the file name.

Your post-processor can simply overwrite the existing K-line with a
known valid one.  It's probably best to comment-out the old one in case
you need it later.  


--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 24320
Subject: Re: End of my rope.
From: sriley <sueriley@my-deja.com>
Date: Thu, 03 Aug 2000 22:32:37 GMT
Links: << >>  << T >>  << A >>

> "K.Orthner" wrote:
>
> > As the subject says, I fell like I'm at the end of my rope, here.
( I get
> > the feeling I'm mixing metaphors, but I haven't actually had an
english
> > conversatoin for so long, I forget.)
> >
> > This is (was?) related to the coregen thread, except that now, I
have
> > completely removed everything Coregen-related.
> >
> > I have the simple problem of:
> >
> > My code simluates fine, I get exactly the answers that I expect.
Then I put
> > it throught the Xilinx mapper, it "optimizes" out some signals that
are
> > rather important.  It then falls over saying that there are
components who's
> > input signals have been optimized.
> >
> > If I select the "Don't  trim logic"option it seems to work fine;
but I
> > haven't tested it on a real board yet.  (It's PnR'ing as I type.)
> >
> > Anyone have a suiggestion for how to track this problem down?
> >
> > I've been tracing nets with the EDIF file/FPGA Express Schematic
viewer, and
> > as far as I can tell, the output of the synthesizer is just fine.
> >
> > ------------
> > Kent Orthner
>
>

Kent,

I am currently having a similar problem with a schematic project I
inhereted (see thread "foundation 2.1i problem").  The mapper declares
nets unloaded, optimizes them out and anything in either direction
(upriver or down).  Even funnier was the fact I could not find the nets
being optimized out.

Ver-r-r-r-ry late last night, I decided to shut down project manager &
the pc and try again.  I couldn't get project manager to respond then
the pc got hung up on task manager.  I powered down, rebooted, and
relaunched 2.1i.  When I opened the schematic editor, some bus taps
were unamed!  I had named them earlier in the day, created a netlist
and printed a copy of the sheet.  When I checked their net numbers,
sure enough they were the elusive nets being optimized out!  Once again
I edited the schematic and created a netlist.   This time everything
worked. . . . except for the design of course.

I had chalked this up to a schematic tool problem until I read your
post.  One thing I did last night that may have helped. . . I cleared
the transcript window's huge file by selecting
file -> preferences -> clear messages. I can't think of anything else,
if you figure this out I'd like to know too.

regards,

-SueR


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24321
Subject: Who needs all those printed ac parameters?
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 04 Aug 2000 00:57:46 GMT
Links: << >>  << T >>  << A >>

--------------FCEE0EFB74776E8D3BA5944F
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Let me pose a provocative question to this smart, diverse, and vocal
audience. (Shameless flattery might help me get a few additional
answers...)

Why do we ( Xilinx, etc) print and publish all those detailed ac
parameters describing on-chip performance ?
(Let's exclude I/O parameters from this question)

I have a 30-year tradition of fighting for complete IC
documentation. But that started when the parts were simple, and the
designers worked with pencil and paper.
Today, nobody designs with pencil and paper, the parts are very
complex, and the software accurately computes any on-chip delay for
you, using hundreds of "atomic" incremental values, carefully
derived from extensive measurements, and carried forward with
picosecond accuracy.

What benefit is there in publishing a select subset of these values
in the data sheet, necessarily excluding most routing delays ?

How would you react if we reduced the published on-chip delay
parameters to a limited number of relevant performance values, and
then referred you to the software tool for the detailed, complete
and very accurate  analysis ?
Wouldn't you be better off ?

This was triggered by the recent debate over the delay differences
between the 4 different LUT inputs. I feel strongly that the
designers should not be bothered with such details. The software
should analyze and synthesize this for you.

This is Peter speaking. It is not an official  Xilinx proposal.
It is also not an attempt to save cost and paper, although it would
do that as a side benefit.

It is just a fresh look at a 40-year old habit.
Every couple of dozen years one should clean out the closet   :-)

Please let me know what you think.
I know I can count on your opinionated response !

Peter Alfke



--------------FCEE0EFB74776E8D3BA5944F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Let me pose a provocative question to this smart, diverse, and vocal
<br>audience. (Shameless flattery might help me get a few additional answers...)
<p><b>Why do we ( Xilinx, etc) print and publish all those detailed ac</b>
<br><b>parameters describing on-chip performance ?</b>
<br>(Let's exclude I/O parameters from this question)
<p>I have a 30-year tradition of fighting for complete IC
<br>documentation. But that started when the parts were simple, and the
<br>designers worked with pencil and paper.
<br>Today, nobody designs with pencil and paper, the parts are very
<br>complex, and the software accurately computes any on-chip delay for
<br>you, using hundreds of "atomic" incremental values, carefully
<br>derived from extensive measurements, and carried forward with
<br>picosecond accuracy.
<p><b>What benefit is there in publishing a select subset of these values</b>
<br><b>in the data sheet, necessarily excluding most routing delays ?</b><b></b>
<p>How would you react if we reduced the published on-chip delay
<br>parameters to a limited number of relevant performance values, and
<br>then referred you to the software tool for the detailed, complete
<br>and very accurate&nbsp; analysis ?
<br>Wouldn't you be better off ?
<p>This was triggered by the recent debate over the delay differences
<br>between the 4 different LUT inputs. I feel strongly that the
<br>designers should not be bothered with such details. The software
<br>should analyze and synthesize this for you.
<p>This is Peter speaking. It is not an official&nbsp; Xilinx proposal.
<br>It is also not an attempt to save cost and paper, although it would
<br>do that as a side benefit.
<p>It is just a fresh look at a 40-year old habit.
<br>Every couple of dozen years one should clean out the closet&nbsp;&nbsp;
:-)
<p>Please let me know what you think.
<br>I know I can count on your opinionated response !
<p>Peter Alfke
<br>&nbsp;
<br>&nbsp;</html>

--------------FCEE0EFB74776E8D3BA5944F--

Article: 24322
Subject: XST?
From: "peter dudley" <padudle@spinn.net>
Date: Thu, 3 Aug 2000 19:57:51 -0600
Links: << >>  << T >>  << A >>
I saw a reference to XST in an earlier post. Could someone please explain to
me what is XST?

I'm running Xilinx 2.1i software and I've never heard of XST.

Thanks,

--
Pete Dudley

Arroyo Grande Systems



Article: 24323
Subject: Re: Who needs all those printed ac parameters?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 04 Aug 2000 02:01:07 GMT
Links: << >>  << T >>  << A >>
All well and good for the average user. 
Still for the expert, it helps to have
this information available in some form
that is easier to access than going into
the chip editor as an aid for
development of highly optimized blocks. 
Surely it doesn't need to be in the data
book, but how about in an app note where
he who wants it can get it.

Peter Alfke wrote:
> 
> Let me pose a provocative question to
> this smart, diverse, and vocal
> audience. (Shameless flattery might
> help me get a few additional
> answers...)
> 
> Why do we ( Xilinx, etc) print and
> publish all those detailed ac
> parameters describing on-chip
> performance ?
> (Let's exclude I/O parameters from
> this question)
> 
> I have a 30-year tradition of fighting
> for complete IC
> documentation. But that started when
> the parts were simple, and the
> designers worked with pencil and
> paper.
> Today, nobody designs with pencil and
> paper, the parts are very
> complex, and the software accurately
> computes any on-chip delay for
> you, using hundreds of "atomic"
> incremental values, carefully
> derived from extensive measurements,
> and carried forward with
> picosecond accuracy.
> 
> What benefit is there in publishing a
> select subset of these values
> in the data sheet, necessarily
> excluding most routing delays ?
> 
> How would you react if we reduced the
> published on-chip delay
> parameters to a limited number of
> relevant performance values, and
> then referred you to the software tool
> for the detailed, complete
> and very accurate  analysis ?
> Wouldn't you be better off ?
> 
> This was triggered by the recent
> debate over the delay differences
> between the 4 different LUT inputs. I
> feel strongly that the
> designers should not be bothered with
> such details. The software
> should analyze and synthesize this for
> you.
> 
> This is Peter speaking. It is not an
> official  Xilinx proposal.
> It is also not an attempt to save cost
> and paper, although it would
> do that as a side benefit.
> 
> It is just a fresh look at a 40-year
> old habit.
> Every couple of dozen years one should
> clean out the closet   :-)
> 
> Please let me know what you think.
> I know I can count on your opinionated
> response !
> 
> Peter Alfke
> 
> 

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group,
Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or
http://www.fpga-guru.com
Article: 24324
Subject: Re: End of my rope.
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 4 Aug 2000 02:07:43 GMT
Links: << >>  << T >>  << A >>
SueR,

Thanks a lot for the advice/suggestion.

I ended up taking a different route . . . I kind of redesigned the block 
that was giving me problem from the groud up.

What I *was* doing was, I had a RAM with a feedback loop.  The ram was 16 
bits wide, and everytime you accessed the RAM, it foud feed "output+1" back 
to "input".  In that was, I can have 16x 16bit counters, using 16 LUTs as 
RAMs.

What I *think* I did, but I'm not sure, is that I had no way to force my 
RAM input's to zero . . . It so happenned that I didn't really care what 
the default value was.  I think what happaned was that since there was no 
way to initialise the RAM inputs, it figured the inputs and outputs would 
always be 'X', and therefore unuseabe, and therefore trimmable.

But that is a *very* shaky theory on my part!


>Ver-r-r-r-ry late last night, I decided to shut down project manager &
>the pc and try again.  I couldn't get project manager to respond then
>the pc got hung up on task manager.  I powered down, rebooted, and
>relaunched 2.1i.

Well, I use windows, see, so that happens to me on a daily basis. <growl>

>When I opened the schematic editor, some bus taps
>were unamed!  I had named them earlier in the day, created a netlist
>and printed a copy of the sheet.  

I'm not exactly sure wqhat you mean by "Bus taps were unnamed".  That 
sounds as though it's schematics realted.  I'm using purely HDL, so it's 
impossible to have a net without a name.  Or was it after the synthesis 
stage the the names seemed to be lost?

When I looked at the post synthesis results, everything seemed to be 
connected nicely.  It wasn't until the mapper went on a trimming spree that 
I ran into trouble.

>I had chalked this up to a schematic tool problem until I read your
>post.  One thing I did last night that may have helped. . . I cleared
>the transcript window's huge file by selecting
>file -> preferences -> clear messages. I can't think of anything else,
>if you figure this out I'd like to know too.

Like I said, instead of getting past the problem, I went around it, so 
there probably won't be anything I can say to help.  I'll make a point of 
doing the 'clear messages' thing, though.

Which brings me to a question . . . whenever I look at the post synthesis 
report files in Foundation 2.1 (FPGA Express 3.3), it's as though the top 
half (quarter?  seven eights?) of the file is missing, and I'm only getting 
the last bit.

Anyone else get this?

-Kent



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