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 4500

Article: 4500
Subject: Re: XACT under WinNT is very slow
From: no.bulk.mailing@thanks.com (Peter)
Date: Wed, 06 Nov 1996 10:51:03 GMT
Links: << >>  << T >>  << A >>

>Any 16 bit DOS app is going to run much slower under NT. 

Not necessarily *noticeably* so. I run most of my 50 (yes, fifty) or
so ex-win3.x apps under NT4 (I have a dual-boot NT/WFWG system), and
while there is a noticeable slowdown in some operations (e.g. file
open speed in Protel PCB) most things are just as quick.

But this assumes you have RAM appropriate to NT, i.e. at least 32
megs.

>The next release of the Xilinx tools will be made to run under NT.  This
>current release does run, at least all the DOS tools do.  I don't know if
>the number I get is 30 times slower, it may be 2-4 times slower.

The only way PPR will be 2-4 times slower is if it is set-up to get
say 50% of CPU time.

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4501
Subject: Re: UART FOR FPGAS
From: no.bulk.mailing@thanks.com (Peter)
Date: Wed, 06 Nov 1996 10:51:04 GMT
Links: << >>  << T >>  << A >>

>I need a RS-232 interface for XILINX FPGAS.

You need a RS232-TTL converter first, e.g. a MAX232, to take care of
the voltage levels.

>I need a ready and tested UART-DESIGN for quick implementation.

If anyone finds a *decent* UART schematic, I would be very interested
to see it. The best I have seen to date is a cut-down UART in an old
Actel app note book. 

Now, if someone published a 16550, complete with the FIFOs... I did a
design (not a UART) a while ago, with a 24-byte FIFO in it, and after
heavy layout tweaks it filled a 3020. A 16550 in a FPGA would be the
world's most expensive UART :)

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4502
Subject: Re: What is the fastest fpga for ...
From: eteam@aracnet.com (bob elkind)
Date: Wed, 6 Nov 1996 11:05:51 -0000
Links: << >>  << T >>  << A >>
In article <55clpn$dod@news2.Belgium.EU.net>, Vincent.Himpe@ping.be says...
> I have a fairy simple circuit : a 24 bit counter with parallel load  
> The counter is hooked to a comparator which can either reset the counter  , or
> make it load a new value. In this way it forms a sequencer. This should be easy. 
> 
> now comes the tricky part: This counter needs to run at at least 60MHZ !.
> 
> I tried synthesizing it into a xilinx Xc4003 and XC4004 : no luck.
> It fits all right. But the maximum speed i can get is around 25 MHz. 
> 
> Are there any components out there that can do this ?

There are several options for addressing this design problem, some
of which have already been described by Ray Andraka and others.

When you're pushing the edge (any edge, be it density, heat, speed,
etc.) your design time tends to increase exponentially; and the
design tools aimed at speeding up design time (at the expense of
performance, density, power, etc.) become inappropriate.

So let's set the synthesis tools aside, for now.  This isn't the sort
of problem that is gracefully handled by synthesis tools.

Here are some approaches you can take for this problem:

1.  Pick the fastest component available for the job.  This may be
a Xilinx 4Kex, it may be a Lucent (formerly ATT) 2cXX ORCA.  Both
have dedicated carry acceleration facilities.

Traditionally, the ORCA parts have been faster and lower power
than their Xilinx 4K equivalents.  This may not be the case
right now, I haven't compared the latest available parts recently,
so I can't speak with certainty on this.

[Note: There *are* other FPGA vendors out there.  I mentioned the
two with which I am most familiar, and which I think are most
likely to provide a reasonable solution.  Comments are always
welcome!]

2.  Is this a one-off product that only has to work in a single
instance (rather than a volume-manufactured device)?  If so, then
you can be less concerned with worst-case timing across process,
temperature, and voltage.  If the timing verifier says it works
at 55 MHz, it will usually work at 60 MHz with nominal voltage,
and 25 deg C ambient air (with circulation).

This approach is totally unacceptable for a device that will be
duplicated many times over.  But that may not be your situation,
and you don't want to fight battles that don't really concern
you.

3.  Design architecture, specifically parallelism, should be
able to get you to your target.  How much parallelism needs to
be applied depends very much on the specific minimum requirements
of your application.  Without insight into these details, the
casual observers (and experts) in this newsgroup are handicapped.

Tradeoffs in the logic feeding this counter, or responding to the
counter, can be helpful in minimizing the design problem.

4.  Get some help.  If this is a commercial product, rather than a
"term paper" for an academic program, then it often pays to get help
from either an FPGA design hotshot in the company, or a "hired gun"
such as Ray Andraka, Phil Freidin, or one the many others who
contribute to this newsgroup (including myself, of course!).

The cost of the hired help is often tiny compared to the benefits,
which include...

  a.  a more reliable design
  b.  cheaper (smaller, slower, more available) FPGA, cheaper product
  c.  shorter schedule (get the design done on time, more predictably)
  d.  gain expertise from the expert, for next project(s)

As an added note, you may be able to get free design help from either
Xilinx or Lucent, if they think that your company's business is worth
their effort, and if they think you might otherwise go elsewhere.
Are you (potentially or currently) a key account?  I wouldn't
recommend "overstaying your welcome", but if you are in a position of
influence amongst your colleagues, then your satisfaction may be
a valuable asset to either vendor.

I hope this has helped.  Please follow up with the outcome of your
project.  These sorts of real-world problems are interesting to many
people, and posting the results is a genuine service to the
FPGA (and others) design community.

-- Bob Elkind

**************************************************************************
Bob Elkind                mailto:eteam@aracnet.com            CIS:72022,21
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: 4503
Subject: Re: PCB Handling of chip packages greater than 100 pins?
From: kgold@watson.ibm.com (K Goldman)
Date: 6 Nov 1996 14:15:11 GMT
Links: << >>  << T >>  << A >>

Manolis Stratakis <strataki@ics.forth.gr> writes:
|> 
|>         We are using Allegro to make several complicated PCBs for
|> our designs. We use extensively Xilinx FPGAs and other chips but up
|> to now we take care our chips not to exceed ~ 100 pins. Actually when
|> the package comes in any PGA we can handle it easily with our layout
|> software and our lab's facilities. But when it comes to greater chip
|> packages we do not have the necessary experience.
|> 
|>         Are there any pointers to info about the handling of these
|> monster chips? How about the PCB manufacturers, do they normally support
|> them? How does the package choice affect the total cost of the PCB?
|> It is true that at least for the Xilinx FPGAs the PGA packages tend to
|> be a lot more expensive than the respective PLCCs. I would expect this
|> to be especially true with the more complicated packages.
|> 
|>         Also are there any converter sockets available that would
|> convert a xxx (xxx = a difficult to handle) package to PGA? 

1 - We have been using Allegro for years with 200+ pin packages.  I
have never had a problem with a pin limit.

2 - Pin count should not matter at all to a PCB manufacturer.  Artwork
is just lines, vias, and pads.  Vendors here price PCB's based on
total area, number of layers, and design rules, but _not_ on the kind
of IC's on the board.

3 - There are convertor sockets from surface mount to PGA for many
packages.  Try Emulation Technology, Advanced Interconnections, and
Ironwood, or whomever you typically buy sockets from.

With some vendors you can send them your surface mount IC's and they will
send them back soldered to their PGA adaptor.

We sometimes create a PCB with both the PGA and surface mount pattern.
That way we can use the PGA or the surface mount with adaptor during
debug and then switch to the surface mount part for production without
changing the PCB.
-- 
Ken Goldman   kgold@watson.ibm.com   914-945-1466
Article: 4504
Subject: Re: XACT under WinNT is very slow
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 6 Nov 1996 15:43:07 GMT
Links: << >>  << T >>  << A >>
Peter,

> But this assumes you have RAM appropriate to NT, i.e. at least 32
> megs.

I have 80M, priorities are fine.  It's just that NTVDM (NT Virtual DOS
Machine) is a  layer within NT that are not in 3.1, 95, WFW, DOS etc.  This
overhead is there because NT is a protected environment, and this is what
causes this stuff to run slower.

> The only way PPR will be 2-4 times slower is if it is set-up to get
> say 50% of CPU time.

I have two identical (hardware wise, same CPU, disk, controller, video card
etc.) one running 3.1 and one running NT 4.0.  I ran PPR with the same
design, same seed as follows:  (no other significant tasks were running) 
The design is ~%65 of a 4013.

NT	-	CPU time taken for Partition:	0 hrs 18 mins 49 secs
		CPU time taken for Placement:	0 hrs 34 mins 35 secs
		CPU time taken for Routing:	0 hrs 46 mins 42 secs

Win 3.1	-	CPU time taken for Partition:	0 hrs   6 mins 30 secs
		CPU time taken for Partition:	0 hrs 29 mins 43 secs
		CPU time taken for Routing:	0 hrs 33 mins 53 secs

This is pretty conclusive to me, and is quite explainable.  As others have
said, WIR2XNF is really quite a bit slower.  This is because all I/O
instructions are emmulated and have to go through the 16-bit MS-DOS
emmulator. I haven't timed that yet.......I just read my e-mail.... 
 
There's a lot of information on NTVDM in the Windows NT 4.0 Resource Kit. 
A bargain at $69!

Austin Franklin
darkroom@ix.netcom.com

Article: 4505
Subject: Re: Info on FPGA Internal Architecture/ Programming
From: husby@fnal.gov (Don Husby)
Date: 6 Nov 1996 15:52:09 GMT
Links: << >>  << T >>  << A >>
Craig Slorach  craigs@elec.gla.ac.uk wrote:
>I'm looking for info on any FPGA's currently available where the internal
>architecture and programming information is known (ie. where I can write to
>programming registers myself instead of having to use manufacturers own
>tools).

Try Xilinx 6000.  According to one sales guy, specifiactions for their
internal architecture are available because they are intended to be used
for on-the-fly reconfigurability and things like genetic algorithms.


Article: 4506
Subject: References - FPGA to ASIC Conversion Vendors
From: "Keith E. Henry" <keh%pvision@mcimail.com>
Date: Wed, 06 Nov 1996 11:40:23 -0500
Links: << >>  << T >>  << A >>
If you have experience with any of the many FPGA to ASIC conversion
vendors and are willing to share your experiences, good or bad, I 
would greatly appreciate a reply.  Reply directly to me, and I will 
summarize (anonymously, if you like) to the group.

We have two small Xilinx designs, XC5202-5 and XC4003E-3, that we 
are considering converting, for lower cost.  Currently, our favorite 
vendors are ATS/Microchip, and SiQuest.

Anybody?

/keh
Article: 4507
Subject: Re: Info on FPGA Internal Architecture/ Programming
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 06 Nov 1996 10:07:07 -0700
Links: << >>  << T >>  << A >>
Well, well. 
Some people see a conspiracy at every corner.
But reality is different.
Designing place-and-route tools is a very demanding task. We have a
large software R&D group who has been working for years on the
development of such tools, and some of you may think that they still are
not quite perfect :-).
Our developers have of course access to all the detailed chip
information, and Xilinx puts many millions of dollars every year into
the development effort. 
I don't think we would do anybody a favor if we encouraged him ( or her
) to embark on an individual, underfunded development effort in an area
as difficult as this.
Just my opinion.

Peter Alfke
Article: 4508
Subject: Re: VHDL for Xilinx designs?
From: brenes@c2t.com (Erasmo Brenes)
Date: Wed, 6 Nov 1996 19:34:50 GMT
Links: << >>  << T >>  << A >>
In article <01bbc12f$d4b55d60$34c220cc@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes:
>every time if given the SAME inputs....but...how do you know what that
>logic is going to be?  Different compilers compile down to different logic.
> Since you don't know what it is going to compile down to, you don't know
>if it's good or bad...With a schematic, what you see is what you get...

I disagree. Once a VHDL module has been synthesized, you get a structural
net list which can be either read textually, or better yet, seen as a
schematic. I believe both Viewlogic and Exemplar provide you with such
capability (So does Synopsys, Mentor, etc.). So if your timing analysis
shows that your design isn't making it, then you can analyze the quality
of the synthesis.

>
>I agree too.  But how do you know what the compiler is going to do with the
>case statement, since different compilers will generate different results
>with the same VHDL code...
>

I guess that the crux of the matter is that you are worried about having
your HDL code be implemented differently by moving across compilers. I
believe that in most cases, aside from consultants ;-), a company sticks
to one compiler, not a variety and thus your issue becomes irrelevant.
But even in your case, as I stated before, you can tell the quality and
type of synthesis obtained by the compiler. How hard is it to determine
that the code synthesized into a CLA counter vs. a ripple one? Or how
hard can it be to be able to tell that the case statement has "ancillary"
stuff which should've been removed?. My experience in the synthesis arena
doesn't agree with your complain against the HDLs. I've been able to
determine the quality of the synthesis without much trouble.

>> Floorplanning is needed independent of the design entry method.
>
>Agreed, but with VHDL, you don't get intellegible names out of the code. 
>Also, when you change the design, the names change too.  At least that's
>the experience I have had.  There is a way around that....and when we do
>VHDL for designs, or our clients do, we do the design so it will give us
>consistent naming.
>

>
>There are a lot of self proclaimed Xilinx gurus out there, and self
>proclaimed gurus in general, but a bad engineer, with any tool, VHDL or
>schematic, is going to get bad results.  I spend half my life cleaning up
>other peoples bad engineering, and the other half doing what I believe to
>be good engineering from scratch (I don't get much sleep...).  The real
>truth is you have to know the device and the tools in order to do a good
>job.  BTW, who was this guru? (email, not in group please)
>
Agree 100%.


>schematics, or whatever, will lead to better results.  The tools for VHDL
>for FPGAs have been pretty poor until recently.  The EDA vendors have done
>a good job making their tools work with FPGAs recently.  I do believe that

My experience on the VHDL camp has been that my "efficiency" has increased
to the point that I can turn around a new design at a much higher rate than
a previously all schematic approach. The point I like to make is, that if
the design fits within the same size FPGA, and it meets the same system
performance, then I couldn't care if you got there by schematic or by 
HDL, and I also couldn't care how the synthesizer translated my HDL code,
since I've met the design criteria. I would pick the HDL path because it is 
more maintainable than the schematic, and easier to "read" for a lot 
bigger audience than the schematic. Also, not all schematics are created
equal. If the schematic is drawn such that it is a collection of gates,
it is unreadable, period. My experience has been that I find the same
idiosyncracies in the way designers draw schematics, as I see designers
write HDL code. In fact, you can tell if the HDL coder was a previous
schematic kind of guy, or a software-kind of guy by the code they produce.
One is more incline to write structural code than the other. :-)

>today, you can do a pretty good (near minimum resource utilization, and
>somewhat fast timing) design with VHDL.  Previously, VHDL used to cap out
>at 10Mhz (in a Xilinx 4k).  Today, because of better VHDL compilers, and
>faster parts, you can get 25+Mhz out of it.  I still don't think, nor have
>I seen, anyone be able to get near 33Mhz out of VHDL in a Xilinx 4k FPGA.
>

It depends on the type of application. I've done Xistink applications which
do operate on the 33MHz range, but were heavily pipelined. On the other
hand, I don't think that a random control logic design, either schematic
or HDL based would run in a Xistink any higher than upper 20s.

>I also think that data path in schematics (there is no optimization in data
>path...) is far better than in VHDL because you can see it.  You don't have
>to sift through pages and pages of code to figure it out.
>

I don't know what type of coding you've seen or used, but my experience
with VHDL is that if your code is hierarchical, then you can see the data
path in an even easier manner than with schematics since it is concen-
trated in one place. The same applies to schematics, in that if it is
hierarchical, then you can tell of all of the places that the data paths
reach, if not, then you have to sift through pages and pages of schematic
to tell where is the data path reaching.

>This appears to have been the liveliest discussion in this
>newsgroup....It's like the Mac is better than PC thing....

I'm glad that you've enjoyed the discussion, but I think that it is
more like assembler vs. C stuff. Both do the job, the question is
which one lets the designer be more efficient overall.

>

Erasmo
Article: 4509
Subject: A new vendor for Xilinx parts.
From: "Michael Holley" <holley@data-io.com>
Date: Wed, 6 Nov 1996 20:37:12 GMT
Links: << >>  << T >>  << A >>
I just saw a press release from Xilinx. They are discontinuing
some old XC4000 devices and the press release explains their
"customer-friendly product discontinuation policy". Xilinx 
provides 12 to 24 months notice for last-time orders of various products. 

The section I like is "In addition, Xilinx will use an 
after-life supplier that specializes in obsolete products to 
aid customers after the discontinuation date".

I guess you place your order with the Psychic Friends Hotline.

Michael Holley
holley@data-io.com

Article: 4510
Subject: Re: XACT under WinNT is very slow
From: no.bulk.mailing@thanks.com (Peter)
Date: Thu, 07 Nov 1996 08:12:37 GMT
Links: << >>  << T >>  << A >>


>NT	-	CPU time taken for Partition:	0 hrs 18 mins 49 secs
>		CPU time taken for Placement:	0 hrs 34 mins 35 secs
>		CPU time taken for Routing:	0 hrs 46 mins 42 secs
>
>Win 3.1	-	CPU time taken for Partition:	0 hrs   6 mins 30 secs
>		CPU time taken for Partition:	0 hrs 29 mins 43 secs
>		CPU time taken for Routing:	0 hrs 33 mins 53 secs

Austin,

The Partition time difference would suggest that this part of the
program is doing a lot of e.g. keyboard checking.

If a prog has a very tight loop, and within that loop is doing an
INT21 call to see if ctrl-c has been pressed, then that may well run
very much slower under NT.

Actually PPR also does the INT21 check, but apparently not so often. I
cannot account for the PPR slow-down any other way, because it really
is just CPU activity.

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4511
Subject: Re: UART FOR FPGAS
From: no.bulk.mailing@thanks.com (Peter)
Date: Thu, 07 Nov 1996 08:12:47 GMT
Links: << >>  << T >>  << A >>
Peter,

Yes, one could just reconfigure the FPGA to change the # of bits/word
etc. But there are lots of combinations

 7,n
 7,e
 7,o
 8,n
 8,e
 8,o

and then you have 1 or  stop bits. That makes 16 different configs 

And what about baud rate? You generally need at least
300/600/1200...115200 for modern comms products.

You would end up with an EPROM packed with different FPGA config
files. I really wish somebody did a proper UART, even if it had just
the standard 2-byte buffers.

Actually, the Zilog SIO was a very efficient design, which is why it
is such a pig to get it to work.

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4512
Subject: Re: Info on FPGA Internal Architecture/ Programming
From: Colin Carruthers <cc@xilinx.com>
Date: Thu, 07 Nov 1996 09:29:53 +0000
Links: << >>  << T >>  << A >>
The Xilinx XC6200 is a fine grain SRAM FPGA optimized
for dynamic reconfiguration.  Internal architecture and
complete programming info can be found in the datasheet...

	http://www.xilinx.com/products/fpgaspec.htm

Craig Slorach wrote:
> I'm looking for info on any FPGA's currently available where the internal
> architecture and programming information is known (ie. where I can write to
> programming registers myself instead of having to use manufacturers own
> tools).
> 
> Does anyone know of such an FPGA (from what I've found in the data books so
> far, they talk only about the tools supplied by vendors to produce the
> programming code).


---------------------------------------------------------------------
 / /\/ Colin Carruthers                E-mail: cc@xilinx.com
 \ \   Xilinx Scotland                 Tel:    +44 131 666 2600 x201
 / /   52 Mortonhall Gate              Fax:    +44 131 666 0222
 \_\/\ Edinburgh EH16 6TJ, Scotland
Article: 4513
Subject: Re: Info on FPGA Internal Architecture/ Programming
From: husby@fnal.gov (Don Husby)
Date: 7 Nov 1996 14:51:25 GMT
Links: << >>  << T >>  << A >>
Peter Alfke  peter@xilinx.com wrote:
> Well, well. Some people see a conspiracy at every corner.
> But reality is different.
> Designing place-and-route tools is a very demanding task. We have a
> large software R&D group who has been working for years on the
> development of such tools, and some of you may think that they still are
> not quite perfect :-).
> Our developers have of course access to all the detailed chip
> information, and Xilinx puts many millions of dollars every year into
> the development effort. 
> I don't think we would do anybody a favor if we encouraged him ( or her
> ) to embark on an individual, underfunded development effort in an area
> as difficult as this.
> Just my opinion.

  On the other hand, we have one example of a company that made the effort
to derive the "dark secrets" of xilinx internals and wrote their own
place and route tool.  Xilinx bought them out -- ostensibly because the
tools were BETTER than Xilinx's own tools, but probably equally as likely
to quash the competition.

  There are a lot of good hackers out there and they produce a lot of
good usable software.  For example the Gnu C compiler is pretty much an
industry standard now, it's better than much of the comptetition, and it's 
free.  There's no reason to assume that a similar effort couldn't produce a 
good place and route tool.  A free place and route tool would shut down a
lot of Xilinx's business.  The word "conspiracy" has a lot of bad 
connotations, so maybe a better phrase might be "conservative business 
practices". 


Article: 4514
Subject: VHDL synthesis tools?
From: mike.kopp@gtri.gatech.edu (Mike Kopp)
Date: Thu, 07 Nov 1996 14:13:24 -0500
Links: << >>  << T >>  << A >>
We are looking at doing more VHDL synthesis and are therefore looking at
tools.  We are interested in using VHDL for everything from simple PAL
designs to complex FPGAs.  We would prefer to only use one tool to do all
(or most) of our parts and we would like the tool to be PC based and
interface with ViewLogic which we currently use for all schematic
capture.  

We have the ViewLogic WVOffice ViewSynthesis but have not yet used it. 
Can anyone comment on how well it performs?  Any suggestions as to vendors
to particularly look at?

-- 
Mike Kopp
GTRI/ELSYS/SEN
Article: 4515
Subject: Altera contract in Orange County
From: reginas@cts.com (Regina Steurer-Hall)
Date: Fri, 08 Nov 1996 00:41:53 GMT
Links: << >>  << T >>  << A >>
I apologize if this is not the proper newsgroup for this posting but I
have a 2-month Altera contract in Orange County but you need to be
familiar with AHDL.  If interested please email me at neilh@tlcsd.com
or call at 800/275-4852x228

Thanks.  Neil Hutchison/Technology Locator Corporation
Regina Steurer-Hall, Resource Manager
Technology Locator Corporation
6480 Weathers Place
San Diego, CA  92121-3912

Voice: (800)275-4852
Fax:   (619)552-6820
Email: reginas@tlcsd.com
http://www.tlcsd.com
Article: 4516
Subject: Re: PCB Handling of chip packages greater than 100 pins?
From: Calum MacGregor <calum@econnect.demon.co.uk>
Date: Fri, 8 Nov 1996 09:36:25 +0000
Links: << >>  << T >>  << A >>
In article <32803DAE.167EB0E7@ics.forth.gr>, Manolis Stratakis
<strataki@ics.forth.gr> writes
>Hello,
>
>        We are using Allegro to make several complicated PCBs for
>our designs. We use extensively Xilinx FPGAs and other chips but up
>to now we take care our chips not to exceed ~ 100 pins. Actually when
>the package comes in any PGA we can handle it easily with our layout
>software and our lab's facilities. But when it comes to greater chip
>packages we do not have the necessary experience.
>
>        Are there any pointers to info about the handling of these
>monster chips? How about the PCB manufacturers, do they normally support
>them? How does the package choice affect the total cost of the PCB?
>It is true that at least for the Xilinx FPGAs the PGA packages tend to
>be a lot more expensive than the respective PLCCs. I would expect this
>to be especially true with the more complicated packages.

From the perspective of PCB manufacture, we make pretty much whatever
you design, and 256 pin devices are not unusual.

PCB manufacturing costs are determined by:

        Number of layers
        Board Size
        Track Width + Gap
        Minimum drill size

Roughly in that order. So the impact on cost will depend on your design.

It is possible htat the cost of the test fixture can increase.

Cheers!
 
Calum MacGregor
Electroconnect Ltd. + 44 (0)1294 221360     <calum@econnect.demon.co.uk>
Design . Fast turn PCB . Flexi-rigid PCB . SMT Assembly . Laser Stencils
Article: 4517
Subject: Integration, the VLSI journal
From: saouter@irisa.fr (Saouter Yannick)
Date: 8 Nov 1996 11:32:54 +0100
Links: << >>  << T >>  << A >>

This article is devoted to explain the
problems I had to submit an article to
Integration, the VLSI journal. I write it
in those newsgroups because I mailed my
complain to the managing editor who does
not seem to care about it. If this topic,
does not interest you, please skip. If you
have remarks, please better e-mail me to
"Yannick.Saouter@irisa.fr" since I am not
a regular reader of this newsgroup. I do
not like the proceeding of multiple
crosspostings but I find it here necessary.
The newsgroups were chosen for their subject
of VLSI architectures and parallelism in
general.

I would like to tell you about a story which
happened to me. In August 1994 I sent an
article for submission at "Integration
the VLSI journal". The subject was about
VLSI systolic arrays. The script was sent to
Marion de Vlieger who routed it to Ed
Depreterre, who is in charge of the architecture
topic in this journal. For those who do not this
journal, the typical deadline between submission
and first reading report is about 6 or 8 months.
After one year I e-mailed a message to Marion de
Vlieger in which I ask her to inform me about
the status of the referee process. She replied
me that she will look after the problem. I
had then no answer from her. Six months later
I e-mailed a new letter in which I asked her
again about the referee process. This time
she simply ignores my e-mail. Three months
later I e-mailed her again this time being
much more insisting. Always no reply. Two
months later, I sent an e-mail message to
Ed Depreterre, in which I also ask for
information about the referee report. He
said to me that he was going to see what
was going wrong and that I will have soon
information. One month later (this lead here
to two years delay from first submission),
since I still have no information I wrote
an energetic e-mail to him in which I was
demanding information. He replied then
that the report was ready and that he would
post it before the end of the week. I
effectively received it several weeks later.
He was signed by professor Otten managing
editor of Integration.
The main conclusion of the report was that
it was refused to submission and in fact
definitively (i.e. no corrections suggested).
However the problem is not here: I may accept
that some of my articles are immature to be
submitted. The real problem is the invoked
reasons for that.

The main reproaches were:

- My article was illegible and contains many
english errors (English is not my natural language).
To my knowledge my english expression might be 
heavy but Integration and other publications are
not supposed to be written in pure shakespearian
style. In anyway, my article before being sent
was read and corrected by a professional translator.

- Some references of previous works were missing. Although
this remark was legitimate, the referee cited some persons
who never worked on the precise topic investigated by my
article.

- My article was out of date because the solution of one
problem that I was heuristically investigated is in fact well
known. At first the problem I was dealing and the problem
treated by the article cited were not exactly the same and
thus this article, although legitimate to be cited in my article
was in fact useless for my problem. Moreover, the first
version of this article was published as technical report
in May 1996, so nearly two years after my submission!

- Some of the theorems I claimed in my article were in fact
false. At no place in the report, I had a mention such
that "this theorem is false because ...".

Moreover, several reproaches can still be made about
Integration:

- My script was seemingly read by a unique referee that is
contrary to most rules in scientific publication.

- The referee seemingly waited two years before to make
the report (since he was aware of the work of May 1996) and
was not hunted out by the editors.

- The referee was likely of bad will or absolutely incompetent:
he cannot understand "optimization of number of processors of
VLSI arrays" as "minization", seem to ignore that euclidean
spaces may contain points as well as vectors, etc ...

So my global conclusion is the following one: if you want that
your work is published in the scientific community:

DO AVOID INTEGRATION THE VLSI JOURNAL, ESPECIALLY IN THE AREA
OF VLSI ARCHITECTURES.

Its staff seems to do his work in spite of the common sense. At
least in my personal case it seems that Marion de Vlieger, Ed
Deprettere and Pr. Otten did not have the faintest will to deal
seriously my request of submission.

Article: 4518
Subject: Re: Integer Multiplier
From: Neal Becker <neal@ctd.comsat.com>
Date: 08 Nov 1996 10:03:39 -0500
Links: << >>  << T >>  << A >>
>>>>> "tendy" == tendy the <tthe@aesprodata.com.au> writes:

    tendy> Dear all,
    tendy> Could any one please advise me about the most compact and fastest
    tendy> implementation / algorithm of 16 bit-integer-multiplier. I intend to use
    tendy> the Xilinx XC4000 series or the Altera Flex10K. Many thanks !

 Your requirements are contradictory.
Article: 4519
Subject: behavioural VHDL "BUS MATCHING"
From: Giunt <giuntella@roma1.infn.it>
Date: Fri, 08 Nov 1996 17:03:20 +0100
Links: << >>  << T >>  << A >>
Hi,
   Does anyone have some information about simple behavioural VHDL
description of "bus matching" (32 bit to 8 bit and viceversa)device?
I use a Flex 10K50. 

Thank you.
Matteo Mascagni
I.N.F.N. Roma1
Article: 4520
Subject: Re: Actel Designer and Win NT 4.0
From: Tom Bowns <bowns@data-io.com>
Date: Fri, 8 Nov 1996 16:21:40 GMT
Links: << >>  << T >>  << A >>
Jeffrey C. Marden wrote:
> 
> Hello:
> 
> Is anybody using the Actel Designer tools with Windows NT v4.0

I assume you mean Designer 3.1. We had to get some info from their apps
group to set it up properly, though. Special attention needs to be given
to the setup of the ObjectStore Server in order to make it available as
a service.

I suggest calling them. The number's on the back of any of their
manuals.

-TBB
Article: 4521
Subject: Re: Info on FPGA Internal Architecture/ Programming
From: Tom Bowns <bowns@data-io.com>
Date: Fri, 8 Nov 1996 16:38:49 GMT
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> As far as I'm aware
> all FPGA manufacturers still seem to treat this info as a dark
> secret. This probably stems from the early days of FPGAs where the
> market was so small that the vendors thought the only way to make any
> money was to charge the earth for highly vendor specific tools. 

I would have to disagree with this.

I think primarily it comes of the fact that if a vendor releases a
specification for programming a device, that specification would
necessarily contain enough information for a competitor to be able to
fairly easily reverse-engineer the device and come up with a clone and
steal sockets.

-TBB
Article: 4522
Subject: Re: What is the fastest fpga for ...
From: David Emrich <emrich@exemplar.com>
Date: Fri, 08 Nov 1996 10:32:49 -0800
Links: << >>  << T >>  << A >>
Vincent Himpe wrote:
> 
> hi
> 
> I have a small problem.
> 
> I have a fairy simple circuit : a 24 bit counter with parallel load
> The counter is hooked to a comparator which can either reset the counter  , or
> make it load a new value.
> In this way it forms a sequencer.
> This should be easy.
> 
> The entire design has some additional registers but these are very low speed.
> A Verilog (Synopsys) file is available.
> 
> now comes the tricky part: This counter needs to run at at least 60MHZ !.
> 
> I tried synthesizing it into a xilinx Xc4003 and XC4004 : no luck.
> It fits all right. But the maximum speed i can get is around 25 MHz.
> 
> Are there any comonents out there that can do this ?.
> After all , i can make the entire circuit with some 74Fxxx series ttl chips....

Vincent,

I can't tell you the fastest FPGA - all the leading FPGA vendors offer
some very fast devices.

In fact I got 69MHz performance for a circuit like the one you described
in an ORCA 2ca-4 device.  The load to the counter was registered - I
doubt you could do it otherwise.

This is NOT a benchmark, and I am not saying this device is fastest,
but it is more than enough for the circuit you described.

In this design, Exemplar's Leonardo detects a loadable counter and a
24 bit comparator.  And implements a very fast one of each for the technology
you select.

I you are interested in the design file I used, or the AT&T foundry script,
timing report, etc. - send me email by 11/15/96 - I won't keep this stuff long.

Regards,
David Emrich
Exemplar Logic
Article: 4523
Subject: Re: PCB Handling of chip packages greater than 100 pins?
From: ronxs@dgsys.com (RSES)
Date: 8 Nov 1996 19:32:59 GMT
Links: << >>  << T >>  << A >>
: In article <32803DAE.167EB0E7@ics.forth.gr>, Manolis Stratakis
: <strataki@ics.forth.gr> writes
: >Hello,
: >
: >        We are using Allegro to make several complicated PCBs for
: >our designs. We use extensively Xilinx FPGAs and other chips but up
: >to now we take care our chips not to exceed ~ 100 pins. Actually when
: >the package comes in any PGA we can handle it easily with our layout
: >software and our lab's facilities. But when it comes to greater chip
: >packages we do not have the necessary experience.

We're using the Xilinx XC3090A with 160 pins and the XC3042A 100 pins quad
flat package without any problem (a few of each on the same board). 
There are no major design problems and manufacturers do not get excited
from the .25mm gaps anymore..... You might want to pay attention to the
width of the power and ground traces if it gets too dense, but other than
that... it is 'a walk in the park'.... well.....

*************************************************************************
* Desire, Discipline,        | Ron Spiegel, a.k.a. iRon                 *
* Dedication, Determination, | System Administrator & a Design Engineer *
* No Excuses.....            | RSES - Cutting Edge Design Technologies  *
* Shut Up and Train!         | Washington DC, U.S.A.                    *
*----------------------------+------------------------------------------*
*   ronxs@dgsys.com  |  ron@rses.com  |  http://www2.dgsys.com/~ronxs   *
*************************************************************************
Article: 4524
Subject: US FPGA Engineers
From: "Kevin T. Hawes" <khawes@tiac.net>
Date: Fri, 08 Nov 1996 16:06:46 -0500
Links: << >>  << T >>  << A >>
Systems Pros, Inc. is looking for ASIC & FPGA Engineers. If you are 
interested or know of someone who may be, I can be contacted as follows:

Kevin T. Hawes, Direct Placement Manager
Systems Pros, Inc.
164 Westford Road, Suite 2
Tyngsboro, MA 01879

Phone:	(508)649-2210
FAX:	(508)649-4213
E-mail:	khawes@tiac.net

If sending a resume to my e-mail, please send a TEXT formatted file.


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