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
> > It would be highly appreciated if anyone can let me know if there is any > > good training course related to " ASIC/FPGA flow" (I know its huge; > > still if there is any that covers important aspects) arranged by any > > Institute around North America. I think Esperan has some courses in this area. They are not cheap. You might check their web site.Article: 30901
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3AF027BD.50AFA29B@xilinx.com... > Wrong. > > Go back and re-read his paper. Austin, I do not agree with your interpretation of Shannon's theorem ... but I'm convinced that you're right about the value of reading his paper. Any hints on where I could find a copy? I don't live close to a library, so an web link would be much appreciated. Berni. > > This is really funny, and sad. > > Austin > > Steve Rencontre wrote: > > > In article <3AEF11CD.CEA6992D@xilinx.com>, austin.lesea@xilinx.com (Austin > > Lesea) wrote: > > > > > See what I mean? > > > > > > Still confused after all these years. > > > > > > If the CRC is not information, then you don't need it. > > > > > > If the CRC is information, then you need to send it. > > > > > > I rest my case. > > > > > > Austin > > > > I disagree. The CRC (or whatever) is not information, but you do need to > > send it! The total message of N+CRC physical bit symbols only carries > > N bits of /information/, and it's that which Shannon's theorem applies to. > > > > I think the confusion arises because we automatically think that a 1 or 0 > > in the digital domain is a 'bit' in the Shannon sense, but it's not - it's > > just a symbol which can be used to encode bits. Adding a CRC increases the > > predictability of lost symbols, which means each 0/1 symbol carries less > > than one actual bit. > > > > Shannon tells us how many bits of genuine information we can transmit, but > > we're free to send as many > > symbols-which-superficially-look-like-bits-but-aren't as we like :-) > > > > -- > > Steve Rencontre http://www.rsn-tech.co.uk > > //#include <disclaimer.h> >Article: 30902
Berni, Oh well. You will have to order it from a bookstore, or Amazon.com. It is copyright IEEE Press, or Bell Labs, so you will not find it on the web. The big book by Sloane and Wyner on "Claude Shannon: Collected Papers" is definitely worth buying. He not only invented communications theory, but information theory, and demonstrated many practical results in cryptography as well. It is really a shame that something so simple is so often mis-interpreted. The "example" of using phonetics to communicate is a perfect one. If I speak "a" "b" "c" etc to spell something in the presence of noise, then the listener hears "a" "?" "?" etc. If I speak "alpha" "baker" "charlie" and the listerner hears "al...." "ker" "char..." (50 % of symbols in error, but your matched filter ears figure it all out with the help of your brain). Now if the check characters were not part of the transmission, where the hell were they? If they were not required, then you could remove them at the source (you never received them), and you would have "a" "?" "c" so something was needed.... Shannon also very carefully covers the transmission of the check and correct symbols by another channel, different from the one used for the original information. He covers n-ary symbols, not just binary. Pretty good for the 1930's. The paper was not allowed to be published until well after WWII (1948). He also very carefully covers channels with a reverse channels, also with errors (eh? say again? What? you want me repeat? Repeat? repeat what? ....) Austin Berni Joss wrote: > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > news:3AF027BD.50AFA29B@xilinx.com... > > Wrong. > > > > Go back and re-read his paper. > > Austin, I do not agree with your interpretation of Shannon's theorem ... > but I'm convinced that you're right about the value of reading his paper. > Any hints on where I could find a copy? > I don't live close to a library, so an web link would be much appreciated. > > Berni. > > > > > This is really funny, and sad. > > > > Austin > > > > Steve Rencontre wrote: > > > > > In article <3AEF11CD.CEA6992D@xilinx.com>, austin.lesea@xilinx.com > (Austin > > > Lesea) wrote: > > > > > > > See what I mean? > > > > > > > > Still confused after all these years. > > > > > > > > If the CRC is not information, then you don't need it. > > > > > > > > If the CRC is information, then you need to send it. > > > > > > > > I rest my case. > > > > > > > > Austin > > > > > > I disagree. The CRC (or whatever) is not information, but you do need > to > > > send it! The total message of N+CRC physical bit symbols only carries > > > N bits of /information/, and it's that which Shannon's theorem applies > to. > > > > > > I think the confusion arises because we automatically think that a 1 or > 0 > > > in the digital domain is a 'bit' in the Shannon sense, but it's not - > it's > > > just a symbol which can be used to encode bits. Adding a CRC increases > the > > > predictability of lost symbols, which means each 0/1 symbol carries > less > > > than one actual bit. > > > > > > Shannon tells us how many bits of genuine information we can transmit, > but > > > we're free to send as many > > > symbols-which-superficially-look-like-bits-but-aren't as we like :-) > > > > > > -- > > > Steve Rencontre http://www.rsn-tech.co.uk > > > //#include <disclaimer.h> > >Article: 30903
steve (Steve Rencontre) writes: > In article <X1TH6.16348$482.81848@newsfeeds.bigpond.com>, > murrayal@yahoo.com (auliya) wrote: > > 2. Use a configuration declaration to specift which of B1 or B2 to use. > > For > > this you need an entity declaration (B) and the two architectures (B1 > > and > > B2). Basically, a configuration allows you to bind a specific > > architecture > > (out of many options) to an entity. > > 3. Run it through a C preprocessor first :-) With emacs' VHDL-Mode, you can generate a Makefile from the parsed VHDL code, respecting hierarchical configurations. With that, you can support configurations even for tools that do not by themselves (most synthesis tools e.g.). Kind of 2. and 3. in one. --> http://opensource.ethz.ch/emacs/vhdl-mode.html HTH, ColinArticle: 30904
auliya wrote: > With this you have 2 options: > 1. Use a generic to pass in a parameter which will specify which of B1 or B2 > to use. In this case you need to use 'if...generate' statements to > instantiate each option. You should the B1 and B2 entity/architecture pairs > in separate files and use B as a 'wrapper' to choose which one to use. Option 1 works fine for everything other than VITAL delay backannotation where the top level is a testbench and the generated statement is your design DUT. Here is an example I tried where the generic WITH_DELAY is a boolean: ------------------------------------------ fast_sim : if not WITH_DELAY generate dut : entity work.xszero(synth) port map (clk => clk, -- [in] rst => rst, -- [in] dpos => dpos, -- [in] dneg => dneg, -- [in] mode_16 => mode_16, -- [in] count_std => count_std, -- [out] overflow => overflow); -- [out] end generate fast_sim; delay_sim: if WITH_DELAY generate dut : entity work.xszero(\ep1k50fc256-1\) port map (clk => clk, -- [in] rst => rst, -- [in] dpos => dpos, -- [in] dneg => dneg, -- [in] mode_16 => mode_16, -- [in] count_std => count_std, -- [out] overflow => overflow); -- [out] end generate delay_sim; The first case worked fine (no backanno), but in the second, the generate id gave me an sdf instance of /testbench/delay_sim instead of the expected /testbench/dut and modelsim complained. I could not figure out how to get Modelsim to line up the .sdf delay file with the associated dut level. > 2. Use a configuration declaration to specift which of B1 or B2 to use. For > this you need an entity declaration (B) and the two architectures (B1 and > B2). Basically, a configuration allows you to bind a specific architecture > (out of many options) to an entity. > Just happen to have an example of this also. I ended up putting the delay model (.vho) in a separate library to keep the identical entity names from clashing. ---------------------------------------- configuration vital of test_xszero is for sim for dut:socket use entity vho.xszero(\ep1k50fc256-1\); end for; end for; end configuration vital; configuration fast of test_xszero is for sim for dut:socket use entity work.xszero(synth); end for; end for; end configuration fast; ---------------------------------------- Modelsim was happy with both configs: > vsim fast or > vsim -sdfmax dut=xszero.sdo vital -Mike TreselerArticle: 30905
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. Peter Alfke, Xilinx Applications ========================= Kevin Neilson wrote: > Insight Design Services has Verilog source that functions similarly to the > Mot MC145428, which is a serially-interfaced UART. Not free, though. > > "Mark Walter" <maw@nospam.com> wrote in message > news:1ALH6.226933$GV2.47295492@typhoon.san.rr.com... > > 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 > > > > > >Article: 30906
--------------4F6A00D1C44544036B08CCC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ..... It says that for a rate of C bits per second in the presence of No noise power bandwidth in W hertz, you can have error free operation. It tells you nothing about how to code it to achieve that rate. That's the million dollar question: how do you even get close to the Shannon limit without knowing how? Austin Steve Rencontre wrote: > In article <3af20db4.2149921@news.dtgnet.com>, nemo@dtgnet.com (Nemo) > wrote: > > > C refers the the capacity of a physical band-limited > > channel. By definition, C includes *all* the data carried by the > > channel. This includes the payload data and any overhead (parity bytes, > > etc) needed for the FEC layer if used. > > Sorry, but that doesn't add up. Shannon's Theorem says that you can carry > C bps /without/ error. In that case, why have you included error detection > and correction bits with the payload data?! > > -- > Steve Rencontre http://www.rsn-tech.co.uk > //#include <disclaimer.h> --------------4F6A00D1C44544036B08CCC9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> ..... <p>It says that for a rate of C bits per second in the presence of No noise power bandwidth in W hertz, you <b><i><u>can</u></i></b> have error free operation. <p>It tells you <b>nothing</b> about how to code it to achieve that rate. <p>That's the million dollar question: how do you even get close to the Shannon limit without knowing how? <p>Austin <p>Steve Rencontre wrote: <blockquote TYPE=CITE>In article <3af20db4.2149921@news.dtgnet.com>, nemo@dtgnet.com (Nemo) <br>wrote: <p>> C refers the the capacity of a physical band-limited <br>> channel. By definition, C includes *all* the data carried by the <br>> channel. This includes the payload data and any overhead (parity bytes, <br>> etc) needed for the FEC layer if used. <p>Sorry, but that doesn't add up. Shannon's Theorem says that you can carry <br>C bps /without/ error. In that case, why have you included error detection <br>and correction bits with the payload data?! <p>-- <br>Steve Rencontre <a href="http://www.rsn-tech.co.uk">http://www.rsn-tech.co.uk</a> <br>//#include <disclaimer.h></blockquote> </html> --------------4F6A00D1C44544036B08CCC9--Article: 30907
...I've had the priviledge of fooling around with some FPGA devices over the past few months. In my case, I wanted to test an ASIC design (Verilog RTL code), which I couldn't simulate very well with plain on Verilog stimulus files. I was demodulating a comm-signal. Running the using Cadence Verilog-XL on my workplace's UltraSparc2 300MHz (old, slow by today's standards...), the execution time was horrendous ... roughly 5 minutes of "real world time" (and thumb twiddling) for a scant 30ms of 'circuit simulation time.' Anyway, I got the wise idea that maybe I could compile this circuit to an FPGA-device, get an ADC, and do a 'live test.' So that's what I did. While I did encounter a few problems along the way (each problem was educational for me), in the end I was very satisfied with my laboratory trial. I learned a lot...I uncovered some flaws in my circuit (and corrected them), and then the project was cancelled, game over. (If I could do everything over, I think I would have concurrently written behavioral-level Verilog models along with the actual RTL-code. Then use the behavrioal-models to run 'proof of concept' trials. I had to scrap some of my circuits, and redesigning them at RTL level is more time-consuming than at behavioal-level. I didn't think to try this, because it would have been a gamble. I would have gone out of my way to do something extra, which may or may not pay off.) ... 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?Article: 30908
On Wed, 2 May 2001 21:37:08 +0200, "Berni Joss" <berni_13@yahoo.com> wrote: > >Austin, I do not agree with your interpretation of Shannon's theorem ... >but I'm convinced that you're right about the value of reading his paper. >Any hints on where I could find a copy? >I don't live close to a library, so an web link would be much appreciated. > >Berni. > Here it is: http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf enjoy Philip Philip Freidin FliptronicsArticle: 30909
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. "Michael Strothjohann" <strothjohann@rheinahrcampus.de> wrote in message news:3AEFF103.81165A24@rheinahrcampus.de... > Probably the device is like the one in an > old BYTE-article ( over one decade ago ): > an DRAM was opened and the > precharged C's are decharged by the incoming > photons. The picture reflects the chip-structure, > but the low-cost ('home-made') device realy works. > michael strothjohann > > > Victor Schutte schrieb: > > > About a year ago I read an article on a new image device that looks like RAM > > (manufactured by HP). You don't need to design high speed CCD circuitry and > > device drivers for Windoze. You can use something as simple as a 8051 uC, > > scan the device and then send the data to the PC via RS232. > > > > Unfortunately I do not know the part number or the price (which can probably > > be very high). I know the part exists. If anyone has more details on this > > please post. > > > > "M.B." <martinb@magma.ca> wrote in message > > news:3aeeb905.4091345@news.magma.ca... > > > Hi I have a telescope and some basic experiance with VHDL, FPGAs. > > > I would like to get a CCD (something common and cheap) and use a FPGA > > > perhaps a xilinx or atmel with VHDL. and interface to my computer (win > > > 98. > > > > > > Has anyone done somthing like this? > > > Is there a project in any books or wed sites that you have seen that > > > could get me started? > > > > > > Or is there a development kit from one of the CCD Manufacturers that I > > > could look into? > > > > > > >Article: 30910
Thanks everyone for the info. I think I have enough now to start with a simple Serial interface to my CPU design.... MarkArticle: 30911
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. 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)? Thanks, James Brennan. IArticle: 30912
On Wed, 02 May 2001 13:47:50 GMT, nemo@dtgnet.com (Nemo) wrote: >You may want to get ahold of Shannon's paper, it explains the details better >than I can. C refers the the capacity of a physical band-limited channel. By >definition, C includes *all* the data carried by the channel. This includes the >payload data and any overhead (parity bytes, etc) needed for the FEC layer if >used. In-line comments below... > >"Kevin Neilson" <kevin_neilson@yahoo.com> wrote: > >>There's something I've never quite understood about Shannon's Law. It >>states something like this: >> >>C = W*logbase2(1 + S/N) >> >>where C is channel capacity, bits/s >> W = bandwidth, Hz >> S/N = signal-to-noise ratio >> >>Theoretically, if using enough error-correction, you can transmit C bits/s >>on a channel error-free. > >Yes, exactly as it says - bits are bits, and parity bits are information too. >> >>Say you determine that the channel capacity for a particular channel is >>1Mbit/s. Does that include the error correction bits or not? > >Yes it includes error correction. > >>What if you >>have a 1/2 rate code, where half of the bits are parity bits. Does that >>mean you transmit 2Mbit on that channel (with 1Mbit capacity) for a net data >>throughput of 1Mbit error-free? > >No, if the Shannon limit is 1Mbps, then thats all you get *including* parity. > >>Or does the 1Mbit include the partiy bits? >Yes. > >> >>-Kevin >> > > >Hope that helps. > >Nemo In my opinion, most confusion here comes from the fact, that some people considers the CRC and parity coding/decoding part of the channel, and others do not. Personally I would opt for making the coding/decoding part of the channels, since it gives you a "better" channel. In this case and in the above example you have 1 MBit/s information rate (Bits you are free to choose), but you have a symbol rate of 2 Msymbols/s (CRC and parity are calculated and do not add any information). In the second case CRC and parity are part of the information you want to send over the channel, but your channel is not error free. Another very wrong statement here was : "bits are bits". A Bit in a computer is a symbol with 2 possible values. A Bit in information theory and in Shannons formula is the unit for information (something new you did not know before). It seems like a paradoxa. but a bit in a computer can hold maximum 1 bit information. If a computer bit is always cleared and you know that, it hold 0 bits of information. Best rega Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@IHATESPAMdurst.itArticle: 30913
> 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. Kolja SulimmaArticle: 30914
Check out Datacube's web site (www.datacube.com) for the MaxVideo2000 PCI board. It includes a large Virtex-E, a lot of memory and it's dedicated to image processing applications. Marc James Brennan <s369272@student.uq.edu.au> wrote in message news:9cqr2h$gon$1@bunyip.cc.uq.edu.au... > 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. > > 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)? > > Thanks, > > James Brennan. > I > >Article: 30915
I am interested in downloading configuration bit stream into a FPGA that resides on a PCI card,through the PCI bus. The PCI interface is implemented outside the FPGA as a seperate chip.But connecting this interfacing chip to the FPGA itself requires some handshaking signals from the FPGA which is not possible as long as the FPGA is configured and i don't want to have a serial ROM on the card that holds the configuration data. Then how will the FPGA get configured on power up through the PCI interfacing chip? Please advice.My email id is bhupesh_r@rediffmail.com. thanksArticle: 30916
This is a reply to the query posted by Nisreen Taiyeby. In the first place, in the code the use of priority encoder in naming the architecture body is highly misleading and exhibits poor documentation. Secondly, to the best of my knowledge an if else construct would generate priority hardware as against a multiplexer which is non priotised hardware. A single 4-i/p LUT can implement any function with max. 4 i/ps. In your case u need to select one of the 4 i/ps at the o/p. which needs 2 select lines making the total number of i/s 6, which consumes two first levels of LUTs. Also since u require one o/p. the o/ps of the first 2 LUTs has to be multiplexed which is implemented in the 3rd LUT being inferred at the second level. Hence i guess the hardware being inferred by your synthesizer is correct in all respects. Please mail me ur feedback. My id is bhupesh_r@rediffmail.comArticle: 30917
This is in reply to Matt's query. Since u r using a global clock signal in ur design it has to essentially be routed through the global buffer, because the global signals have a large fan out and hence need to be buffered. If u modify ur design so that the global clock signal is not used only then will u be able to skip the global buffer. best regards bhupesh bhupesh_r@rediffmail.comArticle: 30918
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. 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. > >"Michael Strothjohann" <strothjohann@rheinahrcampus.de> wrote in message >news:3AEFF103.81165A24@rheinahrcampus.de... >> Probably the device is like the one in an >> old BYTE-article ( over one decade ago ): >> an DRAM was opened and the >> precharged C's are decharged by the incoming >> photons. The picture reflects the chip-structure, >> but the low-cost ('home-made') device realy works. >> michael strothjohann >> >> >> Victor Schutte schrieb: >> >> > About a year ago I read an article on a new image device that looks like >RAM >> > (manufactured by HP). You don't need to design high speed CCD circuitry >and >> > device drivers for Windoze. You can use something as simple as a 8051 >uC, >> > scan the device and then send the data to the PC via RS232. >> > >> > Unfortunately I do not know the part number or the price (which can >probably >> > be very high). I know the part exists. If anyone has more details on >this >> > please post. >> > >> > "M.B." <martinb@magma.ca> wrote in message >> > news:3aeeb905.4091345@news.magma.ca... >> > > Hi I have a telescope and some basic experiance with VHDL, FPGAs. >> > > I would like to get a CCD (something common and cheap) and use a FPGA >> > > perhaps a xilinx or atmel with VHDL. and interface to my computer (win >> > > 98. >> > > >> > > Has anyone done somthing like this? >> > > Is there a project in any books or wed sites that you have seen that >> > > could get me started? >> > > >> > > Or is there a development kit from one of the CCD Manufacturers that I >> > > could look into? >> > > >> > > >> > >Article: 30919
Hi U've specified that ur ucf file was empty. An empty ucf file in the Xilinx tool means that the implementation tool will not put in any efforts on its part to improve timing. Probably u need to enter some timing constraints only on ur clock signal if its a counter design using the TIMESPEC keyword. As far as the other query regarding the prescalers is concerned there are available with the xilinx tool certain logiblox available and in fact they can be programmed to divide the input clock by the required amount. best regards bhupesh bhupesh_r@rediffmail.comArticle: 30920
kfalser@REMOVETHISdurst.it (Klaus Falser) wrote: <<BIG SNIP>> > >In my opinion, most confusion here comes from the fact, that some >people considers the CRC and parity coding/decoding part of the >channel, and others do not. No, I think that the confusion here is that people want to talk about the Shannon limit (also known as Shannon-Hartley theorem) without actually having read/studied/digested the source material. > >Personally I would opt for making the coding/decoding part of the >channels, since it gives you a "better" channel. >In this case and in the above example you have 1 MBit/s information >rate (Bits you are free to choose), but you have a symbol rate of 2 >Msymbols/s (CRC and parity are calculated and do not add any >information). It's not up to you to "opt" for making it part of the channel - this is a discussion of Shannon's work, and we have to go by his definition's, and assumptions. The discussion is about the Shannon limit, and the Shannon limit for a given band-limited channel is very strictly defined. > >In the second case CRC and parity are part of the information you >want to send over the channel, but your channel is not >error free. > >Another very wrong statement here was : "bits are bits". >A Bit in a computer is a symbol with 2 possible values. >A Bit in information theory and in Shannons formula is the unit for >information (something new you did not know before). No, in the formula we are discussiing, bits *are* bits. Shannon does not define these any diferently than anyone else. Shannon *does* use the term *symbol* extensively to describe a disctrete piece of information transmitted through the channel. A symbol can represent any number of bits, or even an entirely abstract "piece of information", but abstract thinking is something many here seem to be having trouble with. When discussing information symbols, the maximum symbol rate that can be supported on a given channel is simply 2xB symbols per second (where B is the bandwidth). If we consider that each symbol can represent multiple (M) bits of information, then the equation for maximum capacity of the baseband channel becomes: C = 2*B*log2(M) bps If we want to consider the effects of AWGN on a band-limited channel (i.e. a finite S/N), then the equation becomes the one we have been discussing in this thread: C = B*log2(S/N+1) bps In the later two equations, BITS are BITS and symbols have been removed from the discussion. > >It seems like a paradoxa. but a bit in a computer can hold >maximum 1 bit information. >If a computer bit is always cleared and you know that, it hold >0 bits of information. > Hope that helps. Best regards Nemo >Best rega >Falser Klaus >R&D Electronics Department >Company : Durst Phototechnik AG > Vittorio Veneto Str. 59 > I-39042 Brixen >Voice : +0472/810235 > : +0472/810111 >FAX : +0472/830980 >Email : kfalser@IHATESPAMdurst.itArticle: 30921
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.comArticle: 30922
"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. Today, many DRAM manufacturers store true data in some areas of the die, and complement data in other areas, for a variety of reasons. If you look at the data out of a DRAM that has been just powered up, you will see a somewhat regular pattern. This is one reason why. The irregularities in the patterns, and differences in this pattern from part to part, are in many cases due to the redundancy having been invoked. CMOS image sensors have a very similar structure to DRAM. Regards, Erik Widding. -- Birger Engineering, Inc. -------------------------------- 781.481.9233 38 Montvale Ave #260; Stoneham, MA 02180 ------- http://www.birger.comArticle: 30923
Hi! I'm a member of OpenCores group and we are designing a free PCI bridge IP core that would target FPGA and ASICs. If anyone is interested in helping us out in our effort is very welcome. You can read more about it on our website www.opencores.org where you can also subscribe to our mailing lists. Any kind of help is welcome - advices, HDL design, verification, documentation. Languages we use for our cores are Verilog and VHDL. We already have a part of specification ready and are still working on it, so anyone interested can download it from our site ( http://www.opencores.org/cgi-bin/cvsget.cgi/pci/docs/pci_specification.pdf ) . Comments, feedback, advice are welcome. Regards, Miha DolencArticle: 30924
Peter, That's all true, but we have to design what the customer wants. Sometimes, there are good reasons for putting "doubly programmable" circuitry in the Xilinx, such as making an ASIC prototype, or, in this case, making a drop-in-replacement clone for obsoleted chips. It's surprising though, how many customers just don't get the reconfigurable aspect of the FPGA. There are a lot of applications like a UART in which a customer will only be using it in one configuration to be determined right after startup, such as 4800baud, 8 data bits, no parity bits, one stop bit. 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. -Kevin, IDS "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3AF09619.EA685F70@xilinx.com... > 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. > > Peter Alfke, Xilinx Applications > ========================= > Kevin Neilson wrote: > > > Insight Design Services has Verilog source that functions similarly to the > > Mot MC145428, which is a serially-interfaced UART. Not free, though. > > > > "Mark Walter" <maw@nospam.com> wrote in message > > news:1ALH6.226933$GV2.47295492@typhoon.san.rr.com... > > > 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 > > > > > > > > > > >
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