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 20075

Article: 20075
Subject: Reed Solomon codes and Intelsat specs
From: "Pradeep Rao" <pradeeprao@planetmail.com>
Date: Thu, 27 Jan 2000 00:31:14 +0530
Links: << >>  << T >>  << A >>
Sir/Madam,

1. What are the applications that Reed solomon codes are best suited for ?
Why ?
   Can they be used in GSM ? Do convolutional codes perform better in GSM
systems ?
   Do RS codes find applications in wireless communications ? Please
explain.

2. Where can I find the following specs :
    Intelsat IESS-308
    RTCA D0-217 Appendix F, Revision D
    and the proposed ITU-TS SG-18(formerly CCITT SG-18) standards ?

I'm a student and I'll be glad if someone could lead me to the answers to
the above questions.

Thank You,
Regards,
Pradeep Rao




Article: 20076
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: "giuseppe giachella" <il_templare@hotmail.com>
Date: Wed, 26 Jan 2000 11:01:48 CET
Links: << >>  << T >>  << A >>

>The other thing I found that was causing the infinite loops was bugs in the
>design, not the program. I'm not sure of your design stage, but Quartus is
>poor at the early stage of designs. The culprit was Resets.



Xanatos, first of all thank you for the info about QUARTUS.

Just another question about those design bugs which cause fitter
infinite loops:
apart from the reset fanout, were some of them caused by design's
details incompatible with the hardware structure of the FPGA ?
(example:I remember a clock, placed on a dedicated low skew line in a Flex 
10K
and connected to an output pin in a design, caused an infinite loop in 
MAXPLUS2 due
to the impossibility to connect internal global signal to an output).

Can you remember other "categories" of design bugs which cause such loops ?

Thanks in advance.

Giuseppe Giachella
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com



 Sent via Deja.com http://www.deja.com/
 Before you buy.
Article: 20077
Subject: EEPROM based FPGAs
From: "George" <g_roberts75@hotmail.com>
Date: Wed, 26 Jan 2000 19:09:10 -0000
Links: << >>  << T >>  << A >>
Hi Folks,

EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike
SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they
are slower. Could you think about any other disadvantage? or advantage?
compared to SRAM based ones.

Cheers.


Article: 20078
Subject: Re: EEPROM based FPGAs
From: Ray Andraka <randraka@ids.net>
Date: Wed, 26 Jan 2000 19:26:34 GMT
Links: << >>  << T >>  << A >>
Actually, the EEPROM cells do not slow down the logic per se, as they are used
to control pass transistor switches rather than handling the signal directly.
However, the process for EEPROMs is a step behind the process for SRAM, so
there is more opportunity for the SRAM devices to be tweaked for maximum
performance.

That said, there are significant architectural differences between the EEPROM
and SRAM devices that have nothing really to do with the storage technology
that may make a device more or less suited to your application.  Personally, I
like the SRAM devices because they give you a sizable advantage in system debug
and test, as well as giving you the opportunity for using reconfiguration as
part of the processing.  The debug and test issues are addressed in the Radar
Environment simulator (MAPLD98) paper on my website.

George wrote:

> Hi Folks,
>
> EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike
> SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they
> are slower. Could you think about any other disadvantage? or advantage?
> compared to SRAM based ones.
>
> Cheers.

--
-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: 20079
Subject: FPGA's reconfigurable modes
From: anoriaki@comp.ufscar.br
Date: Wed, 26 Jan 2000 19:42:26 GMT
Links: << >>  << T >>  << A >>
Hi people,

     I need some informations about FPGA's reconfigurations mode like:
Full Reconfiguration, Partial Reconfiguration, Multiple-Context
Configuration, Dynamic Configuration, Striped Configuration and the most
important for me, Configuration Cloning.
     If anyone could help me ....... mail to: anoriaki@comp.ufscar.br

thanks.

Nori.



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20080
Subject: GSR in HDL on instantiated flip-flop primitives
From: Ray Andraka <randraka@ids.net>
Date: Wed, 26 Jan 2000 19:46:37 GMT
Links: << >>  << T >>  << A >>
 I've got two cases that are creating a problem with using the Virtex
GSR with flip-flop primitives for me:

1)  I've got a flip-flop that I need to have use the synchronous reset
that goes directly into the FF (virtex).  I also want it to start up
initialized with GSR. That flip-flop is instantiated as a primitive
(FDRE) in my code so that I can put RLOCs on it to place it from within
the code.  Normally, this could be handled at an RTL level with
appropriate coding, but where I'm instantiating the primitive, I don't
see a way of getting GSR in there too.

2) I've got a case where I instantiate a FDE and an SRL16E and place
them both in the same half of the slice.  The reset/clear on the FDE is
unusable in the design because it is shared with the SRL16E enable.  If
I instantiate an FDCE to get a GSR input, the tools don't seem to make
it into an FDE when they recognize the GSR, and it results in a mapper
failure.

Has anyone encountered this and found a suitable workaround (RTL coding
doesn't count, I need to specify placement).

--
-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: 20081
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: bobperl@best_no_spam_thanks.com (Bob Perlman)
Date: Wed, 26 Jan 2000 20:11:18 GMT
Links: << >>  << T >>  << A >>
On Tue, 25 Jan 2000 20:32:46 -0800, John Larkin
<jjlarkin@highlandSnipSniptechnology.com> wrote:


>thanks for the reference. The papers are interesting, but both ignore
>plane capacitance. A power-ground plane pair with a small dielectric
>gap (a few mills can be easily had) is in fact a very low impedance
>transmission line. Transients looking into the parallel planes (as I
>see with my TDR experiments) see low-Z transmission line in all radial
>directions.  My testing indicates that the highest impedance a chip
>pin sees is the via that reaches down from the pin to the power or
>ground plane; the planes themselves (if the dielectric gap is small)
>are very stiff for fast transients. Of course, if you need X colombs
>of charge to keep your chip happy, you'd better have n*X farads
>available somewhere to supply it. 

And that's the problem: not only do you need n*X farads somewhere, but
somewhere pretty close by.  It's well understood that it takes on the
order of 160ps for a signal to travel 1 inch on a trace embedded in
FR-4.  What's less well understood is that this limitation applies to
power planes, too, which, as you've said, are nothing more than very
low-impedance transmission lines.  If a capacitor is, say, 3 inches
from a chip, it takes ~1/2ns for the request for current to travel
from the chip to the capacitor , and another ~1/2ns for the current to
travel back to the chip.  And that's optimistic; the capacitor and its
connection to the board are inductive, slowing down the response even
further.  If the chip is attempting to switch outputs with a 1ns
risetime, by the time the 3-inch-away capacitor supplies current, it's
all over but the shouting.

To see if planes alone are enough to supply transient current, let's
consider the following example.  Suppose that an FPGA in a BGA package
is attempting, worst-case, to switch 100 outputs from LOW to HIGH, and
let's further suppose that the risetimes are 1ns.  If the outputs are
driving 50 ohm traces, the di/dt is 100*(3V/50 ohms)/1ns = 6A/ns (!).
(This is reduced somewhat by the output impedance of the FPGA drivers,
but drivers as low as 10-20 ohms are commonplace..)

If the board has two pairs of adjacent power and ground planes, and if
the power and ground planes in a pair are separated by a 5 mil
dielectric, we get approximately 2*200pf/in2 = 400pF/in2 of
capacitance.  Now the big question: how much plane capacitance can the
chip actually "see" when it's switching?  My general rule of thumb is
to include only the capacitance that's within risetime/6 of the chip,
so that the current request can get to the capacitance and back before
the transition is more than 1/3rd of the way done.  But in this case
I'm going to load the dice in your favor and double that distance to
risetime/3, or 1/3 ns.  The effective distance is therefore about 2
inches, or the time a signal can travel in 1/3 ns.  So we'll assume
that any point on a power plane within a radius of 2 inches of the
chip can contribute current to the transitions.  We have a total of
pi*2*2*400pf = 5nF at our service.

The droop on the plane attributable to the transition is therefore:

  de = dt * i/C = 1ns * 6A/5nF = 1.2V

That's not good.  Simply put, there isn't enough capacitance on the
planes to help us completely manage Vcc droop.  

At this point it may be tempting to point to all of the capacitance on
the remainder of the plane, but it doesn't help us, either; by the
time we can communicate with it, the transition is supposed to be
over.

We could improve things somewhat by using a couple of buried
capacitance layers instead of the closely-spaced planes, thereby
roughly doubling the available capacitance.  But that still leaves us
with lots of Vcc noise.
   
This may seem like an outrageously pessimistic example.  In fact, I
think it's optimistic.  Consider the following:

 - Many modern-day chips have risetimes faster than 1ns.  If you
really want to be depressed, re-run the numbers with a 0.5ns risetime.

 - I haven't accounted for the current needed to supply the internal
switching requirements of the chip.

 - I've assumed that the chip has exclusive use of all the plane
capacitance within a 2" radius.  I haven't seen many high-speed boards
that are this sparsely populated.

In short: we need some (relatively) high-speed bypass capacitance
reasonably close (tr/6) to the chip to supply the current that the
plane can't.  And we probably need more capacitors than would be
indicated by voltage droop calculations alone, because these caps and
their interconnects are both inductive and resistive, and we can
mitigate both by putting multiple caps in parallel.  What's more, as
the Sun paper indicates, we need low-inductance hook-ups for these
capacitors, or they'll be useless.

Irrelevant aside:  I've always found it ironic that it's actually
easier to design power distribution for ECL, which despite its
high-speed reputation is more or less constant-current, than it is to
design power distribution for CMOS.  It's the current changes that
kill us.  

>I think my point is that, for properly designed multilayer boards, the
>planes themselves are an enormous asset in supplying low-impedance
>power for fast transients. My TDR tests indicate that additional
>bypass caps can be scattered about, and improve the apparent
>capacitance a pin sees, without having to be really close to every
>pin.  I have never observed the multiple-resonances effects predicted
>by the Sun paper Spice models for paralleled caps; I suspect they
>didn't model the planes.

The folks at Sun are aware of the effects of plane capacitance; in
fact, the paper I cited mentions the role of the power plane in
suppressing spikes in the >200MHz region.  There's also a reference to
a to-be-published paper on power plane analysis for CMOS power
distribution systems.  

I agree that the planes are an enormous asset in power distribution;
they are of greatest help at higher frequencies.  But in many cases,
they simply aren't enough by themselves.

>As I get braver, I am using fewer bypass caps, spread farther apart,
>and am still measuring very clean Vcc and ground noise levels. As
>parts get smaller, and have *lots* of pins, one eventually will be
>faced with brickwalling the backside of the board with thousands of
>head-to-butt capacitors. This will eventually get silly, and our
>Manufacturing people will stop saying 'hello' in the hallways.

I find that the manufacturing folks are accommodating if they are told
why something is being done, and if that something prevents a board
spin.  

Take care,
Bob Perlman

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 20082
Subject: Design security
From: +Pablo+ <anon@vapor.net>
Date: Wed, 26 Jan 2000 15:11:21 -0500
Links: << >>  << T >>  << A >>
On Fri, 31 Dec 1999 11:20:44 -0600, "Larry Edington"
<larryeSpam.Me.Not@centuryinter.net> wrote:

>I'm looking at an FPGA for project I'm working on and am concerned about
>security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for
>me.
>
>I'm looking at Altera and Xilinx.
>
>It appears that most FPGA's are programmed with a serial eeprom. I'm
>concerned about the security the data in the eeprom. What keeps someone from
>simply copying your eeprom to duplicate your FPGA's programming?

You can also load from a microprocessor or part of a parallel eprom
elsewhere in the system. It would take a lot more work for someone to
reverse engineer if done this way.

In an extreme case, a missile containing these devices is loaded at
boot time from the launcher. Once launched, the hard configuration
data is no longer part of the system. Once power is lost, the
configuration is also lost. Failed missiles cannot be reverse
engineered by the enemy.

>
>Maybe this is a stupid question but I'm still learning about FPGA's. Since I
>will have some encryption / decryption functions in the FPGA, this is a big
>concern for me. What do you need to do to protect your design when using
>FPGA's ?
>
>thanks,
>Larry E.
>Remove Spam_me_not to reply via email.
>
>
>

Article: 20083
Subject: Re: EEPROM based FPGAs
From: rk <stellare@nospam.erols.com>
Date: Wed, 26 Jan 2000 15:16:38 -0500
Links: << >>  << T >>  << A >>
Yes, EEPROM technology is slower than SRAM.  This comes into play in two
areas.  First, for loading, as all the configuration bits need to be written,
or perhaps partial reconfiguration if an architecture would support that.
Secondly, for applications that use the configuration memory as logic (i.e.,
using LUTs as memories).  For switching, though, I don't think it will make
that much difference, since the cell sense mechanism needs to ultimately bias a
FET pass transistor.

In practice, the Xilinx designs, for example, are frequently used to drive a
process at a semiconductor foundry.  The EEPROM cells will have extra
processing steps and so should be lagging by perhaps a generation or two,
giving just slower chips.  Additionally, device architecture will play a big
role as does the application.  A hard-wired carry chain in the latest process
for artithmetic operatios will be difficult to beat.

Please take the above with a grain of salt, just got done shoveling yet again
(thanks to the snow plow blocking us in) and I'm wiped!

rk

====================

George wrote:

> Hi Folks,
>
> EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike
> SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they
> are slower. Could you think about any other disadvantage? or advantage?
> compared to SRAM based ones.
>
> Cheers.



Article: 20084
Subject: Re: EEPROM based FPGAs
From: rk <stellare@nospam.erols.com>
Date: Wed, 26 Jan 2000 15:30:52 -0500
Links: << >>  << T >>  << A >>
Oops, left off one item, in-circuit programming.  While not necessary in principle,
you may need to supply some odd-ball voltages to drive the programming element.
For example, the latest EEPROM-based FPGA device requires +16.5V and -12V
supplies.  Additionally, they have restrictions on driving I/O pins during
programming.  This is not a fundamental limit of the technology, as many
EEPROM-based devices have internal charge pumps to derive the required voltages,
giving the user a simple interface, say perhaps a voltage for the core and a
separate one for the I/O drivers.  EEPROMs such as the Seeq 28C256 have had this
for many years, letting the user run with a single +5VDC line.  Others, such as
some models made by Northrop-Grumman, allow either an internal pump to be used or
an external one to be provided.  They allow a choice for environmental reasons.

rk

=========================

rk wrote:

> Yes, EEPROM technology is slower than SRAM.  This comes into play in two
> areas.  First, for loading, as all the configuration bits need to be written,
> or perhaps partial reconfiguration if an architecture would support that.
> Secondly, for applications that use the configuration memory as logic (i.e.,
> using LUTs as memories).  For switching, though, I don't think it will make
> that much difference, since the cell sense mechanism needs to ultimately bias a
> FET pass transistor.
>
> In practice, the Xilinx designs, for example, are frequently used to drive a
> process at a semiconductor foundry.  The EEPROM cells will have extra
> processing steps and so should be lagging by perhaps a generation or two,
> giving just slower chips.  Additionally, device architecture will play a big
> role as does the application.  A hard-wired carry chain in the latest process
> for artithmetic operatios will be difficult to beat.
>
> Please take the above with a grain of salt, just got done shoveling yet again
> (thanks to the snow plow blocking us in) and I'm wiped!
>
> rk
>
> ====================
>
> George wrote:
>
> > Hi Folks,
> >
> > EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike
> > SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they
> > are slower. Could you think about any other disadvantage? or advantage?
> > compared to SRAM based ones.
> >
> > Cheers.



Article: 20085
Subject: What has happened to freecore.com ?
From: Steve Dewey <steve@s-dewey123.demon.co.uk>
Date: Wed, 26 Jan 2000 20:50:41 +0000
Links: << >>  << T >>  << A >>
Hi

Does anyone know what has happened to the FreeCore Homepage
(www.freecore.com)? 

I have not been able to get through since the start of this year.

Cheers
-- 
Steve Dewey
Remove 123 for email
Article: 20086
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: Steve Dewey <steve@s-dewey123.demon.co.uk>
Date: Wed, 26 Jan 2000 20:59:50 +0000
Links: << >>  << T >>  << A >>
One point in this debate is that Xylinx seem to put the DLLs into ALL
the Virtex and Spartan parts. Altera definitely only puts them into
certain speed grades/packages/device sizes. So you have to pay extra and
probably not use the speed grade, package, or device size that you
thought. 

It is my opinion that Altera literature is _almost_ misleading about
this: unless you read the small print, you could order a device, and not
realise that only the -x parts have these features.

It makes me really pissed, but there is no chance of the money for a set
of Xylinx tools at present, so I'm stuck.

-- 
Steve Dewey
remove 123 for email
Article: 20087
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 26 Jan 2000 21:06:25 GMT
Links: << >>  << T >>  << A >>
In article <zYiOLEAGB2j4EwGk@s-dewey.demon.co.uk>,
Steve Dewey  <steve@s-dewey123.demon.co.uk> wrote:
>One point in this debate is that Xylinx seem to put the DLLs into ALL
>the Virtex and Spartan parts. Altera definitely only puts them into
>certain speed grades/packages/device sizes. So you have to pay extra and
>probably not use the speed grade, package, or device size that you
>thought. 
>
>It is my opinion that Altera literature is _almost_ misleading about
>this: unless you read the small print, you could order a device, and not
>realise that only the -x parts have these features.
>
>It makes me really pissed, but there is no chance of the money for a set
>of Xylinx tools at present, so I'm stuck.

	How large a design are you dealing with?  Xilinx makes some
limited versions for students and small designs which are cheap.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 20088
Subject: Re: Viterbi decoder in FPGA
From: Thomas Burchard <100115.2621@CompuServe.COM>
Date: 26 Jan 2000 22:09:18 GMT
Links: << >>  << T >>  << A >>
Try http://www-ee.eng.hawaii.edu/~pramod/ee628/viterbi.html

This is a good starting point

Tbu


-- 
Thomas Burchard
Article: 20089
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: Ray Andraka <randraka@ids.net>
Date: Wed, 26 Jan 2000 23:10:49 GMT
Links: << >>  << T >>  << A >>
The DLLs aren't the only advantage the Xilinx has over Altera, at least for
arithmetic intensive designs.  See my previous rants on that for more
details.  If your device is small, you can get the student edition tools for
a song.  If it is a big design, the cost of the tools will be insignificant
compared to your medical bills from banging your head against the wall.
Besides, with the price difference for the Cadillac parts, it won't be many
parts before you've paid more than you would have for the Xilinx tools.  You
might talk to your FAE/local sales rep to see if you can get a break for
volume or just trying the tools out.  If it means gaining another account,
especially a potentially lucrative one, these guys have been known to deal a
little.

Steve Dewey wrote:

> One point in this debate is that Xylinx seem to put the DLLs into ALL
> the Virtex and Spartan parts. Altera definitely only puts them into
> certain speed grades/packages/device sizes. So you have to pay extra and
> probably not use the speed grade, package, or device size that you
> thought.
>
> It is my opinion that Altera literature is _almost_ misleading about
> this: unless you read the small print, you could order a device, and not
> realise that only the -x parts have these features.
>
> It makes me really pissed, but there is no chance of the money for a set
> of Xylinx tools at present, so I'm stuck.
>
> --
> Steve Dewey
> remove 123 for email

--
-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: 20090
Subject: CARRY CHAIN CIRCUIT in ORCA 3T
From: raja <raja@elec.uq.edu.au>
Date: Thu, 27 Jan 2000 12:34:44 +1000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------8D31918EB976B4BF08400CE5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hai folks

              do you anyone know about ORCA 3T series carry chain
1. what is the basic advanatge in ORCA 3T carry chain than XC4000 from
xilinx

 what are basic advanatges and disavantages in both of this


anyone knows this, i need your help
thanks in advance
  kamal

--------------8D31918EB976B4BF08400CE5
Content-Type: text/x-vcard; charset=us-ascii;
 name="raja.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for raja
Content-Disposition: attachment;
 filename="raja.vcf"

begin:vcard 
n:kamalanathan;Raja
tel;home:07  38761962
tel;work:07 33658849
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:raja@elec.uq.edu.au
fn:Raja kamalanathan
end:vcard

--------------8D31918EB976B4BF08400CE5--

Article: 20091
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 27 Jan 2000 02:48:41 GMT
Links: << >>  << T >>  << A >>
In article <388f1ed7.133032340@nntp.best.com>,
Bob Perlman <bobperl@best_no_spam_thanks.com> wrote:

>If the board has two pairs of adjacent power and ground planes, and if
>the power and ground planes in a pair are separated by a 5 mil
>dielectric, we get approximately 2*200pf/in2 = 400pF/in2 of
>capacitance.  Now the big question: how much plane capacitance can the
>chip actually "see" when it's switching?  My general rule of thumb is
>to include only the capacitance that's within risetime/6 of the chip,
>so that the current request can get to the capacitance and back before
>the transition is more than 1/3rd of the way done.  But in this case
>I'm going to load the dice in your favor and double that distance to
>risetime/3, or 1/3 ns.

I don't think this is correct.  The plane capacitance is not like a
capacitor at the end of a transmission line- it is much closer to an ideal
capacitance.  Think of it this way: if you assume the plane is a
transmission line, you naturally want to know what its characteristic
impedance is.  A tiny 8 mil trace is maybe 50 ohms- so a one ohm load will
cause a voltage drop to 1/51 until the power propogates down the line.  The
same is true for the power plane, except that its impedance is much much
lower, so there will be almost no droop (except by the amount you calculate
when you assume you're discharging an ideal capacitor).

Think of it this way- the single point of discharge is being fed by an ever
growing ring of distributed capacitance.  This ring is expanding in all
directions, so it is really like a low impedance transmission line.  I would
like to know exactly what happens when decoupling capacitors recharge the
plane- I think they see the whole plane as well- not an inductive path to
the sink (as with microstrip ground returns).
-- 
/*  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: 20092
Subject: Re: Pin to pin
From: fliptron@netcom.com (Philip Freidin)
Date: 27 Jan 2000 04:06:00 GMT
Links: << >>  << T >>  << A >>

An IBUF and an OBUF ?


In article <388EB6FD.5916DFA9@digigram.com>,
=?iso-8859-1?Q?J=E9r=E9mie?= WEBER  <jwr@digigram.com> wrote:
>Do you know how to link two pins of a virtex fpga like if it is a wire
>between this two pins ( in order to bypass a fpga... )
>


Article: 20093
Subject: Re: Pin to pin
From: "Matt Billenstein" <mbillens@one.net>
Date: Thu, 27 Jan 2000 04:38:45 GMT
Links: << >>  << T >>  << A >>
# in UCF
NET "in_net" LOC = "B4";
NET "out_net" LOC = "B5";



# in top level VHDL
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

ENTITY myTest is
  PORT(
        in_net  : IN  std_logic;
        out_net : OUT std_logic
      );
END myTest;

ARCHITECTURE testARCH OF myTest IS
BEGIN
  out_net <= in_net;
END testARCH;




remember to look into the data book to see what kind of delay you're going
to incure ...  it may be something on the order of 6ns or so depending upon
what kind of device you use...

m

Matt Billenstein
http://w3.one.net/~mbillens/
mbillens@one.net


"Jérémie WEBER" <jwr@digigram.com> wrote in message
news:388EB6FD.5916DFA9@digigram.com...
| Do you know how to link two pins of a virtex fpga like if it is a wire
| between this two pins ( in order to bypass a fpga... )
|


Article: 20094
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: "Matt Billenstein" <mbillens@one.net>
Date: Thu, 27 Jan 2000 04:51:53 GMT
Links: << >>  << T >>  << A >>
We're actually getting into the layout now and I'm not so scared now that
I've found the "correct" dimensions and a suggested escape routing note for
the FG parts...  it turns out the solder balls on the FPGA are substantially
larger than the foot print that is suggested goes on the board...  thus, I
get a ton of more room between pads to route stuff and place vias.  I'll
forward the appnote to anyone who'd like to see; I don't think it can be
found on the Xilinx website.

m



Matt Billenstein
http://w3.one.net/~mbillens/
mbillens@one.net


"Keith R. Williams" <krw@attglobal.net> wrote in message
news:pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost...
| On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein"
| <mbillens@one.net> wrote:
|
| > All,
| >
| > I've not seen (or cannot find) an appropriate appnote or reference
design
| > for laying down these fine pitch BGA parts (say FG256 for example)
There
| > doesn't seem to be a lot of room between BGA solder pads (0.400
millimeters
| > nominal) to route out or drop vias of any substantial size...  I can
route
| > out two rows around the whole part with very little trouble, but I think
I
| > have to dogbone anything further inside the part.  How are you folks
here
| > doing it?
|
| When I switched FPGA manufacturers (at gun-point :-|) I went from
| a BG560 to a FG680 to make things a little easier (it didn't). My
| choices were either a 3mil line width to get two out traces per
| channel or another plane and 5mil traces and one per channel.
| Since I needed a 50 ohm environment and this widget is a "cost is
| no object" type of deal, I chose another plane (actually two -
| one for another power plane to keep 50 ohms). I have a total of
| ten planes (5p, 5S).
|
| ----
|   Keith
|
|


Article: 20095
Subject: Re: GSR in HDL on instantiated flip-flop primitives
From: "Simon Bacon" <simon@tile.demon.co.uk.notreally>
Date: Wed, 26 Jan 2000 22:27:05 -0700
Links: << >>  << T >>  << A >>
Ray

Try putting an INIT attribute on the flop.  To quote the
reference guide (page 18-9 in dev_ref.pdf):

   For Xilinx Virtex devices, a high signal on the GSR
   (Global Set/Reset) net initializes each flip-flop and
   latch to the state (0 or 1) specified by its INIT
   property (default is 0)....

The syntax would be the same as adding an RLOC.  In VHDL:

   attribute INIT: string;
   attribute INIT of Fipper:label is "S";  -- or "R"

Of course the simulation won't match up unless you cook up
your own version of the flop.


Ray Andraka <randraka@ids.net> wrote in message
news:388F4F58.6436047@ids.net...
> I've got two cases that are creating a problem with using the Virtex
> GSR with flip-flop primitives for me:
>
> 1)  I've got a flip-flop that I need to have use the synchronous reset
> that goes directly into the FF (virtex).  I also want it to start up
> initialized with GSR. That flip-flop is instantiated as a primitive
> (FDRE) in my code so that I can put RLOCs on it to place it from
within
> the code.  Normally, this could be handled at an RTL level with
> appropriate coding, but where I'm instantiating the primitive, I don't
> see a way of getting GSR in there too.
>
> 2) I've got a case where I instantiate a FDE and an SRL16E and place
> them both in the same half of the slice.  The reset/clear on the FDE
is
> unusable in the design because it is shared with the SRL16E enable.
If
> I instantiate an FDCE to get a GSR input, the tools don't seem to make
> it into an FDE when they recognize the GSR, and it results in a mapper
> failure.
>
> Has anyone encountered this and found a suitable workaround (RTL
coding
> doesn't count, I need to specify placement).
>
> --
> -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: 20096
Subject: Secondary Clock Distribution in Virtex
From: "Simon Bacon" <simon@tile.demon.co.uk.notreally>
Date: Wed, 26 Jan 2000 23:18:50 -0700
Links: << >>  << T >>  << A >>
Replying to a slightly different question,
Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote

> I don't know anything about the XC6200 stuff, but all of the
> currently-supported Xilinx chips have global low-skew clock buffers.
Using
> them in VHDL is quite simple: use your clock signal ONLY as the clock
signal
> for all of your flip-flops.  Any real synthesis tool will note that
the
> signal's a clock net and assign a BUFGLS (or whatever the low-skew
clock
> buffer's called).  Then, the P+R tools will go "A-ha!" and
automatically
> route the chip with that clock signal put onto a global clock net.

But the Virtex secondary clocks seem to be more dificult.
The Virtex data sheet has this to say about secondary clock nets:

  The secondary local clock routing resources consist of
  24 backbone lines, 12 across the top of the chip and 12
  across bottom. From these lines, up to 12 unique
  signals per column can be distributed via the 12
  longlines in the column. These secondary resources
  are more flexible than the primary resources since they
  are not restricted to routing only to clock pins.

I don't quite understand this because the routing resources
between the HBACKBONE lines and the VLONG lines appear to be
sparse in the extreme.  Looking at the FPGA Editor screen, it
appears that _at any given column_ you can only exit to a VLONG
from two of the HBACKBONE lines.

Also having gotten onto one of the VLONG wires, it does not
seem to be possible to clock (or access at all) all the CLBs
in a column.

I guess I am not reading the FPGA Editor screen correctly...

It would be really, really nice to have a clear picture
of how this secondary clock routing works so that we can
floorplan our designs.  Even if the tools will do the
"right thing", it is hard to floorplan the rest of the
design without an understanding of what the layout requirements
are for secondary clock routing.

Ideally Xilinx can answer this, but there does not appear to be
anything on their site and the standard FAE response is
"secondary clock routing will be used for a net if you specify
MAXSKEW=0 in the UCF".  Following a future software release, the
magic words will become "NET xxx USELOWSKEWLINES".

If Xilinx aren't telling, maybe Philp F knows how the silicon
works...

/rant



Article: 20097
Subject: Re: What has happened to freecore.com ?
From: Andreas Heiner <Andreas.Heiner@de.bosch.com>
Date: Thu, 27 Jan 2000 08:36:53 +0100
Links: << >>  << T >>  << A >>
> Hi
>
> Does anyone know what has happened to the FreeCore Homepage
> (www.freecore.com)?
>
> I have not been able to get through since the start of this year.
>
> Cheers
> --
> Steve Dewey
> Remove 123 for email

The last time I've seen it was in december. But as far as I know, this
wasn't a freecore page in december, because on this page only were Xilinx
Cores (in december). In January the page has been removed. I suppose that
freecore.com was bought by Xilinx at the end of last year.


Andreas Heiner



Article: 20098
Subject: microcontroller in vhdl
From: "Holger Azenhofer" <holger.azenhofer@vs.dasa.de>
Date: Thu, 27 Jan 2000 10:26:05 +0100
Links: << >>  << T >>  << A >>
Dear All,

I'm looking for a small and free microcontroller core (8051). Can someone
tell me, where to find information about this core in the web.

Any information is greatly appreciated !!

Regards,

Holger Azenhofer


Article: 20099
Subject: Re: Anyone changed an NT disk serial number?
From: Steve Bird <steveb@vizef.demon.co.uk.island>
Date: Thu, 27 Jan 2000 10:07:43 +0000
Links: << >>  << T >>  << A >>
In article <388ED3A9.94347124@elis.rug.ac.be>, Jo Depreitere
<jdp_nospam@elis.rug.ac.be> writes
>Steve Bird wrote:
>> 
>> In article <388e1f97.4722839@news.dial.pipex.com>, eml@riverside-
>> machines.com.NOSPAM writes
>> >Anyone managed this? I've tried modding the boot sector with a '95
>> >boot disk and Debug, but Debug can't even see the C drive, let alone
>> >modify the boot sector. And does anyone know where the serial number
>> >is? Presumably the NTFS location is different from the FAT16 and FAT32
>> >locations.
>> >
>> >By the way, this is (I think) legal.
>> >
>> 
>> Depends on why you would want to do this... If you're trying to subvert
>> a s/w licensing schema (say FLEXlm) then its not.
>
>But if you buy a new (faster) PC, shouldn't they allow you to use your
>old software? And with FLEXlm you have to fiddle with the serial number
>(i.e., if you have a student license which has no support). It's not
>exactly legal, but they can't really object to this, since I bought
>the software and I want to keep on using it(?)
>
>Jo
>

You should be able to move your s/w to a new machine. However, my point
was about using this technique to 'aquire' a use of s/w which was not
paid for. Some vendors make the rehosting of s/w difficult, which it
should, in an ideal world, not be. However, from the vendors perspective
they have no way of knowing if the original machine is truely being
decommisioned.

There is no easy answer---if every user of s/w paid the due fees then
this would not be an issue. 

Our own company view of licensing is that it is a technique to keep
honest users honest, the effort required to prevent determined hackers
is not economic and can become a barrier to adoption.

I don't want to start a flame war here---as a small company every
'hacked' license hurts, not just us, but real users as it reduces the
development investment. At the end of the day I like to take home a pay
check, just like everyone else!


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