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
> Nothing like failure to cause one to abandon a feature forever. > > A crystal oscillator that: always starts, is always the right frequency, > and is cheap -- is best left to those who have solved it for a few dozen > useful frequencies (and even they have their share of headaches). > > It would be (and is) a horrible business risk to attempt to supply a > circuit that would always work for every possible crystal from near DC > to daylight. Of course it is understandable that you want to minimize your risk. However, mosts user would benefit from this, as everyone needs an clock from somewhere. I cannot really believe that this is rocket-sience, as almost every uC out there has this. Most likely you can buy the IP for some bucks so that you have not to reinvent the wheel yourself? An addition or alternative to the crystal-oscillator could be a calibrated internal oscillator with reasonable precision (e.g. +/-1 %). Maybe X, A and L can look at Actel (Fusion), they have solved this almost perfectly, at least according to the first look at the datasheet... Thomas www.entner-electronics.comArticle: 106526
> Most vanilla Osc circuits struggle with overtone crystals (above appx > 25-40MHz), and for FPGAs that is on the 'low' side of useful. Why not using the PLLs for this? ThomasArticle: 106527
Peter Alfke wrote: > Been there, done that. > XC3000 had (has) two pins that wrap around a single-stage buffer, and > are meant to be connected to a xtal. Add a biaing resistor plus the > obligatory caps to form a Colpitts oscillator. > It was a support nightmare. Even if 99% of applications had no problem, > the remaining 1% drove us crazy. Too little gain, too much gain, too > low a frequency (32 kHz), too high a frequency (>100 MHz), doesn't > start at cold, bad pc-board layout, etc > Canned oscillators are made by experts, using exactly the best chip for > the particular frequency, and use the smallest amount of power. And > they are surprisingly cheap, far less than the $6 quoted in the posting > here. Where can I find those. I may be looking at the wrong place. I need a 2.5V one. Here is a link for digikey where the quoted price is $5.97 http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=375484&Row=706244&Site=US Sumit > You can even get a 312.5 MHz oscillator for a few dollars...(Sits in > every cellphone) > Never again will we put that driver into an FPGA ! > Peter Alfke, Xilinx > PS: when I was at AMD, we second-sourced the 8051. Most of Intel's mask > revisions were caused by their oscillator circuit... > ===================================Article: 106528
> Well now THAT is incredibly surprising since the on-chip memory should be giving you 0 wait state, 0 latency performance (i.e. > WaitRequest should That's not right anymore. You have at minimum one cycle latency as addresses are registered in current on-chip RAMs. Probably also the output is registered. However, I don't know - would have to look into the VHDL code. > always be low when accessing memory). That would seem to point to either waitrequest always low would only be possible with pipelining using datavalid. That helps on cach fill, but not on an ordinary read. Perhaps I should try to connect the on-chip RAM to my 'native' SimpCon interface and check the performance. That should be better than the 2 cycle SRAM. However, this is a more theoretical experiment as Java programs usually will not fit into on-chip RAMs ;-) C programs with NIOS are more code efficient. > some issue that comes up every now and then in your 'CPU to Avalon' bridge master interface logic or something equally odd inside > the Avalon fabric itself connecting the CPU to the memory. One issue is that my CPU takes advantage from this 'counting down ready' signal (the bsy_cnt in SimpCon). I can't do this with the Avalon spec. Therefore, there is a preformance penalty - Inherent due to the design. > I'd be interested to hear what you find. The CPU/Avalon bridge is probably sub-optimal. Will try to check this out (First I have to get the Altera ModelSim version running - would make it easier - still havn't compiled the missing SOPC libraries for ModelSim). MartinArticle: 106529
DigiKey is a very valuable source of components when you need next-day delivery. I would never use DigiKey to figure out a low price point for production volumes. Peter Alfke ================== shrutisumit@gmail.com wrote: > Peter Alfke wrote: > > Been there, done that. > > XC3000 had (has) two pins that wrap around a single-stage buffer, and > > are meant to be connected to a xtal. Add a biaing resistor plus the > > obligatory caps to form a Colpitts oscillator. > > It was a support nightmare. Even if 99% of applications had no problem, > > the remaining 1% drove us crazy. Too little gain, too much gain, too > > low a frequency (32 kHz), too high a frequency (>100 MHz), doesn't > > start at cold, bad pc-board layout, etc > > Canned oscillators are made by experts, using exactly the best chip for > > the particular frequency, and use the smallest amount of power. And > > they are surprisingly cheap, far less than the $6 quoted in the posting > > here. > > Where can I find those. I may be looking at the wrong place. I need a > 2.5V one. Here is a link for digikey where the quoted price is $5.97 > > http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=375484&Row=706244&Site=US > > Sumit > > > You can even get a 312.5 MHz oscillator for a few dollars...(Sits in > > every cellphone) > > Never again will we put that driver into an FPGA ! > > Peter Alfke, Xilinx > > PS: when I was at AMD, we second-sourced the 8051. Most of Intel's mask > > revisions were caused by their oscillator circuit... > > ===================================Article: 106530
Well. I wasn't gonna buy too many. I checked Mouser also but no luck, But thanks to everybody for the reply. I now understand the reason why FPGAs dont take crystal input. Sumit Peter Alfke wrote: > DigiKey is a very valuable source of components when you need next-day > delivery. > I would never use DigiKey to figure out a low price point for > production volumes. > Peter Alfke > ================== > > shrutisumit@gmail.com wrote: > > Peter Alfke wrote: > > > Been there, done that. > > > XC3000 had (has) two pins that wrap around a single-stage buffer, and > > > are meant to be connected to a xtal. Add a biaing resistor plus the > > > obligatory caps to form a Colpitts oscillator. > > > It was a support nightmare. Even if 99% of applications had no problem, > > > the remaining 1% drove us crazy. Too little gain, too much gain, too > > > low a frequency (32 kHz), too high a frequency (>100 MHz), doesn't > > > start at cold, bad pc-board layout, etc > > > Canned oscillators are made by experts, using exactly the best chip for > > > the particular frequency, and use the smallest amount of power. And > > > they are surprisingly cheap, far less than the $6 quoted in the posting > > > here. > > > > Where can I find those. I may be looking at the wrong place. I need a > > 2.5V one. Here is a link for digikey where the quoted price is $5.97 > > > > http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=375484&Row=706244&Site=US > > > > Sumit > > > > > You can even get a 312.5 MHz oscillator for a few dollars...(Sits in > > > every cellphone) > > > Never again will we put that driver into an FPGA ! > > > Peter Alfke, Xilinx > > > PS: when I was at AMD, we second-sourced the 8051. Most of Intel's mask > > > revisions were caused by their oscillator circuit... > > > ===================================Article: 106531
shrutisumit@gmail.com wrote: > Where can I find those. I may be looking at the wrong place. I need a > 2.5V one. Here is a link for digikey where the quoted price is $5.97 > > http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=375484&Row=706244&Site=US You could use 10 MHz ( http://dkc3.digikey.com/PDF/T062/0962.pdf ) or even lower frequencies and then use the DFS of a DCM to generate higher frequencies. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106532
hi why not have the one fixed max frequency on chip, and have a programmable divider to get a subfrequency if this must be locked to an external clock, the factors are the high capacitance of the crystal, necessitating, a big drive inverter/buffer (XTAL0), which works at high frequency. and enough gain on (XTAL1 pin) that positive feedback occurs. a chain of three inverters, will provide squareish wave. to avoid problems of offset drift in the high impedance of XTAL1 pin it is required that some kind of very small hysterysis (+ve feedback through resistance) after two of the tree inverters is mixed on chip with the XTAL1 in signal, as this flots the XTAL1 pin arround 1/2 supply. the first inverter has to have long channels to reduce power disipation and the last has to have wide channels to drive the XTAL0 pin. the middle one should make the three a gemetric progression of on resistance. a differential pair would make a better comparator for the first inverter, with lower power consumption, and the ability to apply an integration of the signal in as negative feedback to reduce the hystresys needed, which in turn aids starting of the oscillator. basic rule is keep external osc frequency low (less slew rate problems and power dissipation problems), and use a fully digital lock loop (PLL actually frequency locked loop) based on gate delays as the on chip oscillator (must use high resistance inverters for low power, which make longer delay), and use a divider counter to effect VCO. this solution has much jitter, but in most cases external bus speeds are slower than internal ones, and so the jitter % is small. http://indi.joox.net for an open hardware initial CPU specification document, still being written. Cheers jackoArticle: 106533
Jim Granville wrote: > rickman wrote: > > The Coolrunner XPLA3 parts are pretty good. Other than not having > > schmitt trigger inputs, what don't you like about them? > > I like their JTAG enable pin, so you don't have to loose valuable pins > for JTAG - but they are narrow Vcc operation, and only promise < 100uA, > and Xilinx do not have them on the on-line store, and are sparse > elsewhere, so have that NFND look about them.... > > How long is your product lifetime ? Xilinx still sells much older CPLDs and the XPLA3 parts are 5 volt tolerant which may not be in high demand in new designs, but you can't easily design the part out with a non-5 volt tolerant part in its place. I can buy them from stock at Digikey, so someone is still buying them. > >>Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups, > >>Swings from GND to VthP, Nominally 50% duty cycle. Gates very well > >>Can VCO modulate. > > > > > > I don't get this one at all. I looked up the 4046 but all descriptions > > I could find treat the VCO as a black box. I am guessing that the two > > pins are driven with opposite polarity and the cap is grounded at one > > end or the other all the time. So it would be charged like the one pin > > approach and then discharged like the one pin approach. So this is a > > pair of the one pin drivers to give you 50/50 duty cycle? > > > > This seems simple. Any issues with startup? Does it need FFs anywhere > > to make it work without noise? I would think that the lack of schmitt > > trigger inputs would require a FF. > > Yes, normally it is simply a SR latch, with some logic to catch S=R=H. > When running, S,R cross their thresholds only briefly, to trigger the > other phase. Thanks for the tip. I think I will remember this circuit. It would appear to me that this circuit has more dependance on Vth and so would change frequency with temperature more than the three pin circuit which is supposed to be independant of Vth (of which I am not totally convinced). Peter's analysis of the three pin circuit looks pretty good. Any numbers available on the two pin circuit above?Article: 106534
Gerhard Hoffmann wrote: > But please, let me watch it :-) I hope you have a strong stomach! ;) Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 106535
rickman wrote: >>>I don't get this one at all. I looked up the 4046 but all descriptions >>>I could find treat the VCO as a black box. I am guessing that the two >>>pins are driven with opposite polarity and the cap is grounded at one >>>end or the other all the time. So it would be charged like the one pin >>>approach and then discharged like the one pin approach. So this is a >>>pair of the one pin drivers to give you 50/50 duty cycle? >>> >>>This seems simple. Any issues with startup? Does it need FFs anywhere >>>to make it work without noise? I would think that the lack of schmitt >>>trigger inputs would require a FF. >> >>Yes, normally it is simply a SR latch, with some logic to catch S=R=H. >>When running, S,R cross their thresholds only briefly, to trigger the >>other phase. > > > Thanks for the tip. I think I will remember this circuit. It would > appear to me that this circuit has more dependance on Vth and so would > change frequency with temperature more than the three pin circuit which > is supposed to be independant of Vth (of which I am not totally > convinced). Peter's analysis of the three pin circuit looks pretty > good. Any numbers available on the two pin circuit above? Vth of CMOS does not change much with temperature, but the biggest variable, is the absolute value of Vth : that is a process variable. and being digital companies, FPGA vendors will not bother to band Vth as anything other than logic levels.... To check the dependance on Vth, simply drop any of these into spice :) On the 3 pin one, as Vth varies one half of the cycle lengthens, whilst the other half shortens - so the frequency is nominally compensated, but duty cycle varies. -jgArticle: 106536
Colin Paul Gloster wrote: > On Sun, 13 Aug 2006, Davy wrote: > > "I am [..] > confused with 4 > arbitration schemes: > Fixed priority;" > > The one with the highest priority wins. Simple. > > " Round Robin: simple, look-ahead-1,look-ahead-16? > > Is there any book or reference talk about arbiter schemes?" > > Almost any introductory or comprehensive book dealing with concurrency > (e.g. books on multithreading or on operating systems or maybe books on > networking) will contain a mention of fixed priority and round-robin > scheduling. [snip] Hi, Can you recommend a good book about look-ahead arbiter? Thanks! DavyArticle: 106537
Has anyone out there had success instantiating chipscope cores in XPS? I
have a V4FX design that builds with no problem. Then I instantiated
chipscope_opb_iba and chipscope_icon. Now when I build I get the
following error:
ERROR:NgdBuild:455 - logical net 'net_gnd0' has multiple driver(s):
pin G on block XST_GND with type GND
pin O on block
chipscope_opb_iba_0/chipscope_opb_iba_0/i_cs_coregen_chipscope_
opb_iba_0/cs_coregen_chipscope_opb_iba_0/i_no_d/u_ila/u_dout
with type LUT3
WARNING:NgdBuild:452 - logical net 'chipscope_icon_0/control0<3> has not
driver
I am new to xps as well as chipscope, so it is probably a newbie error.
I couldn't find anything in the answers database or usenet archive.
revs:
ise: 8.1.03i
xps: 8.1.02i
cs: 8.1.03i
Someone in another thread mentioned "wiring up" the chipscope_icon core.
How does one do that? All I could figure out how to do was go to system
assembly bus interface view and connect chipscope_opb_iba to the OPB.
thanks,
Jeff
Article: 106538rickman wrote: > >This could work and would only use two pins, one in each direction. >But the device itself would be pushing the boundary of what I would >like to use. > Your four pin scheme is a simpler solution if you have the pins, then you wouldn't need to find a small part with DLL/PLL. > >I assume I would need a 2x clock to generate the 90 degree skewing of >the trailing edge or even a 4x clock if I don't want to play tricks >with using opposite phases clocking FFs. > Yes; I'd probably try a 2x clock with DDR I/O for the transmit waveform. Symon wrote: > > Neat. I guess a problem could be that the signal has some data dependent DC > component. But 8B10B coding fixes that. > Right, that clock modulation scheme duplicates the DC balance of the transmit data; 8B10B should be a nice fit, giving both DC balance and a sync mechanism for alignment. Also, if you want to run near max cable/driver BW out & back, going to a 4x multiply at the "slave" instead of a 2x would make the narrowest modulated clock pulse width the same width as the bit period of the return data path, giving 1/4 rate outbound and 1x inbound data rates. BrianArticle: 106539
On 2006-08-13 23:49:16 -0700, "Antti" <Antti.Lukats@xilant.com> said: > > Simon Gornall schrieb: > >> Hi all, >> >> On 2006-08-10 00:32:52 -0700, "Antti" <Antti.Lukats@xilant.com> said: >> >>> [lots of useful stuff snipped in the interest of brevity] >>> >>> As of multiply access to SDRAM it may be easier to add your peripherals >>> not to the PLB/OPB bus but to the XCL ports of the multichannel SDRAM >>> controller. So the high speed access is streamed directly to SDRAM >>> controller. >> >> So, this is probably a stupid question (it's probably in plain view, >> now that I'm bitching about their site [grin]), but do you have a >> pointer to the documentation about this SDRAM controller, and how you >> interface to it (I found XAPP912 :-) ? Or to any of the >> 'make-your-own-PLB/OPB-device' examples (I found XAPP264 as well, but I >> was figuring there may be a bit more somewhere, a spec, for example :-) >> >> Xilinx sure make it hard to find stuff on their website... I only found >> the XAPPs above using google... You'd have thought there'd be something >> directly under http://www.xilinx.com/edk/ ... >> >> Thanks in advance :-) > > the XCL interface is only described in documentation supplied with the > EDK, > so do not look for any docs on Xilinx website. > > I think the mch_ edk memory controllers could be used without EDK also > with some little wrapper, but such a use is not encouraged > > Antti Hmm. Perhaps I'd just better fork out for the EDK... Thanks for the info though :-) ATB, SimonArticle: 106540
Jeff Cunningham wrote: > Has anyone out there had success instantiating chipscope cores in XPS? I > have a V4FX design that builds with no problem. Then I instantiated > chipscope_opb_iba and chipscope_icon. Now when I build I get the > following error: > > ERROR:NgdBuild:455 - logical net 'net_gnd0' has multiple driver(s): > pin G on block XST_GND with type GND > pin O on block > chipscope_opb_iba_0/chipscope_opb_iba_0/i_cs_coregen_chipscope_ > opb_iba_0/cs_coregen_chipscope_opb_iba_0/i_no_d/u_ila/u_dout > with type LUT3 > WARNING:NgdBuild:452 - logical net 'chipscope_icon_0/control0<3> has not > driver > > I am new to xps as well as chipscope, so it is probably a newbie error. > I couldn't find anything in the answers database or usenet archive. > > revs: > ise: 8.1.03i > xps: 8.1.02i > cs: 8.1.03i > > Someone in another thread mentioned "wiring up" the chipscope_icon core. > How does one do that? All I could figure out how to do was go to system > assembly bus interface view and connect chipscope_opb_iba to the OPB. If you've connected everything properly, the MHS snippet would look something like this: BEGIN chipscope_opb_iba PARAMETER INSTANCE = chipscope_opb_iba_0 PARAMETER HW_VER = 1.01.a PARAMETER C_NUM_DATA_SAMPLES = 1024 BUS_INTERFACE MON_OPB = mb_opb PORT chipscope_icon_control = chipscope_opb_iba_0_icon_control PORT OPB_Clk = sys_clk_s END BEGIN chipscope_icon PARAMETER INSTANCE = chipscope_icon_0 PARAMETER HW_VER = 1.01.a PARAMETER C_NUM_CONTROL_PORTS = 1 PORT control0 = chipscope_opb_iba_0_icon_control END /SivaArticle: 106541
Hi guys, I'm trying to design a very simple system based on Microblaze. I can do Post Place and Route simulation if I have all my instructions and data on the BRAMs. However unfortunately the current applications that I'm trying to run and estimate the power don't fit in the BRAMs so I have no choice but to put them on external memory. Now the problem that I have is that I don't know how to estimate the power with XPower if I have my instructions and data on off-chip memory. I'm not sure but I doubt it if I can do the same simulation with modelsim if I have my instructions on off-chip memory. Thanks alot beforehand for your comments, AmirArticle: 106542
Frank Buss schrieb: > shrutisumit@gmail.com wrote: > > >>Where can I find those. I may be looking at the wrong place. I need a >>2.5V one. Here is a link for digikey where the quoted price is $5.97 >> >>http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=375484&Row=706244&Site=US > > > You could use 10 MHz ( http://dkc3.digikey.com/PDF/T062/0962.pdf ) or even > lower frequencies and then use the DFS of a DCM to generate higher > frequencies. These are the prices that the OP posted. $3,27 for the 2.5V version. (No need to get the expensive frequencies if you have DCMs) The OP said he wanted to buy only a few. Let's say 10 pieces. So maybe a different solution would save him $20. I would say the easiest solution to achieve these $20 savings would be to work a few hours at McDonalds and then spend the money on the simple to use but more expensive oscillators. For higher quantities the OSC should not cost more than $1. Kolja SulimmaArticle: 106543
Does anyone knows where I can find an example of an IIR filter in VHDL ? = It is incredible, I can't find one on google...=20 thanks, Erik !Article: 106544
shrutisumit@gmail.com schrieb: > I am posting this just as a suggestion for future FPGAs. It would be > nice if a crystal can be connected to FPGA to provide clock instead of > a oscillator. The cost difference between an oscillator and a crystal > is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz > one is around $6. But all the crystals are less than $1. I have worked > with PIC microcontrollers in past and they have the option of > connecting both. > Hi, why don't you use something like the ICS501MLF and attach a cheap Crystal to it? A Part search at avnet.com shows a price below $1. Plus the Crystal (e.g. Digikey 631-1030-1-ND) you get a Price over all of $1.50 The only bad thing about this solution is, that it takes some board space and needs either 5.0V or a 3.3V power supply. But you get a stable & good clock signal. I don't see any good reason for a Crystal Input ;-) ChristianArticle: 106545
MM wrote: > Table 7-3 is in the RocketIO manual (UG076 v3.0, May 23, 2006)... > > /Mikhail > Thanks, after staring at that table for a long time (that was where I got the 101, 102 etc numbers from in the first place) I realised that the XnYm numbers were supposed to tell me that the tiles were split into two columns, where n is constant for a column. Whilst this seems blatantly obvious in retrospect, I can't see anywhere where it actually makes that clear. Gripes aside, thanks for taking the time to point out the obvious :) -- PeterArticle: 106546
Jim Wu wrote: > ADEPT shows the MGT map in Excel. The tool is freely available at > http://home.comcast.net/~jimwu88/tools/adept/ > > Below is what you need to do: > * Select and load Device > * View->Display MGT > * Excel->Show MGT Map in Excel > > HTH, > Jim Thanks, Jim. That diagram helped me decipher the datasheet and the table pointed out by another poster. -- PeterArticle: 106547
> Yes, that works, but I like the full mapping as above. > Renaming the signal identifiers as a_s etc. is clearer still: > > port map (a => a_s, -- IN > b => b_s, -- IN > sel => sel_s, -- IN > c => c_s); -- OUT As Mike says you should always instantiate components this way or when you get components of any size (10's of signals in/out) it becomes confusing trying to remember what's connected to what. Nial.Article: 106548
Hi,
i'm trying to put my data into the PROM on the spartan 3 Starter Kit
Board. I followed the instructions in XAPP694 from xilinx and still
have a problem.
here is a part from the .MCS file generated by the perl script:
..
..
:10FF500004000000040000000C000180000000A06C
:10FF60000C000580000000000C0000800000FAEA90
:10FF70000C000180000000B004000000040000003C
:08FF8000040000000400000071
:10FF90008F9FAFBF000000000000000000000000C5 <--starting of
my data
:10FFA0000000000000000000000000000000000051
:10FFB000000000000000000000000000FF02F20549
:10FFC000536443425401520144425201444252019B
:10FFD0004442F60556105796580347465601484680
:10FFE0005601444656014446160017001800F6050F
:10FFF0005608579658034746560148465601444608
:020000040001F9
<--breaking point
:1000000056014446160017001800F6055618579674
:100010005803474656014846560144465601444651
:10002000000000000000000000000000FFFFFFFFD4
:00000001FF
at :10FF90008F9FAFBF000000000000000000000000C5 seems to be where my
data starts.
I have no problem loading my data for as long as the amount of data
does not pass the :020000040001F9 point.
if ever my data pass that point, programming will pass but verification
(using iMpact) fails.
I'm not sure whose mistake is this. the file is generated automatically
by the perl script.
have anyone seen this problem before?
Thx
tejo
Article: 106549Thomas Entner wrote: > > Nothing like failure to cause one to abandon a feature forever. > > > > A crystal oscillator that: always starts, is always the right frequency, > > and is cheap -- is best left to those who have solved it for a few dozen > > useful frequencies (and even they have their share of headaches). > > > > It would be (and is) a horrible business risk to attempt to supply a > > circuit that would always work for every possible crystal from near DC > > to daylight. > > Of course it is understandable that you want to minimize your risk. However, > mosts user would benefit from this, as everyone needs an clock from > somewhere. I cannot really believe that this is rocket-sience, as almost > every uC out there has this. Most likely you can buy the IP for some bucks > so that you have not to reinvent the wheel yourself? > > An addition or alternative to the crystal-oscillator could be a calibrated > internal oscillator with reasonable precision (e.g. +/-1 %). > > Maybe X, A and L can look at Actel (Fusion), they have solved this almost > perfectly, at least according to the first look at the datasheet... > > Thomas > > www.entner-electronics.com Although it may seem at first blush to be simple - buy some IP - there are details that would need to go into the datasheet, change pin assignments etc. A clock buffer is NOT anything like an I/O buffer as made today. Beyond that, I don't know if you have ever designed onto an onboard oscillator for microcontrollers - the documentation stinks, in general (there are a number of choices in crystal and resonator parameters - you can't just say "10MHz crystal") because of too little detail. This was Xilinx' old problem (and the fact that a lot of people don't understand the meaning of the documentation even when they get it). Because it is now expected on microcontrollers and processors, the mfrs will often specify a suitable crystal (within some range too) known to actually operate on that circuit. For a FPGA, that may not be suitable - you may want 10MHz - I might need 20.48MHz - someone else might want to start at 100MHz - who knows. That's a wide range and unless *all* the details are available, you'll have to try a number of solutions before you get it right (if you ever do for the application). That would take two pins for an oscillator (which you would not want to feed into the core directly anyway) rather than using them for I/O. It's not often I defend Xilinx, but on this, the range of applications and the fact it's not their core competence are decent reasons not to have an oscillator section. In the vast majority of cases with FPGAs, there is a clock already being generated elsewhere used to clock data in (not always, I am aware - I have one where I need an oscillator in front of me), and the pins would be wasted. Keep in mind that a microcontroller *always* needs a clock. A FPGA does not *always* need a dedicated clock. Cheers PeteS
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