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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 1325

Article: 1325
Subject: AT&T serial EEPROMS
From: husby@fnal.gov (Don Husby)
Date: 1 Jun 1995 20:26:18 GMT
Links: << >>  << T >>  << A >>

  We recently switched to AT&T serial EEPROMS (17128) instead of Xilinx 
(one-time programmable) PROMS for configuring a 4005A chip.  The AT&T part 
seems to blow the configuration about 50% of the time.

  Does anyone know of problems with these parts?



Article: 1326
Subject: VIRTUAL REALITY
From: mediacan@supernet.ab.ca
Date: 1 Jun 1995 22:10:18 GMT
Links: << >>  << T >>  << A >>
Virtual Reality Headsets!

Now Available!

$ 1299  (CDN)

Dealers are Welcome

(PH)    403-496-9830
(FAX) 403-437-9798
(E-Mail) mediacan@supernet.ab.ca

Here are a few of the games that are supported......

Doom			Doom II			Descent
Magic Carpet		Blake Stone		Spear of Destiny
Slipstream		Dark Forces		Tank Commander


Call or E-Mail now for more details.......


Article: 1327
Subject: Re: ABEL optimization
From: miker@megatek.com (Mike Reeves)
Date: 01 Jun 1995 23:41:55 GMT
Links: << >>  << T >>  << A >>
>>>>> "Tom" == Tom Bowns <bowns@Data-IO.COM> writes:

    Tom> In article <MIKER.95May26181740@sunburn.megatek.com>
    Tom> miker@megatek.com (Mike Reeves) writes:
    >>  Try compiling this simple little file. ABEL's unable to
    >> optimize signals la4..la7 as 1. It does produce a working
    >> equation (cond1 & st2); however, this failure to optimize
    >> between states can lead to some lengthy equations for a complex
    >> state machine. (@DCSTATE/@DCSET doesn't change this) As a
    >> result I'd recommend avoiding ABEL's "with" statement.
    >> 
    >> ---cut here--- module JUNK
    Tom>    [ ABEL source not included ]

    Tom> Mike -

    Tom> I'm not sure if I perhaps misunderstood your post, but
    Tom> running the design through ABEL 6.0 I believe shows correct
    Tom> compilation and reduction.

[deletions...]

    Tom> Thus, these reduced equations provided by ABEL 6.0: la0 :=
    Tom> (0); la1 := (0); la2 := (0); !la3 := (1); la4 := (cond1 &
    Tom> st2); la5 := (cond1 & st2); la6 := (cond1 & st2); !la7 :=
    Tom> (!cond1 # !st2);

These are the result I obtained as well. I was dissapointed to see
la5 reduced to (cond1 & st2). la5 was declated as 'dc', i.e. unspecified
logic is don't care. Being that la5 was only specified in 1 state, I
hoped it would have reduced to 1. Likewise, la7 was declared as 'neg',
i.e. unspecified logic is 1. I concluded (please correct me if I'm 
wrong), that the abel compiler is not intelligent enough to optimize 
mealy outputs across states. 

--
   Michael G. Reeves          email:     miker@megatek.com
   Megatek Corporation        voice:  (619) 675-4300 x2663
   16868 Via Del Campo Court  facsimile:    (619) 675-4341
   San Diego, CA  92127
	


Article: 1328
Subject: Re: Any company for conversion FPGA to ASIC?
From: ????@igs.net (Your Real Name)
Date: 2 Jun 1995 02:21:25 GMT
Links: << >>  << T >>  << A >>
In article <3qcpuk$8ip@dartvax.dartmouth.edu>, jeff_cunningham@fostex.com 
says...
>
>In article <3qbot9$oge@noc.sait.samsung.co.kr>
>backfire@saturn.sst.co.kr (baik jong sung <4224>) writes:
>
>> By the way, is there anybody who knows a company which
>> provides FPGA-to-ASIC conversion services ?
>> That is, I have some control logic designed by several
>> EPLD(5-Altera EPM7064QC100). But I have to convert these
>> chips to one-chip of ASIC, for example, LSI, Toshiba, etc.
>
>Orbit Semiconductor, ATS (Advanced Technical Solutions) & AMI all do
>turnkey FPGA conversions. I would guess all three could convert the
>chips you mention into a single ASIC. In the case of the first two, you
>need to supply full production test vectors. In the case of AMI, you
>can opt to just give them functional test vectors and they will (for a
>fee) insert scan elements and generate production test vectors
>themselves. AMI will also (for a fee) automatically add full JTAG
>boundary scan.
>
>-Jeff.

I would be interested to hear from anyone who has had experience with 
these three companies and also Matra MHS or Chip Express.
We use many FPGAs today in quantities of less than 1000 per year 
which makes it uneconomical to go the traditional ASIC route where they
prefer quantities of 10,000 per year.
Are there companies other than the five mentioned above who might be 
interested in low volume ASICs? 100 to 1000 per year.
Our thinking is to design FPGAs first for protype then move to an ASIC to
reduce cost and potentially increase perforrmance of the final product.

Comments appreciated.

Thanks in Advance.

Jing Kwok
 



Article: 1329
Subject: Re: Appologies : Any company for conversion FPGA to ASIC?
From: jkwok@igs.net (Jing Kwok)
Date: 2 Jun 1995 03:31:44 GMT
Links: << >>  << T >>  << A >>
Appologies to all. It appears that I have not configured my address 
properly. Please forgive the newcomer. Thanks.
Jing Kwok
jkwok@igs.net


In article <3qlsj6$a7@nntp.igs.net>, ????@igs.net says...
>
>In article <3qcpuk$8ip@dartvax.dartmouth.edu>, jeff_cunningham@fostex.com 
>says...
>>
>>In article <3qbot9$oge@noc.sait.samsung.co.kr>
>>backfire@saturn.sst.co.kr (baik jong sung <4224>) writes:
>>
>>> By the way, is there anybody who knows a company which
>>> provides FPGA-to-ASIC conversion services ?
>>> That is, I have some control logic designed by several
>>> EPLD(5-Altera EPM7064QC100). But I have to convert these
>>> chips to one-chip of ASIC, for example, LSI, Toshiba, etc.
>>
>>Orbit Semiconductor, ATS (Advanced Technical Solutions) & AMI all do
>>turnkey FPGA conversions. I would guess all three could convert the
>>chips you mention into a single ASIC. In the case of the first two, you
>>need to supply full production test vectors. In the case of AMI, you
>>can opt to just give them functional test vectors and they will (for a
>>fee) insert scan elements and generate production test vectors
>>themselves. AMI will also (for a fee) automatically add full JTAG
>>boundary scan.
>>
>>-Jeff.
>
>I would be interested to hear from anyone who has had experience with 
>these three companies and also Matra MHS or Chip Express.
>We use many FPGAs today in quantities of less than 1000 per year 
>which makes it uneconomical to go the traditional ASIC route where they
>prefer quantities of 10,000 per year.
>Are there companies other than the five mentioned above who might be 
>interested in low volume ASICs? 100 to 1000 per year.
>Our thinking is to design FPGAs first for protype then move to an ASIC to
>reduce cost and potentially increase perforrmance of the final product.
>
>Comments appreciated.
>
>Thanks in Advance.
>
>Jing Kwok
> 
>



Article: 1330
Subject: Re: AT&T serial EEPROMS
From: Phillip Roberts <proberts@rmii.com>
Date: 2 Jun 1995 05:45:24 GMT
Links: << >>  << T >>  << A >>
husby@fnal.gov (Don Husby) wrote:
>
> 
>   We recently switched to AT&T serial EEPROMS (17128) instead of Xilinx 
> (one-time programmable) PROMS for configuring a 4005A chip.  The AT&T part 
> seems to blow the configuration about 50% of the time.
> 
>   Does anyone know of problems with these parts?
> 
 I have had very similar problems with AT&T EEPROMS. After consulting
with AT&T they faxed my company a document stating that the proms do
not work properly when the power supply rise time exceeds a certain 
amount. This was confirmed by our customer by unplugging some board
from his system. Where upon the gate arrays loaded properly. Sometimes
the done signal would go high yet the gate arrat would be programmed 
incorrectly!
  Our solution was to quit using the EEPROMS for production and for
any application with high current demand.

	phil
	proberts@rmii.com




Article: 1331
Subject: Re: Latch up in Xilinx 3000 Series FPGA's. Part smokes & smells bad.
From: jgriffit@nyx10.cs.du.edu (Jonathan Griffitts)
Date: 2 Jun 1995 00:25:24 -0600
Links: << >>  << T >>  << A >>
dstarr@world.std.com (David J Starr) writes:

>  We are having trouble with latchup using Xilinx 3090/3190 160 pin
>parts.  When it happens the part is toast.  It will draw a couple of amps at 
>5 volts and get hot enough to burn your fingers.  We have had three or
>four parts do this, out of 10 or 12 parts overall.  It seems to happen on
>1st power up, before we can even program the part with Xchecker.  The
>board only has 5 volt power and is running by itself on the bench.  One
>part went poof before any test equipment was connected.  Signals look
>pretty clean, nothing rings very far below ground, or above vcc.  Any
>hints, suggestions or experiences would be appreciated.  Are these parts
>really that tender?  Or is there something we don't understand? TIA.
>David J. Starr

On several occasions I've toasted XC3000 family parts by feeding them
faulty configuration bitstreams.  What I mean is bitstreams that are
just totally invalid due to some procedural error or bad ROMs.
Apparently an illegal configuration can cause the parts to draw lots
of power and overheat rapidly. 

Any chance your parts are getting bad configurations somehow?  Perhaps
if the config input pins (CCLK, etc) are floating, the parts are
pulling config data out of thin air?

				Jonathan Griffitts
				AnyWare Engineering
				Boulder, CO
				(303) 442-0556
				jcg@aurora.com or jgriffit@nyx.cs.du.edu
-- 
			   --JCG
AnyWare Engineering, Boulder CO
303 442-0556  (voice or FAX)


Article: 1332
Subject: Re: AT&T serial EEPROMS
From: msnook@armltd.co.uk (Mark Snook)
Date: 02 Jun 1995 07:36:17 GMT
Links: << >>  << T >>  << A >>
I only recently became aware of the AT&T serial EEPROMS, but as a
general point are there any other alternatives to Xilinx serial PROMs
for programming Xilinx parts.

Who else makes suitable serial devices, and how do they compare on
price/size etc?

Mark
(mark.snook@armltd.co.uk)


Article: 1333
Subject: Biblical Influences At PLD Con/WinEDA '95
From: jcooley@world.std.com (John Cooley)
Date: Fri, 2 Jun 1995 08:09:04 GMT
Links: << >>  << T >>  << A >>

   !!!     "It's not a BUG,                           jcooley@world.std.com
  /o o\  /  it's a FEATURE!"                                 (508) 429-4357
 (  >  )
  \ - /         
  _] [_          "Biblical Influences On PLD Con/WinEDA '95"
                                  - or -
 "One Engineer's Impressions Of The Recent Combined PLD Con '95 & WinEDA '95"
          April 25-27, 1995, Santa Clara Convention Center, Calif.

                       by John Cooley, the ESNUG guy

        Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222


Deuteronomy 20:13-14
--------------------

At dinner the first day of the conference (tutorial day) some of the Silicon
Valley denizens told me about a quote that T.J. Rogers, CEO of Cypress
Semiconductor said when asked about competing against AMD in front of a
bunch of reporters.  I'm told he said: "We will burn down their houses, rape
their women and dance on the bones of their dead children!"  (Not at all
unlike Deuteronomy 20:13-14, "And when the Lord your God delivers [an enemy
city] into your hands, you shall strike every male in it with the edge of
the sword.  But the women, the little ones, the livestock, and all that is
in the city, all its spoil, you shall plunder for yourself."

And I thought the EDA business was cutthroat!


Num 13:2 "Send Men To Spy Out The Land Of Canaan,"
--------------------------------------------------

Once the actual exhibit floor opened, I bumped into a few engineers to get
initial impressions.  The first engineer said he was disappointed that Xilinx
and Altera both decided not to show up at the conference.  (Although the news
that Synopsys & Cadence [both VHDL vendors] blew off exhibiting at the recent
San Diego VIUF was hot gossip in the VHDL community, it didn't sour their
customers like the Xilinx noshow at PLD Con.)  A second engineer said, "Yea,
I find it kind of insulting.  I flew in and Xilinx couldn't bother to come
down the street to be here."  Watching a Xilinx marketing person step onto
the exhibit floor, a third engineer confided: "But they do seem to have the
time to spy on their competition, though."  I grabbed the Xilinx marketing
guy and asked why the noshow.  He told me that PLD Con was too expensive from
a cost per lead, etc.  (A forth engineer later told me this was bunk; PLD
Con was pricey for Xilinx the prior year because they made it so.  "They gave
away a $6700 Kawasaki Ninja ZX-6 motorcycle plus had a mammoth booth then.
Also, they're putting on their own roadshows so they can surround new customers
with Xilinx-only propaganda.")


Lazarus & The Book of Job
-------------------------

Quite a few people were surprized to see Gabriele Saucier's Innovative
Synthesis Technologies (IST) with a booth.  (Gabriele, the CEO of IST, is a
noteably fiesty & outspoken older French woman who wears those funky wire
frame glasses popular in Europe.  She sort of reminded me of a French
version of "Granny" from "The Beverly Hillbillies" but w/ a PhD in synthesis.
Not shy & very much a go getter.  Interesting to talk to.)  She related a
story that could be taken straight out of the Book of Job.  Everything was
going fine with the new American office of IST.  Then suddenly $5 million in
Venture Capital money didn't come through.  Within days the three American
executives (CEO, VP of Sales, and CFO) all resigned after having FAXed to the
IST Sales Partners that the IST source code was up for sale followed by a
sudden closure of the American office.  "Our position was to survive at any
price because this software belongs to Europe.", noted Gabriele, "Now things
are looking better."

Another surprize was to see FPGA vendor Crosspoint Solutions, Inc. raised
from the dead like Lazarus (by big money Japanese investors) at PLD Con.
They were giving out free boomerangs with "We're Back!" painted on them.


Moses, Pharaoh, Christ Entering Jerusalem
-----------------------------------------

The odd effect of this boycott by the two largest PLD vendors, Xilinx and
Altera, was that it created a Xilinx bashing atmosphere.  Mike Dini, a
rather well known FPGA design consultant, seemed to be cast in the role of
"Moses" leading the FPGA buying community out of Xilinx bondage with Curt
Wozniak (President of Xilinx) playing the part of "Pharaoh."  In his tutorial
on high speed design with programmable logic, Dini blasted into Xilinx with
"I can't find a solution from Xilinx that I can't find better implemented
elsewhere." and proceeded to discuss all the Quicklogic, Actel, Altera, AMD,
Cypress and AT&T ORCA parts in detail.  Someone in the audience noted that
Xilinx has gone from owning 84% of the PLD market down to 62% currently.
Later on, Dataquest analyst Gary Smith said: "As designs get larger, Xilinx
loses its advantage.  Xilinx used to make sales based on the fact that it was
reprogrammable.  Engineers could fix the mistakes they made on the same chip
instead of burning new chips.  Now, with large designs, chip costs are noise;
if you find mistakes you're talking weeks of expensive debug time."

The other odd effect of this Xilinx boycott of PLD Con was that the AT&T ORCA
team was greeted like Christ entering Jerusalem; engineers were wildly
ecstatic chanting "Hosanna! Hosanna!" while waving palms branches in the air
at the idea of having a viable competitor (& savior) to Xilinx in the mondo
big FPGA market.  One engineer told me: "Those AT&T guys do 0.01 micron 11
layer metal fab as a weekend hobby when they're bored.  We're talking serious
high speed, big FPGA's here!"  (Ironically, AT&T ORCA has this positive image
*despite* the best efforts of their sales force.  I've heard a few reports
that they don't return phone calls unless they know you're going to buy at
least $0.5 to $1 million worth of product -- they're small customer hostile!)


Christ Feeding The 5000
-----------------------

Unlike the standard Data I/O "Unisite" that so many engineers know from their
one-at-a-time PLD programming days, the big competition in the PLD programmer
world is in tacking the words "Universal" and/or "Gang" onto their current
product offering.  (The U-word stems from a growing variety of new & different
programmable devices, each with their own special programming quirks, coming
out *daily*.  The G-word comes from the overwhelming number of flavors and
revisions that now require programmers to, amongst other things, read the
silicon signature of each device they program.  It used to take 1 - 3 seconds
to burn a single 22V10.  Now a simple Altera EPM7032, which replaces four
22V10's, can take anywhere from 8 to 24 seconds to program!)

What's driving this further?  Low prices made PLD's *too* popular.  Like
how Christ fed the 5000 with 5 loaves a bread and 2 fish, customers now want
thousands of quickly made copies of a few golden programmed PLD's overnight.
All of the wild claims, counter claims & marketing B.S. put out by the five
major players in this market (Data I/O, Logical Devices, SMS, System General,
and BP Microelectronics) was too much for this engineer to wade through -- if
you want to know more, call them yourselves!


Daniel & The Lion's Den
-----------------------

The biggest EDA news brought quite a few curious on lookers to the Escalade
booth.  It's common knowlege that Escalade isn't running like your usual
Silicon Valley start-up.  They have wads of Venture Capital money to play with
but they're burning it up at a fast rate with around 40 employees -- many
of them high priced heavy hitters in the EDA industry.  This burning the
candle at both ends means that in two years either Escalade products will
be everywhere or the company will be another story that EDA kibitzers share
over beers.  "I think ESDA tools like Escalade's are terrible.  With all this
high level diagram entry stuff I can't control from diagram to HDL to
synthesis to final place & route with any accuracy.", says Dini, "Understand
that I'm an old school designer; I'm on the teetering edge of designing high
speed FPGA's."  On the other hand, Actel just gave Escalade $1 million to
develope Actel-specific functionality in Escalade tools.

At lunch, analyst Rita Glover and I had a little fun exchanging barbs on the
Cadence Spectrum business model and the Cadence/Unisys deal.  She related
an analogy of how Hollywood works with skilled people beautifully drawn
together by one studio just for one movie.  I retorted with: "And how many
Hollywood movies have you seen come in on time and on budget?"

The other big news in the EDA industry was ex-Mentor synthesis guru Ken
McElvain finally put his Synplify synthesis tool up for public scrutiny.
(Synplify is unusual in that it has *no* command switches; just a window to
point to your source Verilog/VHDL, another where you want gates out & a START
button.  Also, they claim compile times 10x to 100x faster than anyone else.)
Hoping this public debute would be a clarion call for customers, Ken also
found himself surrounded like Daniel in the Lion's Den by synthesis R&D types
from Mentor, Cadence, ViewLogic, Synopsys, Exemplar, Minc, Synario, and
Intergraph -- all asking detailed questions that Ken wasn't going to answer.

At dinner after the last day of the show, Ken said: "I've got to get working
on having Synplify support AT&T ORCA.  I was swamped with requests for it."


Divide & Conquer
----------------

Alexander The Great once built an empire based on the strategy of "divide and
conquer."  Although this year's attendance of around 1600 people matched last
year's attendance; it *seemed* like there were slightly fewer people there
because the conference suffered from serious "divide and conquer."  That is,
at any one time I had literally *eleven* different places to be.  PLD Con
had 3 full tracks, WinEDA had 3 full tracks; there was the Exhibit Floor,
"ApNotes Live!" (2 tracks), and personal time to talk one-on-one, (plus the
Press track.)  Even the Plenary Session was given by *three* Bigwig speakers!
If old Alex was at PLD Con / WinEDA he would have been proud to see how his
tactics had survived the test of time in making a full conference seem "lite."

Stan Baker, the conference chairman, said: "Five years ago PLD's were new
& curious things by themselves.  Now they've gone mainstream so we wanted to
make PLD Con/WinEDA have hot niche tracks that engineers would find useful for
their careers.  That's why we had papers in diverse topics like basic HDL's &
state machine design all the way up to stereo machine vision, PC buses, DSP,
and reconfigurable computers.  We don't want to go the way of the old National
Computer Conference that died once the novelty of computers went away."


Tower of Babel
--------------

At last year's PLD Con, all the PLD silicon marketing managers took a page
straight out of the book "How To Lie With Statistics" proving that *their*
chips "won" in the PREP benchmarks.  (Fun phrases like "Hypergeometeric mean
used." could sometimes be found in the fine print, if there was fine print!)
Apparently all these adventures in mathmagic land were deemed futile because
this year's PLD Con Exhibit Floor vendor propaganda was markedly devoid of
*any* references to PREP benchmarks...

On the Exhibit Floor, four companies did the star-crossed-lovers routine by
intentially having booths next to each other.  (OrCAD & Massteck; because
OrCad bought Massteck.  AMD & Minc; because Minc cut a deal to do AMD's
software.)

Murray Disman, Editor, "Programmable Logic News & Views", related a cautionary
to watch the sales staff of acquired companies.  Texas Instruments (TI), when
it was in the 2nd source for Actel business, made it a goal to agressively go
after Actel accounts by undercutting prices.  Actel bought out TI, but,
knowing this, the TI sales force went on a frenzy of booking long lead orders
at super cheap prices to land hefty commissions before their division went to
Actel.  As a consequence, Actel was marginally profitable with Q1/95 sales
down 6% and lots of TI sold obligations on the books.  Disman said: "Actel
got hurt by something they should have forseen."

As primarily a dyed-in-the-wool ASIC designer, I was caught off guard with
the acceptance of Verilog in the FPGA world.  (The press & the paid industry
spin doctors liked to create the impression that FPGA design was exclusively
VHDL country.)  Quotes from FPGA designers like Mike Dini of "I prefer
Verilog.  I have struggled with VHDL and I don't like it.  Any language that
doesn't have a structure for flip-flops or basic logic wasn't meant for
hardware design." came up quite a few times.  (Actually I was knocked over
with the Tower of Babel FPGA designers had to swim through for languages
and file formats.  Instead of my simple minded Democrat/Republican, vi/EMACS,
Apple/IBM-PC-clone, Verilog/VHDL binary frame of reference, I found a world of
ABEL, Open-ABEL, CUPL, CUPL-VHDL, ONCUPL, CUPL-PLA, PALASM, Minc, JEDEC, XNF,
POF, LOF, EDIF, PDIF, ASCII HEX, LPM, Liason, A-HDL, AMAZE, PLAN, and,...
oh, yea...  that Verilog and VHDL stuff all over the place.)

Dini had more fun in his tutorial explaining his view of the FPGA/EDA world:
"OrCAD: cheap price, wonderful features & user hostility.  One brutal install;
took two days...  Viewlogic: goes out of its way to make competitor's 3rd
party tools hard to use with their products.  The 5.0 release was clearly not
tested; it crashed hard drives and took a week to install...  PCI interfaces
offered by FPGA vendors are useless -- they're just as a sales checkbox...
QuickLogic: great technology and smart to team up with Synplicity.  If
customers use this software they'll put me out of business...  I can't figure
out Cadence Figero...  Always call Wyle or Avnet for availability of PLD's;
*never* trust the foundry salespeople on this..."

Another talk that had an interesting open was Gordan Hyland's (Philips 
Research) tutorial on ASIC emulation & prototyping w/ programmable logic.
His basic opening advice was: "Don't do it.  You can waste a lot of time
repairing *evolving* designs here.  Completing an *explicit* detailed spec
can save you much more time compared to constantly respinning FPGA
emulations."  (Once said, he then outlined detailed emulation strategies.)

Just as the prophets chronicled the wanderings of the Jews in the Old
Testament, one PLD industry old timer pulled me aside near the Atmel booth
and chronicled to me how a specific reconfigurable SRAM technology went
through 5 companies.  It started at Saratoga Semiconductor (which went
bankrupt) and transfered on to Concurrent Logic then on to National
Semiconductor (which lost interest in the FPGA business) then on to Atmel
and finally being licenced to IBM.  This, plus excess fab capacity, lead to
speculation that IBM might be seriously jumping into the FPGA business soon.

Small group gossip focused on the impact of migrating to PC platforms & the
piracy rife in those markets.  (I'm told that OrCAD is the former Soviet
Union's largest provider of EDA software and that ViewLogic holds the same
distinction in mainland China.  The problem is that none of the "customers"
ever paid OrCAD or ViewLogic!)  Also the discussion of FPGA vendors giving
virtually free EDA tools (thereby depressing the EDA business) raised the
hairs on the backs of many an EDA or FPGA vendor.  (If the Japanese did this,
Congress would be howling "dumping!"; yet its OK if U.S. companies do it.)


A Mess Of David(s) Against One Goliath
--------------------------------------

Half awake in an airplane daze on the long flight home I couldn't believe
what I was seeing in my interview notes.  Engineers and vendors were sounding
just like elementary school children getting all excited that the scrappy new
kid in town, AT&T ORCA, was finally going to beat up that nasty long time
playground bully, Xilinx, who chose to noshow at their industry's conference.

I quickly shook my head to make sure that I was thinking straight.

I asked myself: "John, you're saying that a 10 year old, $321.3 million (1994
sales), Marie Antoinette 'Let them eat cake!', everyone-loves-to-hate Big
Brother monopolistic Xilinx is being challenged by a tiny 70+ year old, $75.1
*billion* (1994 sales), now-friendly-little-up-&-coming-start-up AT&T ??!?"

Ten million dollars worth of contrived PR manipulations couldn't have bought
this image -- yet there it was staring at me!  (Whoa!)

What a long strange trip its been....

                                   - John Cooley
                                     part-time EDA Consumer Advocate
                                     full-time ASIC/FPGA Designer

P.S. I like hearing whether readers think I'm on-the-money or out-to-lunch
     -- and why!  :^)  (Plus I enjoy hearing about the stories you think
     *should* be told about the EDA/ASIC/FPGA world.)  Write me!

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3443 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 1334
Subject: Re: PCI ALTERA design
From: rick@news.algor.co.uk (Rick Filipkiewicz)
Date: 2 Jun 1995 10:12:01 GMT
Links: << >>  << T >>  << A >>
Finn M. Johansen (fmj@pe.dk) wrote:
: Hi you FPGA designers!!!
: I am  designing a data communication add-in card for the PCI bus. We have
: ALTERA Max+Plus II software at your company so I have decided to use FLEX 8K
: device(s) for the design. The add-in card has to operate in a master and
: target configuration. However I have experienced that to drive the PCI
: interface signals as master you need to use 6  I/O cell Output Enable
: signals to keep witin the input-setup time and clock-to-output time
: requirements in the spec. Unfortunately the Flex 8K devices only have 4
: (except EPF81500, it has 10). What is the solution to this problem? Multiple
: devices can be a solution where the master driver logic with my back-end
: device specific logic could go in one device and PCI synchronous inputs and
: target logic in another. But what about load problems??? Is it a better idea
: to use PCI compliant MAX devices.
: Please note folks that I have only worked with the FLEX devices and
: unfortunately I am new in digital design. 

: Please give me some ideas or solutions (if any) ASAP. My time schedule is
: very tight.

Have you considered using what used to be the Intel FX8160, now
supplied by Altera. It has PCI compliant IO and every 10 output logic
block has 2 output enable controls. Another plus is that the PLDSHELL
fitter s/w is very good (and FREE from Intel) as we found when we
designed in the FX780 sister parts. Note that the '740 and '780 don't
have PCI IO.
 


Article: 1335
Subject: ATMEL 6000 question
From: rick@news.algor.co.uk (Rick Filipkiewicz)
Date: 2 Jun 1995 11:09:19 GMT
Links: << >>  << T >>  << A >>
I've recently been evaluating the AT6000 series parts as possible
candidates for a datapath chip and I've run into some problems with
the s/w. The PathFind and CalculateDelay timing utilities seem to give
different delays for the same path ! Does anybody know anything about
this ? I've also found that the auto-place tool supplied cannot even
handle a simple chain of 4 8-bit registers. Is there a better one
available ?

Also has anybody out there in net-land had any experience with running
these parts at high speed. The design has to :

- Clock at 66 MHz (75better)

- Have input setup/hold of 3.75/0 at the pin.

- Number of internal registers for 18-bit slice (out of 72) is 432.

I'm also considering the Altera FLEX8000 series as a candidate but the
last time I eval'ed the s/w the fitter was appalling. Is the new
version any better ?

Any other candidates


Article: 1336
Subject: Re: AT&T serial EEPROMS
From: ksteele@motnengr.com
Date: 2 Jun 1995 14:28:11 GMT
Links: << >>  << T >>  << A >>
In <3ql7pa$sr2@fnnews.fnal.gov>, husby@fnal.gov (Don Husby) writes:
>
>  We recently switched to AT&T serial EEPROMS (17128) instead of Xilinx 
>(one-time programmable) PROMS for configuring a 4005A chip.  The AT&T part 
>seems to blow the configuration about 50% of the time.
>
>  Does anyone know of problems with these parts?

We had the same problem with the 1765 prom loading a 3042, both AT&T. This was over a year and a half ago.
Tracing the startup sequence with a logic analyzer revealed that the 64th bit of the serial bitstream would not go to a valid level.
When I spoke with AT&T, they were aware of a "few" other customers who were having similar problems.  
They attributed it to problems at the semiconductor foundry and were in the midst of changing their vendors for these parts.
They reccomended to use Xilinx.
Note that all of these configuration proms are susceptible to power on VCC timing problems.

I believe Xicor is starting to second source some of these parts...

Kevin Steele  ksteele@cerfnet.com  Motion Engineering, Inc.    Santa Barbara CA



Article: 1337
Subject: Re: Latch up in Xilinx 3000 Series FPGA's. Part smokes & smells bad.
From: ksteele@motnengr.com
Date: 2 Jun 1995 14:39:23 GMT
Links: << >>  << T >>  << A >>
In <3qmask$ofp@nyx10.cs.du.edu>, jgriffit@nyx10.cs.du.edu (Jonathan Griffitts) writes:
>dstarr@world.std.com (David J Starr) writes:
>
>> " We are having trouble with latchup using Xilinx 3090/3190 160 pin
>>parts.  When it happens the part is toast.  It will draw a couple of amps at 
>>5 volts and get hot enough to burn your fingers." ...... "It seems to happen on
>>1st power up, before we can even program the part with Xchecker."

>Jonathan replied:
>On several occasions I've toasted XC3000 family parts by feeding them
>faulty configuration bitstreams.  What I mean is bitstreams that are
>just totally invalid due to some procedural error or bad ROMs.
>Apparently an illegal configuration can cause the parts to draw lots
>of power and overheat rapidly. 

If it's happening on power up and before you attempt to download a bitstream I would check the controls
(M0,M1,M2, cclk etc). Yes they can smoke if they latch up in a bad configuration although I am not clear
why this occurs "before" you download the bitstream.  I've experienced both cases: 
1. Power-on lets the smoke out of the chip.
2. Illegal configuration can do the same.
(See the thread about AT&T serial eeproms for info on the second)

Kevin Steele    ksteele@cerfnet.com   Motion Engineering, Inc   Santa Barbara, CA





Article: 1338
Subject: Xilinx Master/Slave Serial Configuration
From: cjwhite@minimax.wustl.edu (Christopher J. White)
Date: 2 Jun 1995 15:08:19 GMT
Links: << >>  << T >>  << A >>
We're doing a design based on the 4010 FPGA in which we have 8 parts
that we wish to configure identically.  The configuration requires two
Serial PROMS (an XC1765 and an XC17128).  The user guide gives the
following solution:

  1)  Configure one device in Master Serial Mode and all others in
      Slave Serial Mode
  
  2)  Connect the CCLK of the Master to the CLK of the PROMs and the
      CCLK of all Slaves

  3)  Connect DATA of PROMs to DIN of Master and all Slaves

  4)  Enable serial PROM with wired-AND of all DONE pins

This seems like an easy enough solution.  I have a few concerns:

  -  We intend to delay configuration after power up by holding
     PROGRAM.L low until Vcc is valid.  Will tying all INIT.L pins of
     the master and slaves properly synchronize the beginning of
     configuration?  We do not use either PROGRAM.L or INIT.L as user I/O
     pins, thus there is no other connection to them.

  -  Are there any problems in driving 7 slaves with the master's CCLK
     signal.  We're concerned about reflections and the like.  Has anyone
     done this before?  The devices are layed out in a column spanning
     approximately 15 inches -- a 15 inch trace.

  -  How about wiring all DONE pins together?  What are the timing
     constraints here?

Thanks for any help here.

Christopher J. White, cjwhite@rgit.wustl.edu
Department of Electrical Engineering
Washington University
St. Louis MO



Article: 1339
Subject: Re: pci-video-accell.card with Altera ?
From: Russell Petersen <petersr>
Date: 2 Jun 1995 18:08:10 GMT
Links: << >>  << T >>  << A >>
tw38966@vub.ac.be (SH.RYU KIM HOFMANS) wrote:
>
>Hi there,
>
>could someone tell me if it's possible to make a pci video accellerator card 
>with Altera or Xilinx FPGA's ?
>One of my professors (a Xilinx fanatic) is telling me it isn't quite
>possible because for that you need a lot of floating point calculations
>and he says a Xilinx FPGA isn't capable of that sort of things.

Well, it is capable but it will be big and slow.  Floating point hardware is
just not as simply as fixed point so you have to pay the price.

 
>Another of my professors (an Altera fanatic) is telling me it's possible
>because Altera is providing special FPGA features for that kind of things.

Special FPGA features for this sort of thing?  I don't really know what he would
be referring to that would make Altera more suitable than Xilinx for floating
point implementations.  They each have their strengths but in many cases they
can be seen to be approximately equivalent to each other.


>But he doesn't know if it will be a lot of trouble to make it work with a
>PCI-bus (he's also a MAC-fanatic so he doesn't know  lot about PC's)
>
>So, if it is possible to make a PCI-video card with an FPGA, will it be a
>lot of trouble ? And could someone tell me if there are any good books

Lots of trouble?  Well, it certainly won't be as easy as buying a card.  It really
depends upon what you are trying to do and why.  It is possible but it will take a lot
of work of course.  As far as the PCI thing goes, Altera does have a PCI interface/info
packet that you can get complete with disk.

>about the hardware of PCI-busses and video-accelerator cards ?
>
>Thanx in advance,
>
>Kim Hofmans
>tw38966@is1e.vub.Ac.Be
>

-Russell Petersen
 petersr@crackle.ee.byu.edu



Article: 1340
Subject: Survey of FPGA
From: "Edward K. Acosta" <eacosta@media.mit.edu>
Date: 2 Jun 1995 20:18:33 GMT
Links: << >>  << T >>  << A >>
Hi there,
   We are presently moving into genII of a reconfigurable
  computing platform for image processing applications and
  are trying to determine the best devices to use.  I was wondering
  if any of you would be willing to share your thoughts and/or
  experiences.
    In the first generation we used Altera EPF81188's because they
  were the most dense and fastest available at the time.  This choice
  turned out to be a major bummer because Altera traded off
  routability for performance such that we were not able to achieve
  very high device utilization ratios for fixed pinout designs.
    Ideally, we would like to find devices that can implement 33-40MHz
  designs and have 10K+ usable gates (the bigger the better) and are
  specifically designed for fixed pinout designs.  We have looked at
  Xilinx 5000, but these are a loose on availability (we need them
  now, not later) and on price of the tools.  AT&T ORCA would be
  great if tools existed to get the job done.  Can anyone comment
  on the state of software tools for ORCA in the post-NeoCAD buyout
  age??  Altera 8000 family is a total loss for obvious reasons.
  Beyond these three I am not up to date on vendors of very large
  SRAM based FPGAs, can anyone suggest some others to look at??

    Also anyone want to comment on the state of Verilog design for
  FPGAs, or on Verilog vs. VHDL for FPGA design?  I've already read
  Cooley's note on the topic, but would like to hear other opinions
  as well.  Thanks in advance to all those who choose to comment
						Thanks,	
						   Ed Acosta



Article: 1341
Subject: Re: Latch up in Xilinx 3000 Series FPGA's. Part smokes &
From: jeff_cunningham@fostex.com (Jeff Cunningham)
Date: 2 Jun 1995 21:05:15 GMT
Links: << >>  << T >>  << A >>
In article <D9H4B2.L9J@world.std.com>
dstarr@world.std.com (David J Starr) writes:

>   We are having trouble with latchup using Xilinx 3090/3190 160 pin
> parts.  When it happens the part is toast.  It will draw a couple of amps at 
> 5 volts and get hot enough to burn your fingers.  We have had three or
> four parts do this, out of 10 or 12 parts overall.  It seems to happen on
> 1st power up, before we can even program the part with Xchecker.  The
> board only has 5 volt power and is running by itself on the bench.  One
> part went poof before any test equipment was connected.  Signals look
> pretty clean, nothing rings very far below ground, or above vcc.  Any
> hints, suggestions or experiences would be appreciated.  Are these parts
> really that tender?  Or is there something we don't understand? TIA.
> David J. Starr

The earlier 3000 series parts (not the 3000A or 3100 series) are
capable of melting down if they are loaded with random bits. Make sure
your circuit isn't accidentally somehow loading garbage at start up.

Also, be careful about reset during power up - the 3000 series really
should be guaranteed a valid reset by the time Vcc passes through 1v,
otherwise you could have trouble getting the parts to load properly.
They *can* get into a funky state if reset is not asserted, and the
funkyness will not go away by asserting reset when Vcc is stabilized
(though I have never heard of this causing the chip to melt down).

-Jeff.


Article: 1342
Subject: Re: ATMEL 6000 question
From: "Edward K. Acosta" <eacosta@media.mit.edu>
Date: 2 Jun 1995 21:06:39 GMT
Links: << >>  << T >>  << A >>
rick@news.algor.co.uk (Rick Filipkiewicz) wrote:
>
> 
> I'm also considering the Altera FLEX8000 series as a candidate but the
> last time I eval'ed the s/w the fitter was appalling. Is the new
> version any better ?
> 
       We've had very poor luck with the FLEX8000 architecture and
   MaxPlusII design tools.  Using 81188's we couldn't achieve better
  than 45% device utilization for fixed pinout designs.  There are
  definate architectural reasons for this, and compiler performance
  may contribute to this as well.  We were using v4.02 of the tools,
  haven't tried v5.11.  However, give the FLEX8000 architecture it is
  unlikely the newer version will do much better.  Also these won't
  to 60+ MHz for datapath designs that do any thing useful.




Article: 1343
Subject: Re: Latch up in Xilinx 3000 Series FPGA's. Part smokes & smells bad.
From: dstarr@world.std.com (David J Starr)
Date: Sat, 3 Jun 1995 01:39:44 GMT
Links: << >>  << T >>  << A >>
   Thankyou all for your input on this little problem.  I received helpful
e-mail from lkuru (Laura Kuru) and Chuckg (Chuck Garnet).  Today in the
lab I used a storage scope to check the relationship between Vcc coming up
and reset.  We used a TL7705 power management chip to create reset and
it is asserting reset low by the time VCC has reached a volt and some change.
In responce to the previous post, I'll go back and see just where reset
cuts in.  Reset is solid low until VCC is a skosh above 5v.  The power supply
overshoots 5 volts by about a quarter of a volt and then settles down at
5 volts even.  Reset goes high right at the peak of the little overshoot.
The bitstream we are loading is "correct" in the sense that the parts that
don't smoke, start up and run the way we expect them to.  It occurs to me
that the Xchecker cable we use to download the bitstream sometimes pops
out of its socket.  This would let some of the programming pins float.
I'll check that out on Monday.  Again, Thank you all.
David J. Starr



Article: 1344
Subject: Re: Latch up in Xilinx 3000 Series FPGA's. Part smokes & smells bad.
From: lkuru@titanic.trs.ntc.nokia.com (Lauri Kuru)
Date: 03 Jun 1995 07:07:06 GMT
Links: << >>  << T >>  << A >>
In article <D9Kpy8.6Ix@world.std.com> dstarr@world.std.com (David J Starr) writes:

>      Thankyou all for your input on this little problem.  I received helpful
>   e-mail from lkuru (Laura Kuru) and Chuckg (Chuck Garnet).  Today in the

Actually, that is Lauri, not Laura. Here in Finland Laura is female name as in most
of the world whereas Lauri is male name. Well, you're not the first one to be
misguided by my name. :-)

Regards & good luck,
			Lauri


Article: 1345
Subject: Re: Xilinx Master/Slave Serial Configuration
From: fliptron@netcom.com (Philip Freidin)
Date: Sat, 3 Jun 1995 08:09:50 GMT
Links: << >>  << T >>  << A >>
In article <3qn9h3$7fd@ecl.wustl.edu> cjwhite@minimax.wustl.edu (Christopher J. White) writes:
>We're doing a design based on the 4010 FPGA in which we have 8 parts
>that we wish to configure identically.  The configuration requires two
>Serial PROMS (an XC1765 and an XC17128).  The user guide gives the
>following solution:
>
>  1)  Configure one device in Master Serial Mode and all others in
>      Slave Serial Mode
>  
>  2)  Connect the CCLK of the Master to the CLK of the PROMs and the
>      CCLK of all Slaves
>
>  3)  Connect DATA of PROMs to DIN of Master and all Slaves
>
>  4)  Enable serial PROM with wired-AND of all DONE pins
>
>This seems like an easy enough solution.  I have a few concerns:
>
>  -  We intend to delay configuration after power up by holding
>     PROGRAM.L low until Vcc is valid.  Will tying all INIT.L pins of
>     the master and slaves properly synchronize the beginning of
>     configuration?  We do not use either PROGRAM.L or INIT.L as user I/O
>     pins, thus there is no other connection to them.

Tying the INIT.L pins together will properly sync the master to the slaves.
On page 2-27 of the data book it shows that the master checks this pin
after PROGRAM.L is de-asserted, and holds off configuration until INIT.L
is high. This means that if the master finishes the 'clear config memory'
before the slaves, it wont start up until they are all ready. Dont forget
the pullup resistor for the INIT.L net. If you intend all the chips to
go live synchronously with a system clock signal, you will need to also
tie all the DONE.L pins together (with a pullup resistor too), and the
startup mode for all the chips would need to be UCLK_SYNC (see page 2-29).
If you aren't using your own clock for going live, but still want the
chips to be synced on startup, then the CCLK_SYNC mode will also work for
you. In your particular case, since all your chips are 4010's, they
all have the same length count, and the default CCLK_NOSYNC will also
work as they will all enter the startup sequence at the same time, using
the same clock.



>
>  -  Are there any problems in driving 7 slaves with the master's CCLK
>     signal.  We're concerned about reflections and the like.  Has anyone
>     done this before?  The devices are layed out in a column spanning
>     approximately 15 inches -- a 15 inch trace.
>

The master has sufficient drive for the 7 slave CCLK pins, and while it 
is not a 'gutsy' output driver (I think it is like the rest of the I/O pins, 
4 mA high, 12 mA low.), it does have fast edges (1 to 2 nS rise and fall
time into no load). Any trace over 5 to 8 inches has to be considered a
transmission line.

The Xilinx chip flipflops (including the ones in the configuration logic)
are very fast. As such, they will respond like any fast logic family to
noise on the clock signals by double clocking. Noise examples include
reflections that cause U turns during the Rising and falling edges of
the clock.  ASCII GRAPHICS, here we go....

---------\                      /---------------
          \                    /
           \                 ^V
            U^              /
              \            /
               \__________/

These little wiggles (due to termination problems) may only be a few
hundred milivolts high, and 2 to 5 nS wide. Acording to Murphy's law,
they will position themselves close to the threshold point of the chips
receivers. Sometimes to see them, you need at least a 500MHz scope, and
low capacitance probes (1 pF). 

Due to the un-impressive drive characteristics of the master driver of
this CCLK signal, termination is not possible without violating Iol, Ioh,
Vol, or Voh. This is because you loads are spread out and the termination
circuits that can be used with this type of driver dont work with your
load topology. When I am faced with the type of circuit topology you 
describe, I would buffer the clock coming out of the master chip, with
something like a 74F241 or 74F244. I would then terminate the line 
appropriately, i.e. 220/330 ohms to Vcc/Gnd. Note that the master chip
actually sends the CCLK signal out onto the CCLK pin, and then reads it
back in to control its configuration function. This means that even if
you only had significant reflected noise in your system back at the
source (the master), you system could fail. This also means that the
trace from the master to the buffer should be kept short. To avoid race
conditions, you should use the buffered (and delayed) CCLK to clock the
serial proms.

>  -  How about wiring all DONE pins together?  What are the timing
>     constraints here?

See my notes above.

>
>Thanks for any help here.
>

Glad to help when I can
	Philip Freidin.		Fliptron@netcom.com


>Christopher J. White, cjwhite@rgit.wustl.edu
>Department of Electrical Engineering
>Washington University
>St. Louis MO
>




Article: 1346
Subject: Glenayre Job Postings
From: glenapp@charlotte.glenayre.com
Date: 3 Jun 1995 13:50:34 GMT
Links: << >>  << T >>  << A >>
Glenayre, a worldwide telecommunications company, is recruiting for
 positions in Charlotte, NC; Quincy, IL; and Vancouver, BC. For a description 
of the positions, a narrative about Glenayre, and a forms-based online
 application, point your web browser the the following URL.

http://www.synernet.com/glenayre

or email to glenapp@charlotte.glenayre.com



Article: 1347
Subject: Re: FPGAs for PCI Interfaces
From: Roman & Tracey Iwanczuk <iwanczuk@scruznet.com>
Date: 4 Jun 1995 19:25:36 GMT
Links: << >>  << T >>  << A >>

Xilinx has several PCI compatible FPGAs and EPLDs.  Rather than
list all of the info here and make this a too blatant advert 
(since I am a Xilinx employee) I'll just say that you can find 
out more about them by e-mailing pci@xilinx.com

regards
roman iwanczuk




Article: 1348
Subject: Re: FPGAs for PCI Interfaces
From: tak@core.rose.hp.com (Tom Keaveny)
Date: Mon, 5 Jun 1995 01:12:37 GMT
Links: << >>  << T >>  << A >>
Don Husby (husby@fnal.gov) wrote:
: In article <D9G6y4.8py@news.cern.ch>, cfernand@dsy-srv3.cern.ch says...
: > How do you implement the PCI on a ATT2C15-3 FPGA?
: > Indeed, timings are VERY critical or even impossible to meet:
: >
: > With the ATT2C15-3 FPGA, timings seems the folowing
: >
: > - Input-PAD             : 1.8 ns
: > - clock routing         : about 3.4 ns
: > - CK to Output register : 1.7 ns
: > - Output Pad            : 5.9 ns (Bidir, tristate)
: > - 1 PFU layer (LUT)     : 3.1 ns
: >
: > So if I summ those values, I get 15.9 ns.
: 
: According to my data book, I got the following times:
: 
: Clock to Output Pad:
:   Clock pad to PFU CK:             4.9 ns
:   PFU CK to output pad (edge FF):  5.7 ns
:                                  _________
:                         Total:    10.6   Includes routing
: 
: Clock to Pad through tristate control:
:   Clock pad to PFU CK:             4.9 
:   PFU CK to output:                2.8 
:   PFU to PAD TS control (routing): 1.0 
:   TS to PAD:                       4.7       
:                                  _________
:                         Total:    13.4
: 
: Inputs into pipeline register (setup):
:   Setup to Pad (edge FF):          2.1
:   Clock routing:                  -4.9
:                                  _________
:   Actual setup, PAD to CLK PAD:   -2.8 +/- ~1 ns
:   Using delayed input: (6.8-4.9)  +1.9 +/- ~1 ns
: 
: Inputs through a PFU (setup):
:   Pad delay:                       2.3
:   PFU setup to clock:              1.7
:   Routing:                        ~1
:   Clock routing:                  -4.9
:                                  _________
:   Total setup time through PFU:    0.1 +/- ~1 ns
: 

what kind of effect will routing have on "wide fanout" input signals?
for example, both TRDY# and IRDY# can have significant loading, especially
when sustaining zero wait state burst transfers is required.

: 


Article: 1349
Subject: 80x51 in FPGA anyone ?
From: granville@decus.org.nz
Date: 5 Jun 95 22:12:50 +1200
Links: << >>  << T >>  << A >>
Does anyone have info / becnhmarks on the 80x51 in FPGA ?
I saw a 6502 example, but that is rather dated, and are very interested to know
if a 80x51 can fit in what size / spec part ?
 What throughput do you then get ?
 What resource is left over ?
( it does not have to be a DIV 12 core, though that is probably the most likely
to be quoted ).
 Thanks in advance - jim granville.





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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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