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
Hi, Im about to use EPM7064S in 44-pin PLCC in my desing and was wondering what is the correct filter capasitance value between VCC and GND. Couldn't find it in any datasheets. Perhaps, going for the obvious 100nF? Regards and thank you in advance, -- Jussi Lahteenmaki Tampere University of Technology FinlandArticle: 41051
On 20 Mar 2002 02:04:05 -0800, guiducci@cern.ch (Luigi) wrote: >Hi, >under Quartus, programming in VHDL, i use a component instantiated >with some OPEN ports, like: > >MYINST: My_Entity port map( > FIRST_IN => DATA1, > SECND_IN => OPEN, > FIRST_OUT => DATA2, > SECND_OUT => OPEN > ); > >I get the error: > >Association List error: OPEN association element is incompatible with >formal SECND_IN > >and the context-sensitive help says: > >"CAUSE: The VHDL Design File (.vhd) contains an association element >that is incompatible with the specified formal. The association >element and the formal must be compatible. >ACTION: Edit the file to correct the error and recompile the design." > >and then gives the suggestion to check Section(s) 4.3.2 of the IEEE >Std 1076-1993 IEEE Standard VHDL Language Reference Manual, that I >cannot access. >But in every manual and book i got it seems that what I did is >considered correct. >Do you know such an incompatibility? In VHDL you can't leave input signals open unless you have given them a default value. Please direct VHDL questions to news:comp.lang.vhdl in future. Have a nice day. Allan.Article: 41052
Peter Alfke wrote: > *Sprinkle virtual grounds between critical output bus lines, to reduce ground > bounce. "Virtual grounds" are strong, permanently active Low outputs that are > externally directly connected to the ground plane. Each kind of a surrogate extra > ground pin. I am interfacing a 256Mb SDRAM (16 bits data and 13 bits @) to the banks 7 and 6 of a XC2S200PQ208. In the same way, do I need to interleave the data bus and the adress bus lines? StephaneArticle: 41053
Have a look at http://www.sysacom.ca/english/products.htm. Jimmy Zhang <zhengyu@attbi.com> wrote in message news:_lYl8.74605$ZR2.35796@rwcrnsc52.ops.asp.att.net... > I am looking for used ones. Does anyone have what I am looking for? > Where do I go to find a dealer for that, I don't mind buying used ones as > long as they work. > >Article: 41054
Any of the newest FPGAs from ALtera and Xilinx will handle 622+ MHz LVDS inputs, but you'll have to be careful that the ADC's LVDS spec matches the FPGA, and you may need to work it as a double data rate setup (clocking on both edges at the IOB). For single ended inputs, you are pretty much restricted by the limits of what you can drive over a single ended line. An option for high data rate is to use a demux such as the Atmel TS81102G0 to break a high data rate ADC output stream into several parallel interleaved streams at rates the FPGA can easily handle. We did this recently for a 960 MS/S FFT design. Le Mer Michel wrote: > Hello > > Does anyone look at the fastest fpga of the market? > Specially about the io input timing, to record data of an ADC? > Which sample frequency can be reach? > > Thanks > ========================= > Michel Le Mer > Satellite Terminal Access > 12, square du Chene Germain > 35510 Cesson-Sevigne > Tel. 33 (0)2 23 20 04 72 > =========================Article: 41055
Hal, Now that is an intelligent question. Peak to peak jitter is really impossible to measure, as you have to wait forever. Now if you wait forever, the peak to peak value increases forever (becomes unbounded). Lights turn on, power fails, people bump into the setup, etc. But, we are not interested in that as designers, we just want to know over a reasonable interval, to a reasonable confidence level, what the peak to peak value is. So we take 500,000 clock cycles, and use that as our baseline. It takes about two minutes on the Wavecrest, so it isn't so long that you get odd environmental effects, just the jitter (short term variations in the significant instants). If we curve fit a guassian distribution to it, then we extend the peaks out a little bit, and we have a 99.999975 % confidence level, or about as good as you can possibly get and go to lunch at noon. Now if the probability that you get something out at the +peak, or -peak is one in > tens of millions, then getting two in a row is that squared. I think that is called, extremely unlikely, or maybe not in your lifetime. The amazing thing about the DCMs though, that help you out here, is that the most any cycle can be from the last cycle is one tap (~65 ps). So the rest of the "big jump" has to come from the input clock, and how all of the ground bounce and SSOs shift the slice point on the input clock over time and perhaps many cycles. Note that in a PLL, the probability of a really big jump from one cycle to the next is also extremely small, as the intertia of the oscillator prevents a large phase change from occurring...unless there is some coupling directly to the PLL power supply, and then anything can happen. So getting the clock into the FPGA is probably one of the most important design issues for all of these high speed applications. Spending a little more time on it, perhaps grounding the adjacent pin/ball, keeping other signals away from it (just 3x the normal spacing is 1/9 the cross talk and that is almost always sufficient to isolate a signal). That isn't to say that you might have a situation where the jitter is detemined by some IO switching, and when the IO switches high, it shifts one way, and when it switches low, it goes back the other. If this is the case, then all that fancy statistic stuff gets thrown away, as you can tell what is going to happen by examining the coupling from the source clock to the interferer. In that case, you may be right, as if the data switches from 1's to 0's on two successive edges, the periods may be the absolute peak to peak worst case, nad not just half of that. Thankfully, isolating the clock input pin, and good bypassing, and good signal integrity should take us out of the closely coupled case, back into the more random case. Austin Hal Murray wrote: > >Remember that the period constraint must be reduced by 1/2 of the total peak to > >peak jitter if you expect to meet your timing. Now that we routinely have > >clocks of 100 to 300 MHz, the usually ignored jitter is now a significant > >factor. > > Why only 1/2 of the P-P? > > Can't I get a worst case late followed directly by a worst case early? > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 41056
Hi,
Can anybody tell me what's the difference between:
if (CurrentClkState = not PreviousClkState) then
if (CurrentClkState = TCP) then
if (SHR = '0') then
if rising_edge(mclk) then
.
.
.
and :
if rising_edge(mclk) then
if (CurrentClkState = not PreviousClkState) then
if (CurrentClkState = TCP) then
if (SHR = '0') then
.
.
.
The first version seems to be working better than the last (in my
application), but I can't think of any reason why it does......
Article: 41057I have gotten numbers from XPOWER for current requirements. Has anyone any experience as to what the accuracy of the estimates is? In my case, the estimate is about 360mA for my design. The vast majority of that is the 300mA quiescent current. Is that a reliable number? The chip is a spartan2e (2s50etq144-6). Thanks, Theron HicksArticle: 41058
Hi, I hope a little problem. Trying to connect a 74als641 to a spartan 2e i/o pin. And, it is bidirectional ... My idea is something like: (74als641 OC) -- (4k7 pullup to 3.3V) -- (100 Ohm resistor in series) -- (fpga pin) Does it work this way ? Any better ideas ? And if it is of any help, there are around 50-60 pins I have to use this way ... cheers & thanks in advance, emanuelArticle: 41059
Hi, I am using a XPLA3 (CoolRunner) Device XCR3064XL. Now I need a crystal oscillator with low frequency (8...12 MHz). I want to do it with a simple crystal and an inverter within the XPLA3 device. Unfortunately the oscillator is not running. The input stucks on high signal. Although I disabled the XPLA3 internal PullUp Resistors. Who can help me, how to do it. Best Regards MatzArticle: 41060
Okay, a little more work and I'm much closer to getting all the constraints to work. My final issue is with a NET that was named in the original UCF file as NET U1/U2/U1/RESET PERIOD = 40.00; Now, when I go and try and add this net, I get to the list of available NETs and they are all of the form U1_U2_U1_N234 U1_U2_U1_N238 etc. So, how do I know which of these numbered NETs corresponds to the signal RESET? Where can I find this information? Thanks, Dave "Tim" <tim@rockylogic.com.nooospam.com> wrote in message news:1016581350.14680.0.nnrp-12.9e9832fa@news.demon.co.uk... > D Brown wrote > > > With these, ISE can never find the specified NET. So, how do I specify the > > NET name? What syntax do I use, especially if it's not in the top level > > module? > > I go along with Hobson. > > In general, the fastest way to get the syntax correct is > to open up the constraints editor, add a few constraints > of the correct type, and save the results as something > like tmp.ucf. Then look in tmp.ucf. > > > >Article: 41061
If read and write clocks are both 27.5 MHz - though unrelated - and the data widths are the same (your 27.5x4 mention confused me), you'll have a 50% chance of working. The two clocks must phase locked (with the FIFO absorbing any jitter between the two clocks) or you must design the system to occasionally "drop" a data value and design the FIFO to work properly under these conditions. You could recover the 27.5MHz clock internally with many FPGA clock elements (DLL, PLL, DCM) which - if the input clock is a clean source - would guarantee a phase relationship and wouldn't require the FIFO at all. The issue becomes "why were the two clocks not synchronous" and the conversion to the other clock domain made at a different place that's more accommodating to the slight timing difference. - John_H Antonio wrote: > My question starts from the fact that I've a QPSK modulator > the incoming data rate is 2 bit x 27.5Mbps, I apply the clock > governing this data rate to the write clock of my fifo while the write > enable is tied to VCC, the read clock instead is (27.5x4)MHz but it is > produced internally to the FPGA while the read enable is at 27.5MHz. > This is not burst transmission, so I'm a little bit in trouble that if > I have also a little frequency error all my system doesn't work. Maybe > the FIFO is not the right solution in this application, what do you > think about ?? > > Thanks > > AntonioArticle: 41062
Emanual, Why do you need any pullup at all? Set the Spartan IIE IOB to LVTTL, and the IO levels should interface just fine. If the 74ALS powered from 5Vdc pulls to less than 3.3 Vdc for the high, so no series resistor to/from the Spartan IIE is required (simulated the IBIS models for the 74ALS outputs at 5Vdc driving high into a Spartan IIE). Sounds like the right IOB standard, and just connecting things up is the right way to go. Austin emanuel stiebler wrote: > Hi, > > I hope a little problem. > Trying to connect a 74als641 to a spartan 2e i/o pin. > And, it is bidirectional ... > > My idea is something like: > > (74als641 OC) -- (4k7 pullup to 3.3V) -- (100 Ohm resistor in series) -- > (fpga pin) > > Does it work this way ? Any better ideas ? > > And if it is of any help, there are around 50-60 pins I have to use this > way ... > > cheers & thanks in advance, > emanuelArticle: 41063
hi, What is the recommended tool : Modelsim Simulator or the Quartus II simulator (which comes up by default during simulation) when using Quartus II ? Why would one want to use one over the other ? Or does Modelsim Simulator do something the quartus simulator doesn't and hence has to be used irrspective of the Quartus simulator being used ? Thanks, PrashantArticle: 41064
Lähteenmäki Jussi ha scritto nel messaggio ... >Hi, > >Im about to use EPM7064S in 44-pin PLCC in my desing and was wondering >what is the correct filter capasitance value between VCC and GND. >Couldn't find it in any datasheets. Perhaps, going for the obvious >100nF? Generally, I use a 100 nF ceramic capacitor near to each Vcc pin. LuigiArticle: 41065
John_H wrote: > If read and write clocks are both 27.5 MHz - though unrelated - and the > data widths are the same (your 27.5x4 mention confused me), you'll have a > 50% chance of working. The two clocks must phase locked (with the FIFO > absorbing any jitter between the two clocks) or you must design the system > to occasionally "drop" a data value and design the FIFO to work properly > under these conditions. > I find this misleading. The two "27.5 MHz" frequencies need not be phase aligned, but they must have the same average frequency value. Phase differences and short-term frequency deviations are absorbed by the FIFO (that's its only purpose!). If the frequencies are long-term different, then you must either insert or delete characters occasionally. The telecom people have developed this to a fine art. Peter Alfke, Xilinx Applications.Article: 41066
I suggest you buy a xtal oscillator, and leave the oscillator implementation to the specialists. It will be more reliable, consume less power, and probably cost the same. Using any CPLD or FPGA general-purpose inverting output driver, biased into the linear region, is tricky at best, unreliable at worst. (As you saw). Speaking from ugly experiences... Peter Alfke, Xilinx Applications ========================= Matz wrote: > Hi, > > I am using a XPLA3 (CoolRunner) Device XCR3064XL. Now I need a crystal oscillator with low frequency (8...12 MHz). I want to do it with a simple crystal and an inverter within the XPLA3 device. > Unfortunately the oscillator is not running. The input stucks on high signal. Although I disabled the XPLA3 internal PullUp Resistors. > Who can help me, how to do it. > > Best Regards > MatzArticle: 41067
The Quartus simulator has a better user interface but prevents you from using more VHDL features in your simulation. i.e. file I/O to get your input stimulii etc or testbench generation.) It is definitely limited as your simulations become more complex. Quartus is also quite slow in comparison to others. Modelsim that comes with Quartus is also 'crippled' in so far as it runs at about 25% of the full ($$$) licensed version. Unlike the Xilinx equivalent though, at least the Altera ModelSim isn't crippled in other ways. Modelsim is almost an industry-standard simulator so will stand you in good stead for your future, but IMHO its user interface is poor compared with my favourite, Active HDL. Try www.aldec.com and download (or request a free trial of ActiveHDL) The simulator appears as fast as Modelsim (and has similar power behind it) but it has a far superior user interface and also features alot of other VHDL design features making it well worth considering. Trouble is, like Modelsim it costs a lot of money :( Discuss with your local distributor what they might be able to do for you. Paul "Prashant" <prashantj@usa.net> wrote in message news:ea62e09.0203200920.5590bc6d@posting.google.com... > hi, > > What is the recommended tool : Modelsim Simulator or the Quartus II > simulator (which comes up by default during simulation) when using > Quartus II ? > > Why would one want to use one over the other ? Or does Modelsim > Simulator do something the quartus simulator doesn't and hence has to > be used irrspective of the Quartus simulator being used ? > > Thanks, > PrashantArticle: 41068
This is a multi-part message in MIME format.
------=_NextPart_000_005E_01C1D008.8C4480E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
All,
I keep running into this problem all the time in which I have a route =
that misses my constraint by tens of thousands of nanoseconds. I'm =
using the Xilinx 4.1 PAR tools. In this case the bad paths are ones =
that cross from a domain with a 20ns period to a domain with a 10ns =
period. The faster domain is generated from a DLL locked to the first, =
so while it is twice the freq, it is synchronous to the first. I'm =
taking care to read data in the second domain only on "even" cycles of =
the first domain, so the data has 20ns to get from the slow domain to =
the fast.
The first evidence of a problem comes during routing:
End of iteration 1
22869 successful; 0 unrouted; (152088) REAL time: 5 mins 34 secs
You've all cringed at seeing this message before. Then, in the PAR =
summary, I see this:
-------------------------------------------------------------------------=
-------
* PERIOD analysis for net "clk_management/f | 10.416ns | 38591.280ns | =
4
irclk_dcm_clk2x" derived from NET "clk_m | | | =
anagement/CLK_ibufg" PERIOD =3D 41.667 nS | | =
|
HIGH 50.000000 % | | | =
-------------------------------------------------------------------------=
-------
This is obviously a problem: my constraint for the fast clock domain is =
10.4ns, and one path requires 38591ns, meaning I need to slow my clock =
to the kilohertz range. Here's the detail from Trace:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Timing constraint: PERIOD analysis for net =
"clk_management/firclk_dcm_clk2x" derived from
NET "clk_management/CLK_ibufg" PERIOD =3D 41.667 nS HIGH 50.000000 % =
;
divided by 2.00 and duty cycle corrected to 10.416 nS HIGH 5.208 nS
29336 items analyzed, 58 timing errors detected.
Minimum period is 38591.280ns.
-------------------------------------------------------------------------=
-------
Slack: -3.704ns (requirement - (data path - negative =
clock skew))
Source: dpll/theta[12]
Destination: fir/phase_reclock[5]
Requirement: 0.001ns
Data Path Delay: 3.705ns (Levels of Logic =3D 4)
Negative Clock Skew: 0.000ns
Source Clock: sclk rising at 216975.695ns
Destination Clock: firclk rising at 216975.696ns
Data Path: dpll/theta[12] to fir/phase_reclock[5]
Location Delay type Delay(ns) Physical Resource
Logical =
Resource(s)
------------------------------------------------- =
-------------------
SLICE_X57Y32.YQ Tcko 0.568 theta[13]
dpll/theta[12]
SLICE_X54Y33.F1 net (fanout=3D3) 0.551 theta[12]
SLICE_X54Y33.COUT Topcyf 0.769 =
fir/phase_reclock[2]
=
fir/phase_reclock_qxu[2]
=
fir/phase_reclock_cry[2]
=
fir/phase_reclock_cry[3]
SLICE_X54Y34.CIN net (fanout=3D1) 0.000 =
fir/phase_reclock_cry[3]/O
SLICE_X54Y34.Y Tciny 1.446 =
fir/phase_reclock[4]
=
fir/phase_reclock_cry[4]
=
fir/phase_reclock_s[5]
SLICE_X54Y34.DY net (fanout=3D1) 0.001 =
fir/phase_reclock_s[5]
SLICE_X54Y34.CLK Tdyck 0.370 =
fir/phase_reclock[4]
=
fir/phase_reclock[5]
------------------------------------------------- =
---------------------------
Total 3.705ns (3.153ns logic, =
0.552ns route)
(85.1% logic, =
14.9% route)
-------------------------------------------------------------------------=
-------
This is just whack. You can see that the path delay is 3.7ns, which =
easily meets the 20ns period of the slow clock (sclk). However, for =
some reason it thinks the source clock is sclk rising at 216975ns. =
Where did that come from? And how did it get a slack of -3.704ns? =
Also, where did the 38591ns period in the PAR summary come from? That's =
not even close to 216975.
This path really shouldn't be analyzed at all. The Xilinx answer files =
state that 4.1i doesn't analyze paths that cross clock domains. =
Sometimes when I see this problem, I can "fool" PAR by putting a FROM-TO =
in the UCF that explicity states that paths from the "sclk" domain to =
the "firclk" domain have 20ns. However, this isn't working now, and =
Trace claims that 0 items are analyzed using that TIMESPEC, even though =
there are obviously many paths that fit that description.
Has anybody else seen this?
-Kevin
Article: 41069Matz wrote > I am using a XPLA3 (CoolRunner) Device XCR3064XL. Now I need a crystal oscillator with low frequency (8...12 MHz). I want to do it with a simple crystal and an inverter within the XPLA3 device. > Unfortunately the oscillator is not running. The input stucks on high signal. Although I disabled the XPLA3 internal PullUp Resistors. > Who can help me, how to do it. With respect to Peter and Austin, Jim Williams is your best bet here. Look up Linear Technology Application Note AN12 "Circuit Techniques for Clock Sources". Dated Oct 1985, but the laws of physics have not changed much since then.Article: 41070
Thanks both of you, you are a great help! :))Article: 41071
Bob Perlman wrote: > > Rick - > > A few comments/observations: > > 1) If your board stackup is at all conventional, trace impedances will > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > get other impedances, but getting to 200 ohms will require tricks that > you won't want to play. I am not at all clear on how you can guestimate the trace impedance to be in such a narrow range. I was under the impression that it varied directly with trace width. I could be using trace widths anywhere from 4 mil to 10 mil. Further, the board stackup depends entirely on layer count vs. power plane count. What were you assuming for these? I am hoping that I can get away with 4 routing planes and two power planes. But that is not clear at this point. I also would like to use 5/5 width/space on the traces, and I think this is less likely to vary. But I can certainly make the clock traces wider to lower the impedance. HJ has a T circuit analysis (or two) on the web that uses series terminations at each end (all three). The series resistors at the receiver were to damp resonant oscillations that can build up between the receivers. I may give this a try if I can model it. > 2) I don't know the strength of the C6711 clock driver. If it's > strong enough to drive a Thevenin-equivalent parallel termination, and > if you can tolerate the inevitable clock skew that arises from > daisy-chaining the clock net, then use a single net and parallel > termination. But be sure to check the weak/slow corner clock buffer > drive. In my experience, the clock outputs of processor chips tend to > be underpowered. (And they can be glitchy, too; a > ground-bounce-related glitch on the clock output of TI's TMS320C31 > nearly torpedoed one project I worked on.) I think I can afford to be accomodating in the skew since my daisy chained route would be about 3 inches or ~500 ps. However the longest single trace in a star configuration is only 1.4 inches or ~240 ps. The driver spec gives a max of 2 ns (no min) for the rise time, so even if it is 1 ns, my round trip is half the rise time. This is not ideal, but I think it will likley work without termination. > 3) If (2) doesn't pan out, spring for one of the small zero-delay > buffers, and drive each clock load with its own PLL output. If the > zero-delay buffer has built-in series termination, great; if not, > series-terminate each output. It'll cost you (not much) space and > (not much) money. I never try to economize on either when generating > and distributing clocks. Yes, I have thought about that, but small is a relative term and I am loath to add another part to the parts list. I would love to model this circuit, but I don't think I want to plunk down a few $k for a tool that will only be used one or twice per design. I may try to find a friend at a company with the tool and "borrow" it or let him run my tests after I come up with all the relevant data. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41072
D Brown wrote > Okay, a little more work and I'm much closer to getting all the constraints > to work. My final issue is with a NET that was named in the original UCF > file as > NET U1/U2/U1/RESET PERIOD = 40.00; > > Now, when I go and try and add this net, I get to the list of available NETs > and they are all of the form > U1_U2_U1_N234 > U1_U2_U1_N238 > etc. > > So, how do I know which of these numbered NETs corresponds to the signal > RESET? Where can I find this information? Use a TNM. (look this up in the X docs.) From Evans's page: \ attribute TNM: string; -- initial once-only attribute declaration \ signal MY_SIG: MY_TYPE; \ attribute TNM of MY_SIG: signal is "MY_TNAME"; \ \Note that it may also be necessary to preserve the signal name during synthesis \(although this will not normally be a problem, since no 'synthesis' occurs for \a structural description, and no names should be lost). Name preservation, in \general, will require the use of one of the vendor's user-defined attributes, \as opposed to one of your own user-defined attributes. For Exemplar, the code \would now look like: \ \ signal MY_SIG: MY_TYPE; \ attribute preserve_signal of MY_SIG: signal is TRUE; \ attribute TNM of MY_SIG: signal is "MY_TNAME";Article: 41073
D Brown wrote > Okay, a little more work and I'm much closer to getting all the constraints > to work. My final issue is with a NET that was named in the original UCF > file as > NET U1/U2/U1/RESET PERIOD = 40.00; > > Now, when I go and try and add this net, I get to the list of available NETs > and they are all of the form > U1_U2_U1_N234 > U1_U2_U1_N238 > etc. > > So, how do I know which of these numbered NETs corresponds to the signal > RESET? Where can I find this information? And Ray answered this recently: http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=3BB30938. BD4582BD%40andraka.comArticle: 41074
Depends on speed of operation. The 100nF is fine at lower speeds but at higher speeds (e.g 100Mhz and above) is might be a good idea to place a smaller value cap in parallel. The idea behind this is that the capacitor is actually a combination of series and parallel resistance, lead/component inductance and the actual capacitance. Smaller capacitors (check the specs. of the capacitors you want to use) tend to charge and discharge faster. If the CPLD suddenly requires more current the smaller cap. will provide it first. Keep in mind that the combination of the PCB track and capacitor form a low pass filter. My one FPGA supplier uses values down in the pF range (speeds of 200Mhz +). For your application you will to play around. I also use 100nF capacitors for most of my circuits. These days I stick with SMD types, with better results. If it works under all conditions it is probably sufficient. Don't skimp on track width on power supplies. If you can make the power tracks thicker and/or pour a power plane on the board the power distribution will improve. Victor "luigi funes" <fuzzy8888@hotmail.com> wrote in message news:X44m8.48603$1S3.1455746@twister1.libero.it... > > Lähteenmäki Jussi ha scritto nel messaggio ... > >Hi, > > > >Im about to use EPM7064S in 44-pin PLCC in my desing and was wondering > >what is the correct filter capasitance value between VCC and GND. > >Couldn't find it in any datasheets. Perhaps, going for the obvious > >100nF? > > > Generally, I use a 100 nF ceramic capacitor near to each Vcc pin. > > Luigi > >
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