Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
By my calculations, I am afraid so. An egg-faced, Nemo "Kevin Neilson" <kevin_neilson@yahoo.com> wrote: >Uh oh, does this leave Austin as the lone dissenter? > > >"Nemo" <nemo@dtgnet.com> wrote in message >news:3afa67dc.10129415@news.dtgnet.com... >> I apologize to all those posting/reading the recent Shannon capacity >thread. I >> was 100% wrong in my statements about parity bits. Here is some >background... >> >> There has been an on-going thread in this news group about Shannon >capacity. >> The original question was about the following equation: >> >> C = W*Log2(1-S/N) bps >> >> Does the caculated capacity C include parity bits of a coded channel? >> >> I now believe the answer is *no, it does not*. Throughout Shannon's >paper, C >> refers to the *information rate only*. The above equation shows the >> relationship between the amount of error-free *information* throughput, >> bandwidth and S/N. The information throughput does *not* include the >added >> bits due to whatever coding scheme is chosen. In the following typical >system, >> the above equation shows the limit to the total info in and out for a >channel of >> a given bandwidth and S/N. The challenge of the engineer is to design the >> encode/decode and mod/demod functions so as to achieve this limit. >> >> info in -> encoding -> modulation -> channel -> demod -> decode -> info >out >> >> Again, in my previous posts I mis-stated how "parity" bits are considered >in the >> above equation/system. I apologize for any confusion. >> >> Good Day to all. >> >> Nemo >> >Article: 31026
Wow, It amazes me how confused everyone is. So if parity is not considered information, you don't need it. OK, so I won't send it. It isn't part of the channel, so it never makes it to the other end. Fine. Never happened. At the receive end, I have to parity bits, Fine. I'll just use the bits I have received, and well, are they good? I don't know....I can't check them....I don't have any parity bits.... Austin Nemo wrote: > I apologize to all those posting/reading the recent Shannon capacity thread. I > was 100% wrong in my statements about parity bits. Here is some background... > > There has been an on-going thread in this news group about Shannon capacity. > The original question was about the following equation: > > C = W*Log2(1-S/N) bps > > Does the caculated capacity C include parity bits of a coded channel? > > I now believe the answer is *no, it does not*. Throughout Shannon's paper, C > refers to the *information rate only*. The above equation shows the > relationship between the amount of error-free *information* throughput, > bandwidth and S/N. The information throughput does *not* include the added > bits due to whatever coding scheme is chosen. In the following typical system, > the above equation shows the limit to the total info in and out for a channel of > a given bandwidth and S/N. The challenge of the engineer is to design the > encode/decode and mod/demod functions so as to achieve this limit. > > info in -> encoding -> modulation -> channel -> demod -> decode -> info out > > Again, in my previous posts I mis-stated how "parity" bits are considered in the > above equation/system. I apologize for any confusion. > > Good Day to all. > > NemoArticle: 31027
Austin Lesea wrote in message <3AF9676B.6E94E35D@xilinx.com>... > >2V1000ES are here at the factory. I don't know about the FF896, but I did >evaluate one in the lab, and it is a really clean nice package (tons of >connections to ground so it is really quiet for ground bounce -- love those >flip chips!). Austin Where did you put the decoupling capacitors? And have you ever seen an FF1517 package? It sounds pretty scary :)Article: 31028
Hallo, in a verilog base design with fixed I/O pins, synplicity chooses a dedicated input pin with high drive capability for an input with a load of 24. However in a constraints file I explicitly told to use a standard IO pin and when mapping the device with the quicklogic mapper, things clash. I tried several hints. like /*synthesis syn_noclockbuf = 1*/ in the verilog module, but synplicity warned me about that options being ignored and things still didn't work. Can anybody give a hint how to stop synplicity to choose a dedicated input pin for an input with high load? Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 31029
Uwe Bonnes wrote: > I tried several hints. like > /*synthesis syn_noclockbuf = 1*/ in the verilog module, but > synplicity warned me about that options being ignored and things still > didn't work. Did you make sure to put the comment *before* the semicolon at the end of the line? If you don't, the option is ignored. Alan Nishioka alan@nishioka.comArticle: 31030
"The Designer's Guide to VHDL" by Peter J. Ashenden Su We wrote: > Hello, > I am looking for a VHDL/synthesis book. > One similar to "Numerical methods in C" > > I looked at VHDL coding styles by Cohen, but I want to know if anyone had > other suggestions > > SWArticle: 31031
I disagree with your statements. I believe the answer lies clearly in the equation itself. C = W*Log2(1-S/N) bps Note the units of the information rate is bits per second. I have no idea how you can say that parity bits are factored out of this equation. Are the parity bits not transmitted through the same bandwidth limited channel as the bits that you are calling *information bits*? Do they not take the same amount of time to be transmitted through the channel? Are the parity bits not required to have the same average signal power? Are the parity bits immune to perturbations in the channel (noise power)? It seems as though everyone is taking an abstract view of a theorem that is based very strongly in physics. It seems that everyone is creating a convention that encoding bits are not part of the information rate - fine, if you want to do that, but the transmission channel is still going to be filled by a maximum number of bits per second governed by the Shannon-Hartley Theorem. Bits per second is still bits per second. Anything you do with the information after transmission is your interpretation of the information and is not covered by the theorem. A meaningful information data rate can be derived as Cmeaningful = Ctotal - Cencoding. Nemo wrote: > I apologize to all those posting/reading the recent Shannon capacity thread. I > was 100% wrong in my statements about parity bits. Here is some background... > > There has been an on-going thread in this news group about Shannon capacity. > The original question was about the following equation: > > C = W*Log2(1-S/N) bps > > Does the caculated capacity C include parity bits of a coded channel? > > I now believe the answer is *no, it does not*. Throughout Shannon's paper, C > refers to the *information rate only*. The above equation shows the > relationship between the amount of error-free *information* throughput, > bandwidth and S/N. The information throughput does *not* include the added > bits due to whatever coding scheme is chosen. In the following typical system, > the above equation shows the limit to the total info in and out for a channel of > a given bandwidth and S/N. The challenge of the engineer is to design the > encode/decode and mod/demod functions so as to achieve this limit. > > info in -> encoding -> modulation -> channel -> demod -> decode -> info out > > Again, in my previous posts I mis-stated how "parity" bits are considered in the > above equation/system. I apologize for any confusion. > > Good Day to all. > > NemoArticle: 31032
Has anyone done a 1553 serial bus interface that they would like to share?? Thanks, Stan RamsdenArticle: 31033
Tim, Good question. We placed the bypass caps on the other side of the pcb, within 0.4" from the outermost rings of pads for the package. We used planes for ground, Vccint, and Vcco's (sort of an octal slice for the eight banks - we needed to test each bank separately), and one of the slices is for 3.3 V so it also goes to the Vccaux pins. 0.01uF and 0.001uF caps were alternated for power/ground pin pairs. We didn't have a lot of IO's (lab pcb), and it wasn't designed for running a design that was bigger than about 40% of the part, so it wasn't as busy as it could be. In the larger pattern packages, you can lose the interior set of balls to pcb on the backside for the ground pins (ground pins inside a ring of ground pins carry no current at all -- obvious to electric field solver people, not so obvious to people who think of DC currents as going through resistances) and insert the Vccint bypass caps in this area. FF1517 packages are for professional drivers only, on a closed course. Or another way of putting it: use IBIS modeling, floorplan your IO's, perform the power analysis, design the heatsinking, and use controlled impedance trace layout, and make sure you adhere to the SSO guidelines, and leave some IO's uncommitted in case they need to be used to provide additional grounds, testpoints, or guard traces. Of course, if you want to succeed the first time every time, you should take all of the above steps for each design, regardless of package size. Austin Tim wrote: > Austin Lesea wrote in message <3AF9676B.6E94E35D@xilinx.com>... > > > > >2V1000ES are here at the factory. I don't know about the FF896, but I did > >evaluate one in the lab, and it is a really clean nice package (tons of > >connections to ground so it is really quiet for ground bounce -- love those > >flip chips!). > > Austin > > Where did you put the decoupling capacitors? > > And have you ever seen an FF1517 package? It sounds pretty scary :)Article: 31034
--------------8894F1576992B8F3073D4480
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Davis,
They are not listening. I should not have fallen back in again. You clearly
understand the definition of a channel. They would prefer you to 'vote', or to say
who is 'right' or 'wrong' than discuss the issues.
Shannon drew Venn diagrams for his proofs ("Communication in the Presence of Noise,"
1940), and was challenged because the proof was not "mathematical" enough. I liked
the geometrical proofs as they were obvious. Of course, that troubled the
mathemeticians who wanted to have a lock on the knowledge, and did not like this idea
that anything "that complex" could be stated and then proved so elegantly.
Austin
Davis Moore wrote:
> I disagree with your statements. I believe the answer lies clearly in the
> equation itself.
>
> C = W*Log2(1-S/N) bps
>
> Note the units of the information rate is bits per second. I have
> no idea how you can say that parity bits are factored out of
> this equation. Are the parity bits not transmitted through the same bandwidth
> limited channel as the bits that you are calling *information bits*?
Hear hear!
>
> Do they not take the same amount of time to be transmitted
> through the channel? Are the parity bits not required to have
> the same average signal power?
Agreed!
> Are the parity bits immune
> to perturbations in the channel (noise power)?
Nope! They are not.
>
> It seems as though everyone is taking an abstract view of a theorem
> that is based very strongly in physics.
>
> It seems that everyone is creating a convention that encoding bits are not part
> of the information rate - fine, if you want to do that, but the transmission
> channel is still going to be filled by a maximum number of bits per second
> governed by the Shannon-Hartley Theorem.
>
> Bits per second is still bits per second. Anything you do with the information
> after transmission is your interpretation of the information and is not
> covered by the theorem.
>
> A meaningful information data rate can be derived as
> Cmeaningful = Ctotal - Cencoding.
More appropriately, Conlywhat i reallywanted=Ctotal-Cencoding
I would argue that Cmeaningful = Ctotal
Otherwise I can't get Cmeaningful without also having Cencoding! QED, Shannon.
>
>
> Nemo wrote:
>
> > I apologize to all those posting/reading the recent Shannon capacity thread. I
> > was 100% wrong in my statements about parity bits. Here is some background...
> >
> > There has been an on-going thread in this news group about Shannon capacity.
> > The original question was about the following equation:
> >
> > C = W*Log2(1-S/N) bps
> >
> > Does the caculated capacity C include parity bits of a coded channel?
> >
> > I now believe the answer is *no, it does not*. Throughout Shannon's paper, C
> > refers to the *information rate only*. The above equation shows the
> > relationship between the amount of error-free *information* throughput,
> > bandwidth and S/N. The information throughput does *not* include the added
> > bits due to whatever coding scheme is chosen. In the following typical system,
> > the above equation shows the limit to the total info in and out for a channel of
> > a given bandwidth and S/N. The challenge of the engineer is to design the
> > encode/decode and mod/demod functions so as to achieve this limit.
> >
> > info in -> encoding -> modulation -> channel -> demod -> decode -> info out
> >
> > Again, in my previous posts I mis-stated how "parity" bits are considered in the
> > above equation/system. I apologize for any confusion.
> >
> > Good Day to all.
> >
> > Nemo
--------------8894F1576992B8F3073D4480
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Davis,
<p>They are not listening. I should not have fallen back in again.
You clearly understand the definition of a channel. They would prefer
you to 'vote', or to say who is 'right' or 'wrong' than discuss the issues.
<p>Shannon drew Venn diagrams for his proofs ("Communication in the Presence
of Noise," 1940), and was challenged because the proof was not "mathematical"
enough. I liked the geometrical proofs as they were obvious.
Of course, that troubled the mathemeticians who wanted to have a lock on
the knowledge, and did not like this idea that anything "that complex"
could be stated and then proved so elegantly.
<p>Austin
<p>Davis Moore wrote:
<blockquote TYPE=CITE>I disagree with your statements. I believe the answer
lies clearly in the
<br>equation itself.
<p>C = W*Log2(1-S/N) bps
<p>Note the units of the information rate is bits per second. I have
<br>no idea how you can say that parity bits are factored out of
<br>this equation. Are the parity bits not transmitted through the same
bandwidth
<br>limited channel as the bits that you are calling *information bits*?</blockquote>
Hear hear!
<blockquote TYPE=CITE>
<br>Do they not take the same amount of time to be transmitted
<br>through the channel? Are the parity bits not required to have
<br>the same average signal power?</blockquote>
Agreed!
<blockquote TYPE=CITE>Are the parity bits immune
<br>to perturbations in the channel (noise power)?</blockquote>
Nope! They are not.
<blockquote TYPE=CITE>
<br>It seems as though everyone is taking an abstract view of a theorem
<br>that is based very strongly in physics.
<p>It seems that everyone is creating a convention that encoding bits are
not part
<br>of the information rate - fine, if you want to do that, but the transmission
<br>channel is still going to be filled by a maximum number of bits per
second
<br>governed by the Shannon-Hartley Theorem.
<p>Bits per second is still bits per second. Anything you do with the information
<br>after transmission is your interpretation of the information and is
not
<br>covered by the theorem.
<p>A meaningful information data rate can be derived as
<br>Cmeaningful = Ctotal - Cencoding.</blockquote>
More appropriately, Conlywhat i reallywanted=Ctotal-Cencoding
<p>I would argue that Cmeaningful = Ctotal
<p>Otherwise I can't get <b><i>Cmeaningful without also having Cencoding!
QED, Shannon.</i></b>
<blockquote TYPE=CITE>
<p>Nemo wrote:
<p>> I apologize to all those posting/reading the recent Shannon capacity
thread. I
<br>> was 100% wrong in my statements about parity bits. Here is
some background...
<br>>
<br>> There has been an on-going thread in this news group about Shannon
capacity.
<br>> The original question was about the following equation:
<br>>
<br>> C = W*Log2(1-S/N) bps
<br>>
<br>> Does the caculated capacity C include parity bits of a coded channel?
<br>>
<br>> I now believe the answer is *no, it does not*. Throughout
Shannon's paper, C
<br>> refers to the *information rate only*. The above equation
shows the
<br>> relationship between the amount of error-free *information* throughput,
<br>> bandwidth and S/N. The information throughput does *not*
include the added
<br>> bits due to whatever coding scheme is chosen. In the following
typical system,
<br>> the above equation shows the limit to the total info in and out for
a channel of
<br>> a given bandwidth and S/N. The challenge of the engineer is to design
the
<br>> encode/decode and mod/demod functions so as to achieve this limit.
<br>>
<br>> info in -> encoding -> modulation -> channel -> demod -> decode ->
info out
<br>>
<br>> Again, in my previous posts I mis-stated how "parity" bits are considered
in the
<br>> above equation/system. I apologize for any confusion.
<br>>
<br>> Good Day to all.
<br>>
<br>> Nemo</blockquote>
</html>
--------------8894F1576992B8F3073D4480--
Article: 31035Since I have to ask what the price is, I probably can't afford it, but what the heck: What is the price range of Nallatech products like Benblue and the DIME-II cPCI carrier? ( http://www.nallatech.com )Article: 31036
Austin Lesea wrote: > > Rick, > > 2V1000ES are here at the factory. I don't know about the FF896, but I did > evaluate one in the lab, and it is a really clean nice package (tons of > connections to ground so it is really quiet for ground bounce -- love those > flip chips!). It is -5, even though ES is not "graded". The -5 for 2V is > faster than the -8 for Virtex E. As an example, in Virtex E a design with > 155 MHz global clocks is getting agressive, and constraints may get tough > to meet in a large design. In Virtex II, we see the same at 311 MHz. That > isn't to say that with careful tweaking and floor planning you can not do > better in either. > > By the way, there are 2V40's in fg256 as ES around, too. > > Get to a disti or FAE. > > Austin > > Sounds to me like it will be worth struggling pretty hard to get some of these parts. I really need the FF896 since I need a lot of IOs. The IO/CLB balance of the Virtex-E is closer to our general need but if the speed equation extends to V2-4 <=> V-E-7 then I'll gladly pay the extra price. I'm using 2.1i at the moment so do you know if its possible to get 3.3i on a short term eval so I can do what Kolja did & re-target our existing XCV400E/600E design.Article: 31037
Rick, You can get a free eval version of 3.3i from http://support.xilinx.com/products/software/ise_eval.htm -Vikram Xilinx Applications Rick Filipkiewicz wrote: > > Sounds to me like it will be worth struggling pretty hard to get some of > these parts. > I really need the FF896 since I need a lot of IOs. The IO/CLB balance of > the Virtex-E is closer to our general need but if the speed equation > extends to V2-4 <=> V-E-7 then I'll gladly pay the extra price. > > I'm using 2.1i at the moment so do you know if its possible to get 3.3i > on a short term eval so I can do what Kolja did & re-target our existing > XCV400E/600E design.Article: 31038
Austin Lesea wrote in message <3AF9C0FC.E2976FF4@xilinx.com>... >We placed the bypass caps on the other side of the pcb, within 0.4" from the >outermost rings of pads for the package. We used planes for ground, Vccint, and >Vcco's (sort of an octal slice for the eight banks - we needed to test each bank >separately), and one of the slices is for 3.3 V so it also goes to the Vccaux >pins. 0.01uF and 0.001uF caps were alternated for power/ground pin pairs. I guess the 0508 caps (or 0306?) could be useful here. They seem to have much better performance than 0805/0603 types. Are they freely available in distribution? I could not see them in Digi-Key, but maybe I didn't look in the right place.Article: 31039
Austin Lesea wrote: > > Tim, > > <snip> > > In the larger pattern packages, you can lose the interior set of balls to pcb on > the backside for the ground pins (ground pins inside a ring of ground pins carry > no current at all -- obvious to electric field solver people, not so obvious to > people who think of DC currents as going through resistances) and insert the > Vccint bypass caps in this area. > A1 right. The inner ones are just a component of what I call h/w voodoo. However if that's the case & you know it then how come the inner GND balls are there ? Could you maybe arrange a demonstration to your packaging folks by scraping off the inner balls on the package and the PCB pads and then stuffing the device with the noisiest logic you can manage. > FF1517 packages are for professional drivers only, on a closed course. > They's have to be given the cost of the devices that live inside the FF1517. BTW Austin I've been following the ``debate'' on Shannon's Thm & you are absolutely right. I remember reading it a long time ago & realising quite quickly that on the surface it seems easy [not the proof but the statement] in fact its a very subtle thing. But then its all about Entropy & people have been confused & confusing about that since Carnot.Article: 31040
input foo /* synthesis qln_padtype="normal" */; See the help file for examples. Uwe Bonnes wrote: > > Hallo, > > in a verilog base design with fixed I/O pins, synplicity chooses a > dedicated input pin with high drive capability for an input with a > load of 24. However in a constraints file I explicitly told to use a > standard IO pin and when mapping the device with the quicklogic > mapper, things clash. I tried several hints. like > /*synthesis syn_noclockbuf = 1*/ in the verilog module, but > synplicity warned me about that options being ignored and things still > didn't work. > > Can anybody give a hint how to stop synplicity to choose a dedicated > input pin for an input with high load? > > Thanks > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- -- Ken McElvain, CTO Synplicity Inc. (408)215-6060Article: 31041
One more try (typo): input foo /* synthesis ql_padtype="normal" */; See the help file for examples. Ken McElvain wrote: > > input foo /* synthesis qln_padtype="normal" */; > See the help file for examples. > > Uwe Bonnes wrote: > > > > Hallo, > > > > in a verilog base design with fixed I/O pins, synplicity chooses a > > dedicated input pin with high drive capability for an input with a > > load of 24. However in a constraints file I explicitly told to use a > > standard IO pin and when mapping the device with the quicklogic > > mapper, things clash. I tried several hints. like > > /*synthesis syn_noclockbuf = 1*/ in the verilog module, but > > synplicity warned me about that options being ignored and things still > > didn't work. > > > > Can anybody give a hint how to stop synplicity to choose a dedicated > > input pin for an input with high load? > > > > Thanks > > -- > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > -- > Ken McElvain, CTO > Synplicity Inc. > (408)215-6060 -- Ken McElvain, CTO Synplicity Inc. (408)215-6060Article: 31042
Important new medical news for those suffering with genital herpes, cold sores and shingles! http://crazydude.com/newmedicArticle: 31043
Sometimes the constraints editor leaves me a little flat so I've generally stuck to editing the constraints file by hand. The OFFSET IN AFTER and OFFSET OUT BEFORE syntaxes are completely valid (according to the nice little powerpoint presentation on 3.1i Constraints I have sitting around). Check out the page from the online software doc: http://toolbox.xilinx.com/docsan/3_1i/data/common/dev/chap06/dev06006.htm So if the editor can't get you where you want to be, just open it up with a text editor and make your own changes. You should still be able to edit things fine afterwards.Article: 31044
Don't know about avail of cap types, I would be interested if there is still a shortage of discretes out there, or if they solved that problem. Austin Tim wrote: > Austin Lesea wrote in message <3AF9C0FC.E2976FF4@xilinx.com>... > > >We placed the bypass caps on the other side of the pcb, within 0.4" from > the > >outermost rings of pads for the package. We used planes for ground, > Vccint, and > >Vcco's (sort of an octal slice for the eight banks - we needed to test each > bank > >separately), and one of the slices is for 3.3 V so it also goes to the > Vccaux > >pins. 0.01uF and 0.001uF caps were alternated for power/ground pin pairs. > > I guess the 0508 caps (or 0306?) could be useful here. They seem to have > much better performance than 0805/0603 types. Are they freely available > in distribution? I could not see them in Digi-Key, but maybe I didn't > look in the right place.Article: 31045
On Wed, 09 May 2001 12:05:22 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >Wow, > >It amazes me how confused everyone is. > >So if parity is not considered information, you don't need it. OK, so I won't send >it. > >It isn't part of the channel, so it never makes it to the other end. Fine. > >Never happened. > >At the receive end, I have to parity bits, Fine. I'll just use the bits I have >received, and well, are they good? I don't know....I can't check them....I don't >have any parity bits.... I've been home with the flu 5 days. Having lost all will to live, I thought I'd jump into this thread. I think that including the parity/ECC bits in the max symbol rate is wrong, and leads to a logical contradiction. Let's suppose I have a link on which I'm transmitting B symbols per second. Unfortunately, the bandwidth is too narrow or the S/N too small to support error-free transmission. So I start converting some of the bits to ECC, until the bit error rate reaches an acceptable level. At this point I'm still transmitting B symbols per second, but only X of them are my message, the other E of them are ECC. (B = X + E) At this point I say, hey, all of those symbols are information of some sort, so B must be less than or equal to Shannon's limit. (If I've used a good coding scheme, it's not too far away from that limit; I don't know what state of the art is for trellis coded modulation or turbo codes, but it's pretty good.) If B really *is* the Shannon limit, I should be able to convert those ECC symbols back into message symbols. But I've already proved that I can't. So Shannon must be telling us the number of *message* symbols is what's being predicted by his equation. Otherwise, Shannon's limit tells us nothing about maximum message rate on a channel, because we may have to add lots of ECC bits to get the message through. In other words, Shannon's limit either applies to message bits only, or it's worthless. The problem with the arguments being used agains this is the conflation of "useful" and "information." ECC bits are useful; they are not information. Call me wrong, call me names, whatever. You can't make me feel any worse. Bob PerlmanArticle: 31046
--------------4B1E8BED82B31BF97F887631 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Aaaaah! Shannon found me here on this thread! Entropy lives! Just kidding, thanks. The balls in the center pattern can carry off some significant heat, so having a pattern to solder them to, that isn't even electrically connected, takes away heat (really! or so the packaging folks tell me -- I am thermally challenged so don't ask me any heat questions...). Well, the 1517 and 1132 packages certainly provide a lot of capabilty. I was on a call with a customer, and I asked why they had five asynchronous clocks. He said, "well, it is five separate designs.." I asked him why he had five completely unrelated designs in the chip. He replied, "cause it fits." He further commented, "I don't know about 'system on a chip' but you enable us to make 'systems' on a chip." Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > > Tim, > > > > > > <snip> > > > > > In the larger pattern packages, you can lose the interior set of balls to pcb on > > the backside for the ground pins (ground pins inside a ring of ground pins carry > > no current at all -- obvious to electric field solver people, not so obvious to > > people who think of DC currents as going through resistances) and insert the > > Vccint bypass caps in this area. > > > > A1 right. The inner ones are just a component of what I call h/w voodoo. > However if that's the case & you know it then how come the inner GND > balls are there ? Could you maybe arrange a demonstration to your > packaging folks by scraping off the inner balls on the package and the > PCB pads and then stuffing the device with the noisiest logic you can > manage. > > > FF1517 packages are for professional drivers only, on a closed course. > > > > They's have to be given the cost of the devices that live inside the > FF1517. > > BTW Austin I've been following the ``debate'' on Shannon's Thm & you are > absolutely right. > I remember reading it a long time ago & realising quite quickly that on > the surface it seems easy [not the proof but the statement] in fact its > a very subtle thing. But then its all about Entropy & people have been > confused & confusing about that since Carnot. --------------4B1E8BED82B31BF97F887631 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Aaaaah! <p>Shannon found me here on this thread! Entropy lives! <p>Just kidding, thanks. <p>The balls in the center pattern can carry off some significant heat, so having a pattern to solder them to, that isn't even electrically connected, takes away heat (really! or so the packaging folks tell me -- I am thermally challenged so don't ask me any heat questions...). <p>Well, the 1517 and 1132 packages certainly provide a lot of capabilty. <p>I was on a call with a customer, and I asked why they had five asynchronous clocks. He said, "well, it is five separate designs.." I asked him why he had five completely unrelated designs in the chip. He replied, "cause it fits." <p>He further commented, "I don't know about 'system on a chip' but you enable us to make 'system<b>s</b>' on a chip." <p>Austin <br> <br> <p>Rick Filipkiewicz wrote: <blockquote TYPE=CITE>Austin Lesea wrote: <br>> <br>> Tim, <br>> <br>> <p><snip> <p>> <br>> In the larger pattern packages, you can lose the interior set of balls to pcb on <br>> the backside for the ground pins (ground pins inside a ring of ground pins carry <br>> no current at all -- obvious to electric field solver people, not so obvious to <br>> people who think of DC currents as going through resistances) and insert the <br>> Vccint bypass caps in this area. <br>> <p>A1 right. The inner ones are just a component of what I call h/w voodoo. <br>However if that's the case & you know it then how come the inner GND <br>balls are there ? Could you maybe arrange a demonstration to your <br>packaging folks by scraping off the inner balls on the package and the <br>PCB pads and then stuffing the device with the noisiest logic you can <br>manage. <p>> FF1517 packages are for professional drivers only, on a closed course. <br>> <p>They's have to be given the cost of the devices that live inside the <br>FF1517. <p>BTW Austin I've been following the ``debate'' on Shannon's Thm & you are <br>absolutely right. <br>I remember reading it a long time ago & realising quite quickly that on <br>the surface it seems easy [not the proof but the statement] in fact its <br>a very subtle thing. But then its all about Entropy & people have been <br>confused & confusing about that since Carnot.</blockquote> </html> --------------4B1E8BED82B31BF97F887631--Article: 31047
Rick, I would call your local FAE. The SSO guidelines reflect the difference between the fg256 and the other packages. Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > > Rick, > > > > 2V1000ES are here at the factory. I don't know about the FF896, but I did > > evaluate one in the lab, and it is a really clean nice package (tons of > > connections to ground so it is really quiet for ground bounce -- love those > > flip chips!). It is -5, even though ES is not "graded". The -5 for 2V is > > faster than the -8 for Virtex E. As an example, in Virtex E a design with > > 155 MHz global clocks is getting agressive, and constraints may get tough > > to meet in a large design. In Virtex II, we see the same at 311 MHz. That > > isn't to say that with careful tweaking and floor planning you can not do > > better in either. > > > > By the way, there are 2V40's in fg256 as ES around, too. > > > > Get to a disti or FAE. > > > > Austin > > > > > > Sounds to me like it will be worth struggling pretty hard to get some of > these parts. > I really need the FF896 since I need a lot of IOs. The IO/CLB balance of > the Virtex-E is closer to our general need but if the speed equation > extends to V2-4 <=> V-E-7 then I'll gladly pay the extra price. > > I'm using 2.1i at the moment so do you know if its possible to get 3.3i > on a short term eval so I can do what Kolja did & re-target our existing > XCV400E/600E design.Article: 31048
Very good !! cyber_spook Jakab Tanko wrote: > "The Designer's Guide to VHDL" by Peter J. Ashenden > > Su We wrote: > > > Hello, > > I am looking for a VHDL/synthesis book. > > One similar to "Numerical methods in C" > > > > I looked at VHDL coding styles by Cohen, but I want to know if anyone had > > other suggestions > > > > SWArticle: 31049
On Mon, 07 May 2001 18:46:20 -0700, Vikram Pasham <Vikram.Pasham@xilinx.com> wrote: >Berni & all, > >One of Shannon's paper "A Mathematical Theory of Communication" can be found on >the web at >http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf > >As per my understanding, "C" in Shanon's equation includes information + >parity. finally I read this paper and I'd like to submist my 2¢. Please look at figure 8. It talks about a transmitter, channel, receiver and correction data. Theorem 10 talks about the capacity of a correction channel. The idea is if the correction channel has capacity of Hy(x) then all the capacity of the normal channel (C) can be utilized because correction channel allows all errors to be corrected. So o page 22, the channel capacity is defined as C = max(H(x) - Hy(x)). In other words, if the correction channel is used the full capacity of the original channel is utilized. If correction data is transmitted in the channel itself, the capacity of the channel drops so the capacity of a real channel doesn't include the correction data. Comments please. Muzaffer FPGA DSP Consulting http://www.dspia.com
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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