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
In message <1157579221.974696.109440@e3g2000cwe.googlegroups.com>, dated Wed, 6 Sep 2006, phaeton <blahbleh666@hotmail.com> writes >Hi can someone please explain to me how to post to usenet? > No, it can't be done. Usenet is read-only as from 2210 GMT today. -- OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk 2006 is YMMVI- Your mileage may vary immensely. John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UKArticle: 108226
Kolja Sulimma wrote: > rickman schrieb: > > J Thomas wrote: > > At > > that size the power difference would be virtually unmeasureable. > > Ripple carry counter power is independant of counter size. > (Except for clock tree power) Good example of a rule of thumb gone bad. If you think about that you will realize that it can't be true... otherwise the extra bits must use no power! Each added bit toggles half as fast as the last. So the power for a ripple carry counter is a power series which is asymptotic to two bits toggling all the time. That is not the same as independant. However your point is valid that once you get past a few bits the added power for more bits is very small. The power for a Gray code counter is pegged at 1 bit toggling. So the difference is always small.Article: 108227
Ray Andraka wrote: > The SRL16's are actually one of the most versatile blocks on the FPGA. > You can use them for: > > counters > state machines How can you use SRLs for these? I guess a shift register can be used for a simple FSM like a Johnson ring counter.Article: 108228
You can also use the shiftregister as LFSR counter, or as pseudo-random bitstream generator. But you always have to remember that there is no parallel access to the shiftregister content. Peter Alfke ========== rickman wrote: > Ray Andraka wrote: > > The SRL16's are actually one of the most versatile blocks on the FPGA. > > You can use them for: > > > > counters > > state machines > > How can you use SRLs for these? I guess a shift register can be used > for a simple FSM like a Johnson ring counter.Article: 108229
"Ray Andraka" <ray@andraka.com> wrote in message news:kdHLg.7104$SZ3.421@dukeread04... > The SRL16's are actually one of the most versatile blocks on the FPGA. You > can use them for: > > reprogrammable LUTs --poor man's reconfiguration > dual port memory --serial write port, parallel read > synchronous FIFO --smallest FIFO implementation > data reordering --this is really cool for sorting and other apps > counters state machines > variable delays > fixed delays > > The only one of these that is inferred by synthesis tools is the fixed > delay, and that is also the least interesting out of all these. I've > probably used them for other things as well, but these are the ones that > pop out at me. It is a shame that Xilinx doesn't promote the usefulness > of the SRL16 more than they do, as I suspect most users don't have a clue > how powerful these little buggers are. Inference works for SynplifyPro and Verilog without trouble for quite some time. The simplest implementation is to shift into the SRL register vector bit[0] and index the vector with your MUX. Variable length FIFOs infer nicely. The counter-type use I liked *so* much was started by Antti who showed how to get a 2^27 divider into 6 LUTs (or similarly tiny number). I extended that to an NCO and was real happy with the results. The key to counters in this sense is bit serial arithmatic. Fun! The only caveat for the NCO which recirculates the phase value in a looped SRL is to make sure the clock is stable before letting the system shift!Article: 108230
phaeton wrote: > > Hi can someone please explain to me how to post to usenet? Get and install a version of Thunderbird for your system. See: <http://mozilla.org> Interrogate your ISP for the proper URL for the news server, and enter it in the configuration. You now have something like 20,000 (maybe 50,000) newsgroups available to you. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>Article: 108231
I am trying to use I2C to configure TI TFP410 DVI transmitter. I put differential clock input and VSYNC/HSYNC with the data. I suppose to get 1600x1200 image on the monitor. Basically, I just want to show a simple image and my hardware pins configuration is like below: DKEN (35) <--- GND /PD (10) <--- GND MSEN (11) <--- pull high EDGE (09) <--- float with a serial resistor 1k DE (02) <--- floating (since it should be ignored after I2C configured it as disabled) ISEL (13) <--- pull high Vref (03) <--- VDD I believe this chip should work with only input VSYNC/HSYNC, +/-CLOCK and 24bits DATA. Point me out if I am wrong. Thanks. ChaoArticle: 108232
I have a setup that is passing behavioral sim but not timing sim. The basic setup is as follows. I have a 100 MHz clock input to a Virtex 4 FPGA (ML401 board - LX25 -10). It goes through a global buffer and connects to a DCM. The DCM multiplies this clock by 3 and outputs that on CLKFX. That output is connected to a buffer that, in turn, connects to another DCM input. The second DCM outputs on CLK0, CLK90, CLK180, and CLK270. The first DCM does NOT have a feedback source. I know there are caveats about doing this, but the only warnings I have had from Xilinx are in regards to the output phases of the DCM not having a known phase relationship with respect to the input clock. That doesn't matter to me. I have the CLK0 output of the second DCM connected to a global buffer. Then the global buffer is connected to a BUFR. The output of the BUFR drives 24 FF's. There is one LUT in the design. Basically serial data is clocked into 2 banks of 8 FF's. The other 8 FF's implement a 'wrap-around' shifter. When the last bit of that shifter is a one, the enable to the first bank of 8 FF's is turned off and the enable to the second set of 8 FF's is turned on. That way I get two 8-bit shift registers ping-ponging data captured at the clock rate divided by 8. Eventually I will move the data at the divided clock speed...basically deserailizing the input data. I have only built the CLK0 logic so the other clocks are optimized out. I have run a post-place-and-route sim. At an input clock of 100 MHz to the first DCM, the output clocks from the second DCM should all be 300 MHz. This is fine. The problem is with the BUFR. The CE is 1'b1, the CLR is a 1'b1 that goes low when the second DCM locks. This should ensure that a valid clock is input to the BUFR, and I would expect the BUFR to just forward the input clock. I am using the divider value of the BUFR set to '1'. However, when running the sim at this speed, the 'I' input to the buffer is '0' and then goes to a steady '1'. There is NO CLOCK signal at the input!! I can slow the sim input clock by half and everything works OK. Why would I not see the clock at full speed? Is there a SIMPRIM constraint that I do not know about? 300 MHz does not seem unreasonable. I don't know if there is some DCM/BUFG/BUFR connection I am doing wrong either. Thanks for any help...or thanks for just reading this!Article: 108233
We have a wired Spartan-3 based sensor unit and want to make it wireless. We'd like to have a mesh network with 100-1000 nodes, 80-100m distance between nodes, 16 bytes/s rate from each node. Anybody has experience with this size of mesh networks? How easy is to handle the RF side of communication to make sure the host machine will receive all the data? Do I have to care about repeating packets, buffering packets etc.? I guess to attach the Zigbee hw to Spartan-3 (Microblaze) should be really straight forwarded. Regards, ZoltanArticle: 108234
"Homer J Simpson" <nobody@nowhere.com> wrote in message news:rpHLg.10081$Hr1.1028@clgrps12... > > "phaeton" <blahbleh666@hotmail.com> wrote in message > news:1157579221.974696.109440@e3g2000cwe.googlegroups.com... > >> Hi can someone please explain to me how to post to usenet? > > Use extra postage. > Tried that once. It got awful hard to read the screen between all the stamps. (that, and the white-out my wife keeps painting on the screen to correct her typing mistakes :-)Article: 108235
You need to read the datasheet for this and other devices (DVI TX/RX). HSYNC and VSYNC are not differential clocks. These are horizontal and vertical blanking signals, respectively. Feeding them a differential clock will result in nothing of any use on the output. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin To send private email: email = x@y.com where: "x" = "martineu" "y" = "pacbell.net" "Chao" <ssc3k@yahoo.com> wrote in message news:ednl96$ecp$1@news.ks.uiuc.edu... >I am trying to use I2C to configure TI TFP410 DVI transmitter. I put >differential clock input and VSYNC/HSYNC with the data. I suppose to get >1600x1200 image on the monitor. Basically, I just want to show a simple >image and my hardware pins configuration is like below: > > DKEN (35) <--- GND > /PD (10) <--- GND > MSEN (11) <--- pull high > EDGE (09) <--- float with a serial resistor 1k > DE (02) <--- floating (since it should be ignored after I2C configured > it as disabled) > ISEL (13) <--- pull high > Vref (03) <--- VDD > > I believe this chip should work with only input VSYNC/HSYNC, +/-CLOCK and > 24bits DATA. Point me out if I am wrong. Thanks. > > ChaoArticle: 108236
Peter Alfke wrote: > You can also use the shiftregister as LFSR counter, or as pseudo-random > bitstream generator. > But you always have to remember that there is no parallel access to the > shiftregister content. > Peter Alfke > ========== > rickman wrote: > > Ray Andraka wrote: > > > The SRL16's are actually one of the most versatile blocks on the FPGA. > > > You can use them for: > > > > > > counters > > > state machines > > > > How can you use SRLs for these? I guess a shift register can be used > > for a simple FSM like a Johnson ring counter. How do you make an LFSR if you can't access any intermediate taps? The two forms require that you either insert XOR gates into the shift path or that you tap the intermediate outputs to XOR a value that is shifted into the shift register. If you have to use multiple SRLs, then you are just using them as fixed length shift registers.Article: 108237
hi, all I am developing a design with V4 LX100, and the project is large, which usually cost me 2 hours to synthesis and PAR. It's more than I can bear when debug it. Is there any solutions to decrease the time cost? Incremental design or planahead? Can anybody with these experience figure out what should I do? Many thanks!! Regards KingArticle: 108238
rickman wrote: > Peter Alfke wrote: > >>You can also use the shiftregister as LFSR counter, or as pseudo-random >>bitstream generator. >>But you always have to remember that there is no parallel access to the >>shiftregister content. >>Peter Alfke >>========== >>rickman wrote: >> >>>Ray Andraka wrote: >>> >>>>The SRL16's are actually one of the most versatile blocks on the FPGA. >>>>You can use them for: >>>> >>>>counters >>>>state machines >>> >>>How can you use SRLs for these? I guess a shift register can be used >>>for a simple FSM like a Johnson ring counter. > > > How do you make an LFSR if you can't access any intermediate taps? The > two forms require that you either insert XOR gates into the shift path > or that you tap the intermediate outputs to XOR a value that is shifted > into the shift register. If you have to use multiple SRLs, then you > are just using them as fixed length shift registers. > You have to be judicious on your choice of taps. One SRL16 and the accompanying flip-flop gives you access to two adjacent taps, which works for a fair number of small LFSR lengths. You can also use the SRL16 as a Johnson counter by adding only an inverter. For short counts, you can use the shift register as a shift count, which I use frequently in state machines. I've also used the SRL addressing a LUT that controls the read address as a state machine a while back in a Spartan50 design that was pretty close to 100% utilized (customer didn't want to go to a larger device). Yes, a lot of the uses simply use the SRL as a shift register, but the point is by being conscious of the SRL as a design option you can often design the logic in a way that uses the SRL to realize a smaller implementation than a straightforward approach migh provide. This is particularly true with small counters where only a terminal count output is needed, or in state machines.Article: 108239
motty wrote: >> MGTs on V4-LX parts? You may want to revisit the datasheet before >> getting your hopes up: only the FX V4 variant has MGTs. Unless you can >> still ECO the part and live with the price delta between the two parts, >> this avenue is busted. > > Yeah, I am not well versed in the V4 parts, but I quickly found out the > LX doesn't have MGT's. : ) > > We will eventually be using a V5 part, so I need to look into those > details. I don't know if the MGT would work anyway. It lists a > minimum frequency of ~600 Mbps. I don't know if that is a hard line or > not. But right now I am just looking in to what methods are available > and trying different approaches. I tend to overlook that sort of details too when I am too busy with global aspects and have no immediate time to worry about specific (sub-)modular aspects. As for the MGT's 622Mbps bottom limit, this is due to clock recovery delay lines - in order to keep the MGT macros' footprint down to reasonable levels, they have to keep the amount of delay taps in the CDR circuitry down. Xilinx probably chose this value because it covers the transition from the upper range of what is doable in user logic up to OC48 and beyond. Since ASICs are always designed for worst-case timing to maximize yields (this is why a 600MHz design is tuned to pass 650+MHz gate-level timing simulations), MGTs can probably go at least 10% lower than that if you are willing to sacrifice process/environmental/etc. safety margins. Also, since this would be unqualified territory, you would be on your own as far as Xilinx is concerned. -- Daniel Sauvageau moc.xortam@egavuasd Matrox Graphics Inc. 1155 St-Regis, Dorval, Qc, Canada 514-822-6000Article: 108240
Are you sure that when you look at the assignments, in the assignament editor, that you don't have Fast Output/Input Enable Register enabled anywhere? Description of Fast Output: Implements an output enable register in a cell that has a fast, direct connection to an I/O pin. If such a fast, direct connection to the I/O pin is not available in the I/O cell hardware, this option instructs the Fitter to lock the output enable register in the LAB adjacent to the I/O cell it is feeding.Turning on the Fast Output Enable Register option can help maximize I/O timing performance, for example, by permitting fast clock-to-output times. Turning this option off for a particular signal prevents the Fitter from implementing the signal automatically in an I/O cell or locking down the output enable register in the LAB adjacent to the I/O cell. This option is ignored if it is applied to anything other than a register or an output or bidirectional pin fed by a register. "alterauser" <fpgaengineerfrankfurt@arcor.de> wrote in message news:1157471016.274755.295470@d34g2000cwd.googlegroups.com... > During the synthesis process, Quartus reports "Ignoring invalid > Fast-IO-Timing Assignments" which I am not able to discover, since > Quartus does not say WHERE or WHICH assignment is set incorrectly. Any > Idea ? >Article: 108241
Jim Stewart wrote: > > phaeton wrote: > > > Hi can someone please explain to me how to post to usenet? > > Um, you just did... No, he used "Google Groups", which is spliced into usenet. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 108242
king wrote: > hi, all > > I am developing a design with V4 LX100, and the project is large, which > usually cost me 2 hours to synthesis and PAR. It's more than I can bear > when debug it. > Is there any solutions to decrease the time cost? > Incremental design or planahead? > Can anybody with these experience figure out what should I do? > > Many thanks!! > > Regards > King > 2 hours isn't bad. I've got a design in house right now that has taken about 30 hours on the last two place and route runs, and that is with a lot of hand placement (it is a 400 MHz design in a Virtex4 SX55 in the -10 speed grade and occupies about 70% of the FPGA resources to be fair though) Synthesis pretty much is what it is. Place and route can be improved by starting with a placement that makes the routing phase easier. That means either doing floorplanning and manually placing the critical parts of the design, or using the guided place and route to leverage the floorplan from a previous place and route. You can also use the modular design tools to break the design into pieces, although I haven't tried that again recently (last time I did, it wasn't really quite working). It will help tremendously if the timing constraints are not pushing the envelope for your design. Reduce the number of combinatorial levels of logic the signal goes through between flip-flops in order to reduce the propagation delay between flip-flops. Reducing the delay due to the logic elements increases the budget for routing delays, which in turn makes the router's job a lot easier.Article: 108243
On 2006-09-05, Austin Lesea <austin@xilinx.com> wrote: > Tejo, > > http://direct.xilinx.com/bvdocs/userguides/ug073.pdf The TOC of that document refers to instantiation templates on p58/60 while the PDF seems to go from 56..63 directly. Trouble with my pdf reader?? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 108244
phaeton wrote: > > Hi can someone please explain to me how to post to usenet? You are posting through Google Groups from 209.236.224.213 which is assigned to <http://www.mia.net>. They don't appear to have a news server, but you could ask them. The other way is to either pay for access to a USENET server, or fight with the free, but flaky free USENET servers. If you can afford a few bucks a month I would go for one of the biggies like Supernews. The last option is to find an ISP who offers USENET access as part of their regular package. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 108245
Dave, Funny you should mention this. We came across the same issue, but we found out the limitations of the memory interface before we decided to spin boards. We ultimately went with an FPGA. You can't be an FPGA for parallel processing. In our particular application an FPGA running at 67MHz out performed the BlackFin running at 500MHz, all because of the FPGA's inherent power of parallel processing. Take care, Rob "David Ashley" <dash@nowhere.net.dont.email.me> wrote in message news:44fded00$1_3@x-privat.org... > David Ashley wrote: >> Now if we'd opted for an FPGA, if it was big enough we'd have had >> lots of options to improve performance. We could have licensed >> some existing IP, modified it to suit. It would have been a bigger >> unknown since none of us had direct FPGA experience, but we did >> have low level programming experience. Going an FPGA route might >> have been a better investment in the long run... > > One more thing occured to me. With the Analog Devices blackfin DSP > approach we found out the hard way memory bandwidth was a severely > limiting factor. The DSP had some small amount of on chip memory > that ran at the CORE clock frequency. The SYSTEM clock was a fraction > of that, say 1/5th or 1/6th. Accessing external SDRAM took something > like 6 SCLOCKS, which translates to 36 CORE clocks. Thats a *long* > time in DSP space. The SDRAM controller never did burst accesses, as I > recall. > > What that means is you can't effectively do anything unless you use > the on chip fast memory, which operates at the CORE clock frequency > (600 mhz to 750 mhz for example). But that was a limited resource. > And there was no way to improve the SDRAM controller, that was part > of the chip. So the resolution *couldn't* improve, we didn't have memory > for it, and no amount of optimization would work. > > With an FPGA, on the other hand, one could have modified the external > memory controller to burst out a whole 64 byte chunk of memory, or > burst one into a BRAM. Then operate in the BRAM, then write it back > out. Doing burst accesses would really speed things up, and the memory > IO could go in in parallel with other processing. In short there would be > almost unlimited ability to optimize, as needed. > > With the fixed-cpu DSP approach, we found out the limits the hard way. > Then we had to reduce our expectations. In the end it was OK, but it > might have been a disaster. > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architectureArticle: 108246
A PC on a fast network is far from an embedded solution. And many application require an embedded solution. "Nico Coesel" <nico@puntnl.niks> wrote in message news:44fdbcad.1055864262@news.kpnplanet.nl... > Austin Lesea <austin@xilinx.com> wrote: > >>Tejo, >> >>http://direct.xilinx.com/bvdocs/userguides/ug073.pdf >> >>Yes, the 18X18 multiplier/accumulator is a hardened block, so that >>performing this function results in from 8 to 20 times less power than >>performing this function would if it was done in the logic of the FPGA >>(luts, dff, interconnect, etc.) >> >>The above guide details use of the V4 for "extreme" DSP uses. >> >>FPGAs are useful for tasks that DSP processors are too slow for, >>otherwise, DSP processors are generally far easier and better suited for >>DSP. For example, a video conference processor, where multiple streams >>must be encoded, decoded, combined, along with all audio processing is >>one such task where a FPGA would excel for both cost, power, and >>performance. > > I doubt about cost and preformance. Developing such a device would > probably take so much time that an ASIC is just as cost effective and > uses even less power. An older PC is already capable of doing these > functions with a development time that can be expressed in days, not > years. > > Even when dealing with loads of videostreams at high resolutions it is > more cost effective, reliable and flexible to use PCs on a fast > network to do the processing rather than building a custom FPGA/ASIC > solution. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108247
Ray Andraka wrote: > > The SRL16's are actually one of the most versatile blocks on the FPGA. > You can use them for: > *snip* > variable delays > fixed delays > > The only one of these that is inferred by synthesis tools is the fixed > delay, and that is also the least interesting out of all these. Several years ago I managed to get Synplify 6.3 to infer SRL16s for a variable delay. Frankly I was amazed it worked :) I can dig up the code if anyone is interested. cheers, aaronArticle: 108248
"king" <frogkinger908@sina.com> wrote in message news:1157590436.111863.250840@d34g2000cwd.googlegroups.com... > hi, all > > I am developing a design with V4 LX100, and the project is large, which > usually cost me 2 hours to synthesis and PAR. It's more than I can bear > when debug it. > Is there any solutions to decrease the time cost? > Incremental design or planahead? > Can anybody with these experience figure out what should I do? I've long since found that more extensive simulation is many times much more productive in weeding out the bugs than trying to debug on actual hardware. I've found this to be true even when you have to create many of the models that surround the FPGA that emulate the board environment. If those models happen to be readily available then it goes that much quicker, but if not, it's not that bad. When I'm 'developing' I run synthesis sort of in the background. I run it not to produce any file that should be used on the board but just as another set of eyes to catch bugs. An example might be if suddenly I've dropped from 80% utilization down to 70% even though I didn't think I had made any changes to knock out anything like that. The reason for the drop might be because I've misconnected something that now causes the synthesis optomization to reduce out a whole section of logic. Granted I'll find that in simulation as well, but like I said the synthesis runs are meant to be a separate set of eyes looking at the code. Bottom line is, the best way I've found to break the long synthesis cycle time is to just not do them when you're actively debugging...use the simulator. When you do get to debugging on the board level you'll still find things that require rebuilds and you can spend the two hours build time pondering how you could've caught this bug if only you had modelled _____. And next time you'll have more experience about which things you really should model and catch in simulation and which can be deferred. KJArticle: 108249
Charlie Edmondson wrote: > > Michael A. Terrell wrote: > > > > > > > > Ernie wasn't very happy by the time it was over, then was forced to > > quit or be fired a few months later at a time when my word could have > > let him keep his job. On top of that, I got ten times what he did for > > my Christmas bonus that year. I made almost twice what he got that > > year, then he was looking for another job with the company telling his > > prospective new employers that they couldn't comment till the lawsuit > > was settled. :) > > > > > > > > > Had a similiar situation when I worked on the 91 Express lanes toll > road. My boss was a real A-hole, who would do things like, pull out a > knife and shave his arms, commenting on how sharp it was, while asking > for the status of your assignments. The threat was very thinly veiled... > > Then, about 9 months later, I was working for the other toll road > company and he came in for an interview. For some reason, he wasn't > hired... 8-) > > Charlie Too bad he didn't get hit by a truck when he was leaving. ;-) -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central Florida
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