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
Roger Bourne wrote: > Hello all, > > I recently learned/heard that when implementing a IIR digital filter > of direct form I, the gain has to be finely adjusted with an > additionnal module on the output. Otherwise, the 0dB level will not be > perfectly reached in your passband (filter is low pass) and e.g. > consequently a digital value that is suppose to be 40000.0000 will be > 4000.0001. ... How many dB error is that? Do you care? How many significant bits in your calculation? Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 102726
Jerry Avins wrote: > Roger Bourne wrote: > > >>Hello all, >> >>I recently learned/heard that when implementing a IIR digital filter >>of direct form I, the gain has to be finely adjusted with an >>additionnal module on the output. Otherwise, the 0dB level will not be >>perfectly reached in your passband (filter is low pass) and e.g. >>consequently a digital value that is suppose to be 40000.0000 will be >>4000.0001. > > > ... > > How many dB error is that? Do you care? How many significant bits in > your calculation? > > Jerry 1 part in 40 million would be at least 26 bits. Something like measuring kTB hiss in the air during a nuclear explosion. :-) SteveArticle: 102727
> That, for me, is the primary factor. If a complete failure can be > tolerated, it's generally acceptable to use a single part and replicate > the design - but with safety critical, it's another story. I worked for > a while at a nuclear power plant, and every critical system has at > least one backup, and in some cases, two backups. Clearly, not a > situation where you can tolerate a complete failure gracefully. If I implement a function in an FPGA twice and do all these measures to make sure that there are no functional interactions between theese two implementations: What makes this implementation worse comparing to an implementation based on two separate devices? The single power supply? If this single piece of silizium is "faulty"? anything else? Regards Falk S.Article: 102728
... or write a core by myself! MaxArticle: 102729
Antti <Antti.Lukats@xilant.com> wrote: >noway, its not Altera SW! So if I want an asynchronous flip-flip with D, Q, _Q, CLK, _PRE, _CLR as one "symbol" in schmatic. How do I accomplish this ?Article: 102730
patches11@gmail.com writes: > A friend and I have come up with some interesting ideas that involve > messing around with DVI interfaces, and we'd like to physically > implement them. Neither of us has a whole lot of knowledge in the way > of FPGAs, just that they're faster for low-level tasks than a > firmware-based controller would be. > Sounds reasonable. > We have the basic resources for board production and schematic design, > but we need some direction, especially what to look for in the way of > FPGA selection (some microcontroller-like functionality is desired, > multiple hardware I2C interfaces are needed), and where we can get TMDS > transmitters and receivers. > We used a TFP410 (from TI) for sending DVI signals. Worked fine. > We're going to be pushing the limits of DVI. Dual link, high frequency > (more than the single link limit of 165 MHz). The ability to buffer > rows of pixel data is likely needed, depending on how critical timing > is for TMDS transmitters. > Not necessarily - we generate testpatterns on the fly (admittedly for lower resoultions, but simple stuff can be done at pixel rate). Depending on the "interesting ideas" you have, operating on the fly might be OK, or you might have to stick stuff in RAM first. > Since we have so little knowledge of FPGA technology, we're looking for > someone to work with us on this project. Experience with generating DVI > signals is needed. We'd like this project to go commercial, but until > we build up some momentum (hope of a working prototype, working > prototype, working prototype that works...) it's just a neat thing to > work on. > Generating DVI signals is not that hard, just a couple of counters and comparators for the syncs, then wiggle the RGB signals around as you see fit. Send those signals onto a DVI interface chip like the TFP410 and you're done. If you want to do the DVI encoding on FPGA, it can be done but why bother - the FPGA can't do TMDS signals, so you'd still need an external chip to do this anyway. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 102731
<max.giacometti@libero.it> wrote in message news:1148044389.204196.14090@g10g2000cwb.googlegroups.com... > ... or write a core by myself! > > Max > It depends on what you must realize. The fastest way is buying emac core. It is fully functional and fully compatible. You can use also emac from opencores, but in this way you don't have any kind of support in your design. You could also do the core by yourself, but it's a great challenge. An emac core is not simple. MarcoArticle: 102732
Hi John,
<fpga_toys@yahoo.com> wrote in message
news:1148038643.382368.137380@j73g2000cwa.googlegroups.com...
>
> We've already been looking at technology specific mapping for FpgaC,
> and one of the things noticed was that LUT4s didn't pack well with
> arithmetics, and were already looking at F5/F6 to improve that problem.
> Building to LUT6s is certainly a better fit for the netlists we
> generate, so my response is YIPPIE :)
I love the LUT6 architecture, particularly for muxes (4:1 in a single LUT,
16:1 in a single slice, with no wasted inputs).
> Also the 64x1 LUT RAMs are also a blessing, as it makes it far easier
> to support many applications with short arrays that size ... where the
> 16 and 32 deep arrays are frequently not enough. Is there an expander
> function in the slice fabric to cascade these, like the 32x1 in the V2
> and V2Pros? Dual port fabric?
I don't believe you get anything to cascade between slices, but a single
SLICEM will give you 256x1-bit by using all four LUTs. You can also get a
variety of dual-port configurations: up to 128x1 true dual-port, or up to
64x3-bit simple dual-port per slice. My personal favourite: 32x2 or 64x1
quad-port per slice (that's 1xRW and 3xRO ports).
> Any chance I can get some better docs and suggested arithmetic
> implementations so we can target these devices with the new technology
> mapper?
I don't know how much of that information gets published - not so much a
secrecy thing as an hours-in-the-day thing. Mostly it's seen as being of
internal interest only. (Your [external] interest has been duly noted. :))
> I'm interested in performance for 32bit and 64 bit arithmetics as Long
> and Long Long variables, will it be the case that the carry logic is
> slower than look ahead functions as with the current carry chains?
I don't have exact details to hand, but the carry-chain delay (CIN->COUT) in
V5 is about the same as V4 - maybe slightly shorter - but for 4 CY stages
per slice, not just 2. i.e. carry-chain dominated logic could potentially go
around 2x faster. The difference between 32-bit add and 64-bit add is
therefore around 600ps... so for the majority of applications, the carry
chain takes some beating! However, straightforward ripple-carry arithmetic
can be a bit wasteful of LUT input resources.
It's also possible (with some degree of cunning) to create an efficient
3-input adder in the fabric, although there is some speed penalty to this.
Cheers,
-Ben-
Article: 102733write VHDL wrapper around the components, implement there inversion and convert to schematic symbol anttiArticle: 102734
Scope schrieb: >>>My Scope is a Tektronix TDS 3054 500Mhz ( 5 GS/s ) > > >>And what kind of probe? How attatched? > > > My probe is a Tektronix P6139A Voltage probe 500 MHz 8.0 pF 10 Mohms 10x Way too slow, too much input capacitance. Try to use a passive 50 ohms probe (see link). Regards FalkArticle: 102735
Hmm, good point - I hadn't thought of that. I assume the button is pulled up internally by the power control IC, which would probably be the unregulated voltage. A voltage check on the button should clear that up. If so, I'm probably looking at an external FET driver instead of directly using M1. Fortunately, there is plenty of room on the back to glue parts.Article: 102736
On Fri, 19 May 2006, Hans H=FCbner posted:
"[..]
The Breakout group "Reclaim the Hardware Design Space!" on the 3rd
European Lisp Workshop is about creating hardware that is suited to
dynamic programming languages in general, and LISP in particular. We
will be investigating current hardware technologies to find out what
they have to offer for systems that are dynamic from the ground up.
The breakout group is meant to provide a meeting point for researchers
and practitioners working on hardware implementation techniques for
dynamic languages. [..]
[..]
Some of the topics of interest are:
* Implementation of LISP-friendly CPUs in hardware
[..]"
Which features are thought of as being Lisp-friendly?
Beware of the warning in Chapter 2 on page 109 of Hennessy, John L and=20
Patterson, David A, "Computer Architecture: A Quantitative Approach",=20
second edition:
"Pitfall: Designing a "high-level" instruction set feature specifically=20
oriented to supporting a high-level language structure.
[..]
[..] often the instructions are simply overkill-they are too general for=20
the most frequent case, resulting in unneeded work and a slower=20
instruction. [..]
[..]"
Article: 102737I don't think I'll write the emac core by myself. I need it only to check that ML401 board works correcly. I think I'll try evaluation version of Xilinx's IP core. MaxArticle: 102738
has anyone experienced problems when operating Cool Runner (XPLA3) CPLDs near the capacity of their macrocells? specifically, we have two devices that have failed independently with hard short circuits to ground on the 3.3V power supplies. a third device showed erratic behavior. in all 3 devices, more than 90% of the macrocells are used (and they all have the same program). ESD has been investigated as a potential cause. however, after a thorough ESD audit, it appears unlikley there was an ESD problem. i have heard some anecdotal evidence that this can happen when too many of the macrocells are used. has anyone heard of this or seen it documented or reported elsewhere?Article: 102739
Hi all. I'm a total newbie to FPGA programming, therefore I'm looking for suggestions. In my project I have the following specs (these are only the critical ones, the whole project consists of additional blocks): - 384 Mbit/s input bitrate - 64-point FFT block, complex numbers with 16 bit fixed-point precision for each real number, the calculation must be performed in less than 1us - 80 Ms/s output symbol rate Do you think it can be easily implemented on an FPGA? If yes, can you address me to some FPGA model? (At least, I would like to know the price range) If not, what is the critical part? Ciao, Franco TiratoreArticle: 102740
According to the errata, my AFQ device should not be affected - which makes sense because my JTAG readback is working fine. I've just realised that I can command the FPGA to shutdown (without losing configuration, this is one of the first steps of readback) after I've verified the configuration using JTAG. So I presume the startup sequence at the end of the JTAG verification is slightly different from the startup after initial configuration. Has anyone seen anything similar before? Or knows if the JTAG commands differ from those in the binary readback file?Article: 102741
Steve Underwood wrote: > Jerry Avins wrote: > >> Roger Bourne wrote: >> >> >>> Hello all, >>> >>> I recently learned/heard that when implementing a IIR digital filter >>> of direct form I, the gain has to be finely adjusted with an >>> additionnal module on the output. Otherwise, the 0dB level will not be >>> perfectly reached in your passband (filter is low pass) and e.g. >>> consequently a digital value that is suppose to be 40000.0000 will be >>> 4000.0001. >> >> >> >> ... >> >> How many dB error is that? Do you care? How many significant bits in >> your calculation? >> >> Jerry > > 1 part in 40 million would be at least 26 bits. Something like > measuring kTB hiss in the air during a nuclear explosion. :-) A meter was originally defined as 1/10,000,000th of the length of the quadrant between the North Pole and the equator passing through Paris. The currently defined meter is very close to that. Roger Bourne's error is the same as a one-meter error in the measured circumference of our planet. Pretty good mensuration, by most standards. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 102742
Franco Tiratore schrieb: > Hi all. > I'm a total newbie to FPGA programming, therefore I'm looking for > suggestions. Hmm. > In my project I have the following specs (these are only the critical > ones, the whole project consists of additional blocks): > - 384 Mbit/s input bitrate > - 64-point FFT block, complex numbers with 16 bit fixed-point precision > for each real number, the calculation must be performed in less than > 1us > - 80 Ms/s output symbol rate > Do you think it can be easily implemented on an FPGA? Easy is a relative term. I you have the expirience, its rather easy. Are YOU sure you want to strart with such a project? > If yes, can you address me to some FPGA model? (At least, I would like A Spartan-3 should do the job. > to know the price range) 100 bucks for an evaluation board. > If not, what is the critical part? Depends on your abilities. 384 Mbit/s on a single lane could be a problem if you dont know what you are doing. I dont know about the FFT, but 64 point in 1 us sounds quite fast. Regards FalkArticle: 102743
Scope schrieb: >>You need more than 1GHz of Scope and probe bandwidth to reliably measure >>signal slopes in the order of 1ns. > > > My Scope is a Tektronix TDS 3054 500Mhz ( 5 GS/s ). Do you think it is not > enough ? Is it possible that I can't see the real signal ? > > ( However, Shannon's rule about sampling is respected ) With a perfectly attached 500MHz setup you will see only the one overtone (300MHz) undamped. The 500MHz part will allready be damped. So even if the FPGA would ouput a perfect square wave your scope would see something that looks worse then the K=5 case in that URL: http://cnx.org/content/m0041/latest/ If you clamp the gnd connection of a regular probe somewhere on your board and just touch the probe to your signal you are going to see something that is a lot worse. Follow the link that Falk suggested and solder a coax cable with a resistor to your signal. ALSO: If your signal is unterminated it will look really bad. If it is series terminated it will only look good at the receiver. ALSO: Select fast slew rate and 24mA drive strength for your output. Kolja SulimmaArticle: 102744
Savs, this type of error seems very familiar to me, since I also work with XPS7.1 :-( Have you tried to do a "clean all" in XPS and recompile the whole thing ? I know that could be time-consuming, but it has helped me before. best regards, Bart De ZwaefArticle: 102745
Servus, Falk! Falk Brunner ha scritto: > Franco Tiratore schrieb: > > Hi all. > > I'm a total newbie to FPGA programming, therefore I'm looking for > > suggestions. > Hmm. :o) > > Do you think it can be easily implemented on an FPGA? > Easy is a relative term. I you have the expirience, its rather easy. Are > YOU sure you want to strart with such a project? These are the main specs of the final project, which will take a lot of time for the complete development (more than one year for sure). At the beginning I will start with a scaled down version of the same project, anyway since we still have to buy the board we want one that can fit the final specs. So don't worry about my inexperience... :o) > A Spartan-3 should do the job. > 100 bucks for an evaluation board. Really so cheap? Sounds great! I will investigate immediately! > Depends on your abilities. 384 Mbit/s on a single lane could be a > problem if you dont know what you are doing. Do you mean... transmission lines issues? > I dont know about the FFT, but 64 point in 1 us sounds quite fast. >From previous posts, it seems that with fixed-point precision this shouldn't be a critical point... > Regards > Falk Gruesse, FrancoArticle: 102746
Franco Tiratore schrieb: Hello, >>Depends on your abilities. 384 Mbit/s on a single lane could be a >>problem if you dont know what you are doing. > > > Do you mean... transmission lines issues? Yes. You need a good connection with appropiate termination from your signal source to the FPGA. Coax cable or impedance matched PCB trace. Ribbon may work too, if used properly (as always ;-). Also clocking might bite you. Whats the source? Is there a clock signal availabe to the datastream? Regards FalkArticle: 102747
It's just for fun to run it in a FPGA rather than making an ASIC. I spent almost all Saturdays in the past 1 year for this project. I should say, it has lots challenge than a single-issue one. True, clock speed is pretty low now now (30-60 Mhz). But I am planning to enhance it by using a smarter compiler to removing some corner case from the design. Hopefully I cam make it to 100Mhz range. Also, looks I need to buy an evaluation kit from Altera. Xilinx V4 blcok ram gives me some trouble during instruction fetching. My design is from scratch. Its instruction set is almost same as MIPS 3000 (without Multiplication). Lcc C compilier was ported. I can publish the source verilog files, do we have public domain for this purpose?Article: 102748
Folks, Does anyone know if either Xilinx or Synplicity have provided a mechanism to explicitly place an inferred LUT? I can produce LUTs that only feed a keep_buf but don't maintain the same LUT name across compiles for RLOCing. I can guarantee the net name for Place & route with the keep_buf but can't associate the net with the LUT's placement. I'd love for the Xilinx tools to propagate a location constraint back to the primitive that drives it since Synplicity hasn't come up with a nice way to guarantee a net driver's name. Any help is appreciated, - John_HArticle: 102749
Austin Lesea (austin@xilinx.com) wrote: : All, : A recent Intel presentation at an IEEE Workshop admitted that clock : frequency has max'd out, and now has to go down (not up) in order to not : create heat. : We have known that for years now. So has AMD. : The only choice is "multi." : Intel proposes a future with more than 200 x86 cores on one die, with a : "communications fabric" and many memories. All on one die. Small : software problem to be solved by the need to have it solved.... : One attendee of the conference (not me!) quipped, "sounds like you are : describing a FPGA..." : Boy did the presenter get mad! To be ccompared to a lowly FPGA! He was : spitting venom back at the attendee. "There is no comparison! FPGAs : are fine grained, and this is not!" : Sounds like if that is the only difference, the FPGA wins. Again. : Oh, and I can't wait for Intel to stub their toes on that : "communications fabric" (left as an exercise for the student). Or the : software. It looks to me like different technologies - CPUS, FPGAs - are on a collision course - FPGAs are incoperating more and more advanced corse grained features and CPUs are segmenting, going parallel and more fine grained, there're flexible interconnects in the former and roadmapped in the later. Middle(ish) ground devices like offerings from Clearspeed and the STI Cell procssor already exist. Convergence of the differnet hardware solutions is happening. Perhaps the real battleground is the software environments - development and runtime. HDLs embrace parallelism naturally, but are stuck at a very low level, procedural languages map to how most people thing and how CPU cores work, and stink at parallelism. Many attempts are in various stages of existence for a mix between these two extremes, none have yet to find acceptence, and none (AFAIK) are usable across the range of technologies. Perhaps this is the real battleground? cds
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