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
Subhasri, you should of course always design according to the worst-case rules. But you should also know what's behind them. The refresh rate is dictated by the leakage current that might drain enough charge away from (or add charge to) a storage capacitor to make the stored bit invalid. The longer you wait, the more there is a chance to have a bit (or many bits) flip. But leakage current is a strong function of temperature. At a temperature below the specified worst-case number (is that 70 or 85 degrees C?) it will take longer to flip a bit. Leakage current doubles for every 10 degrees. That means, at 10 degrees lower temperature, you can, most likely, double the time between refreshes. But nothing is guaranteed... I do not advocate sloppy design, but it helps to know "the enemy". Peter Alfke, Xilinx, from home. =================================== Subhasri krishnan wrote: > Hi all, > There is a situtation in my controller when tRAS(max) is exceeded. My > controller starts to read out from some row but I am not sure exactly > which one. Does anyone know what row will be opened under this > situation? > Thanks > Subhasri.KArticle: 94651
Peter Alfke wrote: > Jim, beware, you are hitting a hot-button ! > Jim Granville wrote: > >>>Digits of precision & granularity ? > > 10 decimal digits fixed-point display, but 2 ppm accuracy. > Above 1 MHz limited by time base accuracy, below 1 MHz by display > (just because we are too lazy to make the display floating point...) > >>>A tad outside the average hobbiest resource pool ? > > I think so. > >>Yes, scopes are dominated by things other than the FPGA, so are not >>ideal demo-examples. > > Yes and no. For low-performance, most complexity would be in FPGA, > DRAM, and PC. > >>My favourites would be for Xilinx to do a split >>a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version > > Wait for the S3Eeval board. It includes a freq.gen design based on my > box. Ken Chapman did the control for both of them (PicoBlaze-based), so > you can be convinced it is good. > But it only goes to 80 MHz (?) and the jitter may be more than 100 ps, > since he has no PLL to clean it up further. > >>b) Freq Ctr & Signal Generator - Money-no-object version > > I am going for 2.5 GHz square wave, 1 Hz resolution, and lowest jitter. > But no arbitrary function, adjustable amplitude or duty cycle. All > those things are possible, but clutter up the design. Maybe there will > also come a USB-controlled derivative that offers more freedom. Those do sound like the Smallest/Cheapest and 'other end' I was talking about. Why stop at 1Hz ? > Please tell me what people need a frequency counter for. I have thought > of a design for years, including reciprocal counting at low frequency > for high resolution with short capture time. But it died for lack of > interest. We could of course include something in the S3E eval board. When I say 'Freq Ctr' that is short hand for the higher end Freq Ctrs. The better ones ( we use a venerable PM6672 here... ) can do much besides simple frequency. I'd start with the simplest gated counter designs, and then work up to Reciprocal and Time-Interval counters, ..maybe Phase too. A small nudge, and you can make a SigmaDelta ADC display section, as that's really a % counter. One idea I have, is for a Dual Readout Recip Counter : A fast update readout, where the precision is the normal trade off of update speed. The second would accumulate precision, so the longer the probe is held there, the more digits you get. That gets a little tricky, as the whole system has to never drop any edges. Uses: As a software development tool, to verify correct settings. Common errors are the off-by-one in divisiors etc. Mostly 2 channel Time-interval, but also frequency. > >>FreqCtr's can become quite complex - so a series of designs would show >>users more and more, but still have a HW platform that is >>i) FPGA dominated >>ii) Clearly ahead of any uC alternative > > The S3E eval board accuracy will be limited by its 50 ppm xtal, and the > resolution might be pushed to almost 1 GHz. Display is no problem @ 2 x > 16 digits. > A 20 times more accurate time base would cost <$20 extra. That's fine. It should NOT be limited by the FPGA. Users would be happy to add timebases as needed - yes, even to atomic ones :) For higher end examples, how about calibrate/correct via GPS timebase (still using the low cost xtal) That expands further, to give an absolute time reference - wider audience, and with 2 lines, one could show 'human' time, and the other the snapshot of the 1 sec time pulse from the GPS, probably to better than 5ns. > I warned you, this is a hot button with me. > My thesis project, looong ago, was a frequency counter. It's deep in my > genes. Talking of looong ago, I think my first film-processed project was a compact 8 digit Freq Ctr, with many old fairchild part numbers. That was before rubylith.... -jgArticle: 94652
Jim Granville wrote: > > Why stop at 1Hz ? It is easy to go to mHz, just make the accumulator longer, but why? With 1 ppm absolute accuracy, even the Hz is dubious above 1 MHz. Who is interested in frequencies below 1 MHz? That also goes for the counter. Jim, you seem to overestimate the time and energy we here can expend on sophisticated and increasingly specialized appliations. That's why I stay with a basic, but extreme design that gives us some real usefulness and also some bragging rights. There are always more urgent projects breathing down our necks: Verifying, testing, finding problems and work-arounds, write documentation, plan the next generation, prove SEU hardness, deal with unhappy postings on the newsgroup, give seminars, attend conferences, analyze the features and find the shortcomings of the "other guy", support Markeing, but prevent them from exaggerating... Life is never dull, often challenging, and rarely really frustrating. Peter AlfkeArticle: 94653
Hello everyone Just wanted to share some of my recent experience from switching to Amfeltec PCI extender from the one from Ultraview (the old one burnt last month). Amfeltec works very nice for me - easy to plug in, compact enough to fit a small box, comes with software for Linux, FreeBSD and Windows and also different types of brackets. The extender has a built-in byte blaster that I use with my Xilinix and Altera FPGAs, which means that I need now just one tool instead of three. It's a cool product, quite unique I'd say, the more I use the more I like it. You can find it at http://www.amfeltec.com StevArticle: 94654
>So, I wonder, how many people here are exclusively logic designers, >and how many are more general EEs, who deal with the analog, power, >thermal, and other aspects of electronic design? I've never worked with any "exclusively logic designers". (At least I don't think I have. Maybe one snuck in that I didn't notice.) There is also the other end of the spectrum: firmware/drivers/software. For most projects that I've worked on, that's a cricital part of the big picture. You could also expend up to system architecture and stuff like that. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 94655
Austin Lesea wrote: > Dimiter, > > As for "does RoHs make my life any safer applied to electronics?" I > would have to agree with you: it does not. > > There is absolutely no reason to go through this nonsense when > automotive lead acid car batteries are thrown away by the roadside and > in landfills every day... Any sensible country recycles lead acid batteries and issues horrendous fines for dumping them. > > I would say clean up the major polluters first, and then go after the > next tier. To go after electronics, and electronics assemblies when > they conrtibute practically no lead to the environment is just silly. > > I can understand not using lead in paint for homes! Or no lead water > pipes! I have no idea where you live, but over here, we don't have leaded paint, nor leaded waterpipes anymore. They were ruled out decades ago. > > Talk about removing 99.99% of the lead from our environment! That indeed is the aim. As long as electronics was produced in little numbers it wasn't considered a problem. But now with a mobil phone costing 1$, you can bet they end up being thrown away rather quickly. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 94656
logjam wrote: > I'm interested in these kits Eric. What else other than the board > would you recomend I get? If you're willinng to try an HDL instead of schematic entry, you should get a good book on the one you choose. I don't have any recommendations for Verilog, but for VHDL you would want "Designer's Guide to VHDL" by Ashenden. > Does this board come with things like a VGA core? There are some demos. I think there was one that did VGA video. "VGA core" is somewhat ambiguous. I haven't seen any free core that actually implements VGA (i.e., the register-level programming interface of the IBM VGA display adapter). But there are many cores that can drive a VGA monitor. > Are the WebPack tools good enough? Yes. > The project requires 110 shift registers to be loaded every 14ms. I'm > going to use some dual port SRAM from cypress, which will basically > take care of ALL the Altair's RAM needs! ;) Would a good beginning > project be an FPGA which reads from the dual port SRAM and sends the > correct byte to the correct shift register? Basically a compicated > parallel to serial converter? Yes. Shouldn't be too difficult.Article: 94657
Simon Peacock wrote: > ahh.. Anybody who doesn't consider the environment is a fool. You may say a > million years is too far to consider.. but it only is if you don't think > Humanity will kill itself off by then. Did you know over a million children > a year die in Asia due to air pollution? How about by the time they reach > 20 the air quality has reduced their lifespan by 5 years ? That has absolutely NOTHING to do with trying to plan for a million years in the future. If it's true, it's a current problem, and needs a current solution. > Its important to care about what we put into the atmosphere or into > our ground. I never said otherwise. But spending a lot of effort trying to eliminate a source of polution that is only a tiny part of the problem, while ignoring other sources that are a much larger fraction, will not accomplish anything useful. > Protect the planet.. its the only one we've got. The planet doesn't need protecting. It was here billions of years before us, and will be here billions of years after us, regardless of what we do.Article: 94658
Kolja Sulimma wrote: > Xilinx has JBits. But I wonder whether there's any plan for it to support Spartan 3 parts.Article: 94659
"Phil Tomson" <ptkwt@aracnet.com> schrieb im Newsbeitrag news:dqefe401nol@enews4.newsguy.com... > In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>, > Tobias Weingartner <weingart@cs.ualberta.ca> wrote: >>Kevin Morris wrote: >>> >>> Any takers? >> >>Real/Complete programming information would be a very good start to a new >>hobby phase. But I think that all the FPGA vendors are too scared to give >>out this information. Come on, xilinx, altera, etc, etc. What could >>there >>possibly be so secret in the format for how to program your parts? :) >> > > Indeed. I don't get it either. How much can be reverse engineered from a > bitstream format? This closedness is a real hindrance to the development > of > an open source eco-system around FPGAs. > > Any university open FPGA architectures being developed out there? While > it's > probably too late in the game for a new FPGA company to enter the race, > it's > possible that one of the smaller, hungier players might be able to > differentiate themselves by opening up their bitstream formats. > > Phil Phil, Atmel AT40K/AT94K bitstream format is almost open eg it is available under NDA from Atmel, and open source reverse engineered documentation is also available - no NDA :) As of BIG FPGA companies making their bitstream format public - do not hope! because the bitstream holds not only the 'known' bits like routing and LUT, but also factory stuff bits that compensate against technology changes, those are 'figured out' by actual measurement by the FPGA companies AFTER wafers are manufactured that is the FPGA companies makes their chips to have a little 'fine tuning' to be done, this fixing is done by bitgen and is totally invisible for the normal user. second there are factory test bits and settings, again something that the end user should not mess up there are some hidden FPGA primitives that are partially visible for the end user but not useable by end user, like PMV primitive in V4 and S3 there are probably hidden features and primitives that are totally invisble for the end user as well. so there are reasons for keeping the bitstream non public. for Xilinx and Lattice the main bitstream info is in NeoCad "BFD" files, those are simple ordered lists of bit names, bitgen uses that info to convert an NCD to bitstream NCD file is almost 1:1 the same as the XDL file would be so actually pretty much of the bit info is visible for those who want to see -- Antti Lukats http://www.xilant.comArticle: 94660
"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag news:qhr7784lw3.fsf@ruckus.brouhaha.com... > Kolja Sulimma wrote: >> Xilinx has JBits. > > But I wonder whether there's any plan for it to support Spartan 3 parts. NO NO NO [...] Jbits is DEAD. Jbits is DEAD. Jbits is DEAD. [...] Jbits is not supporting any current 'active' Xilinx FPGA :( -- Antti Lukats http://www.xilant.comArticle: 94661
Hi, I want to know if anybody has never programmed fpga or proms not using Impact or Quartus programmer but other (third party) tools. If yes, how ? which are the file formats to use? Thanks in advance.Article: 94662
"antonio bergnoli" <bergnoli@pd.infn.it> schrieb im Newsbeitrag news:43cb5fd1$2_2@x-privat.org... > Hi, > I want to know if anybody has never programmed fpga or proms not using > Impact or Quartus programmer but other (third party) tools. If yes, how ? > which are the file formats to use? > Thanks in advance. lots of people do that. most of the info is available, sometimes it needed to reverse engineer SVF or BSDL files to complement the public information there are different formats that can be used depending on device targetted -- Antti Lukats http://www.xilant.comArticle: 94663
Hello Grant, I really must get back on line at home - the whole world has come back with good answers already. I would use a HDL entry method, much easier and flexible in the long run, despite the steeper learning curve. The T80 core (at least the maintained version on the fpgaarcade site) is getting very close to the exact behaviour of a real Z80. However, the bus timing has been simplified slightly for synchronous FPGA work. You will need to generate a two phase clock yourself, but look at some of the other code (for example the Z80 based Bally) which uses a small counter to clock enable the cpu core and generate phase signals for the chipset. Try and convert the logic to synchronous operation otherwise you may have trouble. There is another top level wrapper for the T80 core (T80a) which should work with your peripherals - it is the one I used when I tested the core with a real Z80, although it has not been tested in a while. I would personally go with a Spartan3 based dev board (3E if you can get one). There are many good ones around. Good luck, Cheers, Mike www.fpgaarcade.com logjam wrote: > I was working on a Macintosh clone project (a clone of the original > 128k), but I'm not willing to invest any more time in something that > Apple would probably kill with a C&D order. > > I'm now working on a hardware replica of the Altair. I'm scanning the > PCB layout and creating historically accurate replicas. I've come to > the conclusion that the average person is not going to be able to > afford a kit "just for the fun of it". There are literally square feet > of PCBs required and a lot of the components will be expensive. > > This leads me to the idea of putting the Altair into an FPGA for people > who want the blinking light effect but could care less about the guts. > This would be similar to the PDP-8 clone that is an inch thick and can > be hung on a wall like an interactive picture. I don't have any > experience designing logic for FPGAs, but like learning > C/Assembler/Visual basic...I can probably use code examples to teach > myself. > > Basically what I'm looking for is an FPGA development board that would > be suited to hold the 8080. I would also like to integrate an > "optional" boot ROM, RAM, serial card, cassette card, etc. These > devices wouldn't take up too many resources I'd think. > > The only possible problem I can think of for an Altair FPGA is that I > would want all the bus signals brought out for the front panel and for > optional interface cards. Is the T80 core accurate enough to produce > the two clock phases and all of the bus signals? > > What development board would you suggest I buy for this purpose? I've > heard about schematic entry for the logic, and I'd like to have that > tool as an option. > > Thanks for your time, > GrantArticle: 94664
> > Some info in this presentation particularly with respect to long-life > critical systems. > Don't worry. Military electronics is not covered by the RoHS directive. ;-)Article: 94665
Thank you for the kind words Eric. P.S. has everyone read Eric's article about FPGA Gaming in XCELL? http://www.xilinx.com/publications/xcellonline/xcell_54/xc_pdf/xc_atari54.pdfArticle: 94666
Simon Peacock wrote: > The main problem is the lobby groups.. I'd say the battery makers have a > better lobby group than the electronics. Or it would be an offence to dump > any kind of battery by now, you would have to take them to an approved > recycler that has sufficient protection on its plant to avoid contamination > of the surrounding area. That's how it is in some parts of the EU already. In Germany, all batteries must be taken back by the manufacturer to be disposed of/recycled properly. That means that you can (actually, you HAVE to) return empty batteries to the store you bought them at, and they send 'em back to the manufacturers, who in turn have to deal with them properly (as required by law). Theoretically, you can be fined if someone finds old batteries in your trash. Not that anyone really is looking... Some more examples from Germany: Every store is required to take back packaging materials. It's not uncommon for people in supermarkets to start ripping off cardboard boxes and blister packages from the stuff they just bought and leave it in the store. Every major store has recycling bins for paper and plastic for that purpose. I guess this was supposed to motivate manufacturers to use less packaging, hasn't really worked... Last year, they introduced refundable deposits for most cans and plastic bottles. So now you pay a little something extra for every can of soda or beer, and have to return the empty ones to the store to get the deposit back. This is supposed to motivate people to buy their stuff in reusable glass bottles instead of throw-away cans and plastic bottles. Of course there were some loopholes, and the whole thing caused more ruckus than it did good. So, now that stores have to take back batteries and packaging materials, the next step was to make them take back electronics as well. Now all electronic devices can be returned to the stores, who in turn have to take care of proper recycling (as required by law). And this implies that the stuff indeed CAN be recyled, which in turn requires manufacturers to use minimal amounts of hazardous materials to at least make the process easier. Of course we could instead keep doing what we do now and send the stuff to India and China by the shipload for them to rip it apart with bare hands on unprotected soil... That's another way to return it to where it was made... cu, SeanArticle: 94667
Hi Jim, Thanks. That's what I have to do with 7.1. Go through each net looking for the failures. I vainly hoped that, as it knows some nets have failed, the tool might have the common courtesy to tell me which ones. No. Cheers, Syms. "Jim Wu" <jimwu88NOOOSPAM@yahoo.com> wrote in message news:LYGdnVgC64_rV1fenZ2dnUVZ_sudnZ2d@comcast.com... > If you have access to ISE 8.1, you can use FPGA_EDITOR to find out which > DIRTs failed. > > HTH, > Jim > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:43c7d5ac$0$15784$14726298@news.sunsite.dk... >> All, >> I've got some directed routing constraints in my UCF file. After some > recent >> changes I get the following message in the P&R PAR file:- >> >> # of EXACT MODE DIRECTED ROUTING found:14, SUCCESS:9, FAILED:5 >> >> Anyone know how to find out which nets are failing? I can't find anything > in >> the report files. >> >> TIA, Syms. >> >> >> > >Article: 94668
"Simon Peacock" <simon$actrix.co.nz> wrote in message news:43c8aee9@news2.actrix.gen.nz... > > Protect the planet.. its the only one we've got. Don't rely on finding > another to pollute :-) > Simon I would agree with you here Simon, but would prefer to see efforts targeted where they are going to do the most good. In the power point presentation from 2004 MAPLD that rk posted the link to.. "Texas Instruments (TI) is a $9.83B electronics component manufacturer that sells millions of devices all over the world. They estimate that complete conversion to lead-free products woud result in an annual worldwide lead reduction equivalent to TEN automobile batteries". It hardly seems the best place to start wasting $100sB of people's time and effort to reduce the environmental impact by this amount. Nial.Article: 94669
On 16 Jan 2006 01:15:40 -0800, "al82" <yscdi62k001@sneakemail.com> wrote: > >> >> Some info in this presentation particularly with respect to long-life >> critical systems. >> > >Don't worry. > >Military electronics is not covered by the RoHS directive. ;-) Airbus.Article: 94670
HI, All I have questions regarding a project i am currently working on. I have been assigned to develop an vga_controller with the sparten3.And now there is problem with the dynamic memory. It should at first save the picture to the sram and then read out and show it on the monitor. And i have written any code. But there is still problem. Does anynone know, where can i get any tutorial of the vga_controller? Thanks!Article: 94671
>Dear all, > >This may sound stupid to ask, but I am very frustrating now as my >deadline is approaching. I want to make use of the VGA generator >example on www.xess.com. How could I write/read data to the specific >address of the SRAM? >I would have to have a SRAM controller that writes and reads data to >the SRAM? How should that be implemented in VHDL? What else do I >need? I am planning to hard code the data to SRAM. Thank you very >much!!! > HI, I just also do the same work. I have the same problem. And have you resolve the problem? I would like to discuss it with you! Hier is my email address: qingwang_1978@hotmail.com.Article: 94672
"qtommy" <qingwang_1978@hotmail.com> schrieb im Newsbeitrag news:O-SdnWCndoFhB1beRVn_vQ@giganews.com... > >Dear all, >> >>This may sound stupid to ask, but I am very frustrating now as my >>deadline is approaching. I want to make use of the VGA generator >>example on www.xess.com. How could I write/read data to the specific >>address of the SRAM? >>I would have to have a SRAM controller that writes and reads data to >>the SRAM? How should that be implemented in VHDL? What else do I >>need? I am planning to hard code the data to SRAM. Thank you very >>much!!! >> > > HI, I just also do the same work. I have the same problem. And have you > resolve the problem? I would like to discuss it with you! Hier is my email > address: qingwang_1978@hotmail.com. > > The xess demo only reads from the SDRAM, for write access you need to make some statemachine based arbiter that will allow write access the SDRAM, there is no demo for that unfortunatly, I did a quick dirty thing once it only wrote a small image from camera in the SDRAM -- Antti Lukats http://www.xilant.comArticle: 94673
On 15 Jan 2006 21:39:16 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: >In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>, >Tobias Weingartner <weingart@cs.ualberta.ca> wrote: >>Kevin Morris wrote: >>> >>> Any takers? >> >>Real/Complete programming information would be a very good start to a new >>hobby phase. But I think that all the FPGA vendors are too scared to give >>out this information. Come on, xilinx, altera, etc, etc. What could there >>possibly be so secret in the format for how to program your parts? :) >> > >Indeed. I don't get it either. How much can be reverse engineered from a >bitstream format? This closedness is a real hindrance to the development of >an open source eco-system around FPGAs. Last really open system was the XC6200. But it failed commercially, at least in part, because it was a finer grained architecture. FPGA capacities should now be big enough to support a "virtual FPGA" layer on top of a real FPGA, using only the "public" parts of the bitstream (e.g BRAM and SRL16 contents, possibly a subset of the routing) to give a completely open format. Possibly a virtual XC6200, but probably a coarser grained architecture (mini-Spartan perhaps). I wonder what size Spartan-3 you would need for a virtual XC6264? This would lose a lot of capacity and performance (you may need several LUTs dedicated to routing for every one you can use for logic) but the result is likely to be at least competitive with the sort of technology a startup or small player has on offer. I think it would be big enough to exercise open source development tools until something better came along... - BrianArticle: 94674
Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag news:9p7ns1pch437c81ln9dunkk34bo5p2k3ab@4ax.com... > On 15 Jan 2006 21:39:16 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: > >>In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>, >>Tobias Weingartner <weingart@cs.ualberta.ca> wrote: >>>Kevin Morris wrote: >>>> >>>> Any takers? >>> >>>Real/Complete programming information would be a very good start to a new >>>hobby phase. But I think that all the FPGA vendors are too scared to >>>give >>>out this information. Come on, xilinx, altera, etc, etc. What could >>>there >>>possibly be so secret in the format for how to program your parts? :) >>> >> >>Indeed. I don't get it either. How much can be reverse engineered from a >>bitstream format? This closedness is a real hindrance to the development >>of >>an open source eco-system around FPGAs. > > Last really open system was the XC6200. But it failed commercially, at > least in part, because it was a finer grained architecture. > > FPGA capacities should now be big enough to support a "virtual FPGA" > layer on top of a real FPGA, using only the "public" parts of the > bitstream (e.g BRAM and SRL16 contents, possibly a subset of the > routing) to give a completely open format. Possibly a virtual XC6200, > but probably a coarser grained architecture (mini-Spartan perhaps). > I wonder what size Spartan-3 you would need for a virtual XC6264? > > This would lose a lot of capacity and performance (you may need several > LUTs dedicated to routing for every one you can use for logic) but the > result is likely to be at least competitive with the sort of technology > a startup or small player has on offer. > > I think it would be big enough to exercise open source development tools > until something better came along... > > - Brian > > it has already been done there was MPGA project that implemented a virtual "Meta" FPGA the project is dead vanished/vanishing but its a nice a example of the use of SRL16 for virtual FPGA loading its however far more interessant to implement dynamic bitstream generator that patches some parts of the ready made bitstream to modify the algorithm this needs to no resources to be vasted for the download of the new config. -- Antti Lukats http://www.xilant.com
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