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
Peter Alfke wrote: > > Brian, I think you overdramatize this. > Hardly- it should be mentioned front and center in the BRAM sections of the datasheet and user guides; in bold print; with circles and arrows and a paragraph on the back explaining the problem. Adopting the same head-in-the-sand, "it's in an Answer Record somewhere", mentality that, of recent years, has pervaded Xilinx's approach to documenting serious problems, does not help your customers one whit. > > 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 thread in question was about using BRAMS as logic. Who would expect a ROM to clobber its' own contents due to an address setup violation? BrianArticle: 93001
On 11 Dec 2005 16:31:33 -0800, "Peter Alfke" <alfke@sbcglobal.net> wrote: >Brian, I think you overdramatize this. I have to agree with Brian. This is a big deal. I expected that violating read address setup time would screw up the read result that cycle; I was amazed to find out that violating address timing could actually change the contents of the RAM. I imagine that anyone using the BRAM as a ROM, with WE arc-welded to ground, would be doubly surprised. I have a design in which different buses supply the read and write addresses to a large number of BRAMs. The write address is synchronized; the read address isn't, because I saw no reason to, at least until I saw Answer Record 21870 (which I saw only by accident, thanks to a tip from another designer). Even then, it took about a week and a half working with the Hotline and an FAE before I found out what the Answer Record actually meant, the original version having been more vague than the current one. So I've got a design that I have to redo. The "easy way out of the problem" is easy only if you know there's a problem in the first place. I heard from the Hotline that the data sheets for the affected families would be amended. If amended data sheets haven't been released already, I hope they will be soon. I guess the thing that bothers me the most is that once the problem was identified, no one at Xilinx seemed to know that when RAMs don't work like RAMs, it's potentially a Big Damn Deal for at least some designers, and deserving of something more than to be hidden away in an Answer Record that you might or might not see. Bob Perlman Cambrian Design WorksArticle: 93002
Brian Davis wrote: Peter Alfke wrote: <snip> >>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 thread in question was about using BRAMS as logic. > > Who would expect a ROM to clobber its' own contents due to an > address setup violation? Valid point. Reminds me of an oops Philips made in their UARTS, which was a Test mode kicked into by READ [?!] of a certain address. So, yes, without care on the selection lines, this could go out-to-lunch. Took them a while to admit to it..... Another issue here, is if this IS loaded/used as a ROM, what happens during brownout, where it is quite possible that timing MAY be violated. Sounds like there could be a lot of ?? space between the 'Let's Reconfigure' decision point, and the 'Inside Specs' operate point ? -jgArticle: 93003
Jim wrote: > Another issue here, is if this IS loaded/used as a ROM, > what happens during brownout, where it is quite possible that timing MAY > be violated. Or if the BlockROM clock is sourced by a DCM which goes unlocked, thus rendering all BlockROM contents unreliable until the device has been reconfigured. Oops. Better not use that XST BRAM_MAP logic-into-BRAM mapping option any time soon... BrianArticle: 93004
Hello Sudhir, I too had this same problem. I followed the info from the Xilinx support site to help me get over this problem. http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=19578 Answers Database 6.2i ChipScope Pro - XCF00P/Platform Flash in chain gives 0 core units found by ChipScope Analyzer Answer Record: 19578 Family: Software Product Line: FPGA Implementation Part: ChipScope Pro Version: 6.2i Last Modified: 11/23/04 11:15:27 Status: Active Rate This Answer Very Useful Useful Not Useful Click to submit Email this page Email this page Send us feedback Feedback Print Print Version Problem Description: Keywords: xcf32p, analyzer, PROM, core, unit, found Urgency: Standard General Description: If a XCF08/16/32P is in a JTAG chain, ChipScope cannot initialize the chain as it has no idea of what the instruction register length is. It will try to recognize the device as a XC18V00, but the instruction register is too small (8 bits). The parallel Platform Flash devices are 16 bits. Solution 1: To work around this issue, edit the "%XILINX%\ChipScope_Pro_6_2i\data\deviceid.lst" and add the following 2 lines: C,505,93=XCF00P XCF00P=10 However I did have to change the IR Length field in the "JTAG Chain device order dialog box" to 16 for my Virtex2Pro part to get it working. Good luck. Anup Sudhir.Singh@email.com wrote: > Hi All, > I just got myself an evaluation license for ChipScope Pro 6.2. I used > the Core Inserter tool to insert the ICON and ILA cores into my design. > The first time I used the Pro Analyser to load the configuration file > it all went ok. However, I tried to load the same configuration file > the next day and now Analyser gives me the following messsage: > > COMMAND: configure 1 "C:\my_design_cs.bit" 0 > INFO: Found 0 Core Units in the JTAG device Chain > > The configuration file hasn't been changed. > I have tried multiple times but no luck. > Has anybody else had the same problem? Is this some sort of limitation > put on ChipScope evaluation version? > > Thanks in advance > Sudhir >Article: 93005
I am reading back bitstreams from PROMs (5 xc18v04 and 1 xc18v02 in a chain) since I lost the original copy (mixed up with other bitstreams). How do I verify the readback copy is correct? I only have one board and the good bitstream is already saved in PROMs. Reprogramimg them back into the same board is risking losing them.Article: 93006
We have a very good and expensive design that we want to give freely, as an NGC file, with our generic FPGA products. How can we make the design work only on our board. Our current technology is S3 and the user needs to be able to compile their project with our NGC file, but on OUR fpga product. I thought of keeping a key in an external serial memory, but this is futile if the netlist cost $100K. Again, the points are: Very expensive and useful NGC file Want to avoid reverse engineer and copy to other FPGA stations What should the best solution be. Well if we had some die ID, we could hardwired it to the netlist, so that it checks that everytime it runs. Any suggestion from you ppl? Merry xmas and a happy new year 2006 to all of you! JAArticle: 93007
Bob Perlman wrote: > On 11 Dec 2005 16:31:33 -0800, "Peter Alfke" <alfke@sbcglobal.net> > wrote: > > >>Brian, I think you overdramatize this. > > > I have to agree with Brian. This is a big deal. I expected that > violating read address setup time would screw up the read result that > cycle; I was amazed to find out that violating address timing could > actually change the contents of the RAM. I imagine that anyone using > the BRAM as a ROM, with WE arc-welded to ground, would be doubly > surprised. I'm with Brian and Bob on this. As a designer, we need have limitations like this as well as those with the FIFO16's printed in bold right in the users guides so that it can be avoided by design rather than discovered in the lab. Findng it in the lab is too late in the design cycle. The question is, what other gems like this are hidden away in obscure answer records?Article: 93008
if anyone know and is going to give me a hand, many thanks here!Article: 93009
<lioupayphone@gmail.com> wrote in message news:1134363621.432976.167570@g44g2000cwa.googlegroups.com... > if anyone know and is going to give me a hand, many thanks here! > It's binary format, but you can see the design file name, chip ID and date & time of creation in the first 64 bytes if you open it in winhex editor.Article: 93010
Hi I don't know how to implement a shift register using BRAMs. That is why i tried to use the map property to enable the mapping option. If any one has an idea, could you please share it with me. regards bijoyArticle: 93011
"Frank" <Frank@Frank.com> wrote in message news:dmk525$34f$1@reader01.singnet.com.sg... > > "Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message > news:11oqpeup6ur1k50@corp.supernews.com... > > "Frank" <Francis.invalid@hotmail.com> wrote in message > > news:438d4f5d$1@news.starhub.net.sg... > >> In my digital side, I have a PHY_EN pin which is high when the digital > >> circuit repetitively sends > >> out same data, and the digital circuits work for 30us and idle for 10us. > > On > >> logic analyzer, I set > >> the LA to start filling in the internal memory (256K) once PHY_EN is > >> high, > >> thus I can capture > >> 20 repetitions. I am sure the data capture is correct. > > > > And I am not. this PHY_EN signal, what does it drive on the processor? > > I can imagine that it just signals the processor data is available and > > that > > consequently, the processor issues bus cycles (set an address or CE, > > activate RD, read data, deactivate Rd and CE) to read the data. This means > > that data on the bus during this 30us is not data from the ADC all the > > time. > > Only when the ADC is read during the bus read cycle, valid ADC data is > > readable on the bus. > > > > Meindert > > > > > > Ah! I understand what you mean now. PHY_EN is a stable signal, while my > clock > period is 25ns, in each frame, digital side is sending some 1200 I/Q > samples, > one pair of samples each cycle and unchanged throughout the clock cycle. > > From the datasheet of ADC, I don't see there is any Rd or CD signal, it's as > plain as ADC outputs are hold stable and change every 25ns. > > After all is done, I think I had better flag a "faulty ADC board" message to > the up layer. since even when I disconnect ADC input, many of the pins > mentioned > below still to high level, sampled by a logic analyzer's 400MHz clock. > > Left channel, > bit 7,5 stick to 0, bit 9,4 switches during active, stick to 1 in idle mode, > bit 8,6,3,2 switches during > active, stick to 0 during idle (I expect 9:2 of both channel to behave in > this manner), bit 1:0 are > switching during idle and active (noise during idle mode). > > > Sigh! What should I say!!! After working a number of times, I realized that the god damned LA strobes are broken, and managed to sort out the broken ones with an everchanging pin. With this discovery, I think I will get on much easier.Article: 93012
> A single line with the default, right before the case statement > in DCM_comb, should do it: > > DCM_NextState <= DCM_CurrentState; > > Jan > Hi Jan, You are right. I also thought about that, but somehow I expected it to create latches as well. Strange, since I'm using the defaults-before-case style a lot. Fooled by too much routine possibly :-) But still, ISE created a latch free result before that change. Maybe one could complain about a missing warning. And even after the proposed correction ISE created a smaller and faster result than Precision RTL. (Synopsys dc also created something latchfree but again the FSM extraction failed, so further optimisation wasn't possible) How comes that the simpler(?) tool does the better job? Enlightened, but still wondering :-) EilertArticle: 93013
Why Ngc? And is it necessary to stay on S3? Maybe you should think about Flash based Fpgas (Actel, Lattice,..). bye ThomasArticle: 93014
"Sylvain Munaut" <com.246tNt@tnt> wrote in message
news:439a1f11$0$24466$ba620e4c@news.skynet.be...
> Ray Andraka wrote:
.... (stuff deleted)
> Well, yes optimizing control is good but sometimes very hard ... I've
> basically spent the last few days just doing that to finally meet
> timing. My comparators are not for counters but to detect a "empty"
> condition in a FIFO like block. ('FIFO like' because it's quite more
> complicated than a simple FIFO).
I have the same problem with the high clock to output. I found that when
putting the signal through a delay (SRL16's) I can actually detect zero
condition BEFORE going in, and shift the zero signal with the same delay. In
theory I can detect some bits at each shift, making it very fast. When using
RAMB I can also detect zero condition on any port and reserve a bit for
that.
Article: 93015In some reference design (ppc system on Xilinx ML403 board) I found the following contraints in the UCF file: # GPLED 0-3 NET gpio<0> LOC = G5; #GPLED0 NET gpio<1> LOC = G6; #GPLED1 NET gpio<2> LOC = A11; #GPLED2 NET gpio<3> LOC = A12; #GPLED3 NET "gpio<*>" PULLDOWN; NET "gpio<*>" TIG; NET "gpio<*>" SLEW = SLOW; NET "gpio<*>" DRIVE = 2; These I/Os are connected to LEDs. The I/O standard is not mentionned ... I know that for LEDs that doesn't really matter. But by default which standard will be used? The ML403 contains a xc4vfx12-10ff668 FPGA (Virtex-4 FX12) A+ MehdiArticle: 93016
"GaLaKtIkUsT" <taileb.mehdi@gmail.com> schrieb im Newsbeitrag news:1134378953.648606.127860@g47g2000cwa.googlegroups.com... > In some reference design (ppc system on Xilinx ML403 board) I found the > following contraints in the UCF file: > # GPLED 0-3 > NET gpio<0> LOC = G5; #GPLED0 > NET gpio<1> LOC = G6; #GPLED1 > NET gpio<2> LOC = A11; #GPLED2 > NET gpio<3> LOC = A12; #GPLED3 > NET "gpio<*>" PULLDOWN; > NET "gpio<*>" TIG; > NET "gpio<*>" SLEW = SLOW; > NET "gpio<*>" DRIVE = 2; > > These I/Os are connected to LEDs. > The I/O standard is not mentionned ... I know that for LEDs that > doesn't really matter. But by default which standard will be used? > The ML403 contains a xc4vfx12-10ff668 FPGA (Virtex-4 FX12) > > A+ > Mehdi > just open the pad report file and look it up the defaults are different for different families anttiArticle: 93017
hi, I want to generate simulationlibrarys from edk 6.3 the wizard tells me I have to set the environment variable for modelsim. how do I do this in edk? thank you.Article: 93018
> 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...." > http://www.sdcard.org/sd_memorycard/index.html http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf BTW: will your MMC or SD card interface be open-source? I am interested in the SD card interface, ?but don't find the time to implement it. MartinArticle: 93019
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:439d69c8$0$11610$3b214f66@tunews.univie.ac.at... >> 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...." >> > http://www.sdcard.org/sd_memorycard/index.html > http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf > > BTW: will your MMC or SD card interface be open-source? > I am interested in the SD card interface, ?but don't find > the time to implement it. > > Martin > Hi Martin, your question was to whom? if you want a SD card interface for your JOP, then firstly it can be done 100% in software (I guess you are talking about the host side). the SW version can be painfully slow depending on the CPU and compiler being used and coding style for better speed one combo option could be that CMD line eg all command-response is handled in sw bitbang and only the DAT (eg block read/write) is implemented in hardware this would give very small FPGA core and only have a minor penalty on the speed. for this purpose the LARK mmc vhdl code archive actually contains allmost ready to use block (but I think the crc16 is also wrong there), in any case its not a major issue to design module that can rec-transmit the mmc style commands from-to block ram AnttiArticle: 93020
"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag news:OWXmf.4434$zt1.198@newsfe5-gui.ntli.net... > "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...." > there are enough specs to be find with DEEPgoogling > >> 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. > both mmc and sd have new things MMC has rs-mmc format, also microMMC and the 8 bit mode and turbo speed SD has miniSD and microSD (aga Transflash) OMHO the only card to be used is microSD :) AnttiArticle: 93021
hi,, perhaps I have to refine my question: I am trying to simulate a opb-slave using modelsim, therefore I need to "generate simulation hdl files" in edk. where can I set the environment vars of MODELSIM so that the wizard can do his work? thanks a lot... Christoph Lauer wrote: > hi, > > I want to generate simulationlibrarys from edk 6.3 the wizard tells me I > have to set the environment variable for modelsim. how do I do this in > edk? thank you.Article: 93022
>>> 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...." >>> >> http://www.sdcard.org/sd_memorycard/index.html >> http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf >> >> BTW: will your MMC or SD card interface be open-source? >> I am interested in the SD card interface, ?but don't find >> the time to implement it. >> >> Martin >> > Hi Martin, Hi Antti, > > your question was to whom? Who ever wants to provide it ;-) > > if you want a SD card interface for your JOP, then firstly it can be done 100% in software (I guess you are talking about the host > side). That's the way I (or everybody else) would implement it first. And than when it works one usually 'forgets' to ove it to HW. > > the SW version can be painfully slow depending on the CPU and compiler being used and coding style > > for better speed one combo option could be that CMD line eg all command-response is handled in sw bitbang and only the DAT (eg > block read/write) is implemented in hardware this would give very small FPGA core and only have a minor penalty on the speed. for > this purpose the LARK mmc vhdl code archive actually contains allmost ready to use block (but I think the crc16 is also wrong > there), in any case its not a major issue to design module that can rec-transmit the mmc style commands from-to block ram Yes, a practical idea. MartinArticle: 93023
Thanks a lot Antti. Just forgot about the pad report! It used LVCMOS25. Thanks again! A+ MehdiArticle: 93024
In windows platform go to: -The control pannel=>Performance and Maintenance=>System -On My computer right clic=>properties Go to the advanced tab and choose environment variables. In Linux: add "export MODELSIM=PATH_YOU_WANT" in the /etc/profile file. A+ Mehdi
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