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
Tom, The Golgafrinchian Ark "B" had no lawyers on it. Perhaps this is the reason why. If you search for patents in my name, (or Peter's) you may be amused at what is "patentable." I hope no one gets "insensed." There are many fine legal distinctions that I do not pretend to understand, and the laws are changing daily. As it was explained to me, "new" and "obvious" have totally legal meanings when it comes to patents. The laws in different countries are also different. So it may be old, and obvious to you, but within the very narrow confines of patent law, it may be "new" and not "obvious" and thus, patentable. Also, "one skilled in the art" is another of my favorite phrases, as unless you work for one of two companies, you really don't know anything at all about the design, care, and feeding, or the internal guts of the ultra-deep sub micron FPGA technologies. If we would have patented a few use related issues back in the 2000 days, no one would have been able to use LUTS in FPGA's at all. It isn't the LUT itself, it is the use of the LUT in an FPGA to do something. If that has never been done before, and it is by definition "new," and even if every customer uses it (after all, you didn't need a license to use a Polaroid Camera), you are "protected" (whatever the hell that means). I suggest that anyone really hot about this issue go work as an expert witness for awhile: excellent pay (even while traveling!), good food, short hours. Email us with the number of months you could stomach it, before you give up the fat living, and go back to a real job in total disgust and disillusionment....... Austin Tom Seim wrote: > It might help to look at the big picture: America's economy is largely > based on a technology lead over the rest of the world (we certainly > are not going to compete with China on wage rates). Patents are a key > part of protecting our technology edge. > Are there dumb, obvious, bizare and ridiculous patents? Of course, but > we have a legal system for sorting that out (those poor, destitute > lawyers have to make a living some how, God knows that they don't have > any useful skills). > > Tom Seim > > Kolja Sulimma <kolja@sulimma.de> wrote in message news:<3B399C0B.2A2CAA4@sulimma.de>... > > cyber_spook wrote: > > > > > Being a Fan of Peter I don't wish to upset him... but these are my > > > views... > > > > I sincerely hope we can have contrary views in this newgroup without > > upsetting anybody. > > > > Besides: > > Peter is known for taking a lot of beating in this newsgroup for things that > > are not his fault > > And he still continues with his invaluable support. > > > > Kolja SulimmaArticle: 32476
> Sure people have been using this > logic construct for a long time, but have they been doing it in an FPGA? YES.Article: 32477
> As it was explained to me, "new" and "obvious" have totally legal meanings when it comes to > patents. What is new and novel to the patent examiner may not be new and novel to a truly qualified engineer. > Also, "one skilled in the art" is another of my favorite phrases, I assure you, the patent examiners for this type of stuff are NOT "skilled in the art" to the extent they should be. How "skilled" is "skilled"?. That is unfortunately a fact. It is a downside of technology patents that the USPTO has not dealt with appropriately, IMO. Just think about the "one click" patent and a number of the business "process" patents that have been recently issued...Article: 32478
Falk Brunner <Falk.Brunner@gmx.de> writes: > Just a idea about a dirty-low cost LVPECL-> CMOS converter. > > How about to use a voltage divider to set the bias on an input near the > switching point (1.4 V for TTL) and then capacitiv couple the LVPECL > signal into the pin. Since this signal is a clock signal, no problems > with low frequency components. Will this work? Sounds like a decent idea. I assume the clock is located on the same board, aaand always on? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 32480
The voltage swings are a bit low for guaranteed operation. While 1.4V is the approximate switching threshold, guaranteed values of 0.8V and 2.0V requires a 1.2V swing. The LVPECL will probably generate about 0.8V. Not pretty. Falk Brunner wrote: > Just a idea about a dirty-low cost LVPECL-> CMOS converter. > > How about to use a voltage divider to set the bias on an input near the > switching point (1.4 V for TTL) and then capacitiv couple the LVPECL > signal into the pin. Since this signal is a clock signal, no problems > with low frequency components. Will this work?Article: 32481
Kolja Sulimma wrote: > I sincerely hope we can have contrary views in this newgroup without > upsetting anybody. Agreed but some times the written word dose not carry the body language we see when we talk - so I like to point it out. Cyber_Spook_ManArticle: 32482
Another issue is the speed drive spin at. The small CD's don't generate as much load which can affect the drive and them that are unbalanced can shatter (so do 5" ones if cracked or damaged) which will blow the inside of the drive apart. Cyber_Spook_Man Eric wrote: > Main reason for this is that the 3" CD can move on the tray and > the hole can become unaligned. > If this happens, and because of the way the tray mechanism is built > in most drives, the spindle axle will push very hard on the disk > and break the delicate plastic tray / gear (and damage your disk). > > Risk is greatly reduced if the 3" plastic groove in the tray is high > enough. > > Another problem with some cheap 3" CD is that some of them > are very unbalanced and cause lots of vibrations as they fool > some vibration preventing designs. > > Rectangular "business card" CD that are thicker than regular ones > are the worst. > > However, if you use them with care, it should be Ok. > > Éric. > > Dave Feustel wrote: > > > I was told yesterday by a computer retailer that 3" CDROMs > > (such as the Xilinx Webpack ISE) can cause problems when > > used in 5" CDROM drives. He said that the 3" cdroms can > > damage the 5" drive, forcing a replacement and that some > > manufacturers (Apple) now state that using the 3" cdroms > > voids the manufacturer's warranty on CDROM drives. Since I > > just received the 3" Xilinx cdrom I thought I would ask about this > > potential problem before I tried using the 3" cdroms on my computer. > > > > Has anyone had any trouble with their cdrom drives after using them > > to read 3" cdroms? > > > > Thanks, > > > > Dave Feustel > > Fort Wayne, IndianaArticle: 32483
It is getting clear that I will end up with an amount of Spartan2S50 devices for which I do not have any need. Is anybody interrested to maybe overcome long delivery times. This also counts for the matching OTP configurator.Article: 32484
0.8 V / 2.0 V are values originated in the mid-'sixties, almost 40 years ago, for bipolar 5-V TTL inputs, intentionally guaranteeing 400 mV of noise immunity. The guaranteed Vol(max) was 400 mV, dictated by a saturated transistor, and getting worse with non-saturated Schottky transistors. Voh(min) could be as low as 2.4 V, assuming 4.5 V Vcc(min) and two diode drops of 1 V(max) at military -55 degrees C. All this has nothing whatsoever to do with modern CMOS, but this archaic specification just lives on, because nobody has the guts to kill it. The ghost of decades past... A resistive divider and capacitive coupling of a continuously running clock will work just fine. Peter Alfke ================================ John_H wrote: > The voltage swings are a bit low for guaranteed operation. While 1.4V is the > approximate switching threshold, guaranteed values of 0.8V and 2.0V requires a > 1.2V swing. The LVPECL will probably generate about 0.8V. Not pretty. > > Falk Brunner wrote: > > > Just a idea about a dirty-low cost LVPECL-> CMOS converter. > > > > How about to use a voltage divider to set the bias on an input near the > > switching point (1.4 V for TTL) and then capacitiv couple the LVPECL > > signal into the pin. Since this signal is a clock signal, no problems > > with low frequency components. Will this work?Article: 32485
Actually in the patent system it is the responsibility of the applicant to supply the examiner with all the information needed to make a determination of what is patentable. The applicant has to provide the examiner with _all_ the prior art associated with a proclaimed invention. We had to "train" our examiner but he now has a good grasp on reconfigurable computing. For example I got the patent for automatically downloading configurations into FPGAs. I had applied for this patent years before and was not able to search for all the prior art. When I was allowed the claims I looked around and saw that that there was some prior art (1) so I withdrew the patent and resubmitted it with a ton of prior art and claims about "generating bitstreams on the fly." I got that patent and 4 others. So the bottom line is the applicant is responsible for educating the examiner. That is the reason losers in patent cases have to pay court costs. So really getting a patent is just the first leg of having the protection everyone thinks a patent gives them. One side point on stupid patents. I'd rather that Xilinx had all the stupid patents on FPGAs rather than someone else at least that stops someone running around trying to stop someone from doing a design. Steve Casselman "Austin Franklin" <austin@dark87room.com> wrote in message news:9hda8o$thg$1@slb2.atl.mindspring.net... > > As it was explained to me, "new" and "obvious" have totally legal meanings > when it comes to > > patents. > > What is new and novel to the patent examiner may not be new and novel to a > truly qualified engineer. > > > Also, "one skilled in the art" is another of my favorite phrases, > > I assure you, the patent examiners for this type of stuff are NOT "skilled > in the art" to the extent they should be. How "skilled" is "skilled"?. > That is unfortunately a fact. It is a downside of technology patents that > the USPTO has not dealt with appropriately, IMO. > > Just think about the "one click" patent and a number of the business > "process" patents that have been recently issued... > > > >Article: 32486
Austin Lesea wrote: > Tom, > > The Golgafrinchian Ark "B" had no lawyers on it. Perhaps this is the reason why. > > If you search for patents in my name, (or Peter's) you may be amused at what is > "patentable." I hope no one gets "insensed." Hihi! Yes, you patented to use a Virtex-E IOB comparator instead of the external comparator in XAPP155. Can you please license this to me? I am afraid that a student of mine is using this to read out a joystick port in my lab course. [...] > The laws in different countries are also different. > > Tom Seim: > > It might help to look at the big picture: America's economy is largely > > based on a technology lead over the rest of the world (we certainly > > are not going to compete with China on wage rates). Patents are a key > > part of protecting our technology edge. BUT: A lot of stuff that is patentable in the U.S is not patentable in other countries. So you can only protect the U.S. market. Kolja SulimmaArticle: 32487
> I'm sure Xilinx would not claim to own the rights to a wide input OR > function, but they might be able to claim that their *FPGA* was the first of > its > kind to contain such a circuit. No. If I understand correctly, they claim, that: 1. They where the first to publish that you can use an FPGA CLB with 2 4-LUTs and a Mux to build an 8 input AND gate. 2. They did not publish this before 8/99 3. It was not abvious that can do this (albeit they wrote in their own databook years before that you can implement "some 8 input functions" this way. If you read a sentence like this, of what type of function do you think first? ------------------- As a bottom line, I am not opposing the idea of patents. But I believe in the information age the system just does not work anymore. It is not possible for the patent office to check what has been published in newgroups, e-zines and so on. Think of the many good ideas discussed in this group. Just consider the following patent from 2000: http://www.delphion.com/details?pn=US06150839__ This is identical to one of the main features of a publication by Andre Dehon et. al. at FPGA '99 Publications about FPGA architecture are rare. They occur mainly at the FPGA symposium, at FCCM and some other workshops and make only a small parts of the proceedings. The patent office had a FPGA architecture patent filed and did not even check against the two most important conference proceedings of the previous year! Also, it is impossible to successfully check whether there is a patent on an idea I am using. I am willing to pay license fees, but when someone can come and block the import of my product it's not funny anymore. If this is an old patent, the language used will be completely different from modern terms and I have no chance of finding this with a search engine beforehand. Shortening the time a patent protects the holder would help a lot! 20 years is essentially forever when it comes to EE. Kolja SulimmaArticle: 32488
If we shadows have offended... Peter Alfke wrote: > I have broad shoulders, (but thin skin). > So, I can take it, even when it hurts. But I didn't. did I? > And I can also admit when I am wrong. > This should always remain an open and frank newsgroup. > As long as we can keep the weirdos out. Yeahh, weirdos.... Kolja Sulimma P.S.: I see you removed the "stupid" from the subject line ;-)Article: 32489
But the GTL FPGA input comparators for example have very well define switching thresholds. Should work with that very well. But check first if this use of the comparator is patented. (Sorry Austin, could not resist ;-) Kolja Sulimma John_H wrote: > The voltage swings are a bit low for guaranteed operation. While 1.4V is the > approximate switching threshold, guaranteed values of 0.8V and 2.0V requires a > 1.2V swing. The LVPECL will probably generate about 0.8V. Not pretty. > > Falk Brunner wrote: > > > Just a idea about a dirty-low cost LVPECL-> CMOS converter. > > > > How about to use a voltage divider to set the bias on an input near the > > switching point (1.4 V for TTL) and then capacitiv couple the LVPECL > > signal into the pin. Since this signal is a clock signal, no problems > > with low frequency components. Will this work?Article: 32490
Austin Lesea wrote: > Tom, > > I suggest that anyone really hot about this issue go work as an expert witness for awhile: > excellent pay (even while traveling!), good food, short hours. Email us with the number of > months you could stomach it, before you give up the fat living, and go back to a real job > in total disgust and disillusionment....... > > Austin > This has the true sound of personal experience about it.Article: 32491
I have just started using the ModelSim XE evaluation version. I am used to using MaxPlus for simulation. Is there an easy way to import "vector" files to act as stimulus for the modelsim simulator? I've written .m files to generate and read back .vec and .tbl files from Altera but I don't see any way to do this with Modelsim. Alternatively, is there another way to get waveforms from matlab through Modelsim and back into matlab? Thanks in advance, Clark PopeArticle: 32493
How about: http://splorg.org/~tobin/jamplayer/index.shtml muffinews wrote: > > Hi guys, > > I have been searching for possibilities to configure Altera devices > via JTAG using a small command-line tool. > I found something at www.jamisp.com (called jam-player) but this stuff > is for win. They have also included the source code and some info > about porting this stuff to unix, etc. I put out all my knowlegde > about makefiles and managed to create the executable for linux. > THE PROBLEM: > --> the linux version does not support ByteBlaster, only the > BitBlaster is useable!! > > So, has anyone an idea where to get a ByteBlaster capable > linux-jam-player?? > > Regards, > > Muffi -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 32494
Consider Actel. Their one time programmable parts are quite easy to use and the configuration cannot be upset. You can mitigate upsets in the data by using triple redundancy in critical registers such as state machines. They even publish a synthesis library that will automatically insert TMR logic. Sorry to break up the Xilinx love fest but my experience using Actel antifuse parts for satellite customers has been really positive. -- Pete Dudley Arroyo Grande Systems "Michael Boehnel" <boehnel@iti.tu-graz.ac.at> wrote in message news:3B386F7F.C29974E0@iti.tu-graz.ac.at... > Hi, all! > > State machines (SM) are made more secure with additional logic which > detects an illegal state. If an illegal state occurs the SM is forced to > a special state (trap state; reset state) from where it can start > working correctly again. So far so good. > > What happens, if the additional logic is placed in LUTs of an FPGA? > Aren't the LUTs vulnerable from radiation too? > Is there a better protection for the configuration than for the FPGA's > FFs? > > Michael > >Article: 32495
Nice to hear that my idea isnt that bad. But how about the toggle rate of the FFs in the 95288XL? Will it work, if I configure on FF as an T-FF and clock it via a global clock net (155 MHz, duty cycle somewere 40% or so, with only one FF connected to it) ??. Regards FalkArticle: 32496
On Wed, 27 Jun 2001 09:13:20 -0400, Keith R. Williams <krw@attglobal.net> wrote: >In article <9hb26c$jav$1@slb6.atl.mindspring.net>, >austin@da98rkroom.com says... >> >> > The xilinx >> > mapper will push the FF's to the IOBs if you set the IOB FF's option >> > appropriately provided the rules are met for the IOB FFs. >> >> That's what I do. It is the "pr -b" option to map: >> >> map -pr b filename > >I've tried all of the above and it still appears the flops aren't >getting pushed into the IOBs (this is a XCS40XL-BG256). Map reports: > > Number of External IOBs 190 out of 224 92% > Flops: 0 > Latches: 0 > >---- > Keith map -pr b doesn't always map IOB flops. Using my synthesis tool (Leonardo) I had a frustrating time getting the IO flops where I wanted them. If it doesn't happen right away, there will be a reason, somewhere, that prevents the mapping. Typically you express a desing that allows the mapping, but the synthesis tool optimises it into one that doesn't. And in my opinion the diagnostics are seriously lacking .... MAP probably knows why it can't move that FF into that IOB, but it isn't going to tell you... I have resorted to reading .edf files and comparing parts that worked with parts that don't. Typically: the individual output enables (ENBFF) have been optimised away leaving a single signal; or they have the wrong polarity (they must be active low); or the (INFF/OUTFF) flop was part of a chain that has been optimised into a SRL; or the (OUTFF) flop has been combined with an identical one whose output was used internally; or something like that. Modifying the design into one that the synthesiser won't screw up has been, for me, a tedious and iterative process (not helped by the poor diagnostics) Keith: you could check your design for the abovementioned conditions (not an exhaustive list) and see if fixing them corrects the problem. XILINX: 1) You could improve the MAP diagnostics to say why flops couldn't be mapped ... e.g. <pin>: ENBFF - not mapped into IOB, shared enable signal. <pin>: OUTFF - not mapped into IOB, shared output signal. etc... 2) You could actually describe the UCF constraints in the documentation (I only found out about IOBDELAY from the answers database, looking for something else. Try searching for it in the supplied documentation...) Synthesis vendors: you could improve the behaviour (or at least diagnostics) to attributes/constraints (preserve_signal) etc. I have had mixed luck with these attrributes, and never quite gotten to the bottom of why. (somehow, the signal I was preserving was optimised away anyway. Do you need both "noopt" and "preserve_signal", or what?) - BrianArticle: 32498
hello, i want to implement parallel-parallel multiplier for Xc4k,( coefficient variable ), which architecture will you recommend ? how coding this in VHDL, using just C=a*b how performant will be if we just code it in vhdl using the equation Out=A*B, has someone done any investigation in the matter ? thanksArticle: 32499
hello, with the outcome of virtex,virtex-e, virtex-II, should we have the right to still speak about Xc4k design ? for how long will you expect the Xc4k to still exist? which type precisely, E?,EX,XV thanks
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