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 8675

Article: 8675
Subject: Re: Vantis Enters FPGA Market Unveiling New Variable-Grain-Architecture Devices With Industry Leading Performance
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Mon, 19 Jan 1998 17:26:49 +0000
Links: << >>  << T >>  << A >>
Scott Thomas wrote:
> 
>...Vantis, an AMD company, today is entering the FPGA market with an
>innovative family of Variable-Grain-Architecture(TM) devices, the VF1
>Series, and powerful new Design-Direct(TM) software.

>...absolutely enormous cut...

>Type http://www.vantis.com ...cut..

And find nothing there about this news!

Also, shouldn't this strictly be "RE-entering the FPGA market"?  Didn't
AMD second-source Xilinx at one time?

Tim Forcer               tmf@ecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

The University is not responsible for my opinions
Article: 8676
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 19 Jan 1998 20:10:54 GMT
Links: << >>  << T >>  << A >>
hi austin,

well, at least the list of topics is getting shorter! ;)

rk

---------------
 
rk:
: >                                                                 many
years
: > ago, first started with fpgas, i did some experimenting, picked the i/o
: > pins in a 'logical' bus configuration.  p&r didn't like it - one of the
few
: > times it didn't complete.

austin: 
: Probably because you didn't do internal placement...I've seen that too...

rk:
tools back then supported internal placement but it was, well, rather
painful.  the new graphical based tools are pretty nice.  iirc, the
addition of buffers cleaned up some of the problems since it ran out of
long tracks.  of course, using the long tracks slows things down; see
additional comment below.

-------------

rk: 
: > so, i let the pcb router work a bit harder and
: > this works quite well.  the only draw back is you can't check out a bus
on
: > the scope w/out having the pin list or schematic handy, it's all over
the
: > place.

austin: 
: Hence my reason for assigning pins my self.  It makes the inside, as well

: as the outside of the chip cleaner, faster, and use less resources.
 
rk:
slight disagreement here.  first, distributing wide busses all over the
chip randomly will help with ground bounce.  also, depending on the
functions that are implemented it may cost more in fpga resources if the
signals need to be bussed around the chip to meet a manual placement.  long
tracks cost more in time and power and if buffers are needed to get the
signals across, then more nodes switch and power also goes up.  this
probably doesn't happen all that much but, in early on experimenting, i did
run into this.  on pcb's, if you don't need any more routing layers, more
'random' looking usually cost just a bit more time in the router.  btw, i
haven't had any trouble doing pcb routing w/ 6 layers (pwr, gnd, 4
signals).  if your goal is to have a 4-layer board, then it might be worth
the trouble.  i guess the bottom line is that with p&r doing the pin
assignment as the first step i haven't had any trouble with fpga p&r, no
trouble with 6-layer pcb routing, and have had outstanding success when the
insides of chips had to be redesigned to meet new specs.  of course, some
of this might be moot as iirc the pasic3 stuff guarantees 100% p&r with
i/o's preassigned and full utilization - and with their low-resistance
antifuse should get good performance too.  but still gotta watch the ground
bounce, esp. with the move to 32-bit busses.

-------------------

rk:
: > for hand placing the registers, counters, etc., ..., i almost never do
: > that.  that's the machine's job.
 
austin:
: Cough, cough....  well, you are missing out on the best performance 
: and resource enhancement technique you can possibly to for an FPGA.  
: Almost every job I take that is a re-do of a failed design due to timing 
: gets a floorplan, and magically, it all makes timing....and routes in 
: minutes...

rk:
sorry about the cough - it's going around.  but, perhaps you missed (or
snipped too fast) where i discussed one particular vendors removal of the
manual module placement tool and how, for critical sections, it is really,
really nice to have.  and, with the static timing analysis, those areas can
be found very quickly and optimized.  since, with some good upfront design
rules (i.e., number of gates between flops) most of the chip makes the
timing analysis, i save a lot of time by letting the s/w take the initial
crack at it.  while i hate to use cliches, the first thing that i learned
as an engineer by my first boss (still work with him on and off, many years
later) is "better is the enemy of good enough."  applied here, no need to
optimize paths that don't need optimization.  and engineering time both for
home business and day job are valuable.  and for special jobs (high speed,
ultra-low power, seu hardness, etc.) the manual level (and engineering
time) goes *WAY* up.


rk:
: > just read an article (well, really an ad ;^) in electrical engineering
: > times called "synopsis overhauls strategy in fpga synthesis."  p. 46,
dec
: > 15, '97.  they addressed to a certain extent some of the issues you
raised.
: > 
: > 	"timing-optimization capabilities ahve gained a substantial boost
: > 	with time tracker, a utility based on synopsys' primetime static
: > 	timing analyzer.  time tracker estimates preroute delays and claims
: > 	accuracy within 5 per cent to 15 per cent, depending on architecture.

austin:
: That doesn't really say anything....  That's like saying 'this new 
: product has 300% less calories and improves your outlook on life' both 
: amorphous statements when NOT compared to a baseline.....  I'm sure pork 
: rinds have 300% less calories than something, and eating pork rhinds 
: after eating leaves might just improve your outlook on life, unless 
: you're a giraffe....;-)

rk:
well, first note that i did say 'ad,' and hopefully the ee times guys won't
get too upset - i wish they would have gone into a lot more technical
detail.  but, if they can predict the post-layout timing to an accuracy of
5% ('good architecture' ;-) of the post-layout extracted timing delays,
then that's really pretty good and does address the issue you raised.  my
reading of it doesn't say relative accuracy to previous release but
absolute accuracy to post-layout delays.  i also assume that the estimated
delays are within 5% of the actual value, not that the tool was wrong (by
an unbounded amount for 5% of the paths).  perhaps someone with familiarity
of this tool can comment on it.

over to you, chet,

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8677
Subject: Re: ByteBlaster
From: jolly.ayse@removethis.hol.fr (emmanuel jolly)
Date: Mon, 19 Jan 1998 20:28:42 GMT
Links: << >>  << T >>  << A >>
You can look at http://www.acte.no/freecore/blaster.htm

Manu

On Sun, 18 Jan 1998 13:49:35 +0200, Gabby Shpirer <gabby@isv.dec.com>
wrote:

>Hi.
>
>  Dose any one of you has the schematics of the ByteBlaster Plug.
>
>
>Gabby
>

---
Pour me contacter enlever "removethis." de mon adresse Email.
To contact me, remove "removethis." from my Email address.
Article: 8678
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 19 Jan 1998 16:26:08 -0500
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > gets a bit tiring, making it fit, and then labelling all the instances and
> > nets (which i like to do, helps to communicate with the tools better, i
> > hate instance 3$I102 which is invisible on the schematic.
> 
> Agree, hence, the use of labels on all structured instances.....  You can
> reference the hierarchical labels when doing placement....works very
> well.
> 
Yeah, Now if I could just remember to label the instance when I put them
down....


> AH!  As does the Xilinx doc!  They are wrong, it is certainly better to
> do pin assignment your self, given, of course, an intimate understanding
> of the architecture and design, and how it should be placed...
> 

> Cough, cough....  well, you are missing out on the best performance
> and resource enhancement technique you can possibly to for an FPGA.
> Almost every job I take that is a re-do of a failed design due to timing
> gets a floorplan, and magically, it all makes timing....and routes in
> minutes...
> 
I couldn't agree more.  A little floorplanning goes a long long way. 
Performance, logic density and route times are all improved.  The best
part is that many times I can do the placement better and faster than
the tool.  It does require a knowledge of the device architecture and
the design to be placed.
Article: 8679
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 19 Jan 1998 22:09:40 GMT
Links: << >>  << T >>  << A >>
ray:
: I couldn't agree more.  A little floorplanning goes a long long way. 
: Performance, logic density and route times are all improved.  The best
: part is that many times I can do the placement better and faster than
: the tool.  It does require a knowledge of the device architecture and
: the design to be placed.

rk:
interesting ray.  i note that both you and austin seem to gain a lot more
benefit from hand placement than do i - i only sometimes need to resort to
hand placement (tool sometimes just doesn't want to take the hint ;-).  do
you think it's a function of fpga technology and routing delays?  p&r
capability?  i know you use a variety of devices.  btw, what are your
typical route times?  generally, i find p&r quick enough that substantial
or even moderate human effort to speed it up isn't worth it.

for good benefit of engineering time (and possibly keeping some relevance
to the topic), i note that the biggest improvement in performance, for the
technologies i am using, comes more on the front end design than the back
end p&r.  as such, i have so far kept away from the vhdl and stayed with
mostly schematic design w/ some macros thrown in.  also, careful pipeline
design, bufferign, algorithms, and appropriate use of device 'features'
(i.e., design for combinability, etc.) have yielded greater improvements
than what i can hope to see from a better p&r.
 
--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8680
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Mon, 19 Jan 1998 21:06:14 -0500
Links: << >>  << T >>  << A >>
In article <01bd2526$8f09a1c0$8584accf@default>, 
stellare@erols.com.NOSPAM says...
> ray:
> : I couldn't agree more.  A little floorplanning goes a long long way. 
> : Performance, logic density and route times are all improved.  The best
> : part is that many times I can do the placement better and faster than
> : the tool.  It does require a knowledge of the device architecture and
> : the design to be placed.
> 
> rk:
> interesting ray.  i note that both you and austin seem to gain a lot more
> benefit from hand placement than do i - i only sometimes need to resort to
> hand placement...

I do a lot of bus interfaces (PCI, TurboChannel, ISA...) and any time you 
do a bus interface, there are a lot of registers and counters (which are 
just registers that count ;-) involved.  If you do not have many 
registers (many is > 5) then you can probably get away with not doing 
placement.  If I didn't do placement, I would never make timing, and 
would use a LOT more routing resources.

Austin

Article: 8681
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 20 Jan 1998 03:29:20 GMT
Links: << >>  << T >>  << A >>
austin:
: I do a lot of bus interfaces (PCI, TurboChannel, ISA...) and any time you

: do a bus interface, there are a lot of registers and counters (which are 
: just registers that count ;-) involved.  If you do not have many 
: registers (many is > 5) then you can probably get away with not doing 
: placement.  If I didn't do placement, I would never make timing, and 
: would use a LOT more routing resources.

hmmm ... perhaps you should change manufacturers? ;^)  but seriously, i've
done 1 pci target and, well, not the most trivial circuit.

most of the circuits that i do are generally very counter intensive mixed
in with a lot of adders and multiplier/accumulators and quite often parts
tend to run out of gas in the i/o (although that is sometimes a function of
the design requirements, such as not using i/o in act 3, another story).

just for kicks and to learn about a new family, i ran some timing numbers
on a 36-bit xor function, register to register, to determine min cycle time
of the core for this function.  this is what i got, conditions were:

	t       = 70C
	process = worst-case
	voltage = 4.75

a1460bp-3     14.6 nSec
42MX09-2      10.3 nSec

now i did a simple p&r, not timing driven.  and no hand optimizations were
performed - the output of the macro generator was used.  the goal was to do
a simple comparison of the speed of the new 42mx (0.45 um) vs. the older
act 3 (0.6 um).  identical net lists were used for both devices.  perhaps
others could post results for different systems and we can compare.  or
post some of your critical circuits and timing and we can compare those.

good evening,
 
--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8682
Subject: New Atmel 5.0 software?
From: "Brad Smallridge" <manbike@smallridge.xo.com>
Date: Mon, 19 Jan 1998 20:54:29 -0800
Links: << >>  << T >>  << A >>
Wondering if anyone has reviewed the Atmel 5.0 software?
Does it have anything new for the old At6k user?
Or is it only for the new At4k user?
Brad Smallridge
SIGHTech Vision Systems, Inc.



Article: 8683
Subject: Altera serial PROMs and Xilinx FPGAs
From: mark.snook@arm.com
Date: Tue, 20 Jan 1998 06:01:08 -0600
Links: << >>  << T >>  << A >>
I have a board with an XC4062XL and have two daisy-chained sockets for
serial PROMs. The XC4062XL requires approx 1.5Mbits of configuration
data. Xilinx has announced 512Kbit and 1Mbits serial PROMs, but the
release date has slipped to late March. Clearly I don't want to wire
up 6 XC17256 or AT17256 parts.

I know and have used the EPC1 PROMs (1Mbit) for Altera Flex devices,
and a quick check of the data-sheet shows that these could be used to
configure Xilinx parts if programmed in the Flex8k configuration. Has
anyone actually tried this. The main problem that I can see is a
software one, that is the EPC1 is programmed by a *.pof file which
includes information on the mode required. I'm not sure that I can get
the Altera software to generate a *.pof from a Xilinx hex file, but I
haven't tried yet.

Anyone have any ideas or experiences. My programmer is a Sprint Optima
and I have both the M1 Xilinx tools and the Altera software.

Mark

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 8684
Subject: UART Spec
From: "Frank" <xzf@usa.net>
Date: 20 Jan 1998 12:15:36 GMT
Links: << >>  << T >>  << A >>
Does anyone know where I can find spec for UART (V.24) standard, or design
with FPGA, CPLD? 
TIA
Article: 8685
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Tue, 20 Jan 1998 08:39:51 -0500
Links: << >>  << T >>  << A >>
> hmmm ... perhaps you should change manufacturers? ;^)  but seriously, i've
> done 1 pci target and, well, not the most trivial circuit.

Er, if you did a PCI interface in an Actel part....it wasn't PCI 
compliant.  As far as I know, Actel does not meet all PCI 
requirements....you need to use two pins for one signal, and that is 
illegal in PCI land.

Also, you HAD TO lock your PCI I/O pins, or you couldn't have hoped in a 
million years to be PCI compliant (no crossed signals, one via per 
max...1.5" max length...).

Also, did you take into consideration the /STOP-/FRAME Intel chip set 
bug?  It requires 5 raw /FRAME destinations....though it is NOT part of 
the PCI spec, in order to work in the real world, you need to implement 
it...

Austin

P.S.  Do you really use Actel parts?  Kind of like driving a Mustang II 
;-)  You see a few of them every now and then....not enough to take them 
seriously, but just enough to let you know they are still out 
there....somewhere..for some reason (though that reason escapes me ;-).
Article: 8686
Subject: Xilinx byte wide ROM builder up to 4K bytes
From: Eric Ryherd <"vauto@tiac.net"@tiac.net>
Date: Tue, 20 Jan 1998 08:52:02 -0500
Links: << >>  << T >>  << A >>
A C program for generating byte wide ROMs for Xilinx XC4000 family
is available on my web page at:

HTTP://www.vautomation.com/free/free.htm

We're using this in-house and it is soooo much easier (end makes faster
and denser ROMs) than the old XACT MEMGEN or the newer Logicblox.

-- 
eric@         Eric Ryherd            VAutomation Inc.
vautomation   20 Trafalgar Sq. #443  Synthesizable VHDL and Verilog
Cores
.com          Nashua NH 03063        
(603)882-2282 FAX:(603)882-1587      http://www.vautomation.com
Article: 8687
Subject: bypass for 68 pin PLCC
From: "acbel" <acbel@world.att.net>
Date: Tue, 20 Jan 1998 06:14:44 -0800
Links: << >>  << T >>  << A >>
They fit between the socket and the circuit board.  I used some of these 3
years ago but I have forgotten who makes them and where they are available.
They were quite effective and I would like to source them again.  Any help
would be appreciated.

Arnold Beland

email   acbel@worldnet.att.net





Article: 8688
Subject: Re: bypass for 68 pin PLCC
From: Jeff Seeger <jseeger*remove_to_reply*@appliedcad.com>
Date: Tue, 20 Jan 1998 11:48:29 -0500
Links: << >>  << T >>  << A >>
acbel wrote:
> 
> They fit between the socket and the circuit board.  I used some of these 3
> years ago but I have forgotten who makes them and where they are available.
> They were quite effective and I would like to source them again.  Any help
> would be appreciated.
> 

What is the standoff (cavity height) under the PLCC?  Bypass caps up to 
.22uF are
available < .025" thick.  These are made by the millions weekly in a
couple
common (0805 and 1206) sizes and dielectrics (Y5V and Z5U) by
Murata-Erie, 
AVX/Kyocera, Samsung, Johanson Dielectrics, Novacap, and sevaral more
companies.  
 
Also could have been,
Circuit Components Inc., 2400 South Roosevelt St., Tempe, AZ 85282
Voice:  (602) 967-0624  Fax (602) 967-9385; has a product line that
may be of interest.  The line is called Micro/Q 3000/3500SM
Decoupling Capacitors.

Good luck,
-- 
 
      Jeff Seeger                             Applied CAD Knowledge Inc
      Chief Technical Officer                      Tyngsboro, MA  01879
      jseeger "at" appliedcad "dot" com                    978 649 9800
Article: 8689
Subject: Re: UART Spec
From: z80@ds.com (Peter)
Date: Tue, 20 Jan 1998 19:10:43 GMT
Links: << >>  << T >>  << A >>
Do you mean a schematic?

>Does anyone know where I can find spec for UART (V.24) standard, or design
>with FPGA, CPLD? 
>TIA


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiXYZserve.com but
remove the XYZ.
Article: 8690
Subject: Re: bypass for 68 pin PLCC
From: Leon Heller <leon@lfheller.demon.co.uk>
Date: Tue, 20 Jan 1998 19:36:59 +0000
Links: << >>  << T >>  << A >>
In article <6a20v9$h13@bgtnsc01.worldnet.att.net>, acbel
<acbel@world.att.net> writes
>They fit between the socket and the circuit board.  I used some of these 3
>years ago but I have forgotten who makes them and where they are available.
>They were quite effective and I would like to source them again.  Any help
>would be appreciated.

It was probably Rogers. They make flat capacitors that go under sockets
and chips.

Leon
-- 
Leon Heller: leon@lfheller.demon.co.uk http://www.lfheller.demon.co.uk
Amateur Radio Callsign G1HSM    Tel: +44 (0) 118 947 1424
See http://www.lfheller.demon.co.uk/dds.htm for details of my AD9850
DDS system. See " "/diy_dsp.htm for a simple DIY DSP ADSP-2104 system.
Article: 8691
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Tue, 20 Jan 1998 15:32:57 -0500
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
>
> 
> P.S.  Do you really use Actel parts?  Kind of like driving a Mustang II
> ;-)  You see a few of them every now and then....not enough to take them
> seriously, but just enough to let you know they are still out
> there....somewhere..for some reason (though that reason escapes me ;-).
Austin,

I went around with a similar thread about a year ago with Mr. Katz.  If
I recall properly, he's in the space business (NASA) and needs the rad
hard that only Actel seems to provide.  So far it is the only really
good reason I've seen to select Actel over other vendor's devices!

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 8692
Subject: Re: bypass for 68 pin PLCC
From: "John Eppler" <jeppler@fastcomm.com>
Date: Tue, 20 Jan 1998 15:54:15 -0500
Links: << >>  << T >>  << A >>
Arnold,

We use one for under a PGA socket made by Circuit Components.  Ring a bell??

John R. Eppler
Manager, QA & Mfg. Eng.
FastComm Communications Corp.
jeppler@fastcomm.com
Switchboard (703) 318-7750
Direct Dial (703) 318-4342
FAX             (703) 787-4625
Pager (Nat'l)(888) 929-8090
acbel wrote in message <6a20v9$h13@bgtnsc01.worldnet.att.net>...
>They fit between the socket and the circuit board.  I used some of these 3
>years ago but I have forgotten who makes them and where they are available.
>They were quite effective and I would like to source them again.  Any help
>would be appreciated.
>
>Arnold Beland
>
>email   acbel@worldnet.att.net
>
>
>
>
>


begin 666 John R. Eppler.vcf
M0D5'24XZ5D-!4D0-"DXZ17!P;&5R.TIO:&X[4BX-"D9..DIO:&X@4BX@17!P
M;&5R#0I/4D<Z1F%S=$-O;6T@0V]M;75N:6-A=&EO;G,@0V]R<"X[36%N=6%F
M86-T=7)I;F<-"E1)5$Q%.DUA;F%G97(L(%%!("8@344-"E1%3#M73U)+.U9/
M24-%.C<P,RTS,3@M-#,T,@T*5$5,.TA/344[5D])0T4Z-S S+3(V-"TY-C0R
M#0I414P[5T]22SM&05@Z-S S+3<X-RTW-C(U#0I414P[2$]-13M&05@Z-S S
M+3(V-"TY-C0R#0I!1%([5T]22SH[-S S+3,Q."TW-S4P.S0U-#<R($AO;&ED
M87D@1')I=F4L(%-U:71E(#,[4W1E<FQI;F<[5D$[,C Q-C8[55-!#0I,04)%
M3#M73U)+.T5.0T]$24Y'/5%53U1%1"U04DE.5$%"3$4Z-S S+3,Q."TW-S4P
M/3!$/3!!-#4T-S(@2&]L:61A>2!$<FEV92P@4W5I=&4@,STP1#TP05-T97)L
M:6YG+"!602 R,#$V-CTP1#T-"CTP055300T*0412.TA/344Z.SLQ,34R,R!(
M96%R=&AS=&]N92!#;W5R=#M297-T;VX[5D$[,C Q.3$M-#0Q,3M54T$-"DQ!
M0D5,.TA/344[14Y#3T1)3D<]455/5$5$+5!224Y404),13HQ,34R,R!(96%R
M=&AS=&]N92!#;W5R=#TP1#TP05)E<W1O;BP@5D$@,C Q.3$M-#0Q,3TP1#TP
M055300T*55),.FAT=' Z+R]W=W<N86YG;&5F:7)E+F-O;2]V82]%<'!L97(O
M#0I54DPZ:'1T<#HO+W=W=RYF87-T8V]M;2YC;VTO#0I%34%)3#M04D5&.TE.
M5$523D54.FIE<'!L97) 97)O;',N8V]M#0I%34%)3#M)3E1%4DY%5#HW-3<R
B,2PQ-C,R0$-O;7!U4V5R=F4N8V]M#0I%3D0Z5D-!4D0-"@``
`
end

Article: 8693
Subject: Re: Vantis Enters FPGA Market Unveiling New Variable-Grain-Architecture Devices With Industry Leading Performance
From: scott.thomas@vantis.nospam.com (Scott Thomas)
Date: Tue, 20 Jan 1998 20:57:53 GMT
Links: << >>  << T >>  << A >>
Our web site now has the VF1 information and datasheet. You can find
it at http://www.vantis.com/products/overview/vf1/vf1_announce.html

Strictly speaking, it was MMI that second-sourced the Xilinx parts.
This is Vantis' first FPGA. I guess two company name changes wipes the
slate clean ;-)

Scott

On Mon, 19 Jan 1998 17:26:49 +0000, Tim Forcer
<tmf@ecs.soton.ac.uk.nojunk> wrote:

>Scott Thomas wrote:
>> 
>>...Vantis, an AMD company, today is entering the FPGA market with an
>>innovative family of Variable-Grain-Architecture(TM) devices, the VF1
>>Series, and powerful new Design-Direct(TM) software.
>
>>...absolutely enormous cut...
>
>>Type http://www.vantis.com ...cut..
>
>And find nothing there about this news!
>
>Also, shouldn't this strictly be "RE-entering the FPGA market"?  Didn't
>AMD second-source Xilinx at one time?
>
>Tim Forcer               tmf@ecs.soton.ac.uk
>Department of Electronics & Computer Science
>The University of Southampton, UK
>
>The University is not responsible for my opinions

Article: 8694
Subject: Re: PCI question
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 20 Jan 1998 21:58:58 GMT
Links: << >>  << T >>  << A >>
In article <01bd1ead$c3ebade0$aa49bacd@drt3>,
Austin Franklin <dark7room@ix.netcom.com> wrote:
>Alexandre Pechev <A.Pechev@rdg.ac.uk> wrote in article
><69adi8$586$1@susscsc1.reading.ac.uk>...
>> Hi,
>> Does anybody know
>
>> is it possible to access a PCI's board resources from
>> another PCI board without the CPU?
>
>Yes, assuming that by CPU you mean as in an x86 based system, the CPU you
>are referring to is the x86 on the system board, as opposed to a CPU on the
>PCI board...

But... does this work for conmfiguration space?

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 8695
Subject: Re: SDRAM Interface from an FPGA
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 20 Jan 1998 22:12:10 GMT
Links: << >>  << T >>  << A >>
In article <34BD0834.2D@wgate.com>, Todd KLine  <tkline@wgate.com> wrote:
>Hello,
>
>Is anyone doing a synchronous DRAM interface in an FPGA?  If so, at what
>speeds?  This is for ASIC prototyping only, so FPGA cost is not a big

>
>SDRAMs are rated at speeds up to 100 MHz.  When my boss tells me he
>wants to do this in an FPGA, I just look at him funny.

I've done a 50MHz SDRAM controller in a 4013e-3, but it should be possible
to go all the way up to 100MHz without a problem with the right fpga (say a
3142a-1 or -09).

The SDRAM controller is pretty simple, and everything can be pipelined. 
It's a burst device (I burst 4 words at a time), so the address counter only
needs to be 25MHz (and I use LFSR for the counter, so even that could be
much faster).

The other issue is clock skew between the FPGA clock and the SDRAM clock. 
At 50MHz this was no problem, but at higher speeds it probably will be.  You
may have to add delay lines to minimize the skew.  I'm actually feeding the
clock through the FPGA, so you get a slight variation for each run of the
place & route.  Also you can insert an inverter for a big effect.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 8696
Subject: this is a test
From: Bill Carter <bill@xilinx.com>
Date: Tue, 20 Jan 1998 14:49:14 -0800
Links: << >>  << T >>  << A >>
Please disregard.

Article: 8697
Subject: FPGA / Data Array help in Denver Colorado
From: bbkierst@aol.com (BBKierst)
Date: 20 Jan 1998 23:02:38 GMT
Links: << >>  << T >>  << A >>
sorry to intrude, but i have multiple openings in denver that i could use help
on...

anyone you know that might be interested in this bronco town

brian
Article: 8698
Subject: XC4000Xl IOB switch. charact. ???
From: kho@phobos.gent.bg.barco.com (Kim Hofmans)
Date: 20 Jan 98 15:03:09 CET
Links: << >>  << T >>  << A >>
Hi,

in version1.4 of the Switching Characteristics I read :

From pad through Global Low skew buffer to any clock 2.8ns for
a XC4010XL-2 (p 4.71)

From Pad to clock with no delay 1.5ns (p4.78)

Input Setup time using Global Low skew and IFF (full delay): 7.8ns (p4.76)

7.8ns is much larger than 4.3ns(1.5ns+2.8ns). 
So why the 7.8ns ? 

And how can I obtain the actual Pin-to-pin Setup and hold when using
the timing analyzer ?

thnx in advance,

Kim


Article: 8699
Subject: Re: XC4000Xl IOB switch. charact. ???
From: kho@phobos.gent.bg.barco.com (Kim Hofmans)
Date: 20 Jan 98 15:16:12 CET
Links: << >>  << T >>  << A >>
In article <1998Jan20.150309@phobos.gent.bg.barco.com>, kho@phobos.gent.bg.barco.com (Kim Hofmans) writes:
> Hi,
> 
> in version1.4 of the Switching Characteristics I read :
> 
> From pad through Global Low skew buffer to any clock 2.8ns for
> a XC4010XL-2 (p 4.71)
> 
> From Pad to clock with no delay 1.5ns (p4.78)
> 
> Input Setup time using Global Low skew and IFF (full delay): 7.8ns (p4.76)
> 
> 7.8ns is much larger than 4.3ns(1.5ns+2.8ns). 
> So why the 7.8ns ? 
>

I forgot,

I can't find in the data sheets the Input Setup time for the IFF using the
global low skew buffer with no delay. So I'm using the specs with full delay.
But still, 7.8ns is a lot when I compare this with the XC4000E (6ns with delay)

Kim

 
> And how can I obtain the actual Pin-to-pin Setup and hold when using
> the timing analyzer ?
> 
> thnx in advance,
> 
> Kim
> 
> 


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