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
Who writes this stuff? I can speak from personal experience: When I arrived at Xilinx in 1988 I shuddered at the poor organization of the very first Data Book. And I volunteered to create a new one from scratch. And that's what I did, for 5 years in a row. I did not perform the measurements, but I either wrote or edited every single word and every comma, semicolon and hyphen.( I am hot on hyphens...) The advantage of a start-up is that the company can hire overqualified people to do mundane jobs, and do them very well. With over 30 years of engineering experience, I just rolled up my sleeves and dug into it. (The stock options were a nice motivator...) I disagree with the statement that engineers cannot write, and that the job has to be delegated to tech writers. For that's what you get in a more mature company, where the really savvy engineers are up to their ears in design, if they have not yet been promoted to a managerial position. The tech writers know their grammar and spelling, and the Chicago Book of Style, but they usually have never been working engineers. So you get good grammar, but not necessarily good sense. Sometimes not even good grammar... Excellent documentation is rarely elevated to a top priority. That is a sad fact. No need to convince me or Austin or Steve Knapp about the errors of that reasoning. We know and we try our best to help out Peter AlfkeArticle: 101426
Peter Alfke wrote: > Let me repeat: > If you want a mode pin to be interpreted as all High, you can do one of > three things, and all are correct: > 1. do nothing > 2. use external pull-up of any value > 3. strap to Vcc > > If you want a mode pin to be interpreted as Low, do one of two things: > 1. strap to ground > 2. use a resistor of 330 Ohm or lower to ground. > > The mode pins have an internal pull-up resistor during configuration. > Once the FPGA has been powered up, and the configuration memory has > been cleared, the INIT pin goes High, and this Low-to-High transition > on INIT samples the levels on the mode pins. At any other time, > (earlier or later) the levels on the mode pins are irrelevant to the > FPGA configuration process, or to its operation. > > For people who prefer not to think, we can also be dictatorial: > "You must strap mode pins to either Vcc or ground." > It sure works 100% of the time, but it is not the only possible way. > > This has been described in many generations of Xilinx data books, ever > since I was responsible for them in the late 'eighties and early > 'nineties, and the behavior of the mode pins never changed in our > 18-year history. At risk of you thinking I am asking another dumb question, I have seen any number of devices that sample some input pin at a given point in the startup. There are microprocessors as well as FPGAs that do this. But I never see any setup and hold timing data on these pins. If I am driving the mode pins on a Xilinx FPGA from some other device, any idea how long I need to drive them to the proper state? Is the hold time from INIT_B going high significantly more than 0 ns? How about the setup time? I am asking because one option I am considering is to control these signals directly from the DSP operating at 200 MHz. At these speeds, I want to make sure the mode states don't change too soon after INIT_B goes high and I need to know what to tell the software person.Article: 101427
hi all! what hapens when i send a code written in vhdl through jtag to the fpga? if anyone can tell me in detail the process..or suggest some good links for the same. regards ashuArticle: 101428
rickman wrote: > Peter Alfke wrote: > >> <snip> > >>The mode pins have an internal pull-up resistor during configuration. >>Once the FPGA has been powered up, and the configuration memory has >>been cleared, the INIT pin goes High, and this Low-to-High transition >>on INIT samples the levels on the mode pins. At any other time, >>(earlier or later) the levels on the mode pins are irrelevant to the >>FPGA configuration process, or to its operation. >> > > > At risk of you thinking I am asking another dumb question, I have seen > any number of devices that sample some input pin at a given point in > the startup. There are microprocessors as well as FPGAs that do this. > But I never see any setup and hold timing data on these pins. If I am > driving the mode pins on a Xilinx FPGA from some other device, any idea > how long I need to drive them to the proper state? Is the hold time > from INIT_B going high significantly more than 0 ns? How about the > setup time? I am asking because one option I am considering is to > control these signals directly from the DSP operating at 200 MHz. At > these speeds, I want to make sure the mode states don't change too soon > after INIT_B goes high and I need to know what to tell the software > person. Another benefit of define of Tsu, Th for Mode/INIT_B, is that it is then quite clear that they ARE edge sampled. -jgArticle: 101429
Hi, I'm using ISE 8.1.02, and when working with a 9500XL device I cannot see the Chip Viewer -- other users have posted that they cannot find it, but there never was a resolution or even an answer. Various help and pdf manuals make mention of it, but I cannot see it on the fitter portion of the workflow, or in the mysterious "accessories" menu. Does anyone know why it isn't visible (it is installed), or have any idea how I enable this ?. TIA, -- Regards, Gavin Melville gavin.melville@acclipse.co.nzArticle: 101430
In 18 years, and with over 100 000 designers using our parts, nobody has ever asked that particular question. I assume we have no intentions of 100% production-testing this particular parameter (requiresd of a spec it in the data sheet), but I could produce a well-educated estimate of the longest set-up and hold time requirement, "guaranteed by design". My guess is that 1 microsecond is super-safe, but I will check. Peter AlfkeArticle: 101431
Ok, let's say I want to write a script that adds all new source files into the source control. The first step would be obtainig the list of sources from the report. Is there a better way other than reading the report file and process it to find the relevant section? Apart from that, there is yet another problem. Some of the VHDL files in the project are generated automatically by SOPC builder. Strictly speaking, these are not source files, and I don't want to add them to the source control system (they're already there at their source locations). Is there any way to detect which are these files? As a starting point, it would be nice if I could instruct SOPC builder to put its files into some specific directory under the project, not in its root (even from command line). Thanks, AvishayArticle: 101432
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1146454126.593963.221080@v46g2000cwv.googlegroups.com... > In 18 years, and with over 100 000 designers using our parts, nobody > has ever asked that particular question. > I assume we have no intentions of 100% production-testing this > particular parameter (requiresd of a spec it in the data sheet), but I > could produce a well-educated estimate of the longest set-up and hold > time requirement, "guaranteed by design". > My guess is that 1 microsecond is super-safe, but I will check. > Peter Alfke > Peter, you're an incredible ambassador for Xilinx, and a top-notch engineer from what I can tell. Whatever your salary is and whatever your options yield for you, you're worth it. (No B.S. intended.) I hope your boss reads this newsgroup. You and Austin, and Steve Knapp when he feels like it, are the bomb. I just wish you guys would make all of your software free, including Plan Ahead ChipScope, and EDK. Then I would truly love you. Seriously, you should do that. And charge per hour for tech support, whatever it takes to offset the cost of developing and supporting the tools. Then super-smart guys like me (i.e., cash-poor consultants) would be able to use the tools for free and only the dummies would have to pay. (I was serious up until the last sentance.) Best regards, RobArticle: 101433
> > there are lots of small things... > > Antti > It is very easy for vendors to be SVF compilant. SVF is well documented, and easy to understand. A JTAG stream based on SVF is very stable. The only small things where troubles are coming from vendor is : - in the FREQUENCY definition in the SVF files, - in the need to repeat the last scan (SDR SIR) command if it failed. Our SVF player will have options to auto-detect the frequency, and to allow the repeat of a scan if it failed. My long experience with JTAG topic let me say you, it is not so hard to provide/write a generic SVF Player. From my experience Xilinx, Altera Lattice generate good SVF files. All vendor have just advantage to respect SVF specification. Laurent www.amontec.comArticle: 101434
Hallo, I'm working as hardware developer into an industry. I began one year ago. I have recently received a job offer from another industry. I think to accept it. During this year I developed some cores. I'm obliged to give every source code of my cores, otherwise may I give only netlist? That industry may sell the cores I developed? Many Thanks Marco Toschi PS: Sorry for my terrible english language.Article: 101435
"Marco T." <marc@blabla.com> schrieb im Newsbeitrag news:e34c5l$ijh$1@nnrp.ngi.it... > Hallo, > I'm working as hardware developer into an industry. I began one year ago. > I have recently received a job offer from another industry. I think to > accept it. > > During this year I developed some cores. > > I'm obliged to give every source code of my cores, otherwise may I give > only netlist? > > That industry may sell the cores I developed? > > Many Thanks > Marco Toschi > > PS: Sorry for my terrible english language. > I assume your use of 'industry' means == employer, then basically ALL IP what you developled during paid work belongs to the employer and they can do whatever they want unless it was agreed differently in the your work contract. AnttiArticle: 101436
"Antti Lukats" <antti@openchip.org> wrote in message news:e34i8q$q9v$1@online.de... > "Marco T." <marc@blabla.com> schrieb im Newsbeitrag > news:e34c5l$ijh$1@nnrp.ngi.it... >> Hallo, >> I'm working as hardware developer into an industry. I began one year ago. >> I have recently received a job offer from another industry. I think to >> accept it. >> >> During this year I developed some cores. >> >> I'm obliged to give every source code of my cores, otherwise may I give >> only netlist? >> >> That industry may sell the cores I developed? >> >> Many Thanks >> Marco Toschi >> >> PS: Sorry for my terrible english language. >> > I assume your use of 'industry' means == employer, then basically ALL IP > what you developled during paid work belongs to the employer and they can > do whatever they want unless it was agreed differently in the your work > contract. > > Antti > May I use the cores I developed with new job?Article: 101437
Marco T. wrote:
>> I assume your use of 'industry' means == employer, then basically ALL IP
>> what you developled during paid work belongs to the employer ...
^^^^^^^^^^^^^^^^^^^^^^^
> May I use the cores I developed with new job?
Read this again. -> You can't use something, that belongs to your employer.
Read your contract. It may be defined in a different way.
Ralf
Article: 101438Peter Alfke wrote: > Who writes this stuff? > I can speak from personal experience: When I arrived at Xilinx in 1988 > I shuddered at the poor organization of the very first Data Book. And I > volunteered to create a new one from scratch. And that's what I did, > for 5 years in a row. I did not perform the measurements, but I either > wrote or edited every single word and every comma, semicolon and > hyphen.( I am hot on hyphens...) > The advantage of a start-up is that the company can hire overqualified > people to do mundane jobs, and do them very well. With over 30 years > of engineering experience, I just rolled up my sleeves and dug into it. > (The stock options were a nice motivator...) > I disagree with the statement that engineers cannot write, and that the > job has to be delegated to tech writers. For that's what you get in a > more mature company, where the really savvy engineers are up to their > ears in design, if they have not yet been promoted to a managerial > position. > The tech writers know their grammar and spelling, and the Chicago Book > of Style, but they usually have never been working engineers. > So you get good grammar, but not necessarily good sense. Sometimes not > even good grammar... It has been my experience that tech writers provide a lot more than just a grammer check. They understand how to present information in a clear, concise and complete manner; all things that we are discussing as being missing from the Xilinx documentation. Tech writers understand documentation the way you understand your chips. They know the process of taking raw input and working it into a document by writing, reviewing, finding the holes and plugging them. Tech writers find and fix the problems so your customers don't have to. > Excellent documentation is rarely elevated to a top priority. That is a > sad fact. No need to convince me or Austin or Steve Knapp about the > errors of that reasoning. We know and we try our best to help out That is true here as well. I am constantly being told that the document does not need to be complete, we just need something to meet our schedule. But just like the design, I am responsible for the completeness and accuracy of the documentation. My last ICD was good enough that our customer decided to use it as the governing document for the interface and his ICD removed the related technical info and references our document.Article: 101439
"Antti Lukats" <antti@openchip.org> wrote in message news:e34i8q$q9v$1@online.de... > I assume your use of 'industry' means == employer, then basically ALL IP > what you developled during paid work belongs to the employer and they can > do whatever they want unless it was agreed differently in the your work > contract. > That depends on the country. In the UK it is normal that IP normally expected through the course of your work connected with the company belongs to the company. However an idea or discovery discovered during work time but unrelated to the companies interest may belong to the employee. Similarly if the employee is inspired at bath time of an advance in his company's products then that belongs to the company. In this case if he's employed the cores written in company time for company purposes belongs to the company. He has no rights at all for use outside the company.Article: 101440
> to the company. However an idea or discovery discovered during work time > but unrelated to the companies interest may belong to the employee. What if the employee uses company resources (say a company workstation) to develop/explore the unrelated idea? Wouldn't that give the company grounds for a claim?Article: 101441
"Antti Lukats" <antti@openchip.org> wrote in message news:e32r3p$iv0$1@online.de... > > Hi Hans, > > yes VHDL based morse message could be added, I think I had something some > while ago, but not sure if I can dig that out, so if you find I will look > it. > > I have been actve on short-waves ages ago so Morse of course popped up in > my mind too, well its of course easier to implement with some small > soft-core processor, but plain HDL version could also be a nice example See http://www.ht-lab.com/freecores/Morse/morsetx.html The code is very basic but should give you an idea how to put something together quickly :-) Regards, Hans (G7... too long ago to remember my callsign :-) www.ht-lab.comArticle: 101442
"int19h" <tirath@replacethispartwithmynickname.com> wrote in message news:4455fd7b@dnews.tpgi.com.au... >> to the company. However an idea or discovery discovered during work time >> but unrelated to the companies interest may belong to the employee. > > What if the employee uses company resources (say a company workstation) to > develop/explore the unrelated idea? Wouldn't that give the company grounds > for a claim? > In the UK it would be grounds for dismissal in the same basis any unauthorised use of equipment for non-work purposes can get you dismissed. Essentially theft of resources. They could claim loss which might add up to a pound or two! In other words - no. It does however depend on general working practices within the company such as is the occasional use of phones allowed for private use etc. Whether lawful would include contractual and normal practice within the company. If a clause in your contract is openly abused, known and accepted by management they cannot, on an ad-hoc basis, enforce it.Article: 101443
nop, the do not. it relativly common practice to have separate document for the package details - if there is proper link in the main datasheet to the package info then this ok. this practice is easy to understand, specially for companies with large amount of different products duplicating the package details in each datasheet doesnt make sense. AnttiArticle: 101444
On a sunny day (Mon, 01 May 2006 12:40:56 GMT) it happened "Hans" <hans64@ht-lab.com> wrote in <sln5g.309$A54.32@newsfe2-gui.ntli.net>: >See http://www.ht-lab.com/freecores/Morse/morsetx.html > >The code is very basic but should give you an idea how to put something >together quickly :-) > >Regards, >Hans (G7... too long ago to remember my callsign :-) >www.ht-lab.com If you use an IR LED, you can have the FPGA change channels on the TV. I had an IR LED on the PC par port for a long time, and a photo transistor too. I recorded the remote control signals (just zero / ones) in a few kHz sampling loop. Then had a bitfile for ch1, ch2 ch3 etc. to start the VHS from the PC. It seems in the US you can set the traffic lights to green too.Article: 101445
happens exactly the same thing when you send code written in verilog. AnttiArticle: 101446
hi everyone, i am curently debugging a board developed havin vitex chip... when i try to program this board following error occurs. ERROR:iMPACT:1210 - '1':Boundary-scan chain test failed at bit position '1' i tried to go through the xilinx website and found some instruction but that did not help .. if any one encountered the same problem .... your help will be appreciated...... One of the reason I am thinking is the the speed with which the virtex chip and Jtag are operating are not matching, correct me if I am wrong. If yes is there anyway to change frequency of JTAG.Article: 101447
Hello all, Does anyone know of a link/web page/article/ that gives the equations to calculating the output databus bit resolution of a digital filter. I imagine the following factors should be somewhere in the equations: 1. input databus resolution of the digital filter 2. scaling factor of the coeffciients to their binary equivalents 3. DCgain of the FF coeffcicients (if it is an IIR) 4. order of filter, type of filter, number of taps/coeffcients .... 5. Maximum amplification that the filter will allow, for any given frequency Please advise -RogerArticle: 101448
Which programming cable are you using to interface to the JTAG? What reference voltage into the programming cable are you using at the board interface? "boru" <aborundiya@gmail.com> wrote in message news:1146491542.962164.163010@j33g2000cwa.googlegroups.com... > hi everyone, > i am curently debugging a board developed havin vitex chip... when i > try to program this board following error occurs. > > ERROR:iMPACT:1210 - '1':Boundary-scan chain test failed at bit position > '1' > > i tried to go through the xilinx website and found some instruction but > that did not help .. > if any one encountered the same problem .... your help will be > appreciated...... > > One of the reason I am thinking is the the speed with which the virtex > chip and Jtag are operating are not matching, correct me if I am wrong. > If yes is there anyway to change frequency of JTAG. >Article: 101449
Rick, I have just checked the Spartan 3 changes, and I am pleased to see what I think you need. http://direct.xilinx.com/bvdocs/publications/ds099.pdf page 56, Table 32 has the ranges of pullup currents, and their equivalent ranges in ohms. page 97, Table 68 through page 100 Table 69 has the definitions of the pins, with a statement of when the pullups are active, and when it matters. page 109, Table 74 reinforces the definition of the pins, and the pullups. Do you agree? My only complaints are that 'pullup' and 'pull-up' are both used, so searching for "strength" needed 'pull-up' and searching for "definition" needed 'pullup.' And W is used instead of omega (for ohms) in four places (describing pullup for DONE, etc.). I hope this will allow everyone to go back to work, now that they have the pull-up (pullup) resistors fully specified for 1.14 to 3.45 volts (as active devices, their strength varies with supply voltage). If anyone at your place of work is still unhappy/uncomfortable with your design choices, I would be happy to remind them (in writing) that the data sheet (product specification, combined with the encrypted spice models, IBIS models, and speeds files) are the controlling documents, and that what may be suggested by the hotline, or by a FAE (or even by me!) may not be the most optimal solution (anything that is not in writing and approved by Xilinx may have been subject to mis-interpretation, or may be in error), and that good engineering judgement combined with observance of the data sheet and other specifications I have listed above is what actually matters (in a practical and legal sense). Austin
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