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 8700

Article: 8700
Subject: Re: XC4000Xl IOB switch. charact. ???
From: Brad Taylor <Brad.Taylor@xilinx.com>
Date: Tue, 20 Jan 1998 18:59:13 -0800
Links: << >>  << T >>  << A >>
Kim Hofmans wrote:
> 
> 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
> >
> >

Well actually you can't (obtain the actual Pin-to-pin Setup and hold
when using the timing analyzer).

You can determine the pin-pin specs as follows:

1- If in full-delay IOB mode. 
 Pin-Pin-setup is specified as Tpsd (7.8ns for XC4010XL-2). The 44%
larger      XC4013XL-2 actually has a better setup of 6.0ns (don't ask
why).
 pin-pin-Hold is 0ns

2- If in no-delay IOB mode and using the input FF in the IOB, 
 Pin-Pin-Setup is the same as the parameter specified as Tpick,  (1.5ns)
 Pin-Pin-Hold is the same as the clock delay from the clock pad to the
IOB's clock input pin. You can use the value provided by the timing
analyser or the max value in the AC specs. The clock delay for the
XC4010XL-2 can range from 
less than 1.0ns to 2.8ns. The range reflects the amount of clock loading
and the particular clock buffer used. The BUFGLS buffer delay is
guaranteed to be less than  2.8ns, while a BUFGE(#1,2,5,6) delay can be
as low as 1.1 ns for 16 loads along the top edge of the die. At any rate
the use of no-delay mode requires a positive hold time. (This might be
OK for your particular requirements)

3- If in no-delay IOB mode and using the input FCL (Fast Capture Latch).
Pin-Pin-Setup is the same as the parameter specified as Tpickf,  (2.1ns)
Hold is calculated as above (same as internal clock delay)

If this seems like it is too complicated, and that it should be handled
by the timing tools, well ... I'd have to agree.

I hope this helps
-
Brad   
 




-- 
====================================================================
 Email:   brad.taylor@xilinx.com 
 Phone:   1-408-879-6976
 Fax:     1-408-879-4676
 Address: 2100 Logic Drive, San Jose, Ca. 95124
====================================================================
Article: 8701
Subject: Re: XC4000Xl IOB switch. charact. ???
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 21 Jan 1998 03:53:53 GMT
Links: << >>  << T >>  << A >>
In article <1998Jan20.151612@phobos.gent.bg.barco.com>,
Kim Hofmans <kho@phobos.gent.bg.barco.com> wrote:
>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 can only guess the delay element added to the D pin of the IFF
can vary its delays among speedfiles from 2.8ns to  around 6ns.
Even if the range is tighter, Xilinx will make its numbers
as conservative as possible.


>>
>
>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
>> 
>> 


Article: 8702
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 21 Jan 1998 04:04:08 GMT
Links: << >>  << T >>  << A >>
rk said:
: > 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.

rk adds:
yes, you are correct.  it was in day job the assignment from big-shot was
to implement pci in actel - and it quickly became obvious when reading pci
books and spec that 100% compliance with act 3 'a' series was not going to
happen.  and people who claimed to have done it, when asked some specific
questions, admitted that they were not 100% "legal."  perhaps in writing i
should have put more emphasis on the "well, not the most trivial circuit." 
 and i'm surprised stu didn't jump me first on that one, perhaps he
understands my sarcasm a bit or perhaps he's mellowing! ;) [end of the
story: pci was not used on that project for a variety of reasons with the
lack of 100% compliance not being the major issue since that requirement
could be waived without loss of system integrity].  btw, as an aside, in
status meeting at day job today one project lead engineer told of their
plans to do both initiator and target pci in actel.  i shall not comment on
that here but you guys feel free to say what you think ;)

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 ;-).

rk replies:
hmmmm ... sounds like you're trying to start an actel-xilinx shooting
match; that you can take up with actel guys who have popped in here from
time to time or whoever [or is it whomever ;)] you wish to - me, i'm just
interested in looking at different methodologies, technologies, etc.  

but me driving a mustang II?  i think that's a bit out of line, really; and
quite insulting.  '68 f'bird, '70s trans ams are more my style.  you know,
you still see some trans ams around from the good years, many banged up and
with rust from the NY environment, some individuals don't take them that
seriously, and, well, the t.a.'s do blow the doors off a good number of
fancier looking, newer cars, humiliating their drivers.  and t.a.'s corner
really well too, especially with the ws6 package, but you have to look a
bit close to see what it has w/out driving it.

in actuality most of my designs at jobs have been in actels (have done
pals, some alteras, some chip express [qyh500, cx2001], quicklogic, dyna
chip).  i have, for the most part, been quite happy with the actel devices,
the architecture, and their software.  and a fair number of customers like
the fact that the program is hardwired in them.  while not applicable to
all jobs such as those that require re-programmability (as opposed to
designers who design by trial-and-error - this comment is not intended
towards you), for many applications antifuse programmability is considered
a plus by the customers.  for day job, certain environmental requirements
more or less dictate that if any fpga's be used, select actel models are
the device of choice for a number of different reasons, storage technology
only being one of them.

i did do boards with xilinx on them many years ago (other engineers did the
xilinx) and have "good" memories of the designers finishing up the place
and route by hand - your posts have reminded me of that ;).  (just some
return fire pete, no offense intended).  having done a fair amount of hand
3.0 um cmos design in school (that should date me pretty well) that never
looked very pleasant.

getting back to the original topic, it has been a good discussion of how
engineers work with different tools, architectures and devices.  on one
hand we had HDL-centric points of view and others who are schematic-based
with hand placement of the fpga and others who are in the middle.  some of
the differences are probably individual style, application dependent, and
others technology related - it would be interesting to explore this
further.

and it's interesting to compare the performance of the different systems
and methodologies.  for example, i did a 36-bit xor design with little
effort for a baseline (using automagic p&r and a macro generator) for a
relatively simple architecture which i previously described.  while it was
the actel c-module (act 2,3 and their derivatives) one would note that it
is similar to the module used in the chip express cx2001 series (which
somewhat resembles the act 1).

so, perhaps we can pick up some data on designer efficiency and technology
performance to close out this thread.  

	how long will it take you to equal or exceed the performance of the actel
macro 
		generator, using hand design techniques, for the 36-bit xor?

	using hand placement techniques in the technology you use for pci, what
		reg -> 36-bit xor -> reg delay is required (please include tskew and
		tsu) for worst-case commercial conditions?

this is not an actel vs. xilinx vs. whomever question, as i have no stake
in the outcome (some others may, and they can play too), as my choice of
fpga is frequently determined by other criteria.  perhaps stu will come in
the fastest with his orcas.  or perhaps those new pasic3's.  or you or pete
with the xilinx.  or actel with an optimized circuit.

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

austin:
: seriously, but just enough to let you know they are still out 
: there....somewhere..for some reason (though that reason escapes me ;-).

rk:
hmmmm ... actually i see quite a few of them around for many sorts of
applications.  just saw a high performance board pic. in a magazine with a
1425.  i saw a high-speed ground telemetry system recently filled up with
actels (1460s).  popped open my hp scope - saw an altera in the 'puter
part, an actel in the data acquisition part.  perhaps you need to get out a
bit more ;)

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

have a good evening,

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------

Article: 8703
Subject: Re: complex number challenge
From: Jean-Marc REMONDEAU <jeanm@xilinx.com>
Date: Wed, 21 Jan 1998 11:12:36 +0000
Links: << >>  << T >>  << A >>
You could also write as the Golub's Method :

(a+jb)(c+jd) = [ac-bd] + j[ad+bc]

		= [(a+b)(c-d) + ad-bc] +j[ad+bc].

Has the advantage of computing one part, the imagin, quickly, then
computing the other part.
Can be usefull when I part and R part are multiplexed on a BUS.

Michael P. Hayes wrote:
> 
> > In article <34C4FAAA.F9939DD8@ti.com>, tim massey <t-massey1@ti.com> writes:
> > complex multiply:
> > (a+jb)(c+jd) = [ac-bd] + j[ad+bd]
> > I remember reading that this can be performed in 3 multiplies and 5
> > adds.  But I have forget how.  Can anyone show me how?
> 
>  (a+jb)(c+jd) = [ac-bd] + j[ad+bc]
>               = a(c+d) - d(a+b) + j[a(c+d) - c(a-b)]
> 
> There is little advantage to be gained on most processors these days
> where a multiply is as fast as an add.
> 
> Michael.
Article: 8704
Subject: FreeCore Library - a growing web site
From: Rune Baeverrud <r@acte.no>
Date: Wed, 21 Jan 1998 15:41:27 +0100
Links: << >>  << T >>  << A >>
FreeCore Library - a growing web site

Thanks to the contributions from many CPLD and FPGA designers, my
FreeCore Library web site - dedicated to users of Altera programmable
logic - is growing in size almost every day.

Today I would like to thank the following people for their
contributions:

Woody Johnson for his Linear Feedback Shift Register (LFSR)
Frank Rodler for his Dynamic RAM Controller
Iain Rankin for his Corner Bender function
Steven Groom for his many submissions on math functions
Peter Szymanski for his Byte Wide CRC32 Generator/Detector

Best Regards,
Rune Baeverrud
The FreeCore Library
http://193.215.128.3/freecore
Article: 8705
Subject: Re: FPGA core for ASIC?
From: Dmitry Cherniavsky <cdm@NOSPAM.javad.ru>
Date: 21 Jan 1998 19:04:36 +0300
Links: << >>  << T >>  << A >>
"D.H. Chung" <dhchung@soback.kornet.nm.kr> writes:

> 
> You can have the IP vendor list from Altera's AMPP partner catalog, who
> provide core for Altera PLDs.
> 

May you misunderstood me. I am looking for ASIC implementation of FPGA
functionality, that can be placed along with other modules inside
ASIC.

-- 
 Dmitry Cherniavsky,
 ASIC designer.
 MailTo:cdm@javad.ru
Article: 8706
Subject: Re: FPGA Info.
From: rdamon@BeltronicsInspection.com (Richard Damon)
Date: Wed, 21 Jan 1998 17:40:50 GMT
Links: << >>  << T >>  << A >>
Srikanth Gurrapu <gurrapu@ti.com> wrote:

>Hi, All,
>
>We are currently doing  a project which requires implementation of
>around 
>25K gate-logic and 2K-byte RAM.
>
>We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software.
>But, looks like the XACT5.2.1 has support only upto XC4025E with 25K
>gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can
[snipped]
>
>Also, can somebody recommend if there are any Altera devices which can
>do this efficiently 
>than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM...
>
>We can buy Xilinx new software M1.3 which has support for larger FPGAs
>and VITAL-support
>for backannotation, but is any Altera-approach going to be cheaper?
>
>Any opinions, suggestions or pointers are welcome.
>
>Thanks,
>Srikanth Gurrapu,
>Texas Instruments, Inc.
>gurrapu@ti.com.

The Altera 10K40 has 2k byte memory and 40k typical gates (it has 2300 logic
elements). This may fit your requirements. Note that the 10k series gate count
is a fuzzy spec, they claim a "usable" gate count of 29k to 93k gates, this
variation is mostly based on how you use the rams. I believe the lower numbers
are using the ram as a look-up rom and the higher is using it all as Ram.

How this helps,

-- 
richard_damon@iname.com (Redirector to my current best Mailbox)
rdamon@beltronicsInspection.com (Work Adddress)
Richad_Damon@msn.com (Just for Fun)
Article: 8707
Subject: Re: FPGA core for ASIC?
From: Simon Pegg <simon_pegg@csi.com>
Date: Wed, 21 Jan 1998 18:34:18 +0000
Links: << >>  << T >>  << A >>
Visist Xilinx's web page at http://www.xilinx.com and look for info on the
LogiCore and AllianceCore programs.

D.H. Chung wrote:

> You can have the IP vendor list from Altera's AMPP partner catalog, who
> provide core for Altera PLDs.
>
> Thanks
> D.H.
> Dmitry Cherniavsky ÀÌ(°¡) ¸Þ½ÃÁö¿¡¼­ ÀÛ¼ºÇÏ¿´½À´Ï´Ù...
> >  There are now a lot of IP cores makers around, that make business on
> >providing cores for the system-on-a-chip. Does anybody produce FPGA
> >cores, since FPGA is also part of system often. Does it possible at all?
> >--
> > Dmitry Cherniavsky,
> > ASIC designer.
> > MailTo:cdm@javad.ru



--

Simon Pegg

simon_pegg@csi.com


Article: 8708
Subject: Re: UART Spec
From: Simon Pegg <simon_pegg@csi.com>
Date: Wed, 21 Jan 1998 18:37:49 +0000
Links: << >>  << T >>  << A >>
You may want to have a look at http://www.memecdesign.com

they have some FPGA cores and teh xilinx web page http://www.xilinx.com will
also have some info on IP cores under AllianceCore program

Peter wrote:

> 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.



--

Simon Pegg

simon_pegg@csi.com


Article: 8709
Subject: Opinions of My FPGA - Like Chip Design Wanted
From: microprocsobsolete@angelfire.com
Date: Wed, 21 Jan 1998 12:53:21 -0600
Links: << >>  << T >>  << A >>
I am looking for people's opinions of my design for a FPGA / ASIC - like
integrated circuit design that I hope will make microprocessor - based
systems obsolete because it allows systems to be built that are as easy
to program as microprocessor - based systems, but as fast as systems
specially designed with semi - custom logic chips.

I have posted a description of the chip at
http://members.tripod.com/~ChipMaster and am in the process of adding to
that description, though there already is a LOT there.

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 8710
Subject: Destination FPGA
From: "HDLsRFun" <brownsco@frii.com>
Date: Wed, 21 Jan 1998 13:28:35 -0700
Links: << >>  << T >>  << A >>
Check it out at www.destinationfpga.com.


Article: 8711
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Wed, 21 Jan 1998 17:02:52 -0500
Links: << >>  << T >>  << A >>
> 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 ;-).
> 
> rk replies:
> hmmmm ... sounds like you're trying to start an actel-xilinx shooting
> match; 
> 
> but me driving a mustang II?  i think that's a bit out of line, really; and
> quite insulting.

I wasn't insinuating you DRIVE a Mustang II, but Actels are analogous TO 
a Mustang II.  I thought the analogy quite good ;-)  Nor was I trying to 
start a 'war', was only ribbing you about your choice of technologies (if 
you can call it that ;-).

> i did do boards with xilinx on them many years ago (other engineers did the
> xilinx) and have "good" memories of the designers finishing up the place
> and route by hand - your posts have reminded me of that ;).

Haven't had to do that in 5 years or more...

> 3.0 um cmos design 

Why not just wire wrap?

> austin:
> : seriously, but just enough to let you know they are still out 
> : there....somewhere..for some reason (though that reason escapes me ;-).
> 
> rk:
> hmmmm ... actually i see quite a few of them around for many sorts of
> applications.  just saw a high performance board pic. in a magazine with a
> 1425.  i saw a high-speed ground telemetry system recently filled up with
> actels (1460s).  popped open my hp scope - saw an altera in the 'puter
> part, an actel in the data acquisition part.  perhaps you need to get out a
> bit more ;)

I guess it depends on 'where' and 'with whom' you hang....  I rarely run 
into any Mustang IIs in my neck of the woods ;-)

Austin
Article: 8712
Subject: Re: PCI question
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Wed, 21 Jan 1998 17:08:41 -0500
Links: << >>  << T >>  << A >>
In article <En3rqA.9p6@world.std.com>, jhallen@world.std.com says...
> 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 configuration space?

Configuration space is accessed by /IDSEL, and *usually* /IDSEL is driven 
by one of the upper address lines.  It also requires the COMMAND part of 
PCI cycle to indicate a 'Configuration Read' or 'Configuration Write'.  
Given this, if your PCI Master can generate these cycles, then you can 
get at configuration space....if not, then no, you can't get at 
configuration space.

How will you determine which address bit drives which /IDSEL (if it is 
even implemented that way...it is only a suggestion in the spec) if you 
plan on working in *any* PCI system?

Austin
Article: 8713
Subject: Re: SDRAM Interface from an FPGA
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Wed, 21 Jan 1998 17:10:01 -0500
Links: << >>  << T >>  << A >>
In article <En3sCB.Aq3@world.std.com>, jhallen@world.std.com says...
> 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.

Tell me more....how did you generate the clocks?

Thanks,

Austin
Article: 8714
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: husby@fnal.gov
Date: Wed, 21 Jan 1998 16:22:05 -0600
Links: << >>  << T >>  << A >>
In "richard katz" <stellare@erols.com.NOSPAM> wrote:
> 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.

Numbers for an ORCA 2T06-5 (worst case):

1)  16.76 ns   No optimizations,  timing driven routing
    14 PFU     Time to enter schematic:  1 minute

2)  10.29 ns   Mapping constrained on schematic
    10 PFU     Time to enter schematic: 10 minutes

3)   8.23 ns   Mapping and hand placement
    10 PFU     Time to enter schematic: 10 minutes (same as above)
               Time to place blocks:     2 minutes

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 8715
Subject: Graphical VHDL tools and FPGA design
From: vincent@kodak.com (John Vincent)
Date: 21 Jan 1998 22:42:39 GMT
Links: << >>  << T >>  << A >>
  As a slight tangent to the thread on using schematics vs. HDL, I
was wondering what kind of experience people have had with graphical
VHDL tools, particularly comparative evaluations. In particular, I
am wondering if anyone has any experience using Escalade DesignBook?
They have (in addition to Block Diagram, Finite State Machine, Flow
Chart, and Truth Table editors) what they call ModuleWare, which are
libraries of parameterizable functions, allowing designers to
graphically enter designs (create schematics). HDL can be used for
any block desired. HDL code can then be generated for all or any
portion(s) of the design. Blocks can have alternate implementations
(architectures), affording a way to address portability concerns.
It seems to be a good way to usen the strengths of both schematics
and HDL. Also helps designers transitioning to HDL. 

Thanks for your comments.
  JV
---

************************************************************************
 *******          *********
*******        *************   	John Vincent
******      ****************   	Eastman Kodak Company   
*****    *******************   	Equipment & Software Platform Center
****  **********************   	Digital Technology Center
*** ************************   	Elmgrove Plant Bldg. 1
****  **********************   	Rochester New York 14653-5211
*****    *******************   	Phone:  716-726-4607
******      ****************   	Fax:    716-726-7131
*******        *************   	email:  vincent@kodak.com
 *******          *********
************************************************************************


=======================================================================
  Anything I say may or may not be my opinion, but certainly is not
  the opinion of my kind and generous Internet-enabling employer.
                     (How's that sound, boss?)
=======================================================================

Article: 8716
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 22 Jan 1998 02:41:31 GMT
Links: << >>  << T >>  << A >>
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 ;-).
 
rk replies:
 hmmmm ... sounds like you're trying to start an actel-xilinx shooting
 match; 

 but me driving a mustang II?  i think that's a bit out of line, really;
and
 quite insulting.

austin:
 I wasn't insinuating you DRIVE a Mustang II, but Actels are analogous TO 
 a Mustang II.  I thought the analogy quite good ;-)  Nor was I trying to 
 start a 'war', was only ribbing you about your choice of technologies (if 
 you can call it that ;-).

rk:
 hmmm ... ok, let's see if i can straighten this out.  

	1. oh, you weren't insinuating i DRIVE a mustang - i must have been
soooooooooooooooo confused.

	2. since mustang II's were, well, not such a hot car, you seem to be
saying the actel devices are analogous to that.  i suggest you take that up
with actel, not me.  specific technical issues i don't mind and and in fact
do enjoy discussing, which was the purpose of my posts (which you seem to
want to avoid).  responding to your sort of comments is out of scope of
what i want to do and what i am permitted to do.

	3. you weren't trying to start a 'war.'  oh, are you just naturally
obnoxious?

	4. since you were just ribbing me about my choice of "technologies" which
are obviously bad, i must be an idiot for selecting them. hmmmm, perhaps
you should understand the applications and read what's posted and written,
or perhaps ask a question, before you publicly rib and ridicule someone's
technical decisions.  while we can go into the details of this (and we did
last year as ray has recently pointed out), if i make different decisions
on technologies, perhaps select the technology YOU use, it would be a
technical disaster and quickly dismissed as ill-informed.  perhaps you
should stop, think, listen, and/or ask questions before you continually
shoot off your mouth.  sort of the advice we give raising children, but it
perhaps needs saying here (as private email to you bounced).

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

snipped from rk's summary of old school project, hand design/layout of a
cmos fifo:
3.0 um cmos design 

austin's remark, adding value to the newsgroup and the world at large:
Why not just wire wrap?

well, excuuuuuuuse meeeeeeeeeeeeeee [S. Martin, '77] for going to a public
school in the 'stone ages.'  guess we just wasted out time back then. 
instead of learning, analyzing, and doing technology we should have been
trained as assemblers.  perhaps we should have; i still stink at wire
wrapping and i'm horrible with the soldering iron.  yeah, and spending our
time designing and writing our own vlsi cad layout tools from scratch,
another waste - we should have stayed with our paper, crayons, scissors,
and scotch tape which got interesting when we went to double layer poly,
iirc (esp. for my friend who was color blind, goos sight should have been
on the prerequisites).  and of course another 'mustang II' decision, this
one made by our school - it was programmed in pascal!

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

austin:
seriously, but just enough to let you know they are still out 
there....somewhere..for some reason (though that reason escapes me ;-).
 
rk:
hmmmm ... actually i see quite a few of them around for many sorts of
applications.  just saw a high performance board pic. in a magazine with a
1425.  i saw a high-speed ground telemetry system recently filled up with
actels (1460s).  popped open my hp scope - saw an altera in the 'puter
part, an actel in the data acquisition part.  perhaps you need to get out a
bit more ;)

austin:
I guess it depends on 'where' and 'with whom' you hang....  I rarely run 
into any Mustang IIs in my neck of the woods ;-)

rk:
oh, i see, you don't even see any designs with loser technologies in them,
since you are so blessed. and perhaps the little joke was a bit subtle for
you in the 'dark room'.

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

rk:
oops, forgot to answer this one:

austin the magnificent:
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...

rk:
nope, didn't use the intel chip set with the bug.  happy?

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

well, attempting to have a technical conversation with you sort of failed -
i don't know why you bothered responding since you had so little to say and
in retrospect i did waste some time - that was my bad decision.

end of thread.


Article: 8717
Subject: Re: Xilinx Info.
From: "Ross Swanson" <swan000@erols.com>
Date: Wed, 21 Jan 1998 22:09:48 -0500
Links: << >>  << T >>  << A >>
Doesn't Atmel make a FPGA with a small (?) embedded RAM
--Ross

Srikanth Gurrapu wrote in message <34C383E7.71F9@ti.com>...
>Hi, All,
>
>We are currently doing  a project which requires implementation of
>around
>25K gate-logic and 2K-byte RAM.
>-------snip ------


Article: 8718
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 22 Jan 1998 04:04:25 GMT
Links: << >>  << T >>  << A >>
rk:
 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.

---------

husby:
Numbers for an ORCA 2T06-5 (worst case):

1)  16.76 ns   No optimizations,  timing driven routing
    14 PFU     Time to enter schematic:  1 minute

2)  10.29 ns   Mapping constrained on schematic
    10 PFU     Time to enter schematic: 10 minutes

3)   8.23 ns   Mapping and hand placement
    10 PFU     Time to enter schematic: 10 minutes (same as above)
               Time to place blocks:     2 minutes

----------

hi,

thanks for the reply.  just a short response here (been wasting too much
time on nonsense lately ;-)

first, outstanding results! 

to do something equivalent to your line #1, i did a quick timing driven
layout and the cycle time went down to 10.0 nSec.  here's the breakdown
(routing delays are included as the tool doesn't break them out
separately):

	DFC1B	2.5	f-f clk->q
	XOR2	2.3	tpd 2-input xor
	MX4	2.5	tpd 4-input mux
	MX4	2.4
	XOR2	0.0	combined into s-module
	DF1	0.3	tsu
           ----
           10.0

the function could probably be made faster by using resources specific to
certain members of the 42mx family - however, i kept the same netlist to
compare the act 3 technology vs. the 42MX devices and it is a bit late.

discussion, observations, and questions:

1. 42mx09-2 is signifcantly faster than the act 3 stuff for this function
(i currently use a lot of act 3).

2. there was a factor of 2 between timing driven placement and hand
placement for 2t06.  is that typical for this technology or just an
artifact of this simple circuit?  several commented earlier on the
importance of floor planning, hand placement, etc.

3. the basic timing model (graphical illustration in data sheet) for 42mx
predicts a slightly lower level of performance; the numbers in the tabular
section indicate that ~9.22 nS may be possible which is less than a 8%
improvement.  this is consistent with what was discussed earlier based on
my experience, that major benefits usually aren't obtained in the back end
of the design process by manual operatoins, for these types of devices.

thanks,

rk
Article: 8719
Subject: Re: Opinions of My FPGA - Like Chip Design Wanted
From: ed ngai <engai@sprintmail.com>
Date: Wed, 21 Jan 1998 21:34:48 -0800
Links: << >>  << T >>  << A >>
microprocsobsolete@angelfire.com wrote:
> 
> I am looking for people's opinions of my design for a FPGA / ASIC - like
> integrated circuit design that I hope will make microprocessor - based
> systems obsolete because it allows systems to be built that are as easy
> to program as microprocessor - based systems, but as fast as systems
> specially designed with semi - custom logic chips.

hi, so are you saying that you can re-program it like a flash part?
can you guarantee 100,000 write cycles  ?

ed
Article: 8720
Subject: Share modem, ISDN and cable modem 12029
From: pc88 <sbg88@pc88.net>
Date: 22 Jan 1998 07:26:10 GMT
Links: << >>  << T >>  << A >>
Do you want to share ONE Internet connection with the rest in your Family or office?
SYGATE is the software to do that. 

With features like Dial-On-Demand, it will connect your LAN to the ISP if
and only if there is access from your LAN to the Internet.

It is easier to use than proxy servers in that it doesn't require the setup in
each and everyone of your applications running on your PCs.

Free download from www.sygate.com

With one phone line, one modem and one ISP account, everyone in your office
or family can access the Internet from their own machine.

It works for Analog, ISDN modem and Cable modems.


													12029

Article: 8721
Subject: XC4000E CLB utilization
From: Ho Siu Hung <eg_hsh@stu.ust.hk>
Date: Thu, 22 Jan 1998 17:04:59 +0800
Links: << >>  << T >>  << A >>
Hello,

I go into problems making use of only one CLB to build a 5 variable
function.  While tied 4 of my inputs to the FMap and GMap, the last input
theoretically can be tied to the H1 to form a LUT with 5 inputs.  However,
synopsis FPGA complier always map this to 2 or 3 CLB without utilizing
HMaps.  Does anyone here have tried doing that?  How to explicitly specify
the use of HMaps as mux?

-------------------------------------------------------------------------------
| Best Regards, 	  +--------+   | Email: eg_hsh@stu.ust.hk	      |
| David Ho		  | ¦ó²Ðºµ |   |	cshosh@cs.ust.hk	      |
| Ho Siu Hung		  +--------+   |   	                              |
| University of Science and Technology |  ICQ#: 798357			      |
| Computer Engineering Year 3 (CPEG)   =======================================|
-------------------------------------------------------------------------------


Article: 8722
Subject: Re: Opinions of My FPGA - Like Chip Design Wanted
From: "Stephen Maudsley" <Stephen.Maudsley@btinternet.com>
Date: Thu, 22 Jan 1998 11:21:59 -0000
Links: << >>  << T >>  << A >>

microprocsobsolete@angelfire.com wrote in message
<885408319.1742471169@dejanews.com>...
>I am looking for people's opinions of my design for a FPGA / ASIC - like
>integrated circuit design that I hope will make microprocessor - based
>systems obsolete because it allows systems to be built that are as easy
>to program as microprocessor - based systems, but as fast as systems
>specially designed with semi - custom logic chips.


I've read the info and I can't see substantiation of your "easy to program"
claim. If I can paraphrase what I understand: you seem to have lots of state
machines that communicate state to adjacent state/datapath machines and then
you're proposing to program each state machine in "assembler code".

I can't see any "program model abstraction", have I missed it?

How do you load programs into this machine and start it executing?

How do you cope with so much of the machine active on every clock cycle?

Just a few thoughts

---------------------
Stephen Maudsley      Stephen.Maudsley@btinternet.com
esgem limited
Tel/Fax: +44-1453-521626  Mobile: +44-370-810991
---------------------


Article: 8723
Subject: PCI Bus
From: John Chambers <nospamjohnc@ihr.mrc.ac.uk>
Date: Thu, 22 Jan 1998 12:16:02 +0000
Links: << >>  << T >>  << A >>
I would like to port some simple PC ISA cards I have designed to the PCI
bus.  My first requirement will be to port a simple 16bit data I/O card
- trivial on the ISA bus but not on the PCI I think.  Can anyone
recommend an FPGA and associated library that could enable me to get
this done with the minimum of effort.  Any book references would also be
appriciated

	John
Article: 8724
Subject: Re: PCI Bus
From: "Ronan BARZIC" <barzic@worldnet.fr>
Date: Thu, 22 Jan 1998 14:09:30 +0100
Links: << >>  << T >>  << A >>

John Chambers a écrit dans le message <34C73882.4D6D@ihr.mrc.ac.uk>...
>I would like to port some simple PC ISA cards I have designed to the PCI
>bus.  My first requirement will be to port a simple 16bit data I/O card
>- trivial on the ISA bus but not on the PCI I think.  Can anyone
>recommend an FPGA and associated library that could enable me to get
>this done with the minimum of effort.  Any book references would also be
>appriciated
>
> John

    You can try the  PCI MacroFunction from PLDA (www.plda.com) for ALTERA
Flex10K/6K only
    You can freely download the macro and simulate your design

    Ronan BARZIC
    R&D Engineer
    Visio Nerf




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