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
On Apr 2, 3:08=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > craig.tay...@xilinx.com wrote: > > In many cases Xilinx will not be > > able to assist you in determining if those suspect devices are > > legitimate or usable. > > Hmmm - so these are no counterfeit at all (in the literal sense) > > but relabeled devices ? - Maybe Xilinx die from Easypath, > or do Xilinx have 'creepage' issues on their test rejects ? > > -jg Jim, this is all idle speculation. At least, Jon was desrcribing his dubious source openly. When it comes to things that you cannot easily evaluate (like FPGAs, microprocessors, food, medicine etc) you do not want to buy them at the flea market. The fact that the parts look like the real thing is incidental. I was wrong in offering help (but nobody in Xilinx has chewed me out for it. We are a friendly company,) but I now realize the mistake). Peter AlfkeArticle: 130826
craig.taylor@xilinx.com wrote: > In many cases Xilinx will not be > able to assist you in determining if those suspect devices are > legitimate or usable. Hmmm - so these are no counterfeit at all (in the literal sense) but relabeled devices ? - Maybe Xilinx die from Easypath, or do Xilinx have 'creepage' issues on their test rejects ? -jgArticle: 130827
Antti wrote: > failing circuit > > ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace > FPGA input > > >>F-F strobed with 50mhz > global clock buffer > 2 bit counter > > > now, this 2 bit counter sees > * double clock from asic in about 1:10M pulses > * missing clock from asic in about 1:100m pulses > > the asic clock is know to be perfect many other devices can receive it > and have 0 error rate (have not seen error ever!) > the 50mhz clock signal quality, well it doesn matter, as whatever > could be wrong, it could not explain the double and missing pulse > counts ? > > using PLL on 4mhz is not an option as it is not free running clock but > byte strobe with 4mhz pulses OK, how long does the data stay available after the strobe? If greater than 20 ns, you can register the 4 MHz clock and then clock the data bits by enabling the register. If the data has to be clocked from the 4 MHz, then you can use the 4 MHz as a clock to the register, and set a bit, too. That bit tells another register to copy the data from the register that is clocked by the 4 MHz clock. So, you crossing the clock boundary at the already latched parallel data, not the clock itself. You can put whatever filtering is needed in to qualify the 4 MHz clock edges, if needed, like reject any clock edge within 40 ns of one that you accepted. JonArticle: 130828
Antti wrote: > after that I did remove some of the logic from FPGA (not related to > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization > from 82 to 54% > > and the error rate dropped > * double strobes: 1:500M > * missing strobes: 0, - not happened yet, still running long term test > Ugh! Analog FPGAs! Something I don't want to hear about!!!! You may want to look at these clocks (both of them) with a fast analog scope or a really good digital one. Even if the 4 MHz clock is extremely clean with great rise/fall times, if the 50 MHz is noisy or has slow edges, you'd hardly know the difference. What I'm trying to say is jitter or double clocking of the 50 MHz clock could foul up the relationship between it and the 4 MHz, although I guess it would have to be truly horrible to do that, and the symptoms would undoubtedly show up somewhere else, too. Is the 50 MHz processed by PLLs? Noisy power could affect the locking of the PLL. Good luck, but I doubt you are going to really nail this without serious scope probing. JonArticle: 130829
On Apr 2, 3:57=A0pm, Jon Elson <el...@wustl.edu> wrote: > Antti wrote: > > after that I did remove some of the logic from FPGA (not related to > > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization > > from 82 to 54% > > > and the error rate dropped > > * double strobes: 1:500M > > * missing strobes: 0, - not happened yet, still running long term test > > Ugh! =A0Analog FPGAs! =A0Something I don't want to hear about!!!! =A0You m= ay > want to look at these clocks (both of them) with a fast analog scope or > a really good digital one. =A0Even if the 4 MHz clock is extremely clean > with great rise/fall times, if the 50 MHz is noisy or has slow edges, > you'd hardly know the difference. =A0What I'm trying to say is jitter or > double clocking of the 50 MHz clock could foul up the relationship > between it and the 4 MHz, although I guess it would have to be truly > horrible to do that, and the symptoms would undoubtedly show up > somewhere else, too. =A0Is the 50 MHz processed by PLLs? =A0Noisy power > could affect the locking of the PLL. =A0Good luck, but I doubt you are > going to really nail this without serious scope probing. > > Jon Well, if you worry about double-clocking, there are simple bad-aid fixes that let you live with the double edges: click on http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel... which shows two different ways to avoid the effect of double-edges on a clock. I wrote that long ago, and published it in Xilinx XCell magazine #34 Peter Alfke (repeat of my posting of several days ago)Article: 130830
Peter Alfke wrote: > On Apr 2, 3:08 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>craig.tay...@xilinx.com wrote: >> >>>In many cases Xilinx will not be >>>able to assist you in determining if those suspect devices are >>>legitimate or usable. >> >>Hmmm - so these are no counterfeit at all (in the literal sense) >> >>but relabeled devices ? - Maybe Xilinx die from Easypath, >>or do Xilinx have 'creepage' issues on their test rejects ? >> >>-jg > > Jim, this is all idle speculation. At least, Jon was desrcribing his > dubious source openly. > When it comes to things that you cannot easily evaluate (like FPGAs, > microprocessors, food, medicine etc) you do not want to buy them at > the flea market. Agreed > The fact that the parts look like the real thing is incidental. Yes and no. If it were my company, I'd be interested in just HOW the parts got to be there. Do I need to tighten up the Testers, or Fabs, or do I need to laser mark EasyPath devices ? - or are they someone elses pulls, nicely refurbished (possible, but rather unlikely, due to erratic volumes) Grey market devices are usually 'easy dollars', so a speed-grade hike is one easy action. Intel has struggled with this. Xilinx's call - I guess this must be in the noise floor for them. -jgArticle: 130831
On Apr 2, 4:49=A0pm, Peter Alfke <pe...@xilinx.com> wrote: > On Apr 2, 3:57=A0pm, Jon Elson <el...@wustl.edu> wrote: > > > > > Antti wrote: > > > after that I did remove some of the logic from FPGA (not related to > > > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization= > > > from 82 to 54% > > > > and the error rate dropped > > > * double strobes: 1:500M > > > * missing strobes: 0, - not happened yet, still running long term test= > > > Ugh! =A0Analog FPGAs! =A0Something I don't want to hear about!!!! =A0You= may > > want to look at these clocks (both of them) with a fast analog scope or > > a really good digital one. =A0Even if the 4 MHz clock is extremely clean= > > with great rise/fall times, if the 50 MHz is noisy or has slow edges, > > you'd hardly know the difference. =A0What I'm trying to say is jitter or= > > double clocking of the 50 MHz clock could foul up the relationship > > between it and the 4 MHz, although I guess it would have to be truly > > horrible to do that, and the symptoms would undoubtedly show up > > somewhere else, too. =A0Is the 50 MHz processed by PLLs? =A0Noisy power > > could affect the locking of the PLL. =A0Good luck, but I doubt you are > > going to really nail this without serious scope probing. > > > Jon > > Well, if you worry about double-clocking, there are simple bad-aid > fixes that let you live with the double edges: click onhttp://www.nalanda.= nitc.ac.in/industry/appnotes/xilinx/documents/xcel... > which shows two different ways to avoid the effect of double-edges on > a clock. > I wrote that long ago, and published it in Xilinx XCell magazine #34 > Peter Alfke (repeat of my posting of several days ago) sloppy typing: I meant "band-aid fixes", since some purists insist that it is bad practice to live with such a problem. But I prefer a band-aid to the alternative of spreading blood all over the place or even bleeding to death. PeterArticle: 130832
Hi Peter, On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote: > Well, if you worry about double-clocking, there are simple bad-aid > fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel... > which shows two different ways to avoid the effect of double-edges on > a clock. > I wrote that long ago, and published it in Xilinx XCell magazine #34 I was curious about that article. I don't currently have any related problem but learning these tricks might help me down the road. Unfortunately the link you posted is dead. I tried to dig it up from the xcell archives on xilinx.com, but the last issue available is #48. It would be nice to have the older issues available as well, especially for newcomers who can still learn some basic/historical stuff from that. Do you know another archive? Greetings, TorstenArticle: 130833
> I was curious about that article. I don't currently have any related > problem but learning these tricks might help me down the road. > > Unfortunately the link you posted is dead. I tried to dig it up from > the xcell archives on xilinx.com, but the last issue available is #48. > It would be nice to have the older issues available as well, > especially for newcomers who can still learn some basic/historical > stuff from that. Here's the full link Peter posted a couple of days ago... http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf NialArticle: 130834
Hi here it goes: I got last week new notebook that is faster then the desktop, so I installed 10.x tools there. And I had a small task to verify something with ML505, so I fire up EDK 10.1 open the ML505 reference design, and within 3 minutes EDK self-terminates. So TTFFF (time to first fatal failure) 3 minutes. Ok, this way my fault i opened the XMP project from compressed folder, how foolish from me. But even so EDK should not self-terminate on such event IMHO. Now I open the project from normal folder, after project rev-up the file isnt opened. NEED MANUAL fix! I have been told that there are many people who have tested the 10.1 before release, i would have assumed the Xilinx DEFAULT MAIN refernece design for ML505 was tested as one of the first test cases, but no it wasnt. Ok, I fix manually the MHS file. After some hour of implementation run the project fails with some IO stuff regarding the TEMAC placement something, whatever the project does not run completle. Now I open the other larger ML505 ref design (the main one i think) the std_usb_ip something.. after again some while, I get some termination regarding some fatal thing with some GUIerror !!:( And I only wanted to test some simple C code on ML505 to measure the sysACE performance. A task that should take 2 hours max, but now I already spent 5 hours because the 10.1 mockup. Ok, back to EDK 9.2SP2 ML505 ref design, it does revup because SP update, it takes 5 hours to complete and both the external memories SRAM and DDR2 on ML505 do not work. the auto SP revup must have messed up something with the memory cores. Ok, my test program will fit BRAMs so maybe i can finally do that small C code test that I wanted todo initially. Antti PS, I was thinking that 10.1 is not suggested for ML505, but when i just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1 Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix the revup or make the 10.1 version of EDK ref design available! I dont want spend weeks to troubleshoot why xilinx ML505 ref design doesnt work with EDK 10.1Article: 130835
On 3 Apr., 12:10, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > here it goes: I got last week new notebook that is faster then the > desktop, so I installed 10.x tools there. > > And I had a small task to verify something with ML505, so I fire up > EDK 10.1 open the ML505 reference design, and within 3 minutes EDK > self-terminates. > > So TTFFF (time to first fatal failure) 3 minutes. > > Ok, this way my fault i opened the XMP project from compressed folder, > how foolish from me. But even so EDK should not self-terminate on such > event IMHO. > > Now I open the project from normal folder, after project rev-up the > file isnt opened. > > NEED MANUAL fix! > > I have been told that there are many people who have tested the 10.1 > before release, i would have assumed the Xilinx DEFAULT MAIN refernece > design for ML505 was tested as one of the first test cases, but no it > wasnt. > > Ok, I fix manually the MHS file. > > After some hour of implementation run the project fails with some IO > stuff regarding the TEMAC placement something, whatever the project > does not run completle. > > Now I open the other larger ML505 ref design (the main one i think) > the std_usb_ip something.. > > after again some while, I get some termination regarding some fatal > thing with some GUIerror !!:( > > And I only wanted to test some simple C code on ML505 to measure the > sysACE performance. > > A task that should take 2 hours max, but now I already spent 5 hours > because the 10.1 mockup. > > Ok, back to EDK 9.2SP2 > ML505 ref design, it does revup because SP update, it takes 5 hours to > complete > and both the external memories SRAM and DDR2 on ML505 do not work. > the auto SP revup must have messed up something with the memory cores. > > Ok, my test program will fit BRAMs so maybe i can finally do that > small C code test > that I wanted todo initially. > > Antti > PS, I was thinking that 10.1 is not suggested for ML505, but when i > just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1 > > Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix > the revup or make the 10.1 version of EDK ref design available! > > I dont want spend weeks to troubleshoot why xilinx ML505 ref design > doesnt work with EDK 10.1 UUPS, I downloaded the ML505 ref designs yesterday (they where for 9.2) it seems today the 10.1 versions are available.. sorry I did not check them AnttiArticle: 130836
Hi, I need to know how can I prohibit a configuration file from being downloaded on a similar FPGA device. For example, if I have two similar FPGA boards and I want only one FPGA board to be successfully programmed with the configuration file whereas if the same configuration file is downloaded on the other FPGA board, it should not get programmed. The target device is Virtex II Pro. I know there is this encryption feature available there for Virtex II and VIrtex II Pro devices but I am talking about the environment where the FPGAs will be programmed on startup through host application through PCI and there is no human intervention for programming the FPGA (or providing the encryption key). Here is the whole concept. I have a PC system where a PCI based 'COTS' FPGA card is installed. On startup, my application programs the FPGA board with the configuration file. However, if another similar FPGA board is installed in the same PC system, the application should (somehow) not programm the FPGA or the FPGA fails to get programmed successfully. I looked into the Device IDCODE thing but I came to know that the IDCODEs are the same for all FPGAs belonging to a particular family for example Spartan 3 sc3s1000 FPGA parts will have the same IDCODE. (had it been unique, I would have stored the IDCODE in my application and on finding a different IDCODE, I would have aborted the programming device sequence) I hope I have mentioned my problem statement clearly........ Any suggestion......... FarhanArticle: 130837
On 3 Apr., 13:16, maverick <sheikh.m.far...@gmail.com> wrote: > Hi, > I need to know how can I prohibit a configuration file from being > downloaded on a similar FPGA device. For example, if I have two > similar FPGA boards and I want only one FPGA board to be successfully > programmed with the configuration file whereas if the same > configuration file is downloaded on the other FPGA board, it should > not get programmed. The target device is Virtex II Pro. I know there > is this encryption feature available there for Virtex II and VIrtex II > Pro devices but I am talking about the environment where the FPGAs > will be programmed on startup through host application through PCI and > there is no human intervention for programming the FPGA (or providing > the encryption key). Here is the whole concept. I have a PC system > where a PCI based 'COTS' FPGA card is installed. On startup, my > application programs the FPGA board with the configuration file. > However, if another similar FPGA board is installed in the same PC > system, the application should (somehow) not programm the FPGA or the > FPGA fails to get programmed successfully. I looked into the Device > IDCODE thing but I came to know that the IDCODEs are the same for all > FPGAs belonging to a particular family for example Spartan 3 sc3s1000 > FPGA parts will have the same IDCODE. (had it been unique, I would > have stored the IDCODE in my application and on finding a different > IDCODE, I would have aborted the programming device sequence) > > I hope I have mentioned my problem statement clearly........ > > Any suggestion......... > > Farhan V2Pro has no efuse like V5 has, so you cant personalize the FPGAs on COTS board so whatever you do for your goal it need something on the boards to be different (except the FPGA) the only possibility would be the encryption, if not using it, need something else AnttiArticle: 130838
Nico Coesel wrote: > SOmehow JTAG is extremely sensitive to electrical parameters. IIRC the > method used to generate the waveforms by Impact is not the best around > (data and clk are changed simultaneously). I've also had these sort of > problems on boards with multiple FPGAs. Sometimes adding a small RC to > the clock (TCK) line may help. You can use an oscilloscope to very > setup & hold timing on the JTAG bus. That's interesting. I did wonder how the JTAG bus is driven. I've had a small project running in the background for a while to make my own usb JTAG module. Perhaps it's time to finish it off. AndyArticle: 130839
All, Possible solutions exist today for Virtex II, IIP, 4, 5: use encryption. Only the device with the proper key configures. In Spartan 3A, 3AN, 3ADSP, there is the "DeviceDNA" feature which may be used to identify a specific device. This identification requires a customer design to provide the function you desire (reference designs are available). This is really not a good way to do what you ask (encryption is not authentication and the device ID is not a standard, so it can make no claims of perfect security like one can with SHA), but does work. More advanced would be to have a "secure hash algorithm" like SHA128, which could be used with some user readable efuses to provide for a secure means to authenticate. AustinArticle: 130840
On Wed, 02 Apr 2008 08:35:27 -0700, Duane Clark <user@domaininvalid.com> wrote: >ni wrote: >> I am trying to get rams in xilinx to synthesize in synplify pro. I am >> a novice in syplify pro. I used the core generator to generate BRAM >> and then since for brams we cannot generate edif files I used ngc2edif >> to convert it to .ndf. I then added these ndf files into the project. >> Howewver I seem to get an error with the synplify pro.The core is a >> simple dual port RAM with a write port A and a read port B >> The error is following. I dont know how the synplify pro picksup the >> component from unisim. >> I have given the components name as ramb16_s18_s18. >> >> ERROR : Port web of entity unisim.ramb16_s18_s18 is unconnected >> >> The error is regarind port web which is a writ eenable prot of b . but >> port b is just a read port with we disabled. >> > >Rather than actually answer the question, can I suggest that you infer >BRAM rather than go through that complicated process? As a bonus, >inferred BRAM simulates much faster. You would infer BRAM something like: Err, not necessarily a good idea. For example, inferring a ROM wide enough to need both data buses and the parity bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2 improved on 7.1 in my test case, only inferring twice as many BRAMS as necessary. However, initialising the ROM data using functions caused elaboration to take significant time (of the order of hours for a couple of thousand elements) and 9.2 took twice as long as 7.1. I had to place an assert per memory location to reassure me it was doing anything at all. There is some n^2 algorithm involved; you could see it slow down, and doubling the ROM size quadrupled execution time. I don't know if this has been fixed in 10.1 yet. But it's a lovely idea when it actually works. (Incidentally, according to the resulting webcase, the "something I did wrong while inferring them" was ... inferring them. And the suggested instantiation template glossed over the problem of initialisation entirely.) Synplify probably handles BRAM inference much better; just be aware that relying on it limits portability. - BrianArticle: 130841
On 3 avr, 06:26, Antti <Antti.Luk...@googlemail.com> wrote: > UUPS, I downloaded the ML505 ref designs yesterday (they where for > 9.2) > it seems today the 10.1 versions are available.. sorry I did not check > them > > Antti Still, I think that you have a valid point that the rev up should be working properly. Ref designs are nice but most people will have custom designs in 9.2 that they want to migrate to 10.1. Personnaly I'll try to wait until at least the first service pack, OR until I encounter a bug in 9.2 that is fixed in 10.1... PatrickArticle: 130842
Torsten Landschoff wrote: > > Do you know another archive? > archive.orgArticle: 130843
Hi Comrade, I run into troubles trying to read anything using ICAP. I set "-g security:none", just in case. When I try to read for example STAT Register, BUSY goes HIGH when I switch to reading and stays that way. I deselect device (i.e. assert CE to HIGH) first then toggle WRITE. Output O[7:0] is set to X"9F", all the time. What may be the reason, any guesses? What am I missing? Cheers, [g.d.]Article: 130844
g.d. ICAp is nothing but a simple 2:1 multiplexer which provides internal access to all those "normal" external configuration interface pins. It sounds like PROG is being pulled internally, which causes the device to lose configuration, or something simple like that. After instantiating the ICAP primitive, be sure that all the connections you make to it have the same logical function as you would do externally on the same pins. In fact, debugging can be done by doing whatever it is, externally, and then putting it back inside (if you get really desperate). Be sure to go over all the configuration signals, and their use, in the User's configuration guide for your part. AustinArticle: 130845
Brian Drummond wrote: >>> >> Rather than actually answer the question, can I suggest that you infer >> BRAM rather than go through that complicated process? As a bonus, >> inferred BRAM simulates much faster. You would infer BRAM something like: > > Err, not necessarily a good idea. > > For example, inferring a ROM wide enough to need both data buses and the parity > bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2 > improved on 7.1 in my test case, only inferring twice as many BRAMS as > necessary. > > However, initialising the ROM data using functions caused elaboration to take > significant time (of the order of hours for a couple of thousand elements) and > 9.2 took twice as long as 7.1. I had to place an assert per memory location to > reassure me it was doing anything at all. There is some n^2 algorithm involved; > you could see it slow down, and doubling the ROM size quadrupled execution time. > I don't know if this has been fixed in 10.1 yet. > > But it's a lovely idea when it actually works. > > (Incidentally, according to the resulting webcase, the "something I did wrong > while inferring them" was ... inferring them. > And the suggested instantiation template glossed over the problem of > initialisation entirely.) > > Synplify probably handles BRAM inference much better; just be aware that relying > on it limits portability. > > - Brian Another limitation I have heard is that you can't infer dual port ram of differing port widths. -JeffArticle: 130846
On Apr 2, 4:59=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Peter Alfke wrote: > > On Apr 2, 3:08 pm, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>craig.tay...@xilinx.com wrote: > > >>>In many cases Xilinx will not be > >>>able to assist you in determining if those suspect devices are > >>>legitimate or usable. > > >>Hmmm - so these are no counterfeit at all (in the literal sense) > > >>but relabeled devices ? - Maybe Xilinx die from Easypath, > >>or do Xilinx have 'creepage' issues on their test rejects ? > > >>-jg > > > Jim, this is all idle speculation. At least, Jon was desrcribing his > > dubious source openly. > > When it comes to things that you cannot easily evaluate (like FPGAs, > > microprocessors, food, medicine etc) you do not want to buy them at > > the flea market. > > Agreed > > > The fact that the parts look like the real thing is incidental. > > Yes and no. If it were my company, I'd be interested in just > HOW the parts got to be there. > > Do I need to tighten up the Testers, or Fabs, or do I need > to laser mark EasyPath devices ? - or are they > someone elses pulls, nicely refurbished > (possible, but rather unlikely, due to erratic volumes) > > Grey market devices are usually 'easy dollars', > so a speed-grade hike is one easy action. > Intel has struggled with this. > > Xilinx's call - I guess this must be in the noise floor for them. > > -jg- Hide quoted text - > > - Show quoted text - Let me say this Xilinx is investigating the issue of counterfeit devices. We have taken steps to increase awarness of the issue with other companies in the industry. We are working with several government agencies on the issue. Many time we see that these parts are remarks. In some cases they are remarked devices that originally were not even Xilinx devices. Often they are really old devices that are marked to look young, faster than they are, or of a higher grade then they were. I have not seen pollution of reject materials from our supply base. There are very tight controls on reject and scrap materials, with several levels of validation. Xilinx has personnel (XILINX Employees) in each of our factory partners. We are also looking at the issue proactively. We are investigating several new marking protocols and security features that would be nearly impossible to duplicate or replicate. Our intent is to increase the amount of time and money it would take to remark devices to look like true Xilinx, but this is still off in the future. I recieved a phone call from someone reading my last post. They were not very happy about my authorized channel statement. I provide this information for peice of mind. If you buy parts from independent distributors that is not my issue. If the independent Disti is legitimately buying for an authorized Xilinx channel and can demonstrate a clean line of custody you may be Okay. It is your own comfort level with that transaction. However, some folks choose to buy parts from the broker market. There are some good resources in this market, but the devices that are coming in an out of this have a much higher rate of legitimacy issues. How many hands to you want your parts going through before you put them in your end product? It is really a question of Care, Custody, & Control. If you are buying for the Xilinx Disti, the CCC line is clear and easily supportable buy Xilinx warranty. Then when you get to 3rd, 4th, 5th partys, you have lost whatever CCC you might have warrented with the 2nd party purchase. I hope that this help further clarify.Article: 130847
On 3 Apr., 15:02, g.drozdzow...@gmail.com wrote: > Hi Comrade, > > I run into troubles trying to read anything using ICAP. > > I set "-g security:none", just in case. > > When I try to read for example STAT Register, BUSY goes HIGH when I > switch to reading and stays that way. I deselect device (i.e. assert > CE to HIGH) first then toggle WRITE. > > Output O[7:0] is set to X"9F", all the time. > > What may be the reason, any guesses? > > What am I missing? > > Cheers, > [g.d.] Hi g.d. looks like you're triggering a "SelectMap abort sequence" when switching from read to write. Consult the User Guide on how to avoid this, i guess your CS handling is not correct. JensArticle: 130848
OK, i have just used the secondary ports from the opb_mdm to connect the icon core. Now I am trying to debug with the Chipscope Analyzers, but I get only one value. That is, I have included a clock port, so it sould appears as 101010101 and so on. The real value is 1111111111. It seems like system only does a unique sample but it shows 512 samples. Does anyone have the same result?. What must I configure to show a clock signal up and down? Again, my best regardsArticle: 130849
On Thu, 3 Apr 2008 00:33:33 -0700 (PDT), Torsten Landschoff <t.landschoff@gmx.de> wrote: >Hi Peter, > >On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote: > >> Well, if you worry about double-clocking, there are simple bad-aid >> fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel... >> which shows two different ways to avoid the effect of double-edges on >> a clock. >> I wrote that long ago, and published it in Xilinx XCell magazine #34 > >I was curious about that article. I don't currently have any related >problem but learning these tricks might help me down the road. > >Unfortunately the link you posted is dead. I tried to dig it up from >the xcell archives on xilinx.com, but the last issue available is #48. >It would be nice to have the older issues available as well, >especially for newcomers who can still learn some basic/historical >stuff from that. > >Do you know another archive? > >Greetings, Torsten For an official source of older XCell magazines go here: ftp://ftp.xilinx.com/pub/documentation/xcell/00_index.htm the specific issue is here: ftp://ftp.xilinx.com/pub/documentation/xcell/xcell34.pdf with the article starting on page 54.
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