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
Chipscope will be something we use after we verify clocks/reset and what not. Right now I just want to print up a big sheet so the techs can do some simple probing. I played with pace but didn't get anywhere.Article: 81651
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> schrieb im Newsbeitrag news:d2bso8$n9h$1@lnx107.hrz.tu-darmstadt.de... > Thomas Entner <aon.912710880@aon.at> wrote: > > > > > > evaluation fixed to some specific kit are USELESS - really > > > I have 10+ evaluation boards but none of those you mentioned > > > so there will be no evaluation for me. And I am not going to > > > purchase an kit you support just to eval eric5, no way. > > > > > > just my 2 cents. if you really are planning fixed to board-evals > > > you may as well not todo it at all > > > > > > Antti > > > > > > > > Hmmm... > > > I hoped that I picked two boards that many people have (you really do not > > have the Digilent S3-board?) > > > I found no other useful solution that is both simple for the customer and > > protects our IP. Maybe you know one? (Please do not say: "Open Source", I > > had already this discussion ;-) > > > For Altera, there would be OpenCore plus, but you need to be an AMPP, > > and it is not easy to become that, so it does not help me. > > What about distributing a core with some cycle counter that disables the > core after some cycles. I think there was a discussion about this "feature" > used by some vendor for distributing evaluation cores. > > Bye > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de sure both Altera and Xilinx use evaluation timer method the problem with Altera is that without being AMPP member its not possible to distribute the core as encrypted version that is the core can only be distributed as either edif or flattened verilog/vhdl netlist, in bost cases disabling the eval timer would not be very problematic. for Xilinx, well the eval timer of the EDK cores can be disabled very easily :) It's not a protection at all in the matter of fact. PLEASE dont ask me how. AnttiArticle: 81652
> What about using mif-files (memory initialization files) ? The MegaRAM cannot be initilialized in the hardware. - PaulArticle: 81653
On 29 Mar 2005 05:33:50 -0800, "lecroy7200@chek.com" <lecroy7200@chek.com> wrote: >Not that I do not appreciate everyones help in this matter, but I have >received several PMs included from Xilinx tech support asking if I have >tried the following: > >- Bring the DONE/PROGB pin low >- Hold RESETB low fot at least 6 us >- Start the re-configuration > >I am not sure if some people are not able to read the entire thread and >that is the cause. Well, I have read all of your posts, and everyone elses too. The problem is one of clarity of communications. > The following are from my first and fourth posts: > >"Pulling the XC3000's reset low for 10us has no effect. ... The >only way to reprogram the part is to power down the IC. " Ok, this seems pretty clear, But in another article you write "I would drop the old 3000A" and in another article you write: ****** XC3190A PQ160AKJ9901 A2025068A Assumed date: 99 Fundimental frequency: 16MHz @ -60dB ****** Xilinx produces an XC3000 family, and XC3000A family, an XC3100 family and an XC3100A family (and many others too). My point about clarity is that your original article says XC3000, another article says XC3000A, and finally with actual partnumbers it turns out XC3100A. Are all the devices on all the boards XC3100A? It matters, as the various familys had slightly different config logic. >"The note to your link suggests that setting Reset high for > 6us then >setting it and the Prog/Done pin low for > 6us will bring the device >back to the clear configuration state. Looking at the loader code, >this is pretty much what is being done on every load. "pretty much" is not clear. You are dealing with a tough problem. It is rare, difficult to reproduce, and in an area (configuration) in which almost every designer has at least at one time had problems, some times intermittent, sometimes easy to repeat. The experience has been that except in extremely rare situations the problem has been traced back to something outside the FPGA. I understand your frustration, you've been at this for over 2 weeks, and no magic bullet yet. >The Reset >normally idles high and it along with the Program pin are pulled low >for 7.5us. See, this is surprising. This is not the way configuration is supposed to be started. In normal configuration, the reset is high, Init and Done/Prog both have pullup resistors. The software in your configuration processor should test that INIT is high indicating that housecleaning is complete, then it should test D/P, it should be high too. To start the program process, you pull D/P low, and wait till INIT goes high, indicating it is ready for configuration data. The clock and data should start greater than 10us after INIT goes high. Starting sooner than this can cause the header to not be read correctly. In the fault mode you have described, the D/P is permanently low. For this situation, assuming that the device is in slave serial mode, I believe you would supply a clock (at 1MHz or slower to CCLK), and try taking INIT high for > 10uS, then low for 10 uS, then stop driving it and let the pullup resistor try to pull it high. I would expect for INIT to stay low for the house cleaning, and then eventually, the FPGA would stop asserting it low, and the pullup resistor would then pull it high. At this point, stop driving the CCLK signal. It would now be ready for configuration. The D/P signal (which you should not be driving) should also go high because of the pullup resistor. If you get this far, then things are back to normal, and a low going pulse on D/P should start the config process as described in the previous paragraph. I know you think you have done the above, and the problem is the internal oscillator, but I am unconvinced. I would suggest the following laborious process. Describe in excruciating detail the signal sequence and timing you observe on ALL the following signals, including timing relationships, and whether the signal has a pullup resistor or not, and when the processor is driving it or not. These are the signals: DONE/PROG CCLK DIN DOUT INIT RESET PWRDWN LDC HDC M0 M1 M2 RDY/BSY Somewhere in all of this there is an answer. Still trying to help Philip Freidin =================== Philip Freidin philip.freidin@fpga-faq.org Host for WWW.FPGA-FAQ.ORGArticle: 81654
Proper internal oscillator startup would normally be guaranteed by the monotonic VCC rise requirements for the part in question; oscillator failure would be consistent the earlier speculation of a hypothetical transient of some sort taking out the FPGA. BTW, on a failed part, have you observed DOUT for activity under the test conditions described in Philip's earlier posts? Also, what value pullup/pulldown resistors are you using for the mode and powerdown pins? I have another vague recollection that that the internal pullups were "stiffer" in later 3xxx series parts, and needed lower values for the external resistors. > >From what I see, it all is pointing to a problem with the internal >oscillator. It would be great if there were a way to probe it to >verify what I am seeing with the analyzer. > At the risk of sounding repetitive, the method you seek is called "master serial mode", which lets you directly observe CCLK ( or a divided down version thereof ). Yes, this requires changing another variable in your test setup, which might affect your chances of observing something. However, it provides the benefit that you would now have a signal that can be directly probed, and used to catch whatever transient event is perturbing the FPGA: e.g., trigger a deep memory scope on "loss of CCLK" while probing any likely suspects (VCC, configuration pins, VEE, translator output pins, etc.) at a high sample rate with plenty of pretrigger storage. BrianArticle: 81655
FYI - I tried synthesizing with XST V6.2.03... It looks like XST accepts the assignments to initialize the shift registers it infers, BUT it breaks the chain and inserts a discrete flip-flop every place there's a '1' in the init value. Thus an initialization of the Inc shifter to 32'h1001_0000 appears to infer 2 smaller shift regs and 2 flip-flops. I don't know if this has been fixed in newer versions of XST. Also - I added the following comment to the top of the file: // The frequency is set by the 32 bit PARAMETER 'step' // Consider 'step' as a 0.32 fractional value. // For step <= 0.5 (1/2) (32'h8000_0000), the output frequency is // f_out = (f_in * fraction)/32 // f_out = (f_in * STEP)/(32 * 2^32) // Examples: // STEP Divisor // 32'h8000_0000 64 // 32'h4000_0000 128 // 32'h3000_0000 170.6666 // 32'h1000_0000 512 // 32'h0800_0000 1024 John ProvidenzaArticle: 81656
What about using a mismatched IOSTANDARD constraint (ex. using IOSTANDARD=LVCMOS25 and vcco=3.3v) ? Regards SandroArticle: 81657
> I thought we were going to take this offline, but since you are still > posting here (fine with me, by the way): > >From my previous post to Peter: "Seeing that you have decided to continue to post to the public thread rather than contact me directly, I will assume that this is how you wish to handle this issue. " You had my direct contact information. I expected that you and Peter would have used it rather than continue to post. > Yes. We found the schematic. We found the hand written note in the margin. > > Basically what Rob sent you from the hotline. I believe this is a different problem than what was originally noted. I only state this as it seems that there was never any mention of a non-recoverable state like I am seeing and there is never any mention of the internal oscillator failing. Maybe this was the orignal problem. > If that doesn't work, then I am afraid we are at the end of our > resources to provide help. Your call. My guess is had the device been used in the some of the DOD designs, that help would be coming out of the woodwork. > Changes were later made to the XC4000 so that it did not have this issue. > It is caused by a power supply glitch (and made worse if you use the > power down mode as well). Remove the glitch, and the problem goes away. > Perhaps you just need to add a 1,000 uF capacitor to the power suppy? > (or remove one, to prevent the glitch) Again, the problem I am seeing could be very well be caused by a transient of some kind. That is why I am running so many different transients to try and reproduce the problem. If I am unable to find a way to reproduce the problem, it will be near impossible to know if it can be fixed or if any changes I make have an impact on the problem. It's nice to be able to throw out a recommendation of a 1000uF bulk cap. but without proof that it did anything to improve or hurt the design, there is little value. That is why testing at this stage is so important. > Time spent on the KNOWN CAUSE (the glitch) would be beneficial (in my > opinion). You are unlikely (in fact: never going) to fix the chip. The > issue was addressed in later families, and never in the XC3000. I agree that fixing the device is not an option. I never expected this. Again, to make it very clear, I need to make sure that we do not run into this with whatever device we replace the 3000 with. I had hoped that Xilinx would have been more proactive in helping to identify the problem. If it is an oscillator design issue that you would be able to tell me that the problem was found and that corrections were made to newer devices to prevent it. It would seem that getting anything from Xilinx is impossible. So the next step will be to qualify a new device based on the tests I am currently running. On the upside, it seems that the D/P pin going low is a side effect of the problem. So at least I think we can limit our customers exposure to the problem.Article: 81658
"Mark McDougall" <markm@vl.com.au> wrote in message news:4248da6b$0$22678$5a62ac22@per-qv1-newsreader-01.iinet.net.au... <snip> > Can any verilog gurus explain what will happen? And why something might > be coded like this? <snip> The results may be consistent according to the Verilog Language Reference Manual but I wouldn't expect it. It would be coded this way because someone doesn't know what they're doing. The blocking assignment (=) rather than the non-blocking assignment (<=) is a flag that the person writing the code is green, the assignment of dout_en in different always blocks suggests they don't even know what they're trying to do. This, of course, is only an opinion from someone exposed constantly to professional designs.Article: 81659
lecroy, We have been in contact with you directly (through Rob). I am cc'd on all of the emails, and since I escalated this to the fire department, I was responsible for all communications. I am sorry you are frustrated. We found the shcematics. We (and you) know this is caused by a glitch, yet you will do nothing to change the setup, so nothing changes! A famous line by the owner and CEO of California Microwave - Dave Leason - is as follows: (said to a technician staring at a broken pcb)- "Well, what have you tried?" "I don't know what is wrong, so I don't know what to do." "If you do nothing, nothing will be the result." Basically, by refusing to add a capacitor to the supply (or in your best judgement do anything to the supply that would modify its behavior) you are in exactly the same state as the technician: doing nothing will result in no change. Sometimes you have to do something to get something. In fact, I would state that stronger: you must do something to get any information at all. Playing with a spectrum analyzer is like looking for your keys under the streetlamp: because to look anywhere else is tough (it is dark there!?). To imply that your application is not important enough to warrant a response from Xilinx is an insult to the good folks on the hotline, and to me personnaly. I am now taking time out of my day to reply to you (again). I could be working with the NSA, JPL, NASA, or the US AF, or any one of the government folks that I am responsible for working with on the many government programs that we work on everyday. But, no, I am working on tyring to help you. Abuse is not going to make me likely to post further. As of this moment, the case is closed. We have done what we can with what you are willing to do (look under the streetlamp). I hope you take the other advice here on the newsgroup, and do some of the things they suggest, if you do not like the suggestions we have provided. Sorry that you are upset, we are upset as well now. AustinArticle: 81660
Hi y'all : We create our .mif files by running a custom analysis program on a set of data files. I'd like to include this in the compile process. Whilst I can find interfaces to various EDA tools, I can't find a "just run this program prior to compilation" option Is this possible ? Thanks GaryArticle: 81661
<lecroy7200@chek.com> wrote in message news:1112113812.367672.94020@z14g2000cwz.googlegroups.com... <snip> > I agree that fixing the device is not an option. I never expected > this. Again, to make it very clear, I need to make sure that we do not > run into this with whatever device we replace the 3000 with. I had > hoped that Xilinx would have been more proactive in helping to identify > the problem. If it is an oscillator design issue that you would be > able to tell me that the problem was found and that corrections were > made to newer devices to prevent it. > > It would seem that getting anything from Xilinx is impossible. So the > next step will be to qualify a new device based on the tests I am > currently running. > > On the upside, it seems that the D/P pin going low is a side effect of > the problem. So at least I think we can limit our customers exposure > to the problem. Personally I would consider it unreasonable to expect Ford Motor Company to figure out why a '73 Pinto station wagon is experiencing occasional vapor-lock AND base my decision whether to buy a 2005 Thunderbird on what their level of support was... whether they fixed the problem or not. I applaud your efforts to exhaustively address a problem you're experiencing with ancient parts. Those parts aren't old, they're ancient in the progress of FPGAs. Be happy for the support you HAVE received - the Xilinx and non-Xilinx folks that continue to add their insights are good people. Don't look to hold the FPGA manufacturer accountable when they HAVE addressed the issue you're encountering but it was put to bed a decade ago. Often the true cause of something can't be determined without excessive investment of time, money, or newsgroup postings. I wish you luck in finding your happy place with respect to the error you encountered. Respectfully, - John_HArticle: 81662
Hi http://wiki.openchip.org/index.php/OpenChip:PicoMax there is description of what is implemented and working http://gforge.openchip.org/projects/picomax file snapshot download is there I am releasing it as I possible cant get it finished in a very short time, so presenting a snapshot as it is. It could already serve as example of an bit serial processor implementation the processor including instruction set is optimized to be executed from MAX2 UFM memory doing on the fly decoding. for Xilinx SRL16 optimized bit serial processor the architecture and command set would be different. the snapshot includes a ISE project with UFM model ready to be simulated in ModelSim Antti would be happy to hear any comments and suggestions!Article: 81663
Hi all. I'm looking for a blogger for the new Chip Design blogsphere. The potential candidate will have to meet these three criteria: 1. Experience in FPGA architecture-design-test 2. Respected presence in the reconfigurable processor industry 3. Desire and skill to be a blogger, posting brief editorial twice a week and answering reader responses. In return for his/her efforts, this blogger will have their picture and byline posted on the new Chip Design blogsphere, plus free subscription to our new subscriber-based portion of the magazine. Please respond directly to me at: jblyler@extensionmedia.com Thanks! -- John ********************** John E. Blyler Editor-in-Chief, Chip Design magazine Affiliate Professor, Systems Engineering, PSU Email: jblyler@extensionmedia.com Office: 503-614-1082 Cell: 503-348-1342 Web: www.chipdesignmag.comArticle: 81664
wpiman@aol.com wrote: > Chipscope will be something we use after we verify clocks/reset and > what not. Right now I just want to print up a big sheet so the techs > can do some simple probing. I played with pace but didn't get anywhere. > Open up your design in PACE. The default view is the "Architecture View" which shows the die. If you click on the "Package View" tab on the bottom of the screen then you will see a view of the balls. You may select the top or bottom view, the latter of which will be easier for probing. The placed pins will be shown as filled-in circles. Tooltips will show the net connected to each pin. I don't think you can print this on the diagram, but you can print the picture and print the pin list. You can also set the colors of the balls if you want to highlight certain pins. -KevinArticle: 81665
Mack, A check mark in the Processes for Source window denotes a process that was run successfully. An exclamation mark indicates that the process was run and that there is a warning for the process. More information about warnings can be obtained in the Transcript window. What is the trace output in your Transcript window display? -HTArticle: 81666
Mack, The transcript window shows a "Console" tab, along with "Find in Files", "Warnings" and "Errors". Check you Warnings and Errors tab in the Transcript window. -HTArticle: 81667
Hi, Is there anywayz a 24 bit std_logic_vector can be divided by a decimal number (eg: 1.36)using VHDL. The quotient needs to be a 24 bit std_logic_vector as well. I am currently using Xilinx ISE for implementing this division. Any help is appreciated. ThanksArticle: 81668
Hi, Has anyone successfully hooked up an SRAM to the Spartan3 FPGA yet?? If you have, can you tell me how you hooked it up???? Thanks, AnnArticle: 81669
exactely what I was looking for , thanks you "Invalid User" <spam@nodomain.com> a écrit dans le message de news: d29chf$2n41@cliff.xsj.xilinx.com... > http://www.computer-engineering.org/ > > KCL wrote: >> Hi, >> As I am making a PS/2 keyboard vhd , I am looking for scancodes of an >> azerty keyboard to convert code from keyboard to ascii code. Does anyone >> know where i can find that because I only found it for qwerty keyboard. >> >> Thanks >> >> AlexisArticle: 81670
First of all, is the decimal number constant? If so, think multiplication. Embedded multipliers are quick and easy while dividers are much more work. Do you need a new result every 200 MHz clock or do you need to know the once every 3 microseconds? "genlock" <genlocks@gmail.com> wrote in message news:1112125409.443564.224970@z14g2000cwz.googlegroups.com... > Hi, > Is there anywayz a 24 bit std_logic_vector can be divided by a decimal > number (eg: 1.36)using VHDL. > > The quotient needs to be a 24 bit std_logic_vector as well. > > I am currently using Xilinx ISE for implementing this division. > > Any help is appreciated. > > ThanksArticle: 81671
hello, I'm about to layout a circuit for a pcb that includes the Xilinx spartan II-e and external circuitry (simple interface elements), I was wondering if anyone has laid out a PCB using the chip, because I know there are a lot of capacitors and resistors and other elements that are on the development board, and I am not sure what needs to be transfered and what doesn't.. GeorgeArticle: 81672
Hi, > Has anyone successfully hooked up an SRAM to the Spartan3 FPGA yet?? If you have, can you tell me how you hooked it up???? Are you looking for a schematic? If so try http://www-user.rhrk.uni-kl.de/~alles/fpga/euterpe.pdf This schematic shows you how you can connect a standard synchronous SRAM to the Spartan3. Matthias AllesArticle: 81673
Austin Lesea wrote: > lecroy, > > We have been in contact with you directly (through Rob). >From your following comment and your original comment about going off-line, I assumed you would be in contact. "So, your support for this issue is now Peter Alfke and Austin Lesea." What I did get from Rob was the following: " Have you been in contact with Austin or Peter on this issue yet, aside from the postings on comp.arch.fpga? If so, can you please CC me on those e-mails to keep me in the loop on this case? " Again, leading me to think you would be in touch. > We found the shcematics. > > We (and you) know this is caused by a glitch, yet you will do nothing to > change the setup, so nothing changes! It's great that your putting words in my mouth. I am not sure of the cause of the problem. Sure it could be what you refer to as a "glitch". I really do not know, nor can I seem to find any correlation what any tests I have run. > A famous line by the owner and CEO of California Microwave - Dave Leason > - is as follows: (said to a technician staring at a broken pcb)- > > "Well, what have you tried?" > > "I don't know what is wrong, so I don't know what to do." > > "If you do nothing, nothing will be the result." Nice. I am sorry you feel this way about my efforts. > Basically, by refusing to add a capacitor to the supply (or in your best > judgement do anything to the supply that would modify its behavior) you > are in exactly the same state as the technician: doing nothing will > result in no change. I have taken the opposite direction of trying to cause the failure, and from this you feel I am doing nothing. > Sometimes you have to do something to get something. In fact, I would > state that stronger: you must do something to get any information at all. > Playing with a spectrum analyzer is like looking for your keys under the > streetlamp: because to look anywhere else is tough (it is dark there!?). It's just another tool to me that provides another way to look at the problem. > To imply that your application is not important enough to warrant a > response from Xilinx is an insult to the good folks on the hotline, and > to me personnaly. That's fine, but it's the truth. > I am now taking time out of my day to reply to you (again). I could be > working with the NSA, JPL, NASA, or the US AF, or any one of the > government folks that I am responsible for working with on the many > government programs that we work on everyday. > > But, no, I am working on tyring to help you. I am sorry you felt that all your hard work on this problem has taken away from your other customers. > Abuse is not going to make me likely to post further. As of this > moment, the case is closed. We have done what we can with what you are > willing to do (look under the streetlamp). I hope you take the other > advice here on the newsgroup, and do some of the things they suggest, if > you do not like the suggestions we have provided. Abuse, LOL!!! I needed that bit of humor. > Sorry that you are upset, we are upset as well now. Sorry you are upset. I am just trying to find the root problem.Article: 81674
Yes the decimal number is a constant value. What do you mean by embedded multipliers? Is there a VHDL code available for that or how do we go about coding one. I dont need a clock for this one. Thankyou
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