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
Austin Lesea wrote: > Ray, > > I know, I know! > > We are really open to any good ideas. Austin, For starters, it would help if your hotline folks were up on the current cases. For example, I recently ran across an issue in 7.1sp4 where pipeline stages are getting added to my DSP48's by teh implementation tools, and causing the hardware to behave differently than functional sim (first off, that should be left to synthesis, not PAR). I opened a case for it (case 614397 if you are interested) a bit over a week ago. The only responses I got (and I had to go to the website to find the first after getting the second offering to close the case) was a superbly helpful statement that he wasn't aware of any differences in the behavior between 6.3 (which works fine) and 7.1, and were there any differences between the timing simulations for the two. I found out asking around inside Xilinx that the 7.1sp4 mapper tries to be cute by moving registers in and out of DSP48's, but ignores any effects it might have on timing in parallel pipeline paths. Now, I searched high and low through the answers database for anything with pipeline register and DSP in it, but couldn't find a relevant answer anywhere. My source inside xilinx asked around and found out about answer 22314, which tells how to disable this odd behavior with an environment variable (turns out the word pipeline wasn't in the keywords, so your search engine didn't turn up this answer record). Once again a "known" behavior that took close to a week of my time tracking down, and even the hotline help couldn't find a relevant answer. Perhaps you see this as acceptable (I sure wish I could bill someone for all the debug time I have expended this past 6 months chasing down problems in the silicon or tools and finding suitable work-arounds), but I certainly don't. The current system is broken when the designer has to resort to inside contacts in order to track down problems in his design caused by undocumented but known behavior of the silicon or the tools. I can't imagine that I am the only one running into these issues with Virtex4 (this one, placement of DSP48s with pre-SP4 7.1 tools, problems with the Xilinx DCM NBTI fix circuit, and FIFO16 problems to name a few of the big ones that tripped me up). It wouldn't inflame me if it didn't come down to me spending tens or hundreds of hours on each, and then hearing "oh, yeah, we knew about that". I have spent well over 1/3rd of my time in the past 6 months chasing or correcting issues caused by tools or silicon. That is time that is generally not paid by my customers, plus it makes a significant dent in my schedule. OK, so for a better way. #1 Listen to the users of your software, and I mean all of them, not just your biggest 5 accounts. #2, stop the software folks from mucking with the software. Fix what is broken before adding new features, and for Gosh sakes stop the gratuitous changes that seem to break everything. #3, work on the support for the software you have. #4, organize the answers data base, perhaps with a pre-filter that asks you which device, version of ISE, and maybe synthesis tool you are using so I don't get 1001 answers for ISE4.1 when I am trying to use 7.1. #5, don't just cut off support for an older version (eg 6.3sp3, which works better than 7.1 except the timing parameters haven't been updated) if the newer version is still loaded with fatal bugs. When I report a problem with 6.3, the only answer that is returned is use 7.1 (never mind the fact that 7.1 did not work at all until sp4 for any design I ran it on) #6. Fix the bugs in a major release before committing all your effort to the next major release. #7 Listen to your users, some of them do know what they are talking about. Things like the FIFO16 restrictions need to be in the user manual so that the designer is aware of them before he design them in so that he can work around the limitations. Easy to work around if given the information. A real pain the tail to find the problem if you are not aware of the limitations, and none too fun to rework the design to work within the limitations when you do learn about them. For known bugs in the software, there really should be an errata sheet listing the known issues that can trip up a design (like the pipeline register remapping or what ever you call it) so that when you run into a problem like this you have a prayer of finding an answer record on it. Maybe all it takes is a refinement of the search engine. I don't know, that isn't my area of expertise. I think the fact that you also didn't post any relevant answer records to Brads post that started this should be a flag to you showing you that the system isn't working too. Another suggestion is better testing of your software before you release it, not just on the mainstream push the big green button to make a 40 Mhz design designs either, but some with some handcrafting that are pushing the clock capabilities of the devices. While the compile completion times have gotten remarkably good, the quality of results for a pretty well optimized design (one that includes tight floorplanning) have fallen off with each major release since 4.1. I know other users have remarked as such here, so I know I am not the only one. The regression testing really does need to include the full spectrum of designs, unless Xilinx really is trying to kill off the RLOC as was speculated here many years ago. OK, sorry about the rant (well, not really). This thread just happened to pour vinegar into an open wound, and well, your answer did nothing to soothe the pain.Article: 94626
Brad, it is your addressing. For the wider data widths, the lsbs of the address should be held at zero. You should use bits 14 downto whatever is appropriate for the aspect ratio you are using (in your case the 36 bit should leave the 5 lsbs '0'). Brad Smallridge wrote: > Thanks for words of encouragement Ray. > > I went back to double check if all the simulation > and libraries were downloaded and installed. It > seems as if they are. All from the download page > that Xilinx is advertising on the home page right > now for the 8.i software. Three packages in all, > the ISE, ModelSim III, and it's library. > > I am still not getting any output from the RAMB16 > pArticle: 94627
mughat wrote: > Anyone have experience with designing band pass filters for ACTEL FPGAs? > Tools, appnotes anything is of interest. > > I my project I have to make some DSP on 3 audio signals (100Hz-22Khz). > Planing on using the new Fusion mixed-signal FPGA from ACTEL. > > You need to design the filter first using some filter design software (this will give your the filter architecture and coefficients). Then you can worry about putting into the device. You don't say much about your requirements or environment. Audio sample rates are much lower than what modern FPGAs can be clocked at, so it is perfectly reasonable to use a combination of bit serial and time-multiplexed logic to reduce the footprint of your filter.Article: 94628
On 12 Jan 2006 12:15:13 -0800, "Kevin Morris" <kevin@techfocusmedia.com> wrote: >I'm writing a feature article for FPGA Journal (www.fpgajournal.com) >about FPGAs and the re-birth of the electronics hobbyist. My theory is >that electronics as a hobby went through a "dark age" period, maybe >from the early/mid 1970s until recently becuase of the inaccessibility >and cost of designing with state-of-the-art technology. Radio Shack >shifted their focus from 50-in-1 project kits and hobbyist parts to >selling toys, cell-phones, and stereo equipment. I agree that electronics as a hobby is not as vibrant as it has been in the past, but not on your time line or for your reasons. My theory is that the decline started no earlier than late 80's and has not really recovered. But the projects that are now created are far more complex than those of yester year, but at a level comensurate with the technology available today. The decline has little to do with Radio Shack and 50-in-1 kits. While it is probably true that most electronic hobbyists have at some time owned and played with these kits, there are probably far more that had these kits, and after a few hours, they were put away never to be used again until passed on to some younger cousin. These kits were way too limited, had fairly poor educational content, and no direction as to how one might expand, experiment, and learn more. My theory is that the decline in the late 80's was driven by several things that started in the early 80's: - Reasonably cheap personal computers with sufficient software that hobbyists that may have become electronic hobbyists, instead became software weenies. The open-source movement now extends this to colaborative projects that are very challenging, and include the opportunity for others to use your work, and to get recognition for your contribution. I am not criticising the O-S movement at all here, just pointing out that it is an alternative path for potential electronic hobbyists. - Many of the things that electronic hobbyists used to build could be purchased complete and working for less than the raw components cost. There is not as much fun in building a 7 transistor radio that has mediocre reception in a cardboard box, versus a buying a walkman for the same price. Other projects just are not possible, such as build a CD player or cell phone. - Many of the components that you might want to buy that are used in commercial products were not available to hobbyists. - Many of the challenges that may have enticed an electronic hobbyists are now replaced by toys such as playstations etc.. that consume vast amounts of what would have been hobby time. Electronics as a hobby requires significant study to be able to do interesting projects. 150 channels of TV probably don't help either. - Mentors are in short supply. I think the pressures of work have increased (because electronic work projects are more complex) so the pool of mentors is diminishing. Their hair is getting thinner and grayer too. - Specialization. As the electronics profession has grown over the last 25 years, the amount of new stuff is such that few if any can master (or even be reasonably competent) in multiple sub-fields. This affects the mentor pool, and also the breadth of available literature that might guide a starting-out electronic hobbyists. This was driven home for me about 10 years ago when I met with a world renown Verilog expert, who had no clue that a 74LS74 was a flipflop! - Minaturization of packaging makes some products un-useable by hobbyists, or requires much higher levels of enthusiasm. Surface mount made the older wire-wrap no longer an easy solution for projects, as the availability of wire-wrappable sockets is far more limited, and the latest packages such as QFN and BGA are beyond almost all hobbyists. I am not saying that this kills the hobby, but it certainly raises the bar. >Now, with the emergence of low-cost, high-capability FPGAs, development >boards, and design software, I see a new age of hobbyist activity >beginning (as often evidenced in this group). FPGAs on development boards http://www.fpga-faq.org/FPGA_Boards.shtml go along way to allowing any hobbyist to start playing and experimenting with FPGAs, HDL, simulation, hardware design and interfacing to the real world. Best of all, there are many low priced boards available, and all of the software for the low end products are available free to anyone with a computer and an internet connection (and a few gig of disk space). While this re-enables electronic hobbyists to work with current technology, and pursue it with tools that are similar to what professionals are using, I don't think this is going to get anyone to put down their XBOX-360 and start writing VHDL. >I'm looking for a few people that would be willing to express views on >this topic for the article. This group is full of them. I've been an electronics hobbyists for over 40 years. Sometimes I get to be paid for it (employment), and sometimes not. Cheers, Philip Freidin Philip Freidin FliptronicsArticle: 94629
On 12 Jan 2006 12:15:13 -0800, Kevin Morris blurted: I don't feel qualified to comment on the dark ages, but in the last several years have moved from the software side into hardware. I keep a blog about some of the stuff that I'm doing (www.dtool.com) & read this group regularly - understanding about 5% of it. I am playing w/ a Digilant Spartan3 board, & when the Xilinx software doesn't crash, am making slow progress in understanding how to move from, say a hardware-based ethernet, to one designed w/ logical tools. I don' get paid for this stuff - it's just very cool. My wish is for more tutorials & even more access to free software (Chipscope for more than 60 days for example), as buying all of the ancillary tools, chips, hardware, scopes, probes, etc. can get expensive after awhile. My $.02, Tom Spamming this account signifies your unqualified consent to a free security auditArticle: 94630
Ray Andraka wrote: [User feedback that should have almost everyone in Xilinx cringing..] <snip> > OK, so for a better way. #1 Listen to the users of your software, and I > mean all of them, not just your biggest 5 accounts. #2, stop the > software folks from mucking with the software. Fix what is broken > before adding new features, and for Gosh sakes stop the gratuitous > changes that seem to break everything. #3, work on the support for the > software you have. #4, organize the answers data base, perhaps with a > pre-filter that asks you which device, version of ISE, and maybe > synthesis tool you are using so I don't get 1001 answers for ISE4.1 when > I am trying to use 7.1. #5, don't just cut off support for an older > version (eg 6.3sp3, which works better than 7.1 except the timing > parameters haven't been updated) Very good point : Xilinx: So HOW hard is it, to update the timing parameters ? Actually, SURELY Xilinx do that internally, otherwise HOW do they know they ARE moving forwards in SW, and not simply being carried by the silicon ??! if the newer version is still loaded > with fatal bugs. When I report a problem with 6.3, the only answer that > is returned is use 7.1 (never mind the fact that 7.1 did not work at all > until sp4 for any design I ran it on) #6. Fix the bugs in a major > release before committing all your effort to the next major release. #7 > Listen to your users, some of them do know what they are talking about. How about #8 : Get the SW writers to actually USE the tools ?! Some of the failings reported here, are frankly, stunningly stupid. eg Inverted outputs on CPLDs - I'd really LOVE to hear just how that flew thru all the supposed regression testing ?. --Let me guess - they only tested SW, and no one thought to try real silicon ?! > Things like the FIFO16 restrictions need to be in the user manual so > that the designer is aware of them before he design them in so that he > can work around the limitations. Easy to work around if given the > information. A real pain the tail to find the problem if you are not > aware of the limitations, and none too fun to rework the design to work > within the limitations when you do learn about them. For known bugs in > the software, there really should be an errata sheet listing the known > issues that can trip up a design (like the pipeline register remapping > or what ever you call it) so that when you run into a problem like this > you have a prayer of finding an answer record on it. Maybe all it takes > is a refinement of the search engine. I don't know, that isn't my area > of expertise. I think the fact that you also didn't post any relevant > answer records to Brads post that started this should be a flag to you > showing you that the system isn't working too. This is something of a catch 22: To fully document problems, Xilinx must first understand them. However, if they understood them, they would be fixed/eliminated very quickly. There is a natural vested interest in NOT listing too many bugs in SW. It is classic large company spin, to appear to give support and information, when actually doing neither. > > Another suggestion is better testing of your software before you release > it, not just on the mainstream push the big green button to make a 40 > Mhz design designs either, but some with some handcrafting that are > pushing the clock capabilities of the devices. I'm sure Ray could give Xilinx some very good 'real world' test cases ? While the compile > completion times have gotten remarkably good, the quality of results for > a pretty well optimized design (one that includes tight floorplanning) > have fallen off with each major release since 4.1. I know other users > have remarked as such here, so I know I am not the only one. The > regression testing really does need to include the full spectrum of > designs, unless Xilinx really is trying to kill off the RLOC as was > speculated here many years ago. > > OK, sorry about the rant (well, not really). This thread just happened > to pour vinegar into an open wound, and well, your answer did nothing to > soothe the pain. -jgArticle: 94631
>There is a natural vested interest in NOT listing too many bugs in SW. Not where I come from. Doug Clark wrote a great paper - "Bugs are Good". Unfortunately, I don't think it's available online. Context is roughly: Don't shoot the messenger. Praise the people who find the problems before you tape out. Discuss the bugs you find. Why weren't they found sooner? Where are there similar structures that should be examined/probed? If you can accurately keep track of bugs, then you can plot bugs discovered over time. When that falls off it's time to ship. I think it's a culture thing. It's much better to find bugs sooner. The trick is to make sure that everybody understands that - management too. You need somethingthings like a senior designer standing up in public and saying thanks to a new hire. -- 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: 94632
Jim Granville wrote: > Sudhir.Singh@email.com wrote: > >> Hi folks, >> are there any DSP soft processor cores for fpgas available. I have done >> a search and only found 32 bit RISCs but no DSP processor cores. >> Thanks in advance >> Sudhir > > > I thought the tool flows supported this now, but via the DSP blocks ? > -ie rather than a separate 'core', you compile what you want, into > as many DSP Cells as you need ? > A Soft-DSP will never be as fast as a dedicated device, the key > in FPGA is to spawn DSP in parallel and in HW. > Check with Altera, Lattice, Xilinx... For a topical update on this, check Xilinx website news on their purchase of AccelChip. As you can see, these newest tool flows somewhat side-step the need for DSP Cores, per-se. -jgArticle: 94633
Hal Murray wrote: >>There is a natural vested interest in NOT listing too many bugs in SW. > > > Not where I come from. > > Doug Clark wrote a great paper - "Bugs are Good". Unfortunately, I > don't think it's available online. > > Context is roughly: > > Don't shoot the messenger. Praise the people who find the problems > before you tape out. > > Discuss the bugs you find. Why weren't they found sooner? > Where are there similar structures that should be examined/probed? > > If you can accurately keep track of bugs, then you can plot bugs > discovered over time. When that falls off it's time to ship. > > > I think it's a culture thing. It's much better to find bugs sooner. > The trick is to make sure that everybody understands that - management > too. You need somethingthings like a senior designer standing up in public > and saying thanks to a new hire. 100% Agree - for a properly-run engineering company. However, as companies get more dominated by market-droids, and someone suggests this info is made more public/user accessible, that's where you will see the push-back : Write your own Dilbert lines here : " Hang on, All these defect reports makes our SW look bad - quality was better before" " Those defects will only affect very few customers, so why tell everyone about them ? " Xilinx press releases show some of this mindset already : My present most entertaining favourite is the ISE 8.1i release that says :: "WebPACK 8.1i’s ISE Fmax Technology ... up to 70 percent faster performance than competing FPGA products" [Is this a laundry product, or Engineering SW they are selling ? ] Sounds great, warm fuzzies all round, until you look for meaning.... - Note, no comparison with EARLIER ISE releases, only with someone else's (un-named) offering, and then it's the meanginless "up to" caveat. There is another end to this scale as well, which is "down to" - why is that never published in these press releases ? :) -jgArticle: 94634
At the moment the only link is a button top right on the root page. Just click on that to get back to it. I will try and get it added to the general menu in a more appropriate fashon and on most pages but that may need to wait for the new website to go live. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "kd" <kdfake@spam.com> wrote in message news:43c9a63a$0$62585$ec3e2dad@news.usenetmonster.com... > Whats the direct link to this info? > I cannot find it on your site! > -- > ---------------------------------------------- > Posted with NewsLeecher v3.5 Beta 2 > * Binary Usenet Leeching Made Easy > * http://www.newsleecher.com/?usenet > ---------------------------------------------- >Article: 94635
I'm interested in these kits Eric. What else other than the board would you recomend I get? Does this board come with things like a VGA core? I read on some dev board descriptions that they came with a few modules ready to use. Are the WebPack tools good enough? I love the 96 uncomitted I/O on the dev-board. This will allow the Altair's switches and LEDs to be connected without a bunch of logic other than buffers. :) I've got some crazy ideas for a "serial port" inside the FPGA that emulates a terminal with the VGA and PS2 port, but I'm not sure how practical that is yet. ;) Also on a completely different project, I need some advice. I'm building a 176wX110h pixel display using LEDs. I'm almost half way through soldering! ;) I plan on it being a memory mapped display for the Altair. I bought a bunch of LEDs surplus a while back and have to use them. Plus, the Altair is all about blinking lights...but I don't know of an Altair with 17,000+ blinking LEDs. :) 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? An evolution of the project will be character generation ability (I organized the display as 22x10 characters of 8x11 pixels) This looks like a good board for the project: http://www.digilentinc.com/Products/Detail.cfm?Prod=D2FT&Nav1=Products&Nav2=Programmable Any suggestions on either crazy project would be great to have. :)Article: 94636
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.K tRAS is defined as 'ACTIVE to PRECHARGE command' in a typical Micron datasheet (http://download.micron.com/pdf/datasheets/dram/sdram/512MbSDRAM.pdf) As a row can maintain itself only so long before being refreshed (the purpose of precharge being part of the refresh system), it can only be accessed without a precharge for some maxima. If you exceed that maxima, you will not change the row, you will simply get invalid data. Bottom line is - meet the tRAS spec. Note that the datasheet I mention above has full simulation models freely available at the Micron website: http://www.micron.com/products/dram/sdram/part.aspx?part=MT48LC64M8A2P-75 Verilog, VHDL, IBIS, HSPICE, Denali and Synopsis are all available. Cheers PeteSArticle: 94637
Well, I guess I would be one of those "rebirth" hobbyists. I am younger and just "discovered" the fpga. I was under the impression that things like this were very expensive, but when I see starter kits for $150, I had to snatch one up and try it out. For the last 5 months I have been feverishly programming and learning with Webpack 7.1 implimenting different ideas on codecs, processor cores, and so on. Now I that I have a handle on whats available and possible on most platforms I bought my first dev board a couple of days ago. I can't wait for sun to open up there sparc cores. So many ideas so little time!! I can't believe I went through my undergraduate education without trying fpga's out, and my focus on RF and optics was not very close to VLSI or control. After 5 months though there are a ton of optics processing problems that can be sped up with fpgas. Like I said, can't wait to start debugging!! So much to do, so little time... new HobbyistArticle: 94638
You don't need the DISPLAY :0 for ise project navigator and impact but you still need it for almost all the other progz (PACE, FPGA editor, FloorPlanner etc). MehdiArticle: 94639
"Hahnsolo" <coreyhahn@gmail.com> schrieb im Newsbeitrag news:1137338637.940229.315040@g49g2000cwa.googlegroups.com... > Well, I guess I would be one of those "rebirth" hobbyists. I am > younger and just "discovered" the fpga. I was under the impression > that things like this were very expensive, but when I see starter kits > for $150, I had to snatch one up and try it out. For the last 5 months > I have been feverishly programming and learning with Webpack 7.1 > implimenting different ideas on codecs, processor cores, and so on. > Now I that I have a handle on whats available and possible on most > platforms I bought my first dev board a couple of days ago. I can't > wait for sun to open up there sparc cores. So many ideas so little > time!! > > I can't believe I went through my undergraduate education without > trying fpga's out, and my focus on RF and optics was not very close to > VLSI or control. After 5 months though there are a ton of optics > processing problems that can be sped up with fpgas. Like I said, can't > wait to start debugging!! > > So much to do, so little time... > new Hobbyist > no need to wait for sun commercial quality SPARC core and system on chip library is available now http://www.gaisler.com you need XC3S400 or larger (better larger) to implement a SPARC based system -- Antti Lukats http://www.xilant.comArticle: 94640
Tobias Weingartner schrieb: > No, I'm not talking which pins to toggle how fast and when, but is > there any 600K+ gate (roughly) FPGA available which also gives the > layout and programming information for their bitstreams/etc? Xilinx has JBits. It does not give you the bitstream information but it allows you to quickly modify details of a bitstream on the fly. Think of it as controlling the FPGA editor by a Java programm. Kolja SulimmaArticle: 94641
> > Hmm, really? ;-) As far as I know the only "pure" hobbyists > here are Antti and myself, the rest is more or less professional. > There are many of us here who started out as pure hobbyists, but then grew our passion into a paying endeavor. I started out in the mid '70's first with dissected radios, tape recorders etc, whatever I could get my hands on, with radio shack kits (many of which I heavily modified...one that comes to mind was a regulated power supply where the 2N3055 got hot enough to melt through the red plastic board/box that soon got a heatsink and a darlington pair for more output current and a switch to select output voltages). From there, I started getting into logic. Between a 1976 Signetics IC databook (which is still on my bookshelf) and several of Lancaster's cookbooks (some of his circuits would never get past a critical review, but they were great for learning) I taught myself digital design. Even built a couple of computers based on the then brand new 6800 (on an Ohio Scientific board), and then the Z-80 scratch built on wire-wrap boards before graduating from high school in 1979. Like Philip said, I had a mentor (a friend of the family who is an EE and was consulting mostly in audio and telephony back in the 60's and 70's) that gave me much of the motivation to make and improve on the projects in Radio Electronics (which I was subscribed to from 1971 to 1982, I dumped the entire collection when it caused me to exceed my weight allowance in a move with the Air Force, Killed me, but I couldn't even give them away).Article: 94642
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. PhilArticle: 94643
Nostalgia... I built radios in high-school days, and was a ham operator during college years. Later, in Sweden, I designed and built power supplies and sold a hundred of them as a moonlight operation. Then the usual audio amplifiers and speaker boxes. Now the interest is rekindled and I play with the design of my second-generation programmable clock module (1 Hz to 2.5 GHz with, hopefully, 30 ps jitter). But this also taught me that, for top-notch performance, you need the help of several friends and experts (software design, pc-board lay-out, GHz trickery, test instrumentation) and of a commercial manufacturer. We built a few hundred of the first generation "X-Pod", and are using them inside the company on many test benches. So it's more "skunk works" than hobby activity, but still the same fun. I have toyed with the idea of a storage scope. The digital part in an FPGA plus external RAM looks easy. But less than 500 MHz sample rate seems to make it a toy, and at that rate the A/D becomes quite expensive, and an input attenuator looks forbidding, But there are neat examples of using the PC for display and control. Peter Alfke, from home.Article: 94644
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: 94645
OK, well, I think I have my addressing fixed, and the code below
is for a 9 bit ROM, which is what I originally wanted. It seems to
generate acceptable output, at least for small numbers. I am using
the new ISE 8.i simulator. I will test it with larger values later.
Thanks Ray and Sylvain for taking the time to pick out my mistake.
I should have known.
A number of new questions arise:
1) Is the code around the "begin" keyword, which maps the inputs
to the primitive RAMB16 (BRAM or Block RAM) acceptable or
is there a more concise/better method?
2) I initially went to the V4 library guide and found this primitive.
I did not see there the RAMB_Sx_Sy primitives of Spartan yore,
which lead me to believe that they are abandoned in Virtex-4.
The Xilinx Virtex-4 User Guide ( ug070.pdf ) page 133 would
lead one to believe that they are available. What is the story here?
3) Generally, I would like to transport my future designs between
Spartan3s and Virtex-4 effortlessly. Are their any tips, ap notes,
or other information out there on how to do this?
4) The INIT_xx => sytax is clumsy. Especially if I choose
to use the ninth bit. What alternatives do I have?
5) I have been searching Google for code examples with the words
RAMB16 and std_logic. Is there any primitive or keyword
specific to Virtex-4 that would further refine my search?
6) I did not see the INIT value on the ISE 8.1 simulation which
I expect to see at time 0. Is this a glitch in the 8.1 simulator?
Regards,
Brad Smallridge
aivision dot com
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity bram9p is
port (
clkb : IN std_logic;
enb : IN std_logic;
ssrb : IN std_logic;
regceb : IN std_logic;
addrb : IN std_logic_VECTOR(11 downto 0);
web : IN std_logic;
doutb : OUT std_logic_VECTOR( 8 downto 0) );
end bram9p;
architecture Behavioral of bram9p is
signal addrb15 : std_logic_vector(14 downto 0);
signal dob32 : std_logic_vector(31 downto 0);
signal dopb4 : std_logic_vector( 3 downto 0);
signal web4 : std_logic_vector( 3 downto 0);
begin
addrb15(14 downto 3) <= addrb;
addrb15( 2 downto 0) <= "000";
doutb(7 downto 0) <= dob32(7 downto 0);
doutb(8) <= dopb4(0);
-- Update all web bits,
-- otherwise only some addresses will be written.
web4(0) <= web;
web4(1) <= web;
web4(2) <= web;
web4(3) <= web;
-- RAMB16: Virtex-4 16k+2k Parity Paramatizable BlockRAM
-- Xilinx HDL Language Template version 8.1i
RAMB16_inst : RAMB16
generic map (
DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
DOB_REG => 0, -- Optional output registers on the B port (0 or 1)
INIT_A => X"000000000", -- Initial values on A output port
INIT_B => X"000000001", -- Initial values on B output port
INVERT_CLK_DOA_REG => FALSE, -- TRUE or FALSE
INVERT_CLK_DOB_REG => FALSE, -- TRUE or FALSE
RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
READ_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36
SIM_COLLISION_CHECK => "NONE", --
"ALL","WARNING_ONLY","GENERATE_X_ONLY,"NONE
SRVAL_A => X"000000000", -- Port A ouput value upon SSR assertion
SRVAL_B => X"000000002", -- Port B ouput value upon SSR assertion
WRITE_MODE_A => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
WRITE_MODE_B => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
WRITE_WIDTH_A => 9, -- 1,2,4,9,18 or 36
WRITE_WIDTH_B => 9, -- 1,2,4,9,18 or 36
-- The following INIT_xx declarations specify the initial contents of
the RAM
INIT_00 =>
X"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A09080706050403020100",
INIT_01 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_02 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_05 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_06 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_09 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_10 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_11 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_12 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_13 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_14 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_15 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_16 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_17 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_18 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_19 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_20 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_21 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_22 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_23 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_24 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_25 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_26 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_27 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_28 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_29 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_30 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_31 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_32 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_33 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_34 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_35 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_36 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_37 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_38 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_39 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
-- The next set of INITP_xx are for the parity bits
INITP_00 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_01 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_02 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_03 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_04 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_05 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_06 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_07 =>
X"0000000000000000000000000000000000000000000000000000000000000000")
port map (
CASCADEOUTA => open, -- 1-bit cascade output
CASCADEOUTB => open, -- 1-bit cascade output
DOA => open, -- 32-bit A port Data Output
DOB => dob32, -- 32-bit B port Data Output
DOPA => open, -- 4-bit A port Parity Output
DOPB => dopb4, -- 4-bit B port Parity Output
ADDRA => (others=>'0'), -- 15-bit A port Address Input
ADDRB => addrb15, -- 15-bit B port Address Input
CASCADEINA => '0', -- 1-bit cascade A input
CASCADEINB => '0', -- 1-bit cascade B input
CLKA => '0', -- Port A Clock
CLKB => clkb, -- Port B Clock
DIA => (others=>'0'), -- 32-bit A port Data Input
DIB => (others=>'0'), -- 32-bit B port Data Input
DIPA => (others=>'0'), -- 4-bit A port parity Input
DIPB => (others=>'0'), -- 4-bit B port parity Input
ENA => '0', -- 1-bit A port Enable Input
ENB => enb, -- 1-bit B port Enable Input
REGCEA => '0', -- 1-bit A port register enable
input
REGCEB => regceb, -- 1-bit B port register enable
input
SSRA => '0', -- 1-bit A port Synchronous
Set/Reset Input
SSRB => ssrb, -- 1-bit B port Synchronous
Set/Reset Input
WEA => "0000", -- 4-bit A port Write Enable
Input
WEB => web4 ); -- 4-bit B port Write Enable
Input
end Behavioral;
Article: 94646Hi Clark, Anonymous wrote: > That's interesting. So if I have an FX12 part, for example, your suggestion > is that I run uclinux in a soft core and implement my DSP code in the PPC > core? This is the opposite of what I had expected. As Antti says, you could invert your expectation and do the Linux on MicroBlaze, and an ultra-controller type design on the PPC. Or better still, nothing beats FPGA logic for DSP performance. Why not do your DSP in hardware, make use of those lovely programmable gates, and do the control/interface logic in SW on a MicroBlaze. V4-LX parts are (will be?) cheaper than FX, for equivalent gate counts. The PPC does not come for free. > What do I give up for ucLinux versus PPC Linux? Speed? Device driver > support? MicroBlaze uClinux is slower than PPC Linux, but as the MicroBlaze bus and memory architecture evolves, we are catching up. > Also, what's your suggestion for unit control? I imagined a webserver interfaced to some type of CGI. Maybe perl scripts or php? Sure, the default mb-uclinux bulid has a webserver in it, adding CGI apps is simple. Someone's ported PHP to uClinux before, but it might be overkill. I haven't tried Perl, but I did port a recent Python interpreter to mb-uclinux - performance was pretty ordinary. Better off in C, I think. Feel free to contact me in "commercial mode" to discuss in more detail - john.williams@petalogix.com Regards, JohnArticle: 94647
Peter Alfke wrote: > Nostalgia... > I built radios in high-school days, and was a ham operator during > college years. Later, in Sweden, I designed and built power supplies > and sold a hundred of them as a moonlight operation. Then the usual > audio amplifiers and speaker boxes. > Now the interest is rekindled and I play with the design of my > second-generation programmable clock module (1 Hz to 2.5 GHz with, > hopefully, 30 ps jitter). Digits of precision & granularity ? But this also taught me that, for top-notch > performance, you need the help of several friends and experts (software > design, pc-board lay-out, GHz trickery, test instrumentation) and of a > commercial manufacturer. A tad outside the average hobbiest resource pool ? We built a few hundred of the first generation > "X-Pod", and are using them inside the company on many test benches. So > it's more "skunk works" than hobby activity, but still the same fun. > I have toyed with the idea of a storage scope. The digital part in an > FPGA plus external RAM looks easy. But less than 500 MHz sample rate > seems to make it a toy, and at that rate the A/D becomes quite > expensive, and an input attenuator looks forbidding, But there are neat > examples of using the PC for display and control. Yes, scopes are dominated by things other than the FPGA, so are not ideal demo-examples. My favourites would be for Xilinx to do a split a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version b) Freq Ctr & Signal Generator - Money-no-object version 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 -jgArticle: 94648
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. 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. > > 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. 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. PeterArticle: 94649
dp wrote: > you name it) plan to ruin the European electronics industry (which is > not Ahem.. Europe's a major market - it's more than European companies that are affected :) Jeremy
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