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
Pat, I'm a contractor (currently working at Sony) that does fpga consultancy and design work as a sideline. I'm happy to take a look at your requirements if you like. Regards, Gary Cook. Pat wrote: > Hi, > > I have an old ISA board with an Altera FPGA configured as a frequency > counter. I would like to extend the functionality of the board but have no > FPGA experience. I do however have the original code (MAXPLUS II). Can > anyone recommend a consultant? > > Philip.Article: 31051
Ken McElvain <ken@synplicity.com> wrote: : input foo /* synthesis qln_padtype="normal" */; : See the help file for examples. :> :> Can anybody give a hint how to stop synplicity to choose a dedicated :> input pin for an input with high load? Hallo Ken, thanks for your help. Probably I missed to tell you the information that I run Synpicity delivered with Quickworks (V8.2 plus the 8.22 patch), which identifies itself as "Synplify-Lite 5.1.5", which substantially lags the present Synlify release. Local quicklogic support tried to be helpfull, but only gave the hint to rewrite my verilog code to include explicit buffers. However I don't feel satisfied with that work-around. I tried your solution in two places for a single input and for a vector of inputs, to be sure that the vector doesn't cause problems (line numbers given for reference, not included in the files) 1 `define VERSION "K-DELAY 0.00-1" 2 3 module camacdelay8(/*AUTOARG*/ 4 // Outputs 5 Q_N, X_N, WRITE_EN_N, R_N, 6 // Inouts 7 DOUT0, DOUT1, DOUT2, DOUT3, DOUT4, DOUT5, DOUT6, DOUT7, 8 // Inputs 9 RESET_N, S1_N, S2_N, N_N, I_N, F_N, A_N, W_N 10 ); 11 input RESET_N,S1_N,S2_N,N_N; 12 input I_N/* synthesis ql_padtype="normal" */; 13 input [4:0] F_N; 14 input [3:0] A_N/* synthesis ql_padtype="normal" */; However Synplify ignores these hints and gives following report in the .srr file: $ Start of Compile #Thu May 10 11:11:35 2001 Synplify Verilog Compiler, version 5.1.5, built Jul 20 1999 Copyright (C) 1994-1999, Synplicity Inc. All Rights Reserved @I::"c:\cae\pasic\spde\data\macros.v" @I::"...\camacdelay8.v" @W:"...\camacdelay8.v":12:27:12:36|ignoring property ql_padtype @W:"...\camacdelay8.v":14:33:14:42|ignoring property ql_padtype Verilog syntax check successful! Pathnames truncated for clarity. The .qds file still instanciates a input only pad for the : gate A_Nz_p[2] master Q_HINPAD cell IO108 end Any hints why the properties are ignored? Thanks again -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 31052
For the purposes of creating a random number generator in a testbench I want to use integers with ranges which exceed 32 bits. Is there a way to do this? AlanArticle: 31053
Alan Glynne Jones wrote: > > For the purposes of creating a random number generator in a testbench I > want to use integers with ranges which exceed 32 bits. Is there a way > to do this? Hi Alan, 1. You can use the unsigned or signed types from ieee.numeric_std (or std_logic_arith if you must), as they work for vector lengths > 32 bits. 2. You might find a simulator running on a 64 bit processor that supports 64 bit integers. VHDL defines a minimum range (which is just under 32 bits), but it doesn't define a maximum range. You might get lucky, but it won't be portable. 3. You can define a record containing two integers, then create a package that defines (& overloads) all the appropriate maths operators for this new "bignum" type, then use it in place of regular integers. If you needed completely arbitrary precision, you could use a string to represent the number. (See the Perl arbitrary precision arithmetic packages "bigint" and "bigfloat" at CPAN for example.) Regards, Allan.Article: 31054
Do you know any free tool for painting digital waveforms ? Not for testbench generation, only for documentation. MarekArticle: 31055
My in-line comments below. Davis Moore <dmoore@nospamieee.org> 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. Indeed it is bps or "binary digits". >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*? Yes, indeed they are. Definitely yes!. But consider this - if I can put 200 bps (info plus parity) through the noiseless channel, but added noise causes half of these bits to be corrupt, then I am only guaranteed 100 bps of un-errored bits out the other end. These error free bits *might* be the parity bits, or might not - they are indeed just information bits. The trick is to manipulate the bits (code/decode) so that the 100 error-free bits recovered at the other end are always the useful information bits. THAT is what the Shannon-Hartley equation tells us! It tells us that given a certain amount of noise, you should be able to get 100 error-free *information* bits per second out of the channel even though you put 200 bits per second into the channel. You see! The value C is our design goal! >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: 31056
Hi - please read my comments in the newer thread "Shannon Capacity - An Apology" I think we agree. Nemo Muzaffer Kal <muzaffer@dspia.com> wrote: >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.comArticle: 31057
Austin, please read carefully my response to Davis' post above. Stick to the question of what does C represent in the equation being discussed, and follow the example of 200 bps put into the channel and only getting out 100 bps of *error-free* bits do to added noise. I agree, all bits (info, parity, whatever) are carried on the channel, but C tells us how many *useful* bits we should be able to get out the other end of the channel for a given bandwidth and noise level. You see - no matter how many parity bits we add to the info on the input side, the equation tells us we should be able to get C bps of error-free useful bits out the other end. I am not sure we are disagreeing. Yes, the equation does not distinguish one kind of bit from another, and in that sense, the analysis does include parity, but in another sense, the equation tells us with good channel coding and modulation techniques, C bits of *useful* information should be obtainable *out* of this channel. In that sense, the value C does *not* include parity. Austin Lesea <austin.lesea@xilinx.com> wrote: >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. >> > >> > NemoArticle: 31058
On Wed, 09 May 2001 15:39:55 -0600, Davis Moore <dmoore@nospamieee.org> wrote: >I disagree with your statements. I believe the answer lies clearly in the >equation itself. > >C = W*Log2(1-S/N) bps This is an interesting equation since it has the channel capacity DECREASING as S/N increases(for small S/N), which is intuitively absurd. Anyone care to explain? I can't find it in Shannon's paper in this form, however p.47 has C = W*Log(1+S/N) >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*? They are not information by definition; they are redundant. (Review Section 7 of Part 1 of the paper to see this) Therefore they are not included in the channel capacity, though they must indeed be transmitted through the channel >It seems as though everyone is taking an abstract view of a theorem >that is based very strongly in physics. Agreed. Remember that noise does not affect the bandwidth of the channel; therefore it does not change the number of symbols you can transmit. However it DOES corrupt a fraction of those symbols; therefore you must reserve a fraction of those symbols for redundancy to make the transmission reliable. Reserve too few and comms are unreliable, because you have exceeded the channel capacity. Reserve too many and comms are reliable; however there aren't many symbols left to carry _information_, therefore you fall short of the channel capacity. This is what the following extract from the paper is getting at... -------------- key extract from the paper ----------------- The capacity C of a noisy channel should be the maximum possible rate of transmission, i.e., the rate when the source is properly matched to the channel. We therefore define the channel capacity by C = Max(H(x) - Hy(x)) ------------- and ------------------ Hy(x) is the amount of additional information that must be supplied per second at the receiving point to correct the received message. ------------------------------------ Now although he refers to the error correction as "additional information" that information rate is explicitly subtracted from the channel capacity C. Because it doesn't add information to the message. - BrianArticle: 31059
Marek Ponca wrote: > Do you know any free tool for painting digital waveforms ? > Not for testbench generation, only for documentation. > > Marek ...depends how you store the waveforms. Postscript? PDF? UtkuArticle: 31060
It doesn' matter, how it than will be stored, all I want is to draw a certain waveforms in some more sophisticated way. One possibility were to create an behaviour model of such a system, with that waveforms... M. Utku Ozcan wrote: > > Marek Ponca wrote: > > > Do you know any free tool for painting digital waveforms ? > > Not for testbench generation, only for documentation. > > > > Marek > > ...depends how you store the waveforms. Postscript? PDF? > > UtkuArticle: 31061
TWFyZWsgUG9uY2Egd3JvdGU6DQoNCj4gRG8geW91IGtub3cgYW55IGZyZWUgdG9vbCBmb3Ig cGFpbnRpbmcgZGlnaXRhbCB3YXZlZm9ybXMgPw0KPiBOb3QgZm9yIHRlc3RiZW5jaCBnZW5l cmF0aW9uLCBvbmx5IGZvciBkb2N1bWVudGF0aW9uLg0KPg0KPiBNYXJlaw0KDQpIZWxsbyBN YXJlaywNCg0KaWYgeW91IGFyZSBmYW1pbGFyIHdpdGggTGF0ZXggLCB5b3UgY2FuIHVzZSBh IHN0eWxlIGZpbGUgbmFtZWQNCnRpbWluZy5zdHkgKHNlZQ0KZnRwOi8vZnRwLmRhbnRlLmRl L3RleC1hcmNoaXZlL21hY3Jvcy9sYXRleC9jb250cmliL290aGVyL3RpbWluZy8pLg0KV2l0 aCB0aGUgaGVscCBvZiB0aGVzZSBzdHlsZS1maWxlcyB5b3UgY2FuIGNyZWF0ZSB3YXZlZm9y bXMgd2l0aCB5b3VyDQpmYXZvcml0ZSBlZGl0b3IgYW5kIHRoZSBsYXRleCBlbnZpcm9ubWVu dCBpbnN0ZWFkIG9mIHBhaXRpbmcgdGhlbS4NCg0KY2lhbw0KSm9lcmcNCg==Article: 31062
I'm experiencing some problems trying to perform functional post-synthesis simulation on a VHDL net-list generated by Leonardo (v1999.1d build 6.60) following targeting to a Xilinx xc4000XL device. The VHDL net-list generated from Leonardo contains illegal VHDL characters. Specifically all references to a net are placed in backslash's. (The net is nx2087 and in the VHDL net-list is appears as /_nx2087/). As a result the net-list can not be compiled for simulation without removing these extra characters. I'd like to assume that Leonardo has identified a problem with this particular net and has therefore inserted the illegal characters to make the designer aware of the problem. I have scoured the transcript log and I can find no reason for any a problem occurring on this net. I've searched the Leonardo documentation but can find no reference to this problem. I have tried changing the target device to other Xilinx FPGA's. Using 3000 series the problem disappears. Using Virtex I have the same problem but it occurs on a lot more nets. Has anyone experienced this same problem? I'd be very grateful for any help. Thank, Darrell Gibson. Darrell Gibson Bournemouth University, P422 Poole House, Talbot Campus, POOLE. (UK)Article: 31063
--------------58337A3BB5188779B337B728 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I really am going to quit replying: But I thought I would leave it in Shannon's own words....with a few of my own. For that, I really do apologize: Shannon really did a great job explaining it, and I feel that maybe the best thing to do is read his paper, and then go build something to prove it to yourself. My learning experience was a 16QAM modem with BCH coding. From "Communication in the Presence of Noise," 1940, published 1948. C = W log2 (P+N)/N ..... "This shows that the rate W log (P+N)/N measures in a sharply defined way the capacity of the channel for transmitting information. It is a rather surprising result, since one would expect that reducing the frequency of errors would require reducing the rate of transmission, and that the rate must approach zero as the error frequency does. Actually we can send at the rate C but reduce errors by using a more involved encoding and longer delays at the transmitter and receiver." (emphasis added by me) I begin to see what is so confusing. We have a bunch of people with only two fingers. The bits (C) are encoded into some kind of symbols that are sent over the channel (tones, phases, voltages, currents, photons, wavelengths) in some kind of information coding scheme (BCH code, Virterbi, Turbo, Hamming....). The symbols are recovered at the receiver, and decoded (corrected) and presented as the received information. The theorem does not concern itself with the actual rate of the encoded symbols in the channel or even their format, but rather their power vs. bandwidth and the power and bandwidth of the noise. If one confines oneself to using a binary symbol in the channel (on off, 1-0, etc), then for every bit in C, there must be some extra bits added for correction in the channel to perform error correction. But if we increate the rate of the bits in the channel, we get more errors for a given N, keeping P constant. Thus, C ends up including the error correction bits because the channel C must be equal to or greater than the information C. Thus, we must reduce the number of bits in the channel per unit time given a specific error correcting code to achieve some desired performance. If we instead use arbitrarily more complex symbols (QPSK, 16OQAM, OFDM ....), then for every bit in C, there are bits added to the channel, but the rate of the symbols may now actually be much less than that of the rate of the binary channel (PSK = 2 bits per symbol, 16QAM = 4 bits/symbol, etc.). This added degree of freedom in effect allows for many more bits in the channel to be utilized for error correction without increasing the bandwidth W of the channel, or the power P of the information in the channel. C (rate in b/s) in the channel is greater than the C (rate in b/s) of the information, allowing for the error checking and correcting information. Thus, if one allows for complex symbols (base > 2), one begins to take advantage of the encoding and decoding, without affecting the rate of the symbols in the channel. Austin Brian Drummond wrote: > On Wed, 09 May 2001 15:39:55 -0600, Davis Moore <dmoore@nospamieee.org> > wrote: > > >I disagree with your statements. I believe the answer lies clearly in the > >equation itself. > > > >C = W*Log2(1-S/N) bps > > This is an interesting equation since it has the channel capacity > DECREASING as S/N increases(for small S/N), which is intuitively absurd. > Anyone care to explain? > > I can't find it in Shannon's paper in this form, however p.47 has > > C = W*Log(1+S/N) > > >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*? > > They are not information by definition; they are redundant. > (Review Section 7 of Part 1 of the paper to see this) > > Therefore they are not included in the channel capacity, though they > must indeed be transmitted through the channel > > >It seems as though everyone is taking an abstract view of a theorem > >that is based very strongly in physics. > > Agreed. > > Remember that noise does not affect the bandwidth of the channel; > therefore it does not change the number of symbols you can transmit. > However it DOES corrupt a fraction of those symbols; therefore you must > reserve a fraction of those symbols for redundancy to make the > transmission reliable. > > Reserve too few and comms are unreliable, because you have exceeded the > channel capacity. Reserve too many and comms are reliable; however there > aren't many symbols left to carry _information_, therefore you fall > short of the channel capacity. > > This is what the following extract from the paper is getting at... > > -------------- key extract from the paper ----------------- > The capacity C of a noisy channel should be the maximum possible rate of > transmission, i.e., the rate when the source is properly matched to the > channel. We therefore define the channel capacity by > C = Max(H(x) - Hy(x)) > ------------- and ------------------ > Hy(x) is the amount of additional information that must be supplied per > second at the receiving point to correct the received message. > ------------------------------------ > > Now although he refers to the error correction as "additional > information" that information rate is explicitly subtracted from the > channel capacity C. Because it doesn't add information to the message. > > - Brian --------------58337A3BB5188779B337B728 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> I really am going to quit replying: <p>But I thought I would leave it in Shannon's own words....with a few of my own. <p>For that, I really do apologize: Shannon really did a great job explaining it, and I feel that maybe the best thing to do is read his paper, and then go build something to prove it to yourself. My learning experience was a 16QAM modem with BCH coding. <p>From "Communication in the Presence of Noise," 1940, published 1948. <p>C = W log2 (P+N)/N <p>..... <p>"This shows that the rate W log (P+N)/N measures in a sharply defined way the capacity of the channel for transmitting information. It is a rather surprising result, since one would expect that reducing the frequency of errors would require reducing the rate of transmission, and that the rate must approach zero as the error frequency does. Actually we can send at the rate C but reduce errors by using a <i>more involved encoding</i> <u>and</u> <i>longer delays at the transmitter and receiver</i>." <p>(emphasis added by me) <p>I begin to see what is so confusing. We have a bunch of people with only two fingers. <p>The bits (C) are encoded into some kind of symbols that are sent over the channel (tones, phases, voltages, currents, photons, wavelengths) in some kind of information coding scheme (BCH code, Virterbi, Turbo, Hamming....). The symbols are recovered at the receiver, and decoded (corrected) and presented as the received information. <p>The theorem does not concern itself with the actual rate of the encoded symbols in the channel or even their format, but rather their power vs. bandwidth and the power and bandwidth of the noise. <p>If one <b>confines oneself to using a binary symbol</b> in the channel (on off, 1-0, etc), then for every bit in C, there must be some extra bits added for correction in the channel to perform error correction. But if we increate the rate of the bits in the channel, we get more errors for a given N, keeping P constant. Thus, C ends up including the error correction bits because the channel C must be equal to or greater than the information C. <p>Thus, we must <b>reduce</b> the number of bits in the channel per unit time <b>given a specific error correcting code</b> to achieve some desired performance. <p>If we instead use <b>arbitrarily more complex symbols</b> (QPSK, 16OQAM, OFDM ....), then for every bit in C, there are bits added to the channel, but the rate of the symbols may now actually be much less than that of the rate of the binary channel (PSK = 2 bits per symbol, 16QAM = 4 bits/symbol, etc.). This added degree of freedom in effect allows for many more bits in the channel to be utilized for error correction without increasing the bandwidth W of the channel, or the power P of the information in the channel. C (rate in b/s) in the channel is greater than the C (rate in b/s) of the information, allowing for the error checking and correcting information. <p>Thus, if one allows for complex symbols (base > 2), one begins to take advantage of the encoding and decoding, <b>without affecting the rate of the symbols in the channel</b>. <p>Austin <p>Brian Drummond wrote: <blockquote TYPE=CITE>On Wed, 09 May 2001 15:39:55 -0600, Davis Moore <dmoore@nospamieee.org> <br>wrote: <p>>I disagree with your statements. I believe the answer lies clearly in the <br>>equation itself. <br>> <br>>C = W*Log2(1-S/N) bps <p>This is an interesting equation since it has the channel capacity <br>DECREASING as S/N increases(for small S/N), which is intuitively absurd. <br>Anyone care to explain? <p>I can't find it in Shannon's paper in this form, however p.47 has <p>C = W*Log(1+S/N) <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*? <p>They are not information by definition; they are redundant. <br>(Review Section 7 of Part 1 of the paper to see this) <p>Therefore they are not included in the channel capacity, though they <br>must indeed be transmitted through the channel <p>>It seems as though everyone is taking an abstract view of a theorem <br>>that is based very strongly in physics. <p>Agreed. <p>Remember that noise does not affect the bandwidth of the channel; <br>therefore it does not change the number of symbols you can transmit. <br>However it DOES corrupt a fraction of those symbols; therefore you must <br>reserve a fraction of those symbols for redundancy to make the <br>transmission reliable. <p>Reserve too few and comms are unreliable, because you have exceeded the <br>channel capacity. Reserve too many and comms are reliable; however there <br>aren't many symbols left to carry _information_, therefore you fall <br>short of the channel capacity. <p>This is what the following extract from the paper is getting at... <p>-------------- key extract from the paper ----------------- <br>The capacity C of a noisy channel should be the maximum possible rate of <br>transmission, i.e., the rate when the source is properly matched to the <br>channel. We therefore define the channel capacity by <br>C = Max(H(x) - Hy(x)) <br>------------- and ------------------ <br>Hy(x) is the amount of additional information that must be supplied per <br>second at the receiving point to correct the received message. <br>------------------------------------ <p>Now although he refers to the error correction as "additional <br>information" that information rate is explicitly subtracted from the <br>channel capacity C. Because it doesn't add information to the message. <p>- Brian</blockquote> </html> --------------58337A3BB5188779B337B728--Article: 31064
Alan Glynne Jones wrote: > For the purposes of creating a random number generator in a testbench I > want to use integers with ranges which exceed 32 bits. Is there a way > to do this? > > Alan We build a multi-precision -library to handle numbers up 1024 bit and more (=> 310 decimals). HagenArticle: 31065
John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote: >Hi, > >we've just shipped a new product that uses 5 Spartan-XL chips, and had >a fair amount of grief getting things up. We're using the basic >Foundation schematic-entry stuff, with service packs duly installed. > >The worst thing we found is that, if we connect a signal to a pin and >don't reference it on the schematic, the pin will sometimes become an >output and do weird things. In one case, we ran the VME signal AS* >(address strobe) into the chip and decided later we didn't need it, so >ignored it. It then began hanging the VME bus by pulling AS* low, but >only when certain VME addresses were used! The problem is that the output gets connected to an internally generated net so you are observing the state of some internal logic. The solution is to muck with the edf or the similar netlist and force the pin to an input manually. I have seen this problem too and it is annoying but solvable. By using the and gate you are getting the tool do the input setting on the pin.Article: 31066
Altera has announced a port of Quartus II (including MAX+PLUS II) to Linux! http://www.altera.com/corporate/press_box/releases/pr-linux_quartus.html http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.050701/211270104 At last, one of the programmable logic vendors gets it. They say "Linux has enjoyed dramatic success over the last several years as a platform for a variety of EDA point tools, such as simulation, because of the low cost per compute cycle." An interesting contrast from Xilinx' claims that there is no customer demand for Linux. The availability is a bit confusing; the press release says "Altera [...] today announced plans to port the Quartus (R) II design software to Linux-based environments". Later it says "The Quartus II version 1.0 software is available today", by which they presumably mean a non-Linux version? On 29-Jun-2000, a Cypress employee told me that they were working on Linux support for a future release of their Warp software, which they expected to have developed within a year. It will be interesting to see whether they follow through. Do any other programmable logic vendors support Linux?Article: 31067
I am not familiar with the Altera tools, but I am wondering why Xilinx has no ambitions to port their software. It should be quite easy. Coregen for example should work under linux right away. The backend tools probably do not use more than stdio and should run within a couple of hours. The GUI frontend has been copmletely rewritten recently, and with the use of the right GUI toolkit (Java?) multi platform support should have been not much of a problem. FGPA Express would maybe be more complicated, but thats what XST is for, isn't it? On the other hand: Large parts of tools have not even been ported to Windows 95 yet: No long file names, and the backend tools run in a 16-Bit environment. Also: Did anybody try to run Foundation in a NT multi user environment? Write permission for everybody to a couple of files and directories, and tool preferences are kept globaly, not in a user directory, as it is common with almost every UNIX tool. Kolja Sulimma At least Eric Smith wrote: > Altera has announced a port of Quartus II (including MAX+PLUS II) > to Linux! > > http://www.altera.com/corporate/press_box/releases/pr-linux_quartus.html > http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.050701/211270104 > > At last, one of the programmable logic vendors gets it. They say "Linux > has enjoyed dramatic success over the last several years as a platform > for a variety of EDA point tools, such as simulation, because of the low > cost per compute cycle." An interesting contrast from Xilinx' claims > that there is no customer demand for Linux. > > The availability is a bit confusing; the press release says "Altera > [...] today announced plans to port the Quartus (R) II design software > to Linux-based environments". Later it says "The Quartus II version 1.0 > software is available today", by which they presumably mean a non-Linux > version? > > On 29-Jun-2000, a Cypress employee told me that they were working on > Linux support for a future release of their Warp software, which they > expected to have developed within a year. It will be interesting to see > whether they follow through. > > Do any other programmable logic vendors support Linux?Article: 31068
Eric Smith wrote: > > Altera has announced a port of Quartus II (including MAX+PLUS II) > to Linux! > > http://www.altera.com/corporate/press_box/releases/pr-linux_quartus.html > http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.050701/211270104 > > At last, one of the programmable logic vendors gets it. They say "Linux > has enjoyed dramatic success over the last several years as a platform > for a variety of EDA point tools, such as simulation, because of the low > cost per compute cycle." An interesting contrast from Xilinx' claims > that there is no customer demand for Linux. > > I wonder if Xilinx's attitude stems from these 2 (my opinion only) equivalences: (1) Linux user <=> serious user (2) GUI user <=> !serious user From which we can derive (3) Linux user <=> !GUI user Given that VMWare provides a way of using the command line tools under Linux then (3) => Xilinx doesn't have to do a Linux port. Question: Do Quartus & Warp tools run from the command line as well as the Xilinx ones do ? are the command line i/f's as well documented ? <snip>Article: 31069
Brian Drummond schrieb: > > On Wed, 09 May 2001 15:39:55 -0600, Davis Moore <dmoore@nospamieee.org> > wrote: > > >I disagree with your statements. I believe the answer lies clearly in the > >equation itself. > > > >C = W*Log2(1-S/N) bps > > This is an interesting equation since it has the channel capacity > DECREASING as S/N increases(for small S/N), which is intuitively absurd. > Anyone care to explain? Must be: C = W*Log2(1+S/N) bps Thats what i learned and also found in Shannons paper otherwise there would be Log of a negative number, or did i miss something ? bertram -- Bertram Geiger, bgeiger@aon.at HTL Bulme Graz-Goesting - AUSTRIAArticle: 31070
Bertram Geiger <bgeiger@aon.at> wrote: >Brian Drummond schrieb: >> >> On Wed, 09 May 2001 15:39:55 -0600, Davis Moore <dmoore@nospamieee.org> >> wrote: >> >> >I disagree with your statements. I believe the answer lies clearly in the >> >equation itself. >> > >> >C = W*Log2(1-S/N) bps >> >> This is an interesting equation since it has the channel capacity >> DECREASING as S/N increases(for small S/N), which is intuitively absurd. >> Anyone care to explain? > > >Must be: C = W*Log2(1+S/N) bps >Thats what i learned and also found in Shannons paper >otherwise there would be Log of a negative number, or did i miss >something ? > >bertram You and Brian are correct, it should be a plus sign. NemoArticle: 31071
I am using an XESS XS40 prototyping board and I have a verilog program that, when synthesized, stores a 9 bit value in a register which is updated at certain points in time. Here's the problem: I need to get the data from this register into my PC through the parallel port. I don't have much experience with this, so I'm looking for code examples of how to read the data in on the PC, and also how I would go about sending the data out since, according to the docs, I can only use the 5 status pins of the parallel port to send data from the FPGA to the PC, but I have 9-bit addresses I need to send. I'm assuming I'll have to shift the data out bit by bit and also generate a clock signal on one of those 5 status pins, but I'm vague on the actual implementation. I'm sure many of you have either used these boards or have had to code something similar before, so any code examples, links to code examples, or general advice would be greatly appreciated. I got one response last time I posted this, but I'm looking for something more along the lines of code samples. Thanks! VikArticle: 31072
I am a software engineer and know little about FPGA. There are quite few tutorials on the web. I am looking for a good tutorial suitable for my background. Any one has some recommandations? I'm sorry if I post it to a wrong place. GT -- Sent by guangbutun from hotmail within area com This is a spam protected message. Please answer with reference header. Posted via http://www.usenet-replayer.com/cgi/content/newArticle: 31073
I'm having trouble logging on to the Synplicity online support service (SOS). Anyone else had any problems with this ?Article: 31074
Rick Filipkiewicz <rick@algor.co.uk> writes: > Given that VMWare provides a way of using the command line tools under > Linux then > (3) => Xilinx doesn't have to do a Linux port. I use VMware. But running Windows software under VMware is really annoying compared to running native Linux software. VMware supports more than just the command line tools. Since it runs real Windows, it runs the GUI stuff too. However, I'd much prefer to completely remove Windows from my system. Right now the Xilinx software is the ONLY reason I have Windows installed. I haven't looked at Altera's FPGAs in a few years, but if their parts will do what I want, having native tools for Linux may well make me switch. The Xilinx Windows GUI wrapper is nice in some ways, but I'd trade it for command-line-only tools under Linux without any hesitation whatsoever. But if Xilinx ever does decide to support Linux, there are Windows GUI compatability libraries they could use to port the GUI. My personal preference would be to get the command line tools (only) in a first Linux release, rather than holding up a Linux release until the GUI is ported. However, given how hostile to Linux Xilinx seems to be, I'm not holding my breath.
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