Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 28 Sep., 19:43, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > Antti wrote: > > Hi > > > I am evaluating the possibility to use 2 resitor video output from > > FPGA similar to: > > >http://www.excamera.com/articles/15/ntsc.html > > > to generate color NTSC output, so far my results show less quality > > then the test picture in the link above > > I use 300/600 ohm with Xilinx Spartan3A starterkit > > > I am not yet sure if the difference in visible output is from the > > different receiver USB video grabber vs TV receiver, but the video as > > grabbed with cheap 25EUR grabber is very noisy, almost like the 80MHz > > would be pass the input filtering so that the 16 shaders are almost > > not recognizeable, also there is too much noisy flickering at the top > > the screen. I will be testing with real TV set later, so I can compare > > better. > > > so just asking if anyone has any compare results or suggestions for > > ultra low cost and simple direct video output with FPGA, there is one > > design with 9 resistors and 2 bipolar transistors, or then R-2R type > > networking, both are too complex, if a PWM based solution could work > > with some little neat tricks > > > Antti > > That's interesting. I think several of the Xilinx evaluation boards > have VGA outputs with R-2R networks so you get a very limited set of > colors. I'm not sure why you wouldn't just use a video DAC, though. > Are they too expensive? They can be very small and low-resolution > versions don't use too many inputs. > -Kevin- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - VGA is much simpler then color NTSC/PAL ;) R-2R is an option of course, but i would rather use 2 resistors then the R-2R network AnttiArticle: 124626
Hi, I need a 1:8 (ok 1:10 is good too) differential LVDS clock driver with clock bank enable (individual clk enabling option for every output) and very good clock skew parameters. It seems there is an industrial standard of serial programmable 1:10 LVDSin/LVDSout buffer (STLVD111 or PCK2111, etc) but I dislike the serial programming. I need one with parallel enabling feature, being driven directly by the PCIe card detect signal, like SN65LVDS108 (which can't be used for a PCIe clk because of the huge skew). Unfortunately I didn't found any which met the PCIe clk requirement. Any clue appreciated. thx, VasileArticle: 124627
http://www.vmetro.com/article4056-1276.html On Sep 27, 6:35 am, Sanka Piyaratna <jayasanka.piyara...@gmail.com> wrote: > Hi Everyone, > > Are there any hardware modules that I can buy to convert a data stream > (serial FPDP over fibre) into PCI express and connect to a PC using the > PCIe port? I have not been able to find a module that does this and so I > am thinking about implementing the conversion in V5 ML555 evaluation > board. In this case I need to find a good place to get hold of an > serial FPDP core for Virtex 5. Could you please help me with this? > > Thanks, > > Regards, > > SankaArticle: 124628
"vasile" <piclist9@gmail.com> wrote in message news:1191002912.679438.69810@o80g2000hse.googlegroups.com... > Hi, > > I need a 1:8 (ok 1:10 is good too) differential LVDS clock driver with > clock bank enable (individual clk enabling option for every output) > and very good clock skew parameters. It seems there is an industrial > standard of serial programmable 1:10 LVDSin/LVDSout buffer (STLVD111 > or PCK2111, etc) but I dislike the serial programming. I need one with > parallel enabling feature, being driven directly by the PCIe card > detect signal, like SN65LVDS108 (which can't be used for a PCIe clk > because of the huge skew). Unfortunately I didn't found any which met > the PCIe clk requirement. > Any clue appreciated. > > thx, > Vasile > On Semiconductor has some simple ones. BobArticle: 124629
Hi I know many wise men has said NO NO, but 1) http://www.latticesemi.com/forums/forum/messageview.cfm?catid=42&threadid=3505 Lattice engineer suggest that it works (assumable reliable) on machXO the IO technology between machXO and Xilinx FPGAs isnt so big so I wonder why cant it be done with Xilinx ? for what I see is following 25MHz crystal 27p caps 560 series 1M parallel when using LVCMOS33 SLEW=FAST then there is some sort of overdrive, that makes oscillation to periodically stop and restart 200 us work then 75 idle, then restarts again, the FPGA input sees however nice 25MHz from the crystal ALL time, (also when the output doesnt swing) by simply changing slew=slow the circuit does start work reliable. so any technical reasons why this circuit can not (should not) be used?? crystal vs oscillator price difference is still some 0.30 USD, so why waste the pennies AnttiArticle: 124630
Ok, this doesn't have much to do with fpga's, but I need some help and you guys are a great knowledge base. In all our designs we use an ARM7 microcontroller, a flash, and a FPGA. The ARM powers up and downloads the fpga and we are "up". We have been using a Macraigor "Wiggler" to initially program the flash, or to re-program the flash after we screw up programming and kill the boot sector. Recently we upgraded the Wiggler code (without backing up our system - really stupid!) and since then, we have not been able to program the flash on a couple of our products while our other products seem to program just fine. We have sent boards to Macraigor and have asked for old code to see if we could at least get back to where we were, but they have been very unresponsive and say they don't even keep copies of microcode that's over a couple years old. So anyway, is there a wiggler clone out there somewhere that we could buy and get on with life? We are tired of fighting with Macraigor and more tired of not being able to reliably program our products. Thanks DanArticle: 124631
On 28 Sep., 20:59, "Dan K" <danielgkNOS...@visi.com> wrote: > Ok, this doesn't have much to do with fpga's, but I need some help and you > guys are a great knowledge base. > > In all our designs we use an ARM7 microcontroller, a flash, and a FPGA. The > ARM powers up and downloads the fpga and we are "up". We have been using a > Macraigor "Wiggler" to initially program the flash, or to re-program the > flash after we screw up programming and kill the boot sector. Recently we > upgraded the Wiggler code (without backing up our system - really stupid!) > and since then, we have not been able to program the flash on a couple of > our products while our other products seem to program just fine. We have > sent boards to Macraigor and have asked for old code to see if we could at > least get back to where we were, but they have been very unresponsive and > say they don't even keep copies of microcode that's over a couple years old. > So anyway, is there a wiggler clone out there somewhere that we could buy > and get on with life? We are tired of fighting with Macraigor and more > tired of not being able to reliably program our products. > > Thanks > > Dan just use openocd AnttiArticle: 124632
>> They have to pay for the software development anyway. >> I think the economics term is "sunk costs". >Well, I think your resoning is maybe flawed. They have to pay for the >engineering design on the silicon 'anyway'. Yet you're not asking for >devices which don't take that NRE cost into account. Someone has to pay for >the costs, sunk or otherwise. The incremental cost to make more software is almost zero. (That's not true if you use a package with licensing fees.) The incremental cost of make chips is not zero. You can ship software with no support, or only provide support to people who are willing to pay for it. You can't do that with silicon. I'm not an MBA type. I assume the NRE gets factored into the go/no-go decision when considering a new chip. But once you have made that decision and invested that NRE, it becomes money over the dam. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124633
Dan K wrote: > So anyway, is there a wiggler clone out there somewhere that we could buy > and get on with life? We are tired of fighting with Macraigor and more > tired of not being able to reliably program our products. We recently got some of these: http://www.olimex.com/dev/arm-usb-ocd.html Work fine under Windows and Linux, are quite cheap (we paid ~60EUR) and fast. No problems so far with these. They have a Wiggler clone as well: http://www.olimex.com/dev/arm-jtag.html HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 124634
>In all our designs we use an ARM7 microcontroller, a flash, and a FPGA. The >ARM powers up and downloads the fpga and we are "up". We have been using a >Macraigor "Wiggler" to initially program the flash, or to re-program the >flash after we screw up programming and kill the boot sector. Recently we >upgraded the Wiggler code (without backing up our system - really stupid!) >and since then, we have not been able to program the flash on a couple of >our products while our other products seem to program just fine. We have >sent boards to Macraigor and have asked for old code to see if we could at >least get back to where we were, but they have been very unresponsive and >say they don't even keep copies of microcode that's over a couple years old. >So anyway, is there a wiggler clone out there somewhere that we could buy >and get on with life? We are tired of fighting with Macraigor and more >tired of not being able to reliably program our products. This is obvious in hindsight, but just for the record... When you "release" hardware or software/firmware, it's a good idea to package up all the design files, software, whatever into a nice neat archive bundle. That also includes the tools and libraries that you used. If you are really paranoid, that also includes the OS and such. I'm somewhat surprised you couldn't find a copy of what you need in your backups. You do have backups, right? Many sites store an occasional backup (monthly) off site in case the building burns down. Once you are doing that, it's pretty easy to keep a few extra months in case you can't read the media and/or backups from a year ago in case you really really need something like this. It's also worth testing your archive/backup plan. Take a new box and load the software and see if it all works. (Make sure it isn't peeking at some file server.) -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124635
Antti, The circuit works, only because the IO acts like an inverter with a very small delay. If the IO has more delay, than the circiut will not start up (always). We do not recommend the use of a crystal like this, as we have experience that it doesn't always start up. Will it work once? Sure. Will it works always, nope. I suppose Lattice isn't large enough to worry... Austin Antti wrote: > Hi > > I know many wise men has said NO NO, but > > 1) > http://www.latticesemi.com/forums/forum/messageview.cfm?catid=42&threadid=3505 > > Lattice engineer suggest that it works (assumable reliable) on machXO > > the IO technology between machXO and Xilinx FPGAs isnt so big so I > wonder why cant it be done with Xilinx ? > > for what I see is following > > 25MHz crystal > 27p caps > 560 series > 1M parallel > > when using LVCMOS33 SLEW=FAST > > then there is some sort of overdrive, that makes oscillation to > periodically stop and restart > 200 us work then 75 idle, then restarts again, the FPGA input sees > however nice 25MHz > from the crystal ALL time, (also when the output doesnt swing) > > by simply changing slew=slow the circuit does start work reliable. > > so any technical reasons why this circuit can not (should not) be > used?? > > crystal vs oscillator price difference is still some 0.30 USD, so why > waste the pennies > > Antti >Article: 124636
Jeff Cunningham wrote: > Jon Elson wrote: > >> ... (I don't know why anyone would WANT to use ModelSim, it seems >> insanely creaky and cumbersome, and I have to relearn the DAMN thing >> every time I use it.) ... > > > Jon, > I've always rather liked modelsim (not its price!) - but I'm not > defending it - I'm just curious if you know of any better solutions for > simulation. > -Jeff I had better first explain I am stuck with Xilinx's ise 4.2 due to the later versions not supporting 5 V FPGAs. I am getting ready to move some of my products to newer chips, but still see no need to pay even more $ to Xilinx. So, Maybe Modelsim has improved since the version I use. Part of it is I don't use it often enough to remember where to find internal signals, and have to poke around in a hierarchy of menus to find what I want and get it on the screen. I've never figured out how to save that setup and get it back again for the next sim run. Maybe I need to do some serious RTFM. JonArticle: 124637
Matthew Hicks wrote: > I prefer Active-HDL, it has all of the same features as ModelSim and a > much better GUI. Plus it has better options for driving signals during > a quick simulation run. Although I did find a bug in a recent past > version but it has been fixed in the current version. The version of > ModelSim at the time didn't have the same problem. Yes, these sound like many of the things I find cumbersome in ModelSim. I'll have to try out this Active-HDL. Thanks! JonArticle: 124638
On Sep 3, 11:17 am, austin <aus...@xilinx.com> wrote: > Andreas, > > Per the license agreement that one signs to get the software, 'reverse > engineering' is a violation. License agreements contain all sort of over-reaching unenforceable nonsense... Of course figuring out what is and isn't isn't trivially, but a good portions of it is nothing but FUD. Keep in mind that there are some explicit exemptions in law for reverse engineering for purposes of interoperability, but again figuring out how those match up against over reaching vendor claims is non trivial.Article: 124639
On Sep 28, 12:31 pm, Ray Andraka <r...@andraka.com> wrote: > Andy wrote: > > When you let it infer ram, are you getting LUT based rams > > (combinatorial read), or block rams (registered reads)? > > > LUT rams cannot be reset. I seem to recall block rams on some devices > > can have a reset. But the results of that reset may be deferred by the > > synchronous read circuitry (depending on whether you registered the > > read address, or registered the read data in the inferring code), so > > implementing that same cycle-accurate behavior may take more flops > > than you thought, but since you did not post how you are reading the > > RAM, I cannot tell. > > > Andy > > The Block RAM reset does not reset cells in the memory array, it just > resets bits in the output register forcing the output to the reset > value. The contents of the array are left unchanged. Thanks for the clarification. Maybe Synplify was trying to create a shadow register that held a "reset" status bit for each word, that would drive the ram output reg reset (or AND with it) whenever that word was read, until it had been written to. Clever trick... maybe they just forgot to pull it out w hen they go back to registers? I've also seen Synplify put a feedback mux around a ram that did not have a reset, but was inferred from a process that did have an async reset (due to the 'elsif rising_edge()' not executing during reset). I wonder if that could be related to what's going on? Without code, it is really hard to tell. AndyArticle: 124640
Hi! It seems that many subscribers of this group are professional FPGA/ ASIC designers working for European companies. Now, some time ago I have seen that one person has introduced his/hers concerns about lack of job offers on the job posting sites and was assured that the jobs are there but not necessarily announced. Therefore I ask you, do you know about open application for FPGA/ASIC Designer? I am a student, graduating in October, looking for entry-level/trainee position. I would be happy to work in either Ireland, UK, Netherlands, Sweden or Finland (random order). I am eligible to work in any of these countries without a work permit (an UE citizen). I won't disclose my personal data on Usenet for obvious reasons. I will appreciate any information sent to me via e-mail. theanonymous83 A_T gmail.comArticle: 124641
You can use a TCL script in ModelSim to at least setup the simulation environment and wave window the way you want. Each time you want get the setup just type do filename.do in ModelSim's command window. ModelSim is also good in that it gives you the the TCL command equivalent for most of the options you select and actions you take in the GUI (probably because that is how their kludgy GUI actually communicates to the simulation program). ---Matthew Hicks > Jeff Cunningham wrote: > >> Jon Elson wrote: >> >>> ... (I don't know why anyone would WANT to use ModelSim, it seems >>> insanely creaky and cumbersome, and I have to relearn the DAMN thing >>> every time I use it.) ... >>> >> Jon, >> I've always rather liked modelsim (not its price!) - but I'm not >> defending it - I'm just curious if you know of any better solutions >> for >> simulation. >> -Jeff > I had better first explain I am stuck with Xilinx's ise 4.2 due to the > later versions not supporting 5 V FPGAs. I am getting ready to move > some of my products to newer chips, but still see no need to pay even > more $ to Xilinx. So, Maybe Modelsim has improved since the version I > use. Part of it is I don't use it often enough to remember where to > find internal signals, and have to poke around in a hierarchy of menus > to find what I want and get it on the screen. I've never figured out > how to save that setup and get it back again for the next sim run. > Maybe I need to do some serious RTFM. > > Jon >Article: 124642
You don't tend to get many jobs advertised on this newsgroup and it tends to concentrate on technical issues. Many companies do list jobs on their own websites and some even have direct contacts with university departments so worth asking there too. Occasionally recruitment agencies fill the gap but some companies like ourselves have a policy of not recruiting due to the fees agencies charge and maybe a just a little because the irrating number of calls they make even when they are told that you never use an agency. John Adair Enterpoint Ltd. On 28 Sep, 23:25, theanonymou...@gmail.com wrote: > Hi! > > It seems that many subscribers of this group are professional FPGA/ > ASIC designers working for European companies. Now, some time ago I > have seen that one person has introduced his/hers concerns about lack > of job offers on the job posting sites and was assured that the jobs > are there but not necessarily announced. Therefore I ask you, do you > know about open application for FPGA/ASIC Designer? > > I am a student, graduating in October, looking for entry-level/trainee > position. I would be happy to work in either Ireland, UK, Netherlands, > Sweden or Finland (random order). I am eligible to work in any of > these countries without a work permit (an UE citizen). > > I won't disclose my personal data on Usenet for obvious reasons. I > will appreciate any information sent to me via e-mail. > > theanonymous83 A_T gmail.comArticle: 124643
Austin Might be worth making the suggestion to your sister grouping of GPD of adding a dedicated oscillator crcuit to their range of products. Given a lot of micros do that already there would be some logic in adding such a circuit in the future to the low cost sector FPGA families. John Adair Enterpoint Ltd. On 28 Sep, 21:21, austin <aus...@xilinx.com> wrote: > Antti, > > The circuit works, only because the IO acts like an inverter with a very > small delay. > > If the IO has more delay, than the circiut will not start up (always). > > We do not recommend the use of a crystal like this, as we have > experience that it doesn't always start up. > > Will it work once? Sure. Will it works always, nope. > > I suppose Lattice isn't large enough to worry... > > Austin > > > > Antti wrote: > > Hi > > > I know many wise men has said NO NO, but > > > 1) > >http://www.latticesemi.com/forums/forum/messageview.cfm?catid=42&thre... > > > Lattice engineer suggest that it works (assumable reliable) on machXO > > > the IO technology between machXO and Xilinx FPGAs isnt so big so I > > wonder why cant it be done with Xilinx ? > > > for what I see is following > > > 25MHz crystal > > 27p caps > > 560 series > > 1M parallel > > > when using LVCMOS33 SLEW=FAST > > > then there is some sort of overdrive, that makes oscillation to > > periodically stop and restart > > 200 us work then 75 idle, then restarts again, the FPGA input sees > > however nice 25MHz > > from the crystal ALL time, (also when the output doesnt swing) > > > by simply changing slew=slow the circuit does start work reliable. > > > so any technical reasons why this circuit can not (should not) be > > used?? > > > crystal vs oscillator price difference is still some 0.30 USD, so why > > waste the pennies > > > Antti- Hide quoted text - > > - Show quoted text -Article: 124644
On Sep 28, 3:03 pm, Antti wrote: > VGA is much simpler then color NTSC/PAL ;) > > R-2R is an option of course, but i would rather use 2 resistors then > the R-2R network Here is what my experiments with four resistors looked like (the camera wasn't a good one - the image was nicer live): http://www.merlintec.com:8080/hardware/uploads/14/oliver7a.jpg -- JecelArticle: 124645
On Sep 28, 5:05 pm, John Adair <g...@enterpoint.co.uk> wrote: > Austin > > Might be worth making the suggestion to your sister grouping of GPD of > adding a dedicated oscillator crcuit to their range of products. Given > a lot of micros do that already there would be some logic in adding > such a circuit in the future to the low cost sector FPGA families. > John, "been there, done that". XC3000 used to have a single-stage dedicated inverter, exactly for that purpose. It caused us a lot of support grief. Between 32 kHz and 100 MHz, there is a big variation in xtals, and there also was a sensitivity to Vcc ramp-up rate. Nobody wants a circuit to work "most of the time". I also remember that many of the Intel mask revisions of the 8051 were oscillator-related. (We second-sourced that at AMD) My advice has always been: spend a few pennies on an oscillator circuit made by specialists for a special purpose. And definitely do not abuse a multi-stage I/O circuit to be the xtal inverter circuit. Far too much gain and uncontrolled phase changes at very high frequencies. Peter AlfkeArticle: 124646
I have the same problem. I didn't change the ISE or the EDK version but - unfortunately - I had to install Perl on Cygwin and so it updated itself too. Before the update everything was working great. Trying to create the bitstream for a design that was working fine before now I get: Starting Placer FATAL_ERROR:Portability:PortDynamicLib.c:358:1.27 - dll open of library <D:/Xilinx91i/xilinx/bin/nt/libPlXil_Clocks.dll> failed due to an unknown reason. Process will terminate. For more information on this error, please consult the Answers Database or open a WebCase with this project attached at http://www.xilinx.com/support. ERROR:Xflow - Program par returned error code 91. Aborting flow execution... make: *** [implementation/system.bit] Error 1 Done! I'm sure that if I restore cygwin everything is going to back to normal but looks like is not that easy to do. Cheers ~Andrea On Sep 6, 7:08 am, Helmut <helmut.leonha...@gmail.com> wrote: > Hi, > > I have the same problem with ISE 9.2.02 IP1 > But with all my projects run with ISE 9.1.03 IP2, so returning to > previous ISE helps in my case. > > Bye HL > > > Starting Placer > > FATAL_ERROR:Portability:PortDynamicLib.c:358:1.27 - dll open of > > library <C:/Xilinx91i/xilinx/bin/nt/libPlXil_Clocks.dll> failed due to > > an unknown reason. Process will terminate. > > > Process "Place & Route" failedArticle: 124647
On Sep 28, 11:30 am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > I know many wise men has said NO NO, but > > 1)http://www.latticesemi.com/forums/forum/messageview.cfm?catid=42&thre... > > Lattice engineer suggest that it works (assumable reliable) on machXO > > the IO technology between machXO and Xilinx FPGAs isnt so big so I > wonder why cant it be done with Xilinx ? > > for what I see is following > > 25MHz crystal > 27p caps > 560 series > 1M parallel > > when using LVCMOS33 SLEW=FAST This structure works with *any* kind of logic if you understand it has a pure analogic behaviour and you treat it as a sensitive analogic stuff (and not a digital one like most software guys do). The key for a stable oscillation are the crystal parameters and the value of the output capacitor connected to ground. A small one will increase the oscillation amplitude and decrease the stability. A very big one will increase the stability (and the start-up time) and decrease the amplitude below the gate thresold voltage. None of those situations are good. The input capacitor can be adjusted up to 50% without significant changes. If you plan a mass production, I suggest a variable capacitor of 5-25pF in parallel with a 12pF-20pF (replacing the fixed output capacitor) for the first board and a carefully observation of the amplitude at different ambiant temperatures using a good scope and a 10:1 probe. However, the question "why using a crystal" still remains. Vasile From invalid@dont.spam Fri Sep 28 22:43:47 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!nx01.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny05.POSTED!933f7776!not-for-mail From: Phil Hays <invalid@dont.spam> Subject: Re: 2 leg crystal on FPGA: Lattice vs Xilinx User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.09.29.05.43.46.745176@dont.spam> Newsgroups: comp.arch.fpga References: <1191004215.511717.128950@w3g2000hsg.googlegroups.com> <1191042978.594191.228870@g4g2000hsf.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 40 Date: Sat, 29 Sep 2007 05:43:47 GMT NNTP-Posting-Host: 71.113.113.13 X-Complaints-To: abuse@verizon.net X-Trace: trndny05 1191044627 71.113.113.13 (Sat, 29 Sep 2007 01:43:47 EDT) NNTP-Posting-Date: Sat, 29 Sep 2007 01:43:47 EDT Xref: prodigy.net comp.arch.fpga:136596 X-Received-Date: Sat, 29 Sep 2007 01:43:48 EDT (newsdbm02.news.prodigy.net) vasile wrote: > On Sep 28, 11:30 am, Antti <Antti.Luk...@googlemail.com> wrote: >> Hi >> >> I know many wise men has said NO NO, but >> >> 1)http://www.latticesemi.com/forums/forum/messageview.cfm?catid=42&thre... >> >> Lattice engineer suggest that it works (assumable reliable) on machXO >> >> the IO technology between machXO and Xilinx FPGAs isnt so big so I >> wonder why cant it be done with Xilinx ? >> >> for what I see is following >> >> 25MHz crystal >> 27p caps >> 560 series >> 1M parallel >> >> when using LVCMOS33 SLEW=FAST > > This structure works with *any* kind of logic if you understand it has a > pure analogic behaviour and you treat it as a sensitive analogic stuff > (and not a digital one like most software guys do). Well, no. Back when I was quite a bit younger, I tried to build a stable oscillator with a unused gate on a TTL 7414, with is an inverter with hysteresis. Tried all sorts of values of capacitors and resisters, and the best I was able to do was to usually generate the third harmonic. Sometimes the fifth, sometimes some other multiple of the crystal frequency, sometimes not a stable frequency, and sometimes even the frequency of the crystal. Switched to using a 7404, a plain inverter, and then making a stable oscillator was easy. -- Phil HaysArticle: 124648
>Well, no. Back when I was quite a bit younger, I tried to build a stable >oscillator with a unused gate on a TTL 7414, with is an inverter with >hysteresis. Tried all sorts of values of capacitors and resisters, and the >best I was able to do was to usually generate the third harmonic. >Sometimes the fifth, sometimes some other multiple of the crystal >frequency, sometimes not a stable frequency, and sometimes even the >frequency of the crystal. Switched to using a 7404, a plain inverter, and >then making a stable oscillator was easy. Did you put it into production and ship a million of them? They used to make 74U04, U for unbuffered. It was intended for hacks like this. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124649
On 29 Sep., 02:05, John Adair <g...@enterpoint.co.uk> wrote: > Austin > > Might be worth making the suggestion to your sister grouping of GPD of > adding a dedicated oscillator crcuit to their range of products. Given > a lot of micros do that already there would be some logic in adding > such a circuit in the future to the low cost sector FPGA families. > > John Adair > Enterpoint Ltd. > I have submitted this idea (at least 1 DCM with pins for crystal) many years ago. Antti
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