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
First off, I think it's better to instantiate BRAM than inferring it. When you go to the restaurant and you want veal, you should say it, don't describe the veal to the waiter :) The other issue is that your FFs are read from and written to in the same clock. I vaguely remember reading and writing to the same BRAM address is a bad idea. bijoy wrote: > Hi > > I have read that, it says we should not use asynchronous reset > > The program what i have written is also taken from there and they say it will be mapped to BRAMs > > I am observing in my p&r report that it is getting mapped to BRAM but the slice count is not getting reduced. > > regds bijoyArticle: 92976
Anything that is divulged in a public forum can constitute "prior art". I have been part of a counter-legal action related to postings I have made. So keep posting away if you want to be "prior art" and hope that the "truth" will come through at some point. RAUL Not An AttorneyArticle: 92977
Thanks Hans, I will try this out.Article: 92978
On Fri, 09 Dec 2005 16:42:18 GMT, "Roger" <enquiries@rwconcepts.co.uk> wrote: >I need to buy a license for ISE Foundation to support some VIIPro work I'm >doing. Would it make any difference to the price if I went via a distributor >here in the UK or just bought online via the Xilinx web site? Anyone have >any comments? Won't make a whole lot of difference in price; the distributor would handle VAT if appropriate, versus the shipper. I'm all in favour of supporting the local guy. But getting a UK distributor to respond to a phone call in less than a week can be a challenge. If you manage that, and they quote you a lead time for Foundation in excess of six weeks, why not just go ahead and order online? The worst that will happen is a phone call from the shipper, asking for VAT/import + £30 handling fee before they can release the goods. - BrianArticle: 92979
Sudhir.Singh@email.com wrote: > Thanks for the reply. > Yeah I am giving the FSM a clean sycnhronous reset and the inputs are > all sychronous. I'll test for the FSM going into illegal state. > > Sudhir You could also use Chipscope Pro to monitor the signals on chip. That may help you see what's going wrong. You can get free evaluation version on the Xilinx web siteArticle: 92980
Sylvain Munaut wrote: > And here I was more referring to the drive strenght than the number of > input nets. For example if you have to generate a clock ena > combinatorially (just a single LUT level but still) and it controls like > 50 FFs, the net take like 1.5 ns propagation ... half of my period ... > I don't know if your initial idea is feasible or not, but it sounds good to me. In the meantime, you can reduce the fanout (at cost) by using logic duplication. If you duplicate the signal and drive only half the flip flops, that should improve your timing (at the increased cost in terms of area). You can do that in one of two ways: 1. Manually (in your code) create two signals, and set options so that your synthesis tool does not optimize redundant logic 2. Turn on logic duplication,and hope the synthesis tool will recognize that the critical path can be improved by duplicating that piece of logic FredArticle: 92981
Thomas Entner wrote: > Hi Peter, > > your reply made me think... I assumed that with gray-codes I am safe for > mismatches from one count to the next, but not if the skew between the bits > is more than one complete cycle, because than two bits might be wrong > instead of only one. Now I made a gray-code-table on a sheet of paper and I > found no situation where even this would be "catastrophic", because even > then the count is only of by 1 or 2. (But I think, it can lead to wrong or > "jumping" level-indication, even when the effects in the final application > are most likely of no concern.) > > However, still a controlled delay between this register stages would give me > a better feeling, as otherwise you never can know how long the delay of the > fill-level-indicator is. Yes, that is a hidden danger with passing more than one bit across a clock domain. The propagation paths across the domain do have to be constrained to ensure the skew between them does not come even close to a full clock period of the faster clock domain.Article: 92982
Sylvain Munaut schrieb: > So what if every now and then in the FPGA fabric, there was a small > cluster of like 1 CLB with "Super LUTs" that would have a whole lot > faster logic (but no special func like SRL and distributed ram) and > "bigger" drivers to charge/dischare the net faster to propagate the > controls. Well, there are couple of 14-Input LUTs in their newer devices. The speed is about 2ns in Virtex-4. They call them BRAMs. Kolja SulimmaArticle: 92983
I realize this is a basic question, but I couldn't find a simple answer on the Xilinx site. What is the difference between Foundation, Base X, and Webpack? Does more $$$ mean more applications are included, or does more $$$ mean better applications are included? Thanks! StephenArticle: 92984
Sudhir.Singh@email.com wrote: However when I run the design on > actual FPGA the registers are not updated and design doesn't behave > correctly. Did you check that ALL you inputs to the FSM (including indeed the Clock Enable !) are properly re-synchronized ? This is probably the most common design error. I see it everyday. Hope this helps, BertArticle: 92985
Without trying to sound defensive: That's exactly what I implied by writing "In other words, you don't have to be super-fast, as long as you meet the required (synchronous) timing constraints, determined by the clock rates." Sloppiness that exceeds a clock period will of course always get you in trouble... Peter Alfke, from homeArticle: 92986
And one of those dual-ported BRAMs can be either two identical, but independently addressable, 14-input LUTs, or two completely different, independent 13-input LUTs. Naturally... Peter AlfkeArticle: 92987
I have experience in both PCB Designing , Digital Designing(FPGA based designing).I am also there to do that challenge ... in short time , more relavent to requirements and more cheeper as well ... :)Article: 92988
Hi
We are trying to interface a 16MB MMC(of Infineon) to Spartan-2
FPGA ...
We have designed reader for card(in VHDL) abopting MMC protocol(not
SPI) and this card is supports 2.7 to 3.0 standard ...
Before designing its writer i want to test reader ...
and before that i want your suggestions ... :)
So please share your experience and guide me ...
Thanks
Article: 92989"fahadislam2002" <fahadislam2002@hotmail-dot-com.no-spam.invalid> schrieb im Newsbeitrag news:kdqdnV-4CqYi4AbeRVn_vA@giganews.com... > Hi > We are trying to interface a 16MB MMC(of Infineon) to Spartan-2 > FPGA ... > We have designed reader for card(in VHDL) abopting MMC protocol(not > SPI) and this card is supports 2.7 to 3.0 standard ... > Before designing its writer i want to test reader ... > and before that i want your suggestions ... :) > > So please share your experience and guide me ... > > Thanks > so whats your problem ?? why are "trying" and not "DOING" ?? I have published an project at opencores that can configure an FPGA from MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!) at http://gforge.openchip.org there is snapshot from mmc host controller ip core from LARK project - notice that ipcore is 100% non-tested and www.xilant.com has MMC/SD cardside ipcore that could be used for testing (not announced yet) for initial testing you can just make an Microblaze SoC in the S-2 and use bitbang to read the MMC so it would be easy to debug and see the response, I think I published once that software but dont recall where and if it is still on the web, in any case it isnt complex so go ahead and test you mmc interface, until you do that, you would not know if it works or not AnttiArticle: 92990
Generally the major difference is in the devices supported by the tool. Foundation supports all current devices. BaseX a smaller set and Webpack smaller again. Webpack has also got some of the power user tools like FPGA Editor removed. Comparision here http://www.xilinx.com/ise/devsys_feature_guide.pdf . John Adair Enterpoint Ltd. - Home of Raggedstone1. The Very Low Cost Spartan-3 Development Board. http://www.enterpoint.co.uk "Stephen Craven" <scraven@vt.edu> wrote in message news:1134255059.938545.255950@g49g2000cwa.googlegroups.com... >I realize this is a basic question, but I couldn't find a simple answer > on the Xilinx site. > > What is the difference between Foundation, Base X, and Webpack? > > Does more $$$ mean more applications are included, or does more $$$ > mean better applications are included? > > Thanks! > Stephen >Article: 92991
I would like to build an universal measurement device, composed of
a frequency meter and a bus protocol analyser (among other things).
It will be based on a Spartan 3 chip, i.e. XC3S200-4TQ144C, which
is the largest S3 device I can buy in very small quantities without problems
(with Cyclone 2 the situation is much worse... :-( ). I have never used
Xilinx parts before, so could you please answer the following, perhaps
trivial, questions?
1. What is the highest frequency I can measure using that part
a) without any tricks;
b) with some tricks -- I know that Peter Alfke has implemented
a freqency meter capable of 450MHz on an S2(?). :-)
2. Is it possible to obtain some information about the bitstream format
of that particular chip? The device should support all the IO modes that
Spartans support, which implies about 30 different configuration files...
However, I believe that the only thing that needs different configuration
settings is the IOB subsystem, since the rest of the device remains
unchanged.
So I would like to dynamically patch the bitstream by an on-board
microcontroller, which will generate an appropriate stream from a single
configuration file template. But where is the IO configuration part of the
stream and how is it encoded? Note: I don't want any warranties etc.
from Xilinx and I know that the format could be changed in the future,
but I am only interested in the format of the chip I hold in my hand.
Best regards
Piotr Wyderski
Article: 92992"Hans" <hans64@ht-lab.com> schrieb im Newsbeitrag news:PtSlf.6121$E14.3906@newsfe7-win.ntli.net... > Hi Antti, > > I am happy to see you managed to get it up and running although using the > serial port might have been easier than using chipscope. I will add an > 8254 and 8259 (required for a minimum system) as soon as my workload > reduces a bit (probably around Christmas) If only I had some more "spare" > time...... :-) > > Regards, > Hans. > www.ht-lab.com > Hi Hans, it wasnt so complex, but for those who would like to speed test drive it I just uploaded the ISE Virtex4 project I used in testing, its basically just the files from your website with minor fixes to get it working in Virtex4 http://xilant.com/content/view/20/55/ there is the IP-Core "Review" and link to the project archive AnttiArticle: 92993
"Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl> schrieb im Newsbeitrag news:dnh17b$v6k$1@news.dialog.net.pl... >I would like to build an universal measurement device, composed of > a frequency meter and a bus protocol analyser (among other things). > It will be based on a Spartan 3 chip, i.e. XC3S200-4TQ144C, which > is the largest S3 device I can buy in very small quantities without > problems > (with Cyclone 2 the situation is much worse... :-( ). I have never used > Xilinx parts before, so could you please answer the following, perhaps > trivial, questions? > > 1. What is the highest frequency I can measure using that part > a) without any tricks; > b) with some tricks -- I know that Peter Alfke has implemented > a freqency meter capable of 450MHz on an S2(?). :-) > > 2. Is it possible to obtain some information about the bitstream format > of that particular chip? The device should support all the IO modes that > Spartans support, which implies about 30 different configuration files... > However, I believe that the only thing that needs different configuration > settings is the IOB subsystem, since the rest of the device remains > unchanged. > So I would like to dynamically patch the bitstream by an on-board > microcontroller, which will generate an appropriate stream from a single > configuration file template. But where is the IO configuration part of the > stream and how is it encoded? Note: I don't want any warranties etc. > from Xilinx and I know that the format could be changed in the future, > but I am only interested in the format of the chip I hold in my hand. > > Best regards > Piotr Wyderski > http://gforge.openchip.org/projects/fpgafreqmeter/ there is frequency meter that can be implemented in just any FPGA we have some real world measurement results (no tricks) Spartan3 -4 speedgrade: 420MHz (that was the highest clock I was able to feed into..) Virtex4: 970 MHz if you want to "patch" the bitstream, well we have an bit2frames application that can be used to compare the bits and query the locations, and we had planned an bitpatch what could in turn to be used to post patch the biststreams just for the purpose you mentioned, please contact in private if you are interested in this AnttiArticle: 92994
"Antti Lukats" <antti@openchip.org> wrote in message news:dngni1$olv$1@online.de... > I have published an project at opencores that can configure an FPGA from > MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!) Ah, the Verilog one. Very useful project. I hope to get it booting my own project. > http://gforge.openchip.org > there is snapshot from MMC host controller IP core from LARK project - > notice that ipcore is 100% non-tested Very nice, I've just downloaded that! I've got ideas for using that too. Looks like it is for a 32-bit wide data bus, I'd like to mod it for humble 8-bitters. #> and www.xilant.com > has MMC/SD cardside ipcore that could be used for testing (not announced > yet) I look forward to it. I hear SD is a superset of MMC. SD details are harder to come by without NDA or licences, but presumably if you don't use the 'secure' features then it will just look like an MMC card with 4-bit wide data bus? Cheers, K.Article: 92995
"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag news:WuXmf.5709$XZ6.534@newsfe1-gui.ntli.net... > "Antti Lukats" <antti@openchip.org> wrote in message > news:dngni1$olv$1@online.de... >> I have published an project at opencores that can configure an FPGA from >> MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!) > > Ah, the Verilog one. Very useful project. > I hope to get it booting my own project. > this is one really works ! >> http://gforge.openchip.org >> there is snapshot from MMC host controller IP core from LARK project - >> notice that ipcore is 100% non-tested > > Very nice, I've just downloaded that! > I think there is small bug in CRC7 and maybe something else as said its presented in the way I got it, and its completly untested > I've got ideas for using that too. > Looks like it is for a 32-bit wide data bus, I'd like to mod it for humble > 8-bitters. > go ahead :) > #> and www.xilant.com >> has MMC/SD cardside ipcore that could be used for testing (not announced >> yet) > > I look forward to it. > :) me too > I hear SD is a superset of MMC. > somewhat > SD details are harder to come by without NDA or licences, but presumably > if you don't use the 'secure' features then it will just look like an MMC > card with 4-bit wide data bus? > > Cheers, K. > no exactly SD and MMC have the same mmc like communication protocol what by default is 1 bit SD has somewhat different command set meaning that some commands that are present in MMC are not there in SD like streaming read is only in MMC not in SD also the initialization is different both MMC and SD can turn on 4 bit mode additionally MMC (standard 4.1) can also support 8 bit mode and turbo clock up to 52MHz ! AnttiArticle: 92996
"Antti Lukats" <antti@openchip.org> wrote in message news:dnhgmj$q4f$01$1@news.t-online.com... >>> http://gforge.openchip.org > I think there is small bug in CRC7 and maybe something else > as said its presented in the way I got it, and its completely untested > >> I hear SD is a superset of MMC. >> > SD has somewhat different command set meaning that some commands that are > present > in MMC are not there in SD like streaming read is only in MMC not in SD > also the initialization is different Sigh. SD cards seem to be the best thing to buy for most consumer electronics, they seem to be replacing MMC cards. Better data bus width etc. Any recommendations for documentation describing MMC, SD, and their differences. I have Googled, and got swamped with loads of links to places selling such cards. The few techy links were fairly useless, along the lines of "you can buy the full spec from...." > both MMC and SD can turn on 4 bit mode http://www.howell1964.freeserve.co.uk/parts/sd_mm.htm indicates MMC has only 7 pins, and only one of these for data. > additionally MMC (standard 4.1) can also support 8 bit mode and turbo > clock up to 52MHz ! Wow. I thought most of the 'new features' work would be done on SD cards. The Mini-format is just a repackaging.Article: 92997
According to this page, ISE Webpack does not support the Core Generator. http://www.xilinx.com/ise/products/webpack_config.htm Maybe they'll change their policy with 8.1. It would be nice if they had an informative error message about this. It's funny how some of the IP works by just installing the updates. Brian dean.dunnigan@gmail.com wrote: > Hi Fred: > > I am also getting the same error. Interestingly enough, I am using the > same version of ISE, same IP update, and same version of Windows XP. > I've also tried Dual Port Block Mem versions 6.1 and 6.2 in the CoreGen > tool and get the same error. In my application, I am targetting a > VirtexII. > > I'm not aware of any work-arounds but also hoping someone can jump in > and provide suggestions! > > > Dean.Article: 92998
Peter Alfke wrote: > And one of those dual-ported BRAMs can be either > two identical, but independently addressable, 14-input LUTs, > or two completely different, independent 13-input LUTs. An important "Danger Will Robinson" observation on using BRAMS: If you violate setup/hold on the address inputs of an enabled BRAM, EVEN IF WE IS INACTIVE, BRAM contents can (will) be corrupted. This means: - No multicycles (unless you use EN). - No async inputs. - TIMING CONSTRAINTS ARE A NECCESSITY!!! IF BRAM TIMING CONSTRAINTS ARE NOT SET PROPERLY, AND MET, BRAM CONTENTS WILL BE CORRUPTED!!! See Answer Record 21870 "Virtex-II/-II Pro/-4 block RAM - Do the setup/hold times for the Address inputs need to be met, even if the output is unused and WE is deasserted?" BrianArticle: 92999
Brian, I think you overdramatize this. (I was involved in finding and explaining this behavior a few weeks ago). Anybody who writes into the BRAM must of course abide by the address set-up time requirement. Anybody who reads from the BRAM must also abide by the address set-up time requirement. The surprising, non-obvious requirement is that, if the BRAM is enabled, a violation of the address set-up time can corrupt data, even though WE remained disabled. So, do NOT change the address right before the enabled active clock edge. You would obviously not do this when you are writing, and you wouldn't do it when you are reading, but you must also not do it when you have the BRAM clock-enabled and read-enabled and you really do not care about the result of the uncontrolled read operation. The easy way out of it is to disable the clock, not just WE. Thisis a highly unusual (but explainable) restriction, so unusual that neither Xilinx nor any customer found it for many years. Peter Alfke, Xilinx Applications
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