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
Welcome to the club... I had the same problem some months ago, I googled around and found a solution somewhere. When I remember right, the problem was that some files in a system directory were newer than the current data. -> Use the Windows search function and search for files newer than today (do not forget the check the "look for hidden files" or something like this). Once you have identfied the files that are too new, bring them back to the current date. If this doesn't help, google yourself... (sorry, can't really remember more precise.) Thomas "Michael Kraemer" <mike102de@yahoo.com> schrieb im Newsbeitrag news:1160386020.976528.161930@m7g2000cwm.googlegroups.com... >I seem to have a licensing problem with the Quartus Web edition. I > receive the error message: > > Warning: FLEXlm software error: System clock has been set back Feature: > quartus_lite License path: <filename> FLEXlm error: -88,309 For > further information, refer to the FLEXlm End User Manual, available at > "www.macrovision.com". > > I checked the manual, which lists this error message in the appendix E, > but does not explain how to fix it. > > I requested a new license file from Altera, but no success. I also > uninstalled Quartus II and re-installed it again - no success. I'm out > of ideas. Any suggestions??? > > Thank you, > > Michael >Article: 109976
Martin Thompson <martin.j.thompson@trw.com> writes: > Hmm, google seems to not provide any sources for it at all! The XCELL > archives seem broken as well :-( > > I'll try and dig up an schematic and ASCII it later... > Found it! http://www.xilinx-china.com/company/consultants/flancter.pdf Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 109977
"Christian Ludlam" <chris-news@link.recoil.org> wrote in message news:02c810734e.christian@venice.lab... >> "Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message >> news:1160349835.918930.124340@i42g2000cwa.googlegroups.com... >> > Ok but what if those FPGA outputs can cause problems for other parts of >> > the system, say if the FPGA is on a bus. Maybe there are some bus >> > protocols out there where the bus clock can stop, and the peripheral >> > needs to be able to be reset by the bus master?? >> Like I said, I don't discount that there may be these cases...but have >> yet >> to hear anyone actually name a specific case where the clock isn't >> running >> but a specific reset condition is required. >> >> Can anyone actually provide one? Hard to believe that such a case >> doesn't >> exist, but also hard to believe that one hasn't been articulated >> either....oh well. > > The PCI spec requires all outputs to be tristated on reset even in the > absense of a clock, That's true > so you need an async reset there. But that's not.....just means that the tri-state control of outputs must be shut off while reset is active....says nothing about any flip flops. KJArticle: 109978
> When I remember right, the problem was that some files in a system directory > were newer than the current data. -> Use the Windows search function and > search for files newer than today (do not forget the check the "look for > hidden files" or something like this). Once you have identfied the files > that are too new, bring them back to the current date. If this doesn't help, > google yourself... (sorry, can't really remember more precise.) > > Thomas Great, I found a directory in my temp folder, which I created this morning, but its date was four days later than today. I don't know why. Perhaps the date on our company network was wrong and the PCs retrieve the date from there. After I changed the date back to today, Quartus works again. Thank you for your support. Actually I cannot understand why Altera is so generous to give away this software for free, which I appreciate a lot, and then attach such restrictions. Anyway, this is perhaps the wrong question if one gets something for free. Thanks again, MichaelArticle: 109979
Peter Alfke wrote: > Well, we could get into a long discussion about relative security, and > about radiation mitigation, but this is not the right place for that. > I must, however, point out that "vendor-neutral" design pays a very > high price in not being able to take advantage of all the "goodies" > that you find in any moden FPGAs. (BlockRAMs, FIFO and ECC controllers, > clock manipulation and clock distribution, Serdes and 75-picosecond I/O > granularity, to name just a few that come to mind. And just wait what > we will announce in V-5LXT...) > Portability forces you to design with 15 year-old basic structures. > That's like living without indoor plumbing, electricity and telephone. > :-( > But your company seems to know why they like you to do it. Frugality > envigorates body and soul... > Peter Alfke, Xilinx > ================= > radarman wrote: > > Peter Alfke wrote: > > > We do not need any speculation. Antifuse FPGAs have been around for 20 > > > years, Actel is the oldest supplier, Quicklogic the younger one. > > > The antifuse is a very small (lless than one cubic micron?) speck of > > > silicon that is normally an insulator, but becomes permanently > > > conductive when a certain (rather high) voltage and current is applied. > > > > > > The system advantages are "instant-on" (no configuration process), > > > inherent (but limited) security and a higher radiation tolerance. > > > The disadvantages that have relegated antifuses to a niche market, are > > > one-time-only (and very slow) programmability (now that designers have > > > become accustomed to reprogrammability, and volatility is no longer a > > > dirty word), the inability of complete testing, and a seemingly natural > > > max size limitation. > > > > > > But no need for speculation, just google Actel or Quicklogic, they will > > > be happy to explain... > > > Peter Alfke > > > ============== > > > jacko wrote: > > > > scott moore wrote: > > > > > Does anyone have experience with antifuse fpgas? Are they lower cost > > > > > than static ram fpgas? > > > > > > > > > > Thank you, > > > > > > > > > > Scott Moore > > > > > > > > are they the eeprom ones, or a high current blow? > > > > > > > > just wondering if a reverse biased very small diode potential divider > > > > pair could charge a FET for passthrough switch on, by the division > > > > node. a discharge on the reverse bias diode using fet gate c as energy > > > > source, goes forward bias, and may melt open circuit fuse. achiving cut > > > > off. > > > > > > > > EEPROM cell best, but physical failure is potential after so many > > > > reprogramming cycles. > > > > > > > > a quantum tunnel PIN+ diode gate arrangement would work the best due to > > > > electron injection being the conduction charger of the P- gate rather > > > > than zenner breake down. this allows the substrate voltage to be > > > > increased. but then discharging of the floating gate becomes > > > > statistically unlikely. UV-EPROM magnetic induction discharge also > > > > possible. > > > > > > > > N+ doping on far gate end placed over insulator, and also p track in > > > > the substate beloe that, allows substrate discharge of whole chip. and > > > > p track can be volts held to reverse bias of discharge PIN+ diodes via > > > > p track. external to chip would be a two pin header with preserve > > > > jumper. > > > > > > > > cheers > > > > Peter, > > Reprogrammability, and testing, aren't an issue once the design is > > stable. Where I work, we use SRAM based devices to proof designs > > intended for OTP targets, and once it is functional, we migrate it to > > the final device. Generally speaking, we only do this for designs that > > must function in high-radiation environments, or the customer is > > nervous about the bitstreams not being "secure", but it isn't that > > difficult to port vendor neutral code. > > > > It's not perfect, and any problems with the migration result in > > expensive duds, but we treat it kind of like an ASIC flow, so the > > actual "dud rate" is very low. > > > > This is also the primary reason why our site doesn't use any > > coregen/megawizard/etc tools to generate IP. *All* of our IP must be in > > the form of VHDL, or vendor-neutral netlists, such as EDIF or VQM. It > > can be a pain, but all of our code can be shared without worrying about > > the target device. I dunno - so far everyone's tool chain has been able to pick out the most appropriate bits from the source VHDL. Sure, for some esoteric hardware you have to use vendor specific libraries, but these are generally limited to special I/O options. However, these sorts of things are generally post-algorithm, and part of the final flow. Personally, I'm not so dogmatic about it. I usually include a vendor selection generic, and where appropriate, wrap vendor specific IP with generate statements. I admit, it's easier to use the vendor tools for creating optimal memories, multipliers, simple FIFO's, etc. However, even in my hobby work, I try to keep the algorithms and state logic vendor neutral by writing straight RTL/behavioral models. It pays off because I can use whatever is the cheapest at the moment, without worrying about a rewrite.Article: 109980
Same here, I used an old version of the Time Stamp Modifier from Jonesoft, you might still find it on the web although www.jonesoft.com seems dead. Hans www.ht-lab.com "Thomas Entner" <aon.912710880@aon.at> wrote in message news:452a2a8c$0$26605$91cee783@newsreader01.highway.telekom.at... > Welcome to the club... > > I had the same problem some months ago, I googled around and found a > solution somewhere. > > When I remember right, the problem was that some files in a system > directory were newer than the current data. -> Use the Windows search > function and search for files newer than today (do not forget the check > the "look for hidden files" or something like this). Once you have > identfied the files that are too new, bring them back to the current date. > If this doesn't help, google yourself... (sorry, can't really remember > more precise.) > > Thomas > > "Michael Kraemer" <mike102de@yahoo.com> schrieb im Newsbeitrag > news:1160386020.976528.161930@m7g2000cwm.googlegroups.com... >>I seem to have a licensing problem with the Quartus Web edition. I >> receive the error message: >> >> Warning: FLEXlm software error: System clock has been set back Feature: >> quartus_lite License path: <filename> FLEXlm error: -88,309 For >> further information, refer to the FLEXlm End User Manual, available at >> "www.macrovision.com". >> >> I checked the manual, which lists this error message in the appendix E, >> but does not explain how to fix it. >> >> I requested a new license file from Altera, but no success. I also >> uninstalled Quartus II and re-installed it again - no success. I'm out >> of ideas. Any suggestions??? >> >> Thank you, >> >> Michael >> > >Article: 109981
David Brown wrote: > One thing to consider here is that automated spam bots try out random > email addresses regularly, especially for big domains like hotmail and > gmail. Thus you should not take it for granted that Xilinx, Altera, or > anyone else has leaked or sold your email address. If you make a new > address "rick123@gmail.com", you are going to get spam pretty quickly > even if you never use the address. Add to that the fact that some of > the big free email providers have leaked address lists (both > accidentally, and intentionally), and you can see that there's a > definite spam risk before you get to Xilinx marketing conspiracies. Of > course, I could be wrong - you could be using completely unguessable > addresses and Xilinx could be passing on your address. I hear what you are saying, but this spam was targeted to FPGA users. Like I said, I had this happen once before with Altera. I started getting spam emails from a third party that was affiliated with Altera indirectly. I expect it was a matter of Altera shared the mail list with party A and party A shared it (properly or improperly) with party B who starting sending me the spam. Worse, I could not get them to take me off the list. They were emailing web links and the return address was not functional. Trying to contact the advertising sponser was not effective so I complained to Altera... twice. They finally responded and I stopped receiving the emails. We'll see what it takes to stop the spam to the Xilinx address. I want to say it was a distributor who sent the spam emails. It may have been due to a request I made for an eval board through the Xilinx web site. They use your "account" information and likely that got passed to the disti who is not sending the spam. So far I have not heard anything back from Xilinx.Article: 109982
Hi all, I am buying a new for my work. I do a lot of synhesis, map and P&R using ISE 8.2 (Windows) in Xilinx EDK with quite complex systems. Building a HW for such a system can take a very long time, so selection of an appropriate computer is a must. Does anyone has any experience or benchmark test for a computer selection: - single or dual core processor - AMD or Intel - processor core type Cheers, GuruArticle: 109983
>I am buying a new for my work. I do a lot of synhesis, map and P&R >using ISE 8.2 (Windows) in Xilinx EDK with quite complex systems. >Building a HW for such a system can take a very long time, so selection >of an appropriate computer is a must. >Does anyone has any experience or benchmark test for a computer >selection: >- single or dual core processor >- AMD or Intel AMD for optimal MIPS/cost. >- processor core type - OS I suspect ISE runs more efficient on FreeBSD (Linux emulation) than under MS-win32. Esp considering the posting some days ago where it was found that when memory resources are tight MS-win32 gets a significant performance drop. (infact it works to run ISE with a PII-200MHz/80MB machine with simple constructions for XC3S200 with .bit in minutes). - Memory Can't ever have too much.. ;) It would be interesting too see what kind of computation resources ISE benefits most from. Ie L1/L2 cache, branchprediction, FSB-speed, etc..Article: 109984
My apologies. I wanted to sound cute, and I blew it. It is "invigorate = give strength or energy". And I should really be more sensitive to non-native English speakers, especially since I am one myself... Peter Antti wrote: > Peter Alfke wrote: > > Well, we could get into a long discussion about relative security, and > > about radiation mitigation, but this is not the right place for that. > > I must, however, point out that "vendor-neutral" design pays a very > > high price in not being able to take advantage of all the "goodies" > > that you find in any moden FPGAs. (BlockRAMs, FIFO and ECC controllers, > > clock manipulation and clock distribution, Serdes and 75-picosecond I/O > > granularity, to name just a few that come to mind. And just wait what > > we will announce in V-5LXT...) > > Portability forces you to design with 15 year-old basic structures. > > That's like living without indoor plumbing, electricity and telephone. > > :-( > > But your company seems to know why they like you to do it. Frugality > > envigorates body and soul... > > Peter Alfke, Xilinx > > ================= > Wau - does this mean that V-5LXT has some other super cool > new goodies above PCI Express MAC !? > > Guess so. > > Peter - you usually use simple sentences, but this time I had to look > up 2 words out of 5 word sentence, I found one at wikipedia, the other > not. I am just saying that non-english speaking people will not be able > to understand your last sentence to radarman (not even after a quick > search at wikipedia!). > > AnttiArticle: 109985
Output tristate in Xilinx FPGAs is driven by a flip-flop. Peter Alfke KJ wrote: > "Christian Ludlam" <chris-news@link.recoil.org> wrote in message > news:02c810734e.christian@venice.lab... > >> "Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message > >> news:1160349835.918930.124340@i42g2000cwa.googlegroups.com... > >> > Ok but what if those FPGA outputs can cause problems for other parts of > >> > the system, say if the FPGA is on a bus. Maybe there are some bus > >> > protocols out there where the bus clock can stop, and the peripheral > >> > needs to be able to be reset by the bus master?? > >> Like I said, I don't discount that there may be these cases...but have > >> yet > >> to hear anyone actually name a specific case where the clock isn't > >> running > >> but a specific reset condition is required. > >> > >> Can anyone actually provide one? Hard to believe that such a case > >> doesn't > >> exist, but also hard to believe that one hasn't been articulated > >> either....oh well. > > > > The PCI spec requires all outputs to be tristated on reset even in the > > absense of a clock, > That's true > > > so you need an async reset there. > But that's not.....just means that the tri-state control of outputs must be > shut off while reset is active....says nothing about any flip flops. > > KJArticle: 109986
Folks, Brannon wrote: > The following is an informal letter to Xilinx requesting their > continued efforts to increase the speed of their software tools. If > there are incorrect or missing statements, please correct me! I thought this was a great post. To my eye, only one of the posts till now (Kolja, I believe) has disagreed with any of Brannon's points regarding speedup. Several posts have made constructive suggestions for speedup with the existing tools. Nevertheless the speedup suggestions in this thread (including anonymous: incremental compile) have merit independent of whether Brannon does floorplanning. Don't need to be a race car driver to point out potholes in the road. > Dear Xilinx: > > As many of us spend numerous hours of our life waiting for > Map/Par/Bitgen to finish, I hereby petition Xilinx, Inc., to consider > this issue (of their tool speed) to be of the highest priority. I am > now scared to purchase newer chips because I fear that their increased > size and complexity will only further delay my company's development > times. Please, please, please invest the time and money to make the > tools execute faster. > > Have you considered the following ideas for speeding up the process? I'll be looking forward to seeing even just a basic yes/no response from Xilinx to this question ! > 1. The largest benefit to speed would be obtained through making the > tools multithreaded. Upcoming multi-core processors will soon be > available on all workstation systems. What is it that is causing Xilinx > years on end to make their tools multithreaded? There is no excuse for > this. I assume the tools are written in C/C++. Cross platform C/C++ > threading libraries make thread management and synchronization easy > (see boost.org). > 2. Use a different algorithm. I understand that the tools currently > rely on simulated Annealing algorithms for placement and routing. This > is probably a fine method historically, but we are arriving at the > point where all paths are constrained and the paths are complex (not > just vast in number). If there is no value in approximation, then the > algorithm loses its value. Perhaps it is time to consider a Branch and > Bound algorithm instead. This has the advantage of being easily > threadable. > 3. SIMD instructions are available on most modern processors. Are we > taking full advantage of them? MMX, SSE1/2/3/4, etc. > 4. Modern compilers have much improved memory management and > compilation over those of previous years. Also, the underlying > libraries for memory management and file IO can have a huge impact on > speed. Which compiler are you using? Which libraries are you using? > Have you tried the latest PathScale or Intel compilers? With regards to these two suggestions, it would be interesting to know what is the effective instruction throughput the code is achieving. Which is to say, examine the key time-consuming portion of algorithm, add up the actual adds and multiplies etc, measure how long it takes. If the performance is around 100 MHz on a 3 GHz machine, well there's probably room for improvement. > 5. In recent discussions about the speed of the map tool, I learned > that it took an unearthly five minutes to simply load and parse a 40MB > binary file on what is considered a fairly fast machine. It is > obviously doing a number of sanity checks on the file that are likely > unnecessary. It is also loading the chip description files at the same > time. Even still, that seems slow to me. Can we expand the file format > to include information about its own integrity? Can we increase the > file caches? Are we using good, modern parser technology? Can we add > command line parameters that will cause higher speed at the cost of > more memory usage and visa-versa? Speaking of command line parameters, > the software takes almost three seconds to show them. Why does it take > that long to simply initialize? > 6. Xilinx's chips are supposedly useful for acceleration. If so, make > a PCIe x4 board that accelerates the tools using some S3 chips and > SRAM. I'd pay $1000 for a board that gave a 5x improvement. (okay, so > that is way less than decent simulation tools, I confess I'm not > willing to pay big dolla....) This could be a great opportunity for Nallatech and Xilinx to work out together ! > 7. Is Xilinx making its money on software or hardware? If it is not > making money on software, then consider making it open source. More > eyes on the code mean more speed. > > Sincerely, > An HDL peon My two cents, -rajeev-Article: 109987
Thomas Stanka wrote: > Hi, > > Peter Alfke schrieb: > > I must, however, point out that "vendor-neutral" design pays a very > > high price in not being able to take advantage of all the "goodies" > > that you find in any moden FPGAs. (BlockRAMs, FIFO and ECC controllers, > > clock manipulation and clock distribution, Serdes and 75-picosecond I/O > > granularity, to name just a few that come to mind. And just wait what > > we will announce in V-5LXT...) > > Portability is freedom for the designer. I'm very lucky, that > portability is given for standard RTL-Code. No I like to have > portability for specialised features. Why can't there be one way to > instanciate RAM without dependancy on tool and target lib? > My last XCV-code is fixed to XST and won't work (easily) with Synplify. > Bad thing, if XiIlinx changes the synthesis tool again and I have to > migrate old code. I think Peter went a bit far classifying BlockRAM, FIFO and ECC controllers as not being 'vendor-neutral'. It certainly is possible to write plain old vanilla VHDL code that infers memory (RAM or ROM) that will be vendor and tool neutral and should have no performance disadvantage as compared to the Mr. Wizard approach which produces vendor specific code. For guidance, refer to the synthesis tool's documentation and they will most likely walk you through the process and the code that you get out of that exercise will likely be synthesizable to any target that supports such a memory. Once you know how to infer memory, it is not a large leap to put a few counters around such a memory to build a single clock fifo. Dual clock fifos will require some additional thought about the clock domain crossing issues but again this exercise should produce portable code that is not vendor specific. Where things break down is when you need some form of clock multiplier/divider. At present I don't know of any way to write plain old VHDL that will infer a PLL or a DLL, you're stuck having to instantiate a component from Mr. Wizard that then makes you vendor specific. This inability will likely lock you out of DDR/DDR-2 types of external memory interfaces (and probably other types of things) unless you're running that interface at the speed that the FPGA can handle it and don't necessarily need the top speed that the device can handle. Another area where Mr. Wizard can come in handy is in the area of design productivity. If you don't have the code already written and tested to infer a memory or a fifo and have to instead write it yourself you will likely be able to complete your design quicker with the help of Mr. Wizard. Keep in mind though that depending on your particular situation this could be a penny wise, dollar foolish (feel free to insert your own country's currency) approach. Mr. Wizard can be quicker this time...and next time...and the next...if you never get around to getting the code yourself. But if you take the time now to search for existing code (like OpenCores) or write it yourself you'll be further ahead the next time and Mr. Wizard won't have an advantage since it will be just as easy to instantiate your component as it will be to instantiate the Mr. Wizard component. If your situation finds you switching between vendor 'A' and 'X' often or if you try to defer that decision as late in the game as possible then avoiding Mr. Wizard assisstance is the best way in the long run. KJArticle: 109988
Thomas Stanka wrote: > My last XCV-code is fixed to XST and won't work (easily) with Synplify. I would expect that code templates for a multi-vendor tool like Synplify might be a better choice for portability than those from Xilinx. > I would prefer to have no problem > to transfer code for RAM of DPLLs from one vendor or tool to another. I agree, but until that happens, I still have the choice of either instancing the new gizmo or writing my own hdl that avoids it. -- Mike TreselerArticle: 109989
Hi, I am developing the physical layer of one 802.11b transceiver, I have designed the DBPSK, DQPSK, CCK modulators, scrambler, etc ... and now I have a doubt: How can I control them? ... I will explain the reason of my doubt: As you know, the frame has three parts: preamble, header and data ... the preamble can be trasmitted at 1 Mbps, the header at 2Mbps and data at 5.5Mbps ... How can the physical layer know when it must change the modulation. A finite state machine?? a microcontroller? ... I am not sure about that. To complete the context I can say that: I am developing it with SPW (Coware) and my objetive is implement it into FPGA. Thanks. JajoArticle: 109990
Hello rickman, el al, Please accept my apologies for any inconvenience you have experienced regarding SPAM emails. Xilinx does not, now or ever, sell or provide email addresses, or any information, to any third party company. As the Xilinx EDM Manager I assure you that I take Xilinx customers' privacy very seriously. Please see the Xilinx privacy policy here: http://www.xilinx.com/legal.htm#privacy. I would like to fully investigate this issue and clear it up as soon as I can. Using the email addresses I have found associated with the message board posting here I have searched our databases I have not found any violations and, most often, find that the email addresses used by the members posting here are not in the Xilinx customer database that gets used for push email and Webcast invitations. I am looking forward to fully investigating any specific issues anyone has with email being received from Xilinx or any third party that you may feel received your email address from Xilinx. In order to do so I would like to have an example of one of these emails. To that end I would invite, and strongly encourage, you to send me the email addresses at which you received the emails and, ideally, forward any email that you feel you have gotten from one of the SPAM companies you feel received you name from Xilinx. Please send or forward this information to: edm_manager@xilinx.com at your earliest convenience. For any emails that you receive in the future that you feel is SPAM or an email from a company that Xilinx has sold your information to I would ask that you forward those emails to me @ edm_manager@xilinx.com as soon as they occur. I will investigate. It pains me when I read something like these posts on a message board. And I do understand your frustration and would greatly appreciate your assistance in solving this issue. I am devoted to enforcing Xilinx privacy policy. rickman wrote: > Over the years I have gotten a lot of junk email from Xilinx to email > addresses that I have given out only to support and never to any > marketing channel. I have always been disappointed that Xilinx has > done this. But now they have sunk to a new low, they are giving or > selling my email address to third party junk emailers. > > I guess I should not be surprised at this since it is getting to be the > norm rather than the exception. Everyone seems to think it is > perfectly ok to post a non-"privacy" statement saying in typical > crypto-speak that they share your information with anyone that suits > them. I have found that if I contact a vendor directly and say I want > to opt out of their "privacy" policy and they should not share my info > with anyone at all, they will honor this. But why is this necessary? > Why can't a privacy policy be a PRIVACY policy and not a NON-privacy > policy? > > Am I alone in being irritated by these practices?Article: 109991
Rajeev, Xilinx takes seriously any suggestions. We, of all people, with the introduction of the Virtex 5 LX330, know that we need to somehow make everything work better, and faster. Note that due to the memory required, the LX330 can ONLY be complied on a 64 bit Linux machine.... there are just too many logic cells, and too much routing. 8 Gbytes is about what you need, and windoze can't handle it (at all). Regardless of the 'open source' debate, or any other postings, the FPGA software is much, much larger, and more complex than anyone seems to comprehend (one of the greatest barriers to entry for anyone thinking about competition). As such, I am hopeful that some of the musing here will get folks thinking, but realisitically, I am doubtful as the people responsible are daily trying to make things faster, and better as part of their job. AustinArticle: 109992
Jim Granville wrote: > KJ wrote: > > Like I said, I don't discount that there may be these cases...but have yet > > to hear anyone actually name a specific case where the clock isn't running > > but a specific reset condition is required. > > > > Can anyone actually provide one? Hard to believe that such a case doesn't > > exist, but also hard to believe that one hasn't been articulated > > either....oh well. > > any application where the FPGA is driving downstream power devices : > eg in Motor Drive applications. > > That said, normally that type of hard reset, is normally done with > external logic devices that collect a number of 'OK' signals before > actually allowing the power devices to turn on... > And if you're turning over control of the motor driver to a part that is clocked, I would expect that 'clock is running' would be one of those 'OK' signals. Furthermore, knowing that the clock is an input to the motor driver function, I would guess that the PCBA design would not even release reset to the FPGA until after the clock is actually running. Or is that not typically how one would do it? KJArticle: 109993
I appreciate your response. I will be sending you the info you have requested. I am curious, what does EDM stand for? Xilinx Edm Manager wrote: > Hello rickman, el al, > > Please accept my apologies for any inconvenience you have experienced > regarding SPAM emails. Xilinx does not, now or ever, sell or provide > email addresses, or any information, to any third party company. As the > Xilinx EDM Manager I assure you that I take Xilinx customers' privacy > very seriously. Please see the Xilinx privacy policy here: > http://www.xilinx.com/legal.htm#privacy. I would like to fully > investigate this issue and clear it up as soon as I can. > > Using the email addresses I have found associated with the message > board posting here I have searched our databases I have not found any > violations and, most often, find that the email addresses used by the > members posting here are not in the Xilinx customer database that gets > used for push email and Webcast invitations. > > I am looking forward to fully investigating any specific issues anyone > has with email being received from Xilinx or any third party that you > may feel received your email address from Xilinx. In order to do so I > would like to have an example of one of these emails. To that end I > would invite, and strongly encourage, you to send me the email > addresses at which you received the emails and, ideally, forward any > email that you feel you have gotten from one of the SPAM companies you > feel received you name from Xilinx. Please send or forward this > information to: edm_manager@xilinx.com at your earliest convenience. > > For any emails that you receive in the future that you feel is SPAM or > an email from a company that Xilinx has sold your information to I > would ask that you forward those emails to me @ edm_manager@xilinx.com > as soon as they occur. I will investigate. > > It pains me when I read something like these posts on a message board. > And I do understand your frustration and would greatly appreciate your > assistance in solving this issue. I am devoted to enforcing Xilinx > privacy policy. > > > rickman wrote: > > Over the years I have gotten a lot of junk email from Xilinx to email > > addresses that I have given out only to support and never to any > > marketing channel. I have always been disappointed that Xilinx has > > done this. But now they have sunk to a new low, they are giving or > > selling my email address to third party junk emailers. > > > > I guess I should not be surprised at this since it is getting to be the > > norm rather than the exception. Everyone seems to think it is > > perfectly ok to post a non-"privacy" statement saying in typical > > crypto-speak that they share your information with anyone that suits > > them. I have found that if I contact a vendor directly and say I want > > to opt out of their "privacy" policy and they should not share my info > > with anyone at all, they will honor this. But why is this necessary? > > Why can't a privacy policy be a PRIVACY policy and not a NON-privacy > > policy? > > > > Am I alone in being irritated by these practices?Article: 109994
Bob Perlman wrote: > >Like I said, I don't discount that there may be these cases...but have yet > >to hear anyone actually name a specific case where the clock isn't running > >but a specific reset condition is required. > > > >Can anyone actually provide one? Hard to believe that such a case doesn't > >exist, but also hard to believe that one hasn't been articulated > >either....oh well. > > How about TriState contention? If I'm controlling TriState buffers > with FFs that aren't initialized until the clock comes along, I run > the risk of turning on more than one set of TriStates on a signal or > bus. And when you're using high-current drivers, this can cause > smoke; I've seen it. > Those must be some hefty drivers if they can cause smoke in the probably only a couple of milliseconds between when reset gets released until the clock starts running (assuming that reset was even released first, typically I wouldn't do that). I've seen bus driver TTL type devices, which are relatively hefty drivers, shorted for several weeks while waiting for the short on the board to be found and fixed without any smoke occurring and marveled that devices can take such abuse and still work. Probably cut into the shelf life of that board a bit but this was an engineering prototype. So is there some publicly available "high current tri-state bus where reset releases before clock is running" you can refer to? Or was this some internal proprietary bus? KJArticle: 109995
Peter Alfke wrote: > Output tristate in Xilinx FPGAs is driven by a flip-flop. > Peter Alfke Guess I won't be able to implement anything resembling a 74xx244/374/etc. type of external interface in a Xilinx FPGA then ;) Anyway, given the controllable clearing/setting of flip flops that is occurring in the Xilinx devices as you mentioned earlier, it would seem that even in the absence of a clock one could insure that no output that should be tri-stated by reset is actively driving the bus until (if) that clock ever comes along simply by making the clocked signal that drives the OE be '0' after configuration to disable the output driver. KJArticle: 109996
On 2006-10-09, Austin Lesea <austin@xilinx.com> wrote: > Note that due to the memory required, the LX330 can ONLY be complied on > a 64 bit Linux machine.... there are just too many logic cells, and too > much routing. 8 Gbytes is about what you need, and windoze can't handle > it (at all). Wouldn't it be possible to do something like this: * Divide the design into 4 roughly equal sized parts. * Divide the FPGA into 4 parts * Map each part of the design into one part of the FPGA. (For bonus points, run these 4 parts in parallel on different computers.) These three steps should be doable with (optimistically) 2GB memory. Clock routing, I/O pins and connections between the different parts of the FPGA are not included in the above... Performing the final routing between different parts of the FPGA should be doable by only considering the rows and columns closest to the boundaries of the different parts. This way the memory consumption is reduced as well. For best results it would be necessary to floorplan these connections as well. I guess the partition support in ISE 8.2 can already (theoretically) do some of this, the only problem would be to make sure that for example map/par only considers a part of the FPGA when implementing the design instead of loading the ruleset for the entire FPGA. On the other hand, memory is quite cheap as compared to an LX330 I guess :) /AndreasArticle: 109997
Hi eveyone, I am designing a schematic for a project using Virtex-4 35 SX, and a platform flash for configuration (XCF16PVO48C). For the FPGA I use VCCO_0 = 3.3V, VCCAUX = 2.5V, and VCCINT = 1.2V. For the platform flash I use VCCO = VCCJ = 3.3V and VCCINT = 1.8V. I want to use a 3.3V Jtag interface and the question is: I have connected the FPGA_INIT, FPGA_PROG_B and FPGA_DONE, and FPGA_CCLK to the Platform flash following the guide, but have trouble deciding the power supply to where I have to pull up these signals. Should it be 3.3V because VCCO_0 is 3.3V or should I pull them up to 2.5V because VCCAUX is 2.5V? Or it will work either ways? I have seen it done in the schematics of XILINX ML401_2_3 using 2.5V for pull up, although in the configuration guide it says to use VCCO_0. Am I missing something here? Are those pins powered up by VCCO_0 or VCCAUX? Another user in this forum has told mehe is using the 3.3V tolerant configuration guide from SPARTAN-3 and he is doing the same to V4. What is the optimum way to configure V4 in such a simple configuration scheme? Thank you all in advance, -Tasos-Article: 109998
Andreas Ehliar wrote > On the other hand, memory is quite cheap as compared to an LX330 I guess > :) How many LX330s make one Ferrari? TimArticle: 109999
Thank you rickman and I will look forward to receiving that information. Electronic Direct Mail rickman wrote: > I appreciate your response. I will be sending you the info you have > requested. > > I am curious, what does EDM stand for? > > > Xilinx Edm Manager wrote: > > Hello rickman, el al, > > > > Please accept my apologies for any inconvenience you have experienced > > regarding SPAM emails. Xilinx does not, now or ever, sell or provide > > email addresses, or any information, to any third party company. As the > > Xilinx EDM Manager I assure you that I take Xilinx customers' privacy > > very seriously. Please see the Xilinx privacy policy here: > > http://www.xilinx.com/legal.htm#privacy. I would like to fully > > investigate this issue and clear it up as soon as I can. > > > > Using the email addresses I have found associated with the message > > board posting here I have searched our databases I have not found any > > violations and, most often, find that the email addresses used by the > > members posting here are not in the Xilinx customer database that gets > > used for push email and Webcast invitations. > > > > I am looking forward to fully investigating any specific issues anyone > > has with email being received from Xilinx or any third party that you > > may feel received your email address from Xilinx. In order to do so I > > would like to have an example of one of these emails. To that end I > > would invite, and strongly encourage, you to send me the email > > addresses at which you received the emails and, ideally, forward any > > email that you feel you have gotten from one of the SPAM companies you > > feel received you name from Xilinx. Please send or forward this > > information to: edm_manager@xilinx.com at your earliest convenience. > > > > For any emails that you receive in the future that you feel is SPAM or > > an email from a company that Xilinx has sold your information to I > > would ask that you forward those emails to me @ edm_manager@xilinx.com > > as soon as they occur. I will investigate. > > > > It pains me when I read something like these posts on a message board. > > And I do understand your frustration and would greatly appreciate your > > assistance in solving this issue. I am devoted to enforcing Xilinx > > privacy policy. > > > > > > rickman wrote: > > > Over the years I have gotten a lot of junk email from Xilinx to email > > > addresses that I have given out only to support and never to any > > > marketing channel. I have always been disappointed that Xilinx has > > > done this. But now they have sunk to a new low, they are giving or > > > selling my email address to third party junk emailers. > > > > > > I guess I should not be surprised at this since it is getting to be the > > > norm rather than the exception. Everyone seems to think it is > > > perfectly ok to post a non-"privacy" statement saying in typical > > > crypto-speak that they share your information with anyone that suits > > > them. I have found that if I contact a vendor directly and say I want > > > to opt out of their "privacy" policy and they should not share my info > > > with anyone at all, they will honor this. But why is this necessary? > > > Why can't a privacy policy be a PRIVACY policy and not a NON-privacy > > > policy? > > > > > > Am I alone in being irritated by these practices?
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