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
Kevin Neilson wrote: > Variables like this should be set "pre-synthesis" to allow the use of a > smaller part and remove unneeeded logic from the critical path, and then the > appropriate bitfile should be loaded when required. Yet most customers want > all mutually exclusive modes to be present in the Xilinx at the same time as > though it were an ASIC. One way to do this (assuming you have the source code) is to comment and change the register declarations from an array of signals to an array of constants and comment out the register process. This way you keep the options documented, but let synthesis cut out those functions not being used and hard-wire those that are. -Mike TreselerArticle: 30926
Peter Alfke wrote: > There is something weird about implementing a standard UART in an FPGA. > A UART is a standard chip, endowed with all the programmable registers to adapt > it to particular requirement. Throwing that design onto an FPGA means that you > are double-programmable, and double inefficient. > The FPGA user knows (usually) whether parity is odd or even, how many stop bits, > how large a FIFO, etc. > Controlling all this with registers doesn't make sense when you use an > inherently programmable technology. while this is true, these types of assumptions make me very nervous. The second you fix the UART parameters, someone (probably marketing) will tell you that your design will talk to another device, which needs XX parameters. If you haven't planed for this from the beginning, you might be up shit creek! Besides, it is much easier from a SW point of view to have a standard interface to program (or port code) to. i.e. 16550, 16750, etc. Although the driver that I just finished for a TI16C752 under the ThreadX RTOS was quite a bitch. Makes me wonder if anyone thought before designing these parts (several undocumented gotchas). That having been said, the best (non-standard) UART that I have seen is in Atmel's microprocessors (AT91??????) Rather than putting in FIFOs they have pointer and counter registers (kind of a DMA thing). It is really great from a programmers point of view! Just write a pointer to your buffer in memory and away you go! I don't know what would be involved with programming this in an FPGA would be, though, as I am new to VHDL and FPGAs, but am climbing the learning curve as fast as I can. In (limited) answer to the original poster, I noticed several several free UART designs in the various "open" web pages such as opencores, and freeIP (I think). Anyway, they were links off of the FAQ. jimArticle: 30927
> while this is true, these types of assumptions make me very nervous. > The second you fix the UART parameters, someone (probably marketing) > will tell you that your design will talk to another device, which needs > XX parameters. If you haven't planed for this from the beginning, you > might be up shit creek! Same problem for building an ASIC. If you keep your frequency programmable you have only 20 combinations of options left. Some of them even are compatible. (8S1 and 8N2 for example are identical, 8N1 can receive 8N2 transmissions...) > Besides, it is much easier from a SW point of > view to have a standard interface to program (or port code) to. i.e. > 16550, 16750, etc. There are two options for this: The first one is to implement a subset with a register interface that is compatible to the standard chip as long as only a defined subset of options is set. Write to these configuration bits will just be ignored. We needed for example a 8255 that is always in Mode 1. Another option is to keep the part that receives and sends data compatible, but replace the configuration part. This leaves a well defined portion of the driver that needs to be rewritted to load multiple configuration into the FPGA. But most of the driver does not need to be touched. BTW:.If you have a look a the verious GETTYs for Unix/Linux/BSD you will notice that most of them only support a small subset of the UART options. Kolja SulimmaArticle: 30928
All recruiters. Please do not use this newsgroups to post your job adds. Please use http://groups.yahoo.com/group/EEJOBSArticle: 30929
Guys, I was hoping for more of a consensus! I have done a tally, and it seems that members of the "bits are bits" group (those that believe C refers to ALL bits per second) number two, namely Austin and Nemo. The "bits are information" group (those that believe C refers to bits of INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my colleagues Rob and Dr. Bob. The latter theory has more proponents and seems to be more elegant, though neither of those are great reasons for taking a side. I've read textbooks, which have not been enlightening, so I'll just have to read Shannon's paper before I make any final conclusions. -KevinArticle: 30930
--------------58048A6B68A02CA81D8EDEF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin, I had no idea Shannon was so misunderstood. Actually, I am kidding: I know exactly how well misunderstood Shannon is (was). I know the consultants will continue to make a fortune for their understanding (or lack of understanding) of this subject. Caveat Emptor! I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the Galaxy" who have the Earth destroyed to prevent the "answer to the universe and everyhting" from being found. If you know the answer, who needs the psychiatrist? While the answer is being sought in the very beginning, before it was actually found, two psychiarists realize they and many of their descendents can make a fortune by continuing the controversy..... Enjoy Austin Kevin Neilson wrote: > Guys, I was hoping for more of a consensus! I have done a tally, and it > seems that members of the "bits are bits" group (those that believe C refers > to ALL bits per second) number two, namely Austin and Nemo. > > The "bits are information" group (those that believe C refers to bits of > INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my > colleagues Rob and Dr. Bob. > > The latter theory has more proponents and seems to be more elegant, though > neither of those are great reasons for taking a side. I've read textbooks, > which have not been enlightening, so I'll just have to read Shannon's paper > before I make any final conclusions. > > -Kevin --------------58048A6B68A02CA81D8EDEF1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Kevin, <p>I had no idea Shannon was so misunderstood. <p>Actually, I am kidding: I know <b>exactly</b> how well misunderstood Shannon is (was). <p>I know the consultants will continue to make a fortune for their understanding (or lack of understanding) of this subject. Caveat Emptor! <p>I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the Galaxy" who have the Earth destroyed to prevent the "answer to the universe and everyhting" from being found. If you know the answer, who needs the psychiatrist? <p>While the answer is being sought in the very beginning, before it was actually found, two psychiarists realize they and many of their descendents can make a fortune by continuing the controversy..... <p>Enjoy <p>Austin <p>Kevin Neilson wrote: <blockquote TYPE=CITE>Guys, I was hoping for more of a consensus! I have done a tally, and it <br>seems that members of the "bits are bits" group (those that believe C refers <br>to ALL bits per second) number two, namely Austin and Nemo. <p>The "bits are information" group (those that believe C refers to bits of <br>INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my <br>colleagues Rob and Dr. Bob. <p>The latter theory has more proponents and seems to be more elegant, though <br>neither of those are great reasons for taking a side. I've read textbooks, <br>which have not been enlightening, so I'll just have to read Shannon's paper <br>before I make any final conclusions. <p>-Kevin</blockquote> </html> --------------58048A6B68A02CA81D8EDEF1--Article: 30931
Jonas Thor <thor.NO@SPAM.sm.luth.se> wrote: >Hello! > >This is a not well defined question, but I'll ask anyway... I want to >measure, with high precision, the time between two rising edges of two >pulses. I have a reference clock, frequency F, of about 5-10 MHz, but >I need measurements much more accurate than 1/F. (The rising edges are >of course asynchronous to the reference clock.) > >What can I do in a FPGA get the best precison? What's the best I can >do without a DLL and with a DLL? The following is based on recollections of some equipment that I worked on several years ago, so I am happy to be corrected: This system was a microwave pulsed range measuring system, and the accuracy was improved by making repeated measurements. Effectively a counter was started when a pulse was transmitted and was stopped when it was received. The counter was not cleared, but was allowed to count up again during the next "two way" time. This was done 100 times in all, then the accumulated count was used in the final range measurement. I'm sure that such a system is vulnerable to "accidental" synchronous problems, but it worked very well. Richard ------------Richard Dungan------------- Radix Electronic Designs, Orpington, UK richardATradix-designDOTcoDOTuk ---------------------------------------Article: 30932
For the example of gene-sequence correlation, the accelleration figure given by Compugen for their hardware is 725. That is, they say the FPGA solution correlates a 1-kilobase sequence to the 700 million bases in GenBank in 8 minutes vs. 4 days for a UNIX workstation. Granted, a UNIX workstation isn't a DSP, but a single 1kilobase correlation would probably take at least 1000 cycles on a single-ALU DSP and could take as little as one cycle in a big enough FPGA. http://compugen.co.il/products/bioxl_tech.htm -Kevin "Ray Andraka" <ray@andraka.com> wrote in message news:3AF1609F.D3DC4481@andraka.com... > > > Steve Bradshaw wrote: > >> As Ray already commented, 1000:1 is at the extreme end of potential > > performance gain. Quoting a 10:1 through 1000:1 performance gain range > > though is a bit on the vague side, don't you think Ray ? [I like the web > > site though, I'll have to check it out when I get back in the office next > > week] > > Fact of the matter is the gains really do run this range, and much depends also > on the performance target. It is very easy to trade hardware for performance in > an FPGA. If I dig through past conference papers etc, I can cite specific > examples where the gains are more than 1000:1. As I mentioned, I am typically > applying FPGAs in applications where the requirements dictate somewhere around > 100:1 (thus the design point). Many of these are in smaller FPGAs, and much > higher processing gains can be made with larger parts. The processing gain I am > quoting is the performance measured as the time required to complete the task as > compared with other solutions. > > FPGAs do fit a rathter wide class of problems in the DSP space. Basically > anything that subjects a large or streaming dta set to the same or similar > processes is suitable for FPGA implementation. > > > > > > I'd be careful about comparing GOPS, BOPS, and whatever other clock rate > > multiplied by the number of arithmetic units and the like with logic cells. > > It won't help. Besides, it's really just part of a very sophisticated > > marekting language that doesn't mean very much :^) What you really need to > > do is compare what people are achieving for specific algorithms. I'm not > > really familiar with Intel performance capabilities for DSP but Texas > > Instruments and Xilinx have lots of figures on their web sites, where you > > see what their respective approaches will allow for such things like > > Filters, FFTs, etc... You'll should find some good performance gains on > > anything FIR related, such as decimation, down conversion, etc... > > > > Rays web site is clearly biased towards the FPGA approach. I certainly go > > along with the FPGA offering some substantial gains over DSPs, but it really > > depends on the situation. In the situations where you can exploit > > parallelism at the logic level, the FPGAs will blow DSPs away. You'll > > probably find that this isn't always the case though, and there are many > > advantages for using a DSP also. > > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com >Article: 30933
Austin Lesea <austin.lesea@xilinx.com> writes:
> I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the
> Galaxy" who have the Earth destroyed to prevent the "answer to the
> universe and everyhting" from being found. If you know the answer,
> who needs the psychiatrist?
Philosophers.
"We demand rigidly defined areas of doubt and uncertainty."
-- Vroomfondle, philosopher in Douglas Adams'
_Hitchhiker's Guide to the Galaxy_
> While the answer is being sought in the very beginning, before it was
> actually found, two psychiarists realize they and many of their
> descendents can make a fortune by continuing the controversy.....
They don't realize it. Deep Thought, the computer tasked
with finding the answer, points it out to them.
Article: 30934I wrote: > "We demand rigidly defined areas of doubt and uncertainty." > -- Vroomfondle, philosopher in Douglas Adams' > _Hitchhiker's Guide to the Galaxy_ Forgot to mention that "rigidly defined areas of doubt and uncertainty" is in a sense exactly what Shannon has given us. :-)Article: 30935
My design is quite large,the functional simulation is ok.When doing post timing,I found the output 200MHz clock of my clock module is constant "0", later I tried to do timing simulation of clock module seperately,the problem still exists.
one of my clock module input clock CLKIN is 50MHz, a DCM is used to generate CLK1X(50MHz),CLK2X(100MHz),CLK4X (200MHz).CLK4X is output signal DCM CLKFX through a BUFGMUX.the design is quite simple ,however, I met following problem during post timing simulation:
When I set CLKIN to 50MHz, CLK4X didn't appear,but CLKFX is ok(200MHz);CLKFX is the output of DCM and input of a BUFGMUX,CLK4X is output of this BUFGMUX and output of clock module.
but when I set CLKIN to 25MHz, CLK4X is ok, my clock module goes well.
Device family VitrtexII xc2v1000.
Developing tool: Foundation iSE 3.1i
I think the problem lies in BUFGMUX, but I dont konw what to do with.
Article: 30936Erik Widding wrote: > > "M.B." <martinb@magma.ca> wrote in message > news:3af14d0a.70056665@news.magma.ca... > > On Thu, 3 May 2001 00:47:15 -0400, "Austin Franklin" > > <austin@darkroo87m.com> wrote: > > > > >Actually, we did this at Micron in 1984...just mounted a DRAM in a clear > > >plastic package. Problem is, it is only line art...no gray > scale...unless > > >you did multiple exposures with a different aperture setting. > > > > Do you have any suggested part# and manufacturers of any drams that > > might work.? > > I have a simple cct now that can scan a 256k (262,144 cell) dram. but > > any avalible size could do. > > This used to work, because back in 1984, DRAMs were much simpler. > > In 1984 if a DRAM tested as anything less than "all good", it was considered > bad. Today, if a DRAM tests as less than all good, it is fixed by swapping > in row(s) from somewhere else on the chip to replace the row(s) with failed > bits. Process geometries are being pushed so far, that there is > satistically almost zero probability that an "all good" part will be > produced. If there is a reasonably high probability of producing all good > parts, it is time to shrink your geometry. This is one of the reasons fabs > look at FPGAs as a better indicator, than DRAM, of a clean process. Very > few FPGAs (if any) employ redundancy to correct for fab defects. Very few > tight geometry memory parts do not employ redundancy. IIRC, redundant rows were used in Intel's 2164 64k x 1 DRAM, which came out before 1984. The technique was described in the 1983 Intel Memory data book. Actually, just as hard disks have a table of bad sectors that the operating system knows to avoid, is there any theoretical reason why a list of bad resources on an FPGA die can't be fed to to the back end tools? (There are plenty of practical reasons why not, of course.) Regards, Allan.Article: 30937
> > My question to you folks out here, how many folks use FPGAs to prototype > > ASIC or other digital logic? I see countless posts relating to > > implementing > > certain functions on FPGAs...is that what you guys are doing? > > Here is some data that Xilinx presented at ISPD 2001 > http://www.ispd.cc/presentations/13_1.pdf > > From Slide 11 > 3% Emulation > 30% Prototyping > 30% Pre-Production > 37% Production > > This means that 67% of all FPGAs actually end up in products. Wow, I guess that explains why I see so many questions along the lines of optimization. But would it be fair to say that the 'pre-production' applications don't all end up in retail products?Article: 30938
> I'm a final year engineering honours student, preparing to do some image > processing thesis work on an FPGA. > > I'm interested in PCI cards that have been designed for FPGA-based image > processing (e.g. relatively simple PCI interface, substantial amount of > SRAM). I'm probably leaning toward using one of the Xilinx Virtex > architectures. There's the AVNET Virtex Development Kit (http://www.ads.avnet.com). Has several MBs of ZBT (zero-bus-time) SRAM, 16MB SDRAM, and an onboard 256-color (8-bit CLUT) RAMDAC for VGA-output. The SDRAM probably won't interest you unless you already have access to an SDRAM-controller core. funny, it seems to have disappeared from AVNET's inventory list. Oh well, the VirtexE develpoment kit is less useful to you, because it has no external SRAM memory (just the 64MB SDRAM.) It's also a bit expensive ($1400 USD) oh well... Insight Electronics (http://www.insight-electronics.com) has a very inexpensive ($150 USD) PCI Spartan2-150 board. It has 8MB SDRAM, but that's it. > If you are using such a PCI card and are happy with it, could you reply to > this post with the card's name and manufacturer (and your opinion of the > card)?Article: 30939
In article <1ALH6.226933$GV2.47295492@typhoon.san.rr.com>, maw@nospam.com says... > >Does anyone know of where I can find a free Verilog source code for a Serial >UART that can be used in a Xilinx XC4005XL FPGA? I am in need of such code >to add to a FPGA design I am making for remote access to the FPGA CPU... > >Thanks, >Mark > > ---------- at http://www.cmosexod.com/ ( follow FREE IP ) The micro-UART is a fully functional, synthesizable, universal asynchronous receiver transmitter core. The core is configurable and extremely compact. a full 16450 Compatible UART is planned ---------- not verilog but vhdl at http://www.opencores.org/cores/uart/ fixed 9600 baudrate for this version 1 start bit, 8 data bits, 1 stop bit data stream format both interrupt-based and polling user interface ---------- Desciptions are there own. I have tested neither. Klaus LeissArticle: 30940
Anonymous Idiot wrote: > > > My question to you folks out here, how many folks use FPGAs to prototype > > > ASIC or other digital logic? I see countless posts relating to > > > implementing > > > certain functions on FPGAs...is that what you guys are doing? > > > > Here is some data that Xilinx presented at ISPD 2001 > > http://www.ispd.cc/presentations/13_1.pdf > > > > From Slide 11 > > 3% Emulation > > 30% Prototyping > > 30% Pre-Production > > 37% Production > > > > This means that 67% of all FPGAs actually end up in products. > > Wow, I guess that explains why I see so many questions along the lines > of > optimization. > > But would it be fair to say that the 'pre-production' applications don't > all end up in retail products? The speaker defined these categories in the preceeding slides. Emulation is what you are doing: Take a VHDL-design and run it in an FPGA because your Simulator is to slow. The distinction to the prototyping catagory can be somewhat fluid, but he meant this to be FPGAs are used to build boards or systems as proof of princible, testbeds, system test, etc. In this case the goal is to emulate a whole system at working speed. Pre-Production in his sense are systems that are manufacture with FPGAs to be replaced by ASICs later, when the ASICs finally come out of the fab, or when it turns out the system was successful enough to justify ASIC NREs. So all these 30% end up in products. The final 37% are FPGAs that are used in designs that are meant to be FPGA base throughout there whole lifecycle. (Do a search on eBay. Usualy there are some offers for SCSI controllers with XILINX chipsets. I also own a highend soundcard based on XCS40.) Of course there are much more prototyping DESIGNS done in FPGAs than anything other, but I am surprised that 30% of the CHIPS sold in a huge market end up in prototypes. Kolja SulimmaArticle: 30941
I assume you targeting Xilinx devices if you are using Xchecker, so you can use either promgen (command line) or promfmtr (gui) in the xilinx tool set. Segis <segisweb@jazzfree.com> wrote in message news:sjFH6.6090$q7Tm.76677254@news.jazztel.es... > Hi, > We´re an University searching team and we´re working on FPGA technology. > We´ve developed a program to be downloaded into our FPGA desing by the > Xchecker cable. Now, we´d like to keep our program in a PROM. But, > unfortunately, we don´t know how to translate our FPGA file into a PROM file > to be downloaded to the PROM. > We´re looking for information about a translator program (SW) and any useful > tips related to that. Do you know something about that? Would you mind > helping us? > > Thank you so much for your help!. > > Best regards, > > Segismundo Alonso > > > P.S. Send your reply to segisweb@jazzfree.com > >Article: 30942
Hello, Any pointers where to find a 'simple' CompactPCI card with a Xilinx Virtex and a minimum of 32MBit RAM? thanx, StevenArticle: 30943
Hi, I have a Digilab XLA3 with Spartan XL FPGA on board. I've used the test utility on the digilent site, and the FPGA configures fine. Now, I have used their test design, and implemented a very simple design of my own, in the Xilinx Foundation series environment. The designs are fine, but when I try to program using the JTAG programmer (using parallel cable), it can't configure the FPGA, saying : Loading Boundary-Scan Description Language (BSDL) file 'C:/Utils/Xilinx/spartan/data/xcs10_pc84.bsd'.....completed successfully. Checking boundary-scan chain integrity...ERROR:JTag - Boundary-scan chain test failed at bit position '2' on instance 'firstled(Device1)'. A problem may exist in the hardware configuration. Check that the cable, scan chain, and power connections are intact, that the specified scan chain configuration matches the actual hardware, and that the power supply is adequate and delivering the correct voltage. ERROR:JTag - Boundary scan chain has been improperly specified. Please check your configuration and re-enter the boundary-scan chain information. Boundary-scan chain validated unsuccessfully. ERROR:JTag - : The boundary-scan chain has not been declared correctly. Verify the syntax and correctness of the device BSDL files, correct the files, reset the cable and retry this command. ERROR:JTag - Unable to automatically identify the composition of the boundary-scan chain. A problem may exist in the hardware configuration. Check that the cable, scan chain, and power connections are intact, that the power supply is adequate and delivering the correct voltage. HELP!!!!!!!!!!!!!! Thanks AdrianArticle: 30944
In an application, we try to use record type in an architecture with
several levels. This record type has to replace several signals that are
assigned at the lowest level of the architecture and go to the highest
level of the architecture, as this :
-level 0 (highest in the architecture)
-level 01
-level 011
-level 012
-level 013
-level 02
-level 021
-level 022
-level 023
-level 03
The new type declared in a package is :
type X is
record
X1 : std_logic;
X2 : std_logic_vector(3 downto 0);
X3 : std_logic;
X4 : std_logic;
end record;
The goal is that the entity become smaller to be more readable.
We declare new signals of type X in each level of the architecture, as
input and as output (X011 in level 011, X012 in level 012, ...). For
example, I assigned X011.X1 in level 011, X012.X2 in level 012 and
X013.X3 in level 013.
If the signals are input, the use of record type doesn't make any
problem nor in simulation, nor in synthesis.
As ouput, many problem appear. The instantation in level 01 of a X type
signal with X type output signals of level 011, 012 and 013 shows bus
conflicts (whereas each agregate in the signal of level 01 is only
driven by one signal in the sublevels).
In simulation, we found a solution. It's to initialize all the signals
with 'Z', to use the resolution function of std_logic type, which can
resolve these conflicts because 'Z' is the lowest priority in this
function.We use Innoveda Speedwave to simulate our design.
In synthesis, the same problem appear but the bus conflict cannot be
resolved and it's impossible to synthetize our design. We use FPGA
Express to synthetize our design.
Is there another solution to use record in an architecture like this
(don't speak about bus vector to concatenate signal, it's unreadable...)
Thanks.
P.S. : Please, send answer to my email address below too.
----------------------------------------------
Olivier MALLINGER CELOGIC
Hardware Design Engineer http://www.celogic.com
Phone : (33-1) 30 69 15 30 Z.A. de Pissaloup, Rue E. Branly
Fax : (33-1) 30 69 88 15 BP 33
e-mail : omallinger@celogic.com 78192 TRAPPES cedex - FRANCE
Article: 30945Steve, You could marry our ADM-XRC PMC card with a low cost carrier from Ziatech or Vmetro. Bill http://www.alphadata.co.uk "Steven Sanders" <sanders@imec.be> wrote in message news:3AF273E9.86B2D56E@imec.be... > Hello, > > Any pointers where to find a 'simple' CompactPCI card with a > Xilinx Virtex and a minimum of 32MBit RAM? > > thanx, > > StevenArticle: 30946
---->PANIC! <----- Austin Lesea <austin.lesea@xilinx.com> wrote: >Kevin, > >I had no idea Shannon was so misunderstood. > >Actually, I am kidding: I know exactly how well misunderstood Shannon is (was). > >I know the consultants will continue to make a fortune for their understanding >(or lack of understanding) of this subject. Caveat Emptor! > >I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the Galaxy" who >have the Earth destroyed to prevent the "answer to the universe and everyhting" >from being found. If you know the answer, who needs the psychiatrist? > >While the answer is being sought in the very beginning, before it was actually >found, two psychiarists realize they and many of their descendents can make a >fortune by continuing the controversy..... > >Enjoy > >Austin > >Kevin Neilson wrote: > >> Guys, I was hoping for more of a consensus! I have done a tally, and it >> seems that members of the "bits are bits" group (those that believe C refers >> to ALL bits per second) number two, namely Austin and Nemo. >> >> The "bits are information" group (those that believe C refers to bits of >> INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my >> colleagues Rob and Dr. Bob. >> >> The latter theory has more proponents and seems to be more elegant, though >> neither of those are great reasons for taking a side. I've read textbooks, >> which have not been enlightening, so I'll just have to read Shannon's paper >> before I make any final conclusions. >> >> -KevinArticle: 30947
Interesting - I see two basic questions in this thread. The first was (restated in my own words): (1) When we calculate the maximum capacity of a bandlimited channel in the presence of AWGN does the answer include all bits transmitted on the channel (payload plus parity, headers, etc.) or not? The second question raised later in the thread seems to be: (2) Do the units indicated in above equation (bits-per-second) represent binary 1's and 0's bits in the conventional sense, or are the units (bits) these generic information "symbols" that Shannon is always referring to? Regarding the second question, here is a quote from page 1 of Shannon's paper, A Mathematical Theory of Communication: "If the base 2 is used the resulting units may be called binary digits, or more briefly bits, a word suggested by J. W. Tukey." He clearly defines "bits" to mean binary digits of a base 2 numbering system (which is just the way we all understand bits). So when we see "bits per second" used in one of Shannon's equations, we can be rest assured that we are talking about good old binary digits. Regarding Question #1 above, I tried to briefly follow Shannon's development from general information "symbols" to the capacity equation (in bps) we were discussing. In terms of whether these bits include parity and header, or are only the desired information, well you'll have to read the paper. But I can say that in my understanding, this equation represents the maximum capacity of the *total* number of bits (regardless of what they represent - parity, data, headers, ...) travelling through the channel. The challenge of the communications and/or DSP engineer is to implement coding and modulation techniques that approach this theoretical limit in real-world appplications for a given bandlimited channel. "Kevin Neilson" <kevin_neilson@yahoo.com> wrote: >Guys, I was hoping for more of a consensus! I have done a tally, and it >seems that members of the "bits are bits" group (those that believe C refers >to ALL bits per second) number two, namely Austin and Nemo. > >The "bits are information" group (those that believe C refers to bits of >INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my >colleagues Rob and Dr. Bob. > >The latter theory has more proponents and seems to be more elegant, though >neither of those are great reasons for taking a side. I've read textbooks, >which have not been enlightening, so I'll just have to read Shannon's paper >before I make any final conclusions. > >-Kevin >Article: 30948
This is a multi-part message in MIME format. --------------F6D714C7FF8510DF1507B95C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Olivier, from my experience it is best not to use records for synthesis. One reason is that you never know exactly how the synthesis tool handles them (as your problems demonstrate). Best regards Markus. Olivier MALLINGER wrote: > In an application, we try to use record type in an architecture with > several levels. This record type has to replace several signals that are > > assigned at the lowest level of the architecture and go to the highest > level of the architecture, as this : > > -level 0 (highest in the architecture) > -level 01 > -level 011 > -level 012 > -level 013 > -level 02 > -level 021 > -level 022 > -level 023 > -level 03 > > The new type declared in a package is : > > type X is > record > X1 : std_logic; > X2 : std_logic_vector(3 downto 0); > X3 : std_logic; > X4 : std_logic; > end record; > > The goal is that the entity become smaller to be more readable. > > We declare new signals of type X in each level of the architecture, as > input and as output (X011 in level 011, X012 in level 012, ...). For > example, I assigned X011.X1 in level 011, X012.X2 in level 012 and > X013.X3 in level 013. > If the signals are input, the use of record type doesn't make any > problem nor in simulation, nor in synthesis. > As ouput, many problem appear. The instantation in level 01 of a X type > signal with X type output signals of level 011, 012 and 013 shows bus > conflicts (whereas each agregate in the signal of level 01 is only > driven by one signal in the sublevels). > > In simulation, we found a solution. It's to initialize all the signals > with 'Z', to use the resolution function of std_logic type, which can > resolve these conflicts because 'Z' is the lowest priority in this > function.We use Innoveda Speedwave to simulate our design. > > In synthesis, the same problem appear but the bus conflict cannot be > resolved and it's impossible to synthetize our design. We use FPGA > Express to synthetize our design. > > Is there another solution to use record in an architecture like this > (don't speak about bus vector to concatenate signal, it's unreadable...) > > Thanks. > > P.S. : Please, send answer to my email address below too. > ---------------------------------------------- > > Olivier MALLINGER CELOGIC > Hardware Design Engineer http://www.celogic.com > Phone : (33-1) 30 69 15 30 Z.A. de Pissaloup, Rue E. Branly > Fax : (33-1) 30 69 88 15 BP 33 > e-mail : omallinger@celogic.com 78192 TRAPPES cedex - FRANCE --------------F6D714C7FF8510DF1507B95C Content-Type: text/x-vcard; charset=us-ascii; name="mmichel.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Markus Michel Content-Disposition: attachment; filename="mmichel.vcf" begin:vcard n:Michel;Markus tel;fax:+41 (0)61 336 22 00 tel;work:+41 (0)61 336 22 22 x-mozilla-html:FALSE org:Kontron Medical AG version:2.1 email;internet:mmichel@kontronmedical.ch title:dipl. El'Ing. ETH adr;quoted-printable:;;Reinacherstr. 131=0D=0AP.O. Box;CH- 4002 Basel;;;Switzerland x-mozilla-cpt:;5808 fn:Markus Michel end:vcard --------------F6D714C7FF8510DF1507B95C--Article: 30949
This link has a great explanation of the Shannon-Hartley theorem on page 5. Take careful note of the discussion of Log-base2 and "bits per second". http://www.ctr.kcl.ac.uk/Fatincourse/Mobile/fading(mobile).pdf Hope it helps. Nemo nemo@dtgnet.com (Nemo) wrote: >Interesting - I see two basic questions in this thread. The first was (restated >in my own words): > > (1) When we calculate the maximum capacity of a bandlimited channel in the >presence of AWGN does the answer include all bits transmitted on the channel >(payload plus parity, headers, etc.) or not? > >The second question raised later in the thread seems to be: > > (2) Do the units indicated in above equation (bits-per-second) represent binary >1's and 0's bits in the conventional sense, or are the units (bits) these >generic information "symbols" that Shannon is always referring to? > >Regarding the second question, here is a quote from page 1 of Shannon's paper, A >Mathematical Theory of Communication: > >"If the base 2 is used the resulting units may be called binary digits, or more >briefly bits, a word suggested by >J. W. Tukey." > >He clearly defines "bits" to mean binary digits of a base 2 numbering system >(which is just the way we all understand bits). So when we see "bits per >second" used in one of Shannon's equations, we can be rest assured that we are >talking about good old binary digits. > > >Regarding Question #1 above, I tried to briefly follow Shannon's development >from general information "symbols" to the capacity equation (in bps) we were >discussing. In terms of whether these bits include parity and header, or are >only the desired information, well you'll have to read the paper. But I can say >that in my understanding, this equation represents the maximum capacity of the >*total* number of bits (regardless of what they represent - parity, data, >headers, ...) travelling through the channel. The challenge of the >communications and/or DSP engineer is to implement coding and modulation >techniques that approach this theoretical limit in real-world appplications for >a given bandlimited channel. > > >"Kevin Neilson" <kevin_neilson@yahoo.com> wrote: > >>Guys, I was hoping for more of a consensus! I have done a tally, and it >>seems that members of the "bits are bits" group (those that believe C refers >>to ALL bits per second) number two, namely Austin and Nemo. >> >>The "bits are information" group (those that believe C refers to bits of >>INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my >>colleagues Rob and Dr. Bob. >> >>The latter theory has more proponents and seems to be more elegant, though >>neither of those are great reasons for taking a side. I've read textbooks, >>which have not been enlightening, so I'll just have to read Shannon's paper >>before I make any final conclusions. >> >>-Kevin >>
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