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
Due to server maintainence our website by our hosting provider and email went down last night. After over-running it's all back now. Apologies to anyone disappointed in trying to obtain downloads etc.. John Adair Enterpoint Ltd.Article: 122101
Hi, Sorry, I can't quote your reply properly, bloody opera, I guess! Anyway, yes top bad. If a signal came on the top level from north-east to the centre via, and left on the bottom layer to the south-west, the return current has to travel around the slot cut by the 5 vias. If you can flow the cu in between the vias, that's better. As for connecting the caps together, it might help. Personally I've long given up using planes for power. I route the power to the device and use copper pours at the part. This works well. Using puddles to connect the caps can be a help, I think we mentioned this in a thread a while back about X2Y caps. Google will find it. However, as you're stuck with the PQ208 package, it probably will make no difference. The lead frame has such high inductance, so the bypass caps don't have the desired benefit at the die. Doubling up the ground vias probably makes sense. BTW., putting the caps on the same side as the IC get's rid of the via inductance problem, but probably will screw with your signal routing. However, what you've shown looks like it'll work fine. HTH., Syms.Article: 122102
fazulu deen wrote: > I have to generate buffer descriptor with all its fields like transfer > size,host address and destination address.my question was how to > generate it? Still no real information. Is this elusive "buffer descriptor" actually part of a standard such as a communication protocol?! When you finally put a hint of some detail into what a "BD" might be, I was thinking ti was for a DMA within your embedded system which means you and your software folks determine what you want. If this is something that actually has to conform to a standard, tell us what the heck the standard is! HOW can you expect to get information when your descriptions are completely insufficient?Article: 122103
Symon wrote: > "commone" <dechenxu@yahoo.com.cn> wrote in message > news:qd-dnZ9nU5sQ1ALbRVn_vgA@giganews.com... >>> However, if you split the ground planes you are in a >>> world of pain when signals cross from one plane to the next. Their >> reference >>> changes and the return current path has to go through one of your >> ferrites. >> I will keep the digital signals not overlap the analog plane and the >> analog signals not overlap the digital plane. Will the digital return >> current go into analog plane and where is the volt drop across the FB? >> If you do want to mix the digital and analog traces in the same area, >> noone can do anything to save the analog circuits. >> > I agree, you need to keep analog components away from fast switching digital > ones. However, there's no need to cut the ground plane up to achieve this. > It makes it complicated, and much more likely to go wrong. >> http://www.analog.com/en/content/0,2886,761%255F795%255F97529%255F0,00.html >> > Right, I see this a lot. They say "It may also be beneficial to use separate > ground planes for the analog and the digital circuitry.", but then > singularly fail to say what these benefits are. The reason they don't > explain this is because there are almost no benefits, only drawbacks. I ask > you again, presuming you physically separate the digital and analog circuits > and power supplies, how does noise couple over a single shared ground plane? > > HTH., Syms. I'm wondering if the right thing to do is to let you "fail" which is why I haven't interjected. I've read many A/D data sheets that talk about splitting the grounds for a common point connection. I did a board about a decade ago with some pretty reasonable mixed signal portions in the path. To keep my VCO clean or to make my post-D/A 5-pole filter clean before hitting a quadrature modulator, I had my ground and power "cleanly" split but with hard copper at one point in the region, not a ferrite. When I passed single ended signals, I ran them over this small connection between ground regions. I also used differential signals where I figured crossing the ground split would be acceptable. When all was done, my EMI was lousy. The ground on the BNC connector had a good 2 mV or so of signal different from the ground on the receive side in the same chassis. The BNC cable that connected the TX to the RX turned into one big loop antenna. It took too many aborted attempts to find the root of the problem before I had isolated drivers milled into a block of brass to get the problem licked. With power AND ground filtered in this $75 piece of hardware fed by a differential signal, I was finally able to get rid of the singal on my ground plane. I'm convinced (partly because of radiative probing of the board) that the root cause of the EMI was my ground splits. You can filter the power and make many little power islands. If you try to make too many ground islands, ESPECIALLY through ferrites rather than the "single point connection" of hard copper, your board will become quite the little AM station. I wish there was more hard evidence available to engineers doing early designs in their career about how to properly design a grounding system for low noise analog. I didn't find any and I paid at least 2 months in our tiny EMI prescan chamber. There's a small dent in the metal wall that roughly matches the contour of my forehead. I don't recommend splitting the ground planes. - John_HArticle: 122104
After waiting patiently for Xilinx to support always @* properly, I'm still
having problem with this code:
localparam integer D_W = 32;
localparam integer DEPTH = 512;
reg [D_W-1:0] memory [0:DEPTH-1];
reg [DEPTH-1:0] memory_or;
always @* begin
for ( i = 0; i < DEPTH; i = i + 1 ) begin
memory_or[ i ] = | memory[ i ]; // is any bit high?
end
end // always @*
...
"unexpected event in sensitivity-list of always block."
Same code synthesizes fine in Altera Quartus-II 7.1 Web Edition.
For the case I show above, I can workaround it using a
generate-loop, and a bunch of assign statements...but there are
other code-blocks which I can't easily workaround.
Article: 122105On 18 Jul., 20:30, austin <aus...@xilinx.com> wrote: > Antti, > > "Hot" behavior is usually associated with something that pulled too much > current out of, or into, the substrate/vcc's. > > It is not SCR Latch-up, but instead the memory cells themselves are > de-programmed (loose their brains) because the substrate perhaps went > too far negative or positive, and as a consquence, the device looks like > it needs far more current than usual. > > In effect, you have forced a random bitstream into the device. > > This requires more than 200 mA sink or source. > > Of course, sinking or sourcing 200 mA to supplies above any chip vcc, or > below ground (0 volts), is not something we recommend (or allow). But, > it can happen (power sequence with another chip, connecting a cable to > another pcb, ...). > > I suggest that if you ever see this again, you attempt to do a > readback/verify (if it isn't too hot!). > > Austin Austin, did you read my original posting? the FPGA was programmed with biststream downloaded from Xilinx website the "Picoblaze dataflash programmer" - and the design was working properly. If the FPGA did take too much current (while being properly confoigured with known good bitstream), then it maybe is reason to worry for someone not me. but maybe it was random, misbehav, its rather hot in Munich daytime may reach 32C in shade AnttiArticle: 122106
On Jul 18, 9:47 am, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote:
> devices schrieb:
>
> > I chose the simple following example (perhaps
> > too simple or too specialized). Here's a flip
> > flop with an enable pin:
> > process (clk)
> > begin
> > if (clk'event and clk='1') then
>
> > if (ce = '1') then
> > q <= d;
> > end if;
>
> > end if;
> > end process;
>
> For most target libraries this will result in a D-Flipflop and a
> multiplexer controlled by ce. The multiplexer selected d or q as input
> to the D-FF.
>
> > - FIGURE B
>
> > +---------------------+
> > | _ |
> > | | \ +--------+ |
> > +--|0 | | | |
> > | |---|In Out|--+-> q
> > d--|1 | | |
> > | / | FF |
> > - +-|> |
> > | | +--------+
> > | |
> > ce clk
>
> That is correct.
>
> > 1) If Figure B holds true, does it ALWAYS
> > go like this?
>
> Yes. Because you did not model a latch.
>
> A latch is a storage element. A D-latch has an enable signal and a data
> input.
>
> process(en,data)
> begin
> if (en='1') then
> latch<=data;
> end if;
> end process;
>
> The process you have written first could be changed into:
>
> process (clk)
> begin
> if (clk'event and clk='1') then
> q<=q_next;
> end if;
> end process;
>
> process(ce,d,q)
> begin
> if (ce = '1') then
> q_next<=d;
> else q_next<=q;
> end process;
>
> This describes the same behavior. As you can see, there is always a
> value assigned to q_next. This means: no storage needed.
>
> Ralf
Actually, most FPGA synthesizers will implement the register and mux
as a clock enabled register (which incorporates the mux and the
register as you stated, but is a primitive that does not consume a LUT
for the mux).
I really wish the advise "don't use an if without an else" in
combinatorial logic had never been given. There are a couple of much
more effective and verifiable ways to eliminate the possibility of
inferring a latch:
First, use clocked processes for everything, and include the logic in
the clocked process. No combinatorial processes, no latches. There are
lots of ways to avoid using combinatorial processes in virtually any
circumstance (except when an entity has a completely combinatorial
path from input to output), and using variables helps a lot.
Second, if you HAVE to use a combinatorial process, assign a default
value to every signal driven by the process, right up front in the
process, before anything else happens. It is MUCH easier to see and
verify that every driven signal is in that default list, than it is to
verify that every if contains an else AND that anything assigned in
the if is also assigned in the else.
Example:
process(ce,d,q)
begin
q_next <= q; -- default assignment
if ce = '1' then
q_next <= d;
end if;
end process;
Andy
Article: 122107>Right, I see this a lot. They say "It may also be beneficial to use separate >ground planes for the analog and the digital circuitry.", but then >singularly fail to say what these benefits are. The reason they don't >explain this is because there are almost no benefits, only drawbacks. I ask >you again, presuming you physically separate the digital and analog circuits >and power supplies, how does noise couple over a single shared ground plane? > >HTH., Syms. Symon: Ideally,if we physically separate the digital and analog circuits and power supplies,noise will not couple over a single shared ground plane. But the noisy digital cicuits will make the ground plane nosiy.Right? Is it equivalent to apply a vlot drop in the single gnd plane? Will the analog circuit be influenced? But when we split the gnd plane, and connect them with ferrite beads or schottky diodes. That will supply a great impendence for some high frequency noise that want to go into the analog gnd plane(Pls do not doubt the existence of these noise cause the digital gnd plane maybe damaged by handreds of vias and other holes ). And these nosie will pick other paths with relatively low impedence in the digital gnd plane to return its source. So for the noise sensitive analog circuits, we do have a strong reason to give them a seperated gnd plane. In some high speed AD data capture card, plp tend to seperate the gnd plane into analog gnd plane and digital gnd plane. Leon,Article: 122108
On Jul 17, 7:24 pm, "Symon" <symon_bre...@hotmail.com> wrote: > <dora...@gmail.com> wrote in message > > news:1184690666.682978.42620@e16g2000pri.googlegroups.com... > when I synthesize the FPGA (ProASIC PLUS) in Synplify of Libero I have > got a lot of warnings: "Unbound component (DFF or AND2...) mapped to > black box". It seems that don't recognize the basic components, =BFdo I > need any library? > > thanks > > Maybe not. The placement tool may recognise the names of the black boxes = in > the synthesis results as primitives and insert the appropriate parts. Try= a > place and route and see what happens! > Cheers, Syms. On place and route everything is OK. But this question-warning worried me. I don=B4t find unisim.v for Actel. thank again,Article: 122109
Hello everybody,
I am trying to use the EDK based video decoder design provided by
Digilent. But when I am trying to buid the netlist I get the following
licensing error from the FLEX . I have purchased the video decoder
board. Do we have to purchase the license of this IP as well?
Anybody has any past experiences in using this IP or some way to use
the video decoder for capturing S-video inputs?
Thanks in advance for your help.
INFO:coreutil - Valid license for feature opb_iic_v1 not found.
You may use the customization GUI for this core but you will
not be able to generate any implementation or simulation files.
Contact Xilinx to obtain a full license for this LogiCORE. For more
information please refer to www.xilinx.com/ipcenter/ipevaluation/
FLEXlm Error: No such feature exists (-5,21)
ERROR:MDT - opb_iic (i2c) - C:\video_capture_rev_1_1\system.mhs line
193 -
invalid license or no license found!
plb_v34 (plb) - C:\video_capture_rev_1_1\system.mhs line 99 - 2
master(s) : 2
slave(s)
opb_v20 (opb) - C:\video_capture_rev_1_1\system.mhs line 108 - 1
master(s) : 2
slave(s)
Running UPDATE Tcl procedures for OPTION
PLATGEN_SYSLEVEL_UPDATE_PROC...
ERROR:MDT - platgen failed with errors!
make: *** [implementation/ppc405_0_wrapper.ngc] Error 2
Done!
Article: 122110"commone" <dechenxu@yahoo.com.cn> wrote in message news:uPGdncLp1LNP7QLbRVn_vgA@giganews.com... > >Right, I see this a lot. They say "It may also be beneficial to use > separate >>ground planes for the analog and the digital circuitry.", but then >>singularly fail to say what these benefits are. The reason they don't >>explain this is because there are almost no benefits, only drawbacks. I > ask >>you again, presuming you physically separate the digital and analog > circuits >>and power supplies, how does noise couple over a single shared ground > plane? >> >>HTH., Syms. > > Symon: > Ideally,if we physically separate the digital and analog circuits > and power supplies,noise will not couple over a single shared ground > plane. But the noisy digital cicuits will make the ground plane > nosiy.Right? > Wrong. The ground plane is your reference. Again, what is the mechanism you fear will couple noise into your analog circuitry. > >Is it equivalent to apply a vlot drop in the single gnd > plane? Will the analog circuit be influenced? But when we split the gnd > plane, and connect them with ferrite beads or schottky diodes. That will > supply a great impendence for some high frequency noise that want to go > into the analog gnd plane(Pls do not doubt the existence of these noise > cause the digital gnd plane maybe damaged by handreds of vias and other > holes ). > Why would high speed current want to travel from the digital section to the analog section? You're not going to route digital signals through the analog section, so I don't see what you mean. And, how do a few via holes make any difference? A copper plane has exceptionally low impedance. If you earthed a 'scope probe at one point on the ground plane, you won't see any noise as you move the probe around the plane. Unless, of course, you cut a great big slot in it. > > And these nosie will pick other paths with relatively low > impedence in the digital gnd plane to return its source. So for the noise > sensitive analog circuits, we do have a strong reason to give them a > seperated gnd plane. In some high speed AD data capture card, plp tend to > seperate the gnd plane into analog gnd plane and digital gnd plane. > Not if they know what they're doing, they don't. > > Leon, > OK, you've made up your mind, you go for it. But, make sure you come back and read this thread in 8 months time while your board is failing the CE mark for emissions. I hope you'll learn for the next time. Also, rather than take advice from me on the FPGA newsgroup, why not ask your question on a more appropriate forum, like the SI-LIST mailing list. Maybe they can help you where I have failed. Good luck, Syms.Article: 122111
John_H You mean that the best thing to do is to keep a integral gnd plane and at the same time do not overlap the digital and analog regions on different signal layers?Article: 122112
Antti, I was just letting you know the most likely cause of a "hot" chip. Sorry it is so hot in 'Munchen'. Austin Antti wrote: > On 18 Jul., 20:30, austin <aus...@xilinx.com> wrote: >> Antti, >> >> "Hot" behavior is usually associated with something that pulled too much >> current out of, or into, the substrate/vcc's. >> >> It is not SCR Latch-up, but instead the memory cells themselves are >> de-programmed (loose their brains) because the substrate perhaps went >> too far negative or positive, and as a consquence, the device looks like >> it needs far more current than usual. >> >> In effect, you have forced a random bitstream into the device. >> >> This requires more than 200 mA sink or source. >> >> Of course, sinking or sourcing 200 mA to supplies above any chip vcc, or >> below ground (0 volts), is not something we recommend (or allow). But, >> it can happen (power sequence with another chip, connecting a cable to >> another pcb, ...). >> >> I suggest that if you ever see this again, you attempt to do a >> readback/verify (if it isn't too hot!). >> >> Austin > > > Austin, > > did you read my original posting? > > the FPGA was programmed with biststream downloaded from Xilinx website > the > "Picoblaze dataflash programmer" - and the design was working > properly. > > If the FPGA did take too much current (while being properly > confoigured with > known good bitstream), then it maybe is reason to worry for someone > not me. > > but maybe it was random, misbehav, its rather hot in Munich > daytime may reach 32C in shade > > Antti > > > > > > > >Article: 122113
"Xilinx User" <anonymous@net.com> wrote in message news:9QJni.2694$Dx2.1440@newssvr17.news.prodigy.net... > After waiting patiently for Xilinx to support always @* properly, I'm > still > having problem with this code: > > localparam integer D_W = 32; > localparam integer DEPTH = 512; > reg [D_W-1:0] memory [0:DEPTH-1]; > reg [DEPTH-1:0] memory_or; > > always @* begin > for ( i = 0; i < DEPTH; i = i + 1 ) begin > memory_or[ i ] = | memory[ i ]; // is any bit high? > end > end // always @* > > ... > "unexpected event in sensitivity-list of always block." > > Same code synthesizes fine in Altera Quartus-II 7.1 Web Edition. > For the case I show above, I can workaround it using a > generate-loop, and a bunch of assign statements...but there are > other code-blocks which I can't easily workaround. While I would expect XST to handle this well, consider changing your memory array to a vector, at least for this always block. You can still keep your memory array if you have a wire vector assigned to all the memory elements only for use in this block. Because of your wide OR, the "memory" will be implemented as registers anyway, so maybe specifying them as a register vector will give you the results you need. Shame on XST.Article: 122114
"commone" <dechenxu@yahoo.com.cn> wrote in message news:KsidnZKTFuny5gLbRVn_vw@giganews.com... > John_H > You mean that the best thing to do is to keep a integral gnd plane and at > the same time do not overlap the digital and analog regions on different > signal layers? The integral ground plane is your best bet for EMI performance. My own concern when I split up my ground planes in my unintentional radiator was to keep the digital current surges from affecting the low impedance (though more than a 0-pH per square impedance) ground plane when they passed *through* an analog section. Perhaps this same goal can be achieved through simple positioning of the analog circuitry. The digital and analog signals can share the same signal layer. Crosstalk between regions goes out to several times the spacing from the signals to the reference plane, but that's not very far. It may be the better way to "isolate" the analog and digital realms is to ferrite-couple the power into tiny islands used by the parts with fully adequate local bypassing but avoid using those power planes as a reference. If you hammer the GND and VCC planes with your digital logic and use the same supply for the analog section, somethings' gotta give when the current surges. If your VCC planes are isolated through the ferrites, hammering on the FPGA power plane will be hard to "hear" in the filtered analog power plane. Keeping the ground reference will help to avoid generating ground differentials in any ground sections that are effectively tied together in a loop. Having one hard ground (often consisting of 2 or more physical ground planes with many vias, particularly where signals switch between reference planes) will keep the signals happy by maintaining a common return path and keep the design happy by not *forcing* the current surges to push the ground plane around. The common power and ground planes *will* force the ground plane to wiggle with those current surges when the voltage drops since all the bypassing caps keep things very symmetric. Reread Symon's posts. I doubt you'll find any hard evidence out there countering his comments (the ADI data sheets are more anecdotal, not hard evidence that splitting planes benefits anything at all).Article: 122115
On Thu, 19 Jul 2007 11:22:52 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:vvet935t6s89tn6pkqo9m220mdl52ccnnt@4ax.com... >> On Wed, 18 Jul 2007 09:42:47 -0700, Lue.Her@gmail.com wrote: >> >> >> 6 layers would make life a lot easier, one ground plane and two power >> planes. One power plane can be 3.3 volts, and the other can be split >> 2.5 and 1.2, one island inside the FPGA and a big pour outside. That >> leaves three signal layers, and you can route signals on the 2.5/1.2 >> layer too, once you make the FPGA happy. Two more layers won't cost >> much more. >> >Hi John, >If I had six layers, I'd make 2 and 5 ground planes. That's a lot to give up. We use one ground plane, between the power planes, maybe 3=power, 4=gnd, 5=power. Long traces would run on 2 and 6, and layer 1 has parts and short traces. Trace impedances would vary a bit between all three routing layers, so trace widths can be average-compromised, or tuned per layer when it really matters. We often cheat and run some short traces on the power plane layers, "slitting" the plane, and that works fine too. Even ground, sometimes. We'll also occasionally slit planes as thermal insulators, to keep temperature gradients away from tender stuff. >Then when signals via >from one side to the other, their impedance to the ground plane stays pretty >much the same, provided you use a ground via near to the signal via. We don't believe in the "return current" dogma that's so popular these days. The three planes are so tightly coupled by plane-plane capacitance you can assume them to be equipotential, like a solid block of copper. TDR testing confirms. > This is >also true of LVDS pairs, as the P and N signals are usually poorly coupled >to each other, but strongly coupled to ground. Route the powers on one of >layer 3 or 4. Planes themselves are the best bypass caps, so we try to not "route" power, but pour it. >> >> We ususlly use 4 caps per supply per FPGA, 0.33 uF 0603. Never had a >> problem, even in systems where we measure jitter in picoseconds. Use >> more if it makes you feel better, but they won't change anything. >> >> For fun, lay out a board with more caps and depopulate it until >> something malfunctions. Write a paper. >> >> John >> >Right, it's hard to get bypassing wrong. Which is why so many people have such different opinions, and why the looniest signal-integrity consultants are always right. >If you cover the board in bypass >caps it'll work just fine, but it'll cost you. Beware, the via holes you >have to drill to connect them can be more expensive than the parts. >I would suspect that in a 'real' system, the removal of bypass caps will >probably cause some analog part of the board to fail before the FPGA. The >switching noise from the FPGA can spread back through the power network more >easily as bypassing is reduced. I know one guy who doesn't use bypass caps at all, and his boards work too. Grounding and bypassing are easy. We've had a lot more trouble lately with clock integrity, as the fpga clock inputs get faster and faster and more sensitive to edge noise. Even CCLK. We've been putting tiny logic schmitts adjacent to clock and CCLK pins. LVDS clocks are ok, but routing is harder and even small routing asymetries can make for nasties. As you say, a diff pair on a multilayer board behaves more like two independent signals. JohnArticle: 122116
"Symon" <symon_brewer@hotmail.com> wrote: >"Nico Coesel" <nico@puntnl.niks> wrote in message >news:469e6836.831123642@news.planet.nl... >> Lue.Her@gmail.com wrote: >> >>>Greetings, all, >>> >>>I have read through many postings about bypass/decoupling capacitors >>>for Xilinx FPGAs at comp.arch.fpga. It seems to me common >>>"solution" (there are many, I'm sure) to use at most 10 or 20 caps for >>>the entire FPGA, of one value of one size (i.e.: 0.1 uF or 0.33 uF >>>capacitor, 0603 package, perhaps). I guess I just want a quick a dirty >> >> Bypassing each power pin with a 0402 10nf and a 0402 100nf capacitor >> is a good start. Connect the capacitor directly to the power supply >> pin and use 2 via's to ground for each capacitor. Place a 10uf MLCC >> capacitor for each supply close to the fpga for bulk decoupling. >> >Hi Nico, >I'd be interested to hear your reasoning as to why you would use two >capacitors for each pin, especially bearing in mind this is a PQ208 package. >Do you own Murata shares by any chance? ;-) > >Also, why would you use two different values? Different values have a different self-inductance. If the PQ208 is already bad lets not make it worse. But keep in mind the Spartan 3 is not extremely fast. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 122117
>"commone" <dechenxu@yahoo.com.cn> wrote in message >news:uPGdncLp1LNP7QLbRVn_vgA@giganews.com... >> >Right, I see this a lot. They say "It may also be beneficial to use >> separate >>>ground planes for the analog and the digital circuitry.", but then >>>singularly fail to say what these benefits are. The reason they don't >>>explain this is because there are almost no benefits, only drawbacks. I >> ask >>>you again, presuming you physically separate the digital and analog >> circuits >>>and power supplies, how does noise couple over a single shared ground >> plane? >>> >>>HTH., Syms. >> >> Symon: >> Ideally,if we physically separate the digital and analog circuits >> and power supplies,noise will not couple over a single shared ground >> plane. But the noisy digital cicuits will make the ground plane >> nosiy.Right? >> >Wrong. The ground plane is your reference. Again, what is the mechanism you >fear will couple noise into your analog circuitry. >> >>Is it equivalent to apply a vlot drop in the single gnd >> plane? Will the analog circuit be influenced? But when we split the gnd >> plane, and connect them with ferrite beads or schottky diodes. That will >> supply a great impendence for some high frequency noise that want to go >> into the analog gnd plane(Pls do not doubt the existence of these noise >> cause the digital gnd plane maybe damaged by handreds of vias and other >> holes ). >> >Why would high speed current want to travel from the digital section to the >analog section? You're not going to route digital signals through the analog >section, so I don't see what you mean. And, how do a few via holes make any >difference? A copper plane has exceptionally low impedance. If you earthed a >'scope probe at one point on the ground plane, you won't see any noise as >you move the probe around the plane. Unless, of course, you cut a great big >slot in it. >> >> And these nosie will pick other paths with relatively low >> impedence in the digital gnd plane to return its source. So for the noise >> sensitive analog circuits, we do have a strong reason to give them a >> seperated gnd plane. In some high speed AD data capture card, plp tend to >> seperate the gnd plane into analog gnd plane and digital gnd plane. >> >Not if they know what they're doing, they don't. >> >> Leon, >> >OK, you've made up your mind, you go for it. But, make sure you come back >and read this thread in 8 months time while your board is failing the CE >mark for emissions. I hope you'll learn for the next time. Also, rather than >take advice from me on the FPGA newsgroup, why not ask your question on a >more appropriate forum, like the SI-LIST mailing list. Maybe they can help >you where I have failed. > >Good luck, Syms. > > > Symon: I am appreciate for your advice. You make me clarify some concepts. Maybe I am deeply misleaded by some people's design, you know I do not have enough experience in the field. I think I will take your advice. Thank you and John_H again. Leon,Article: 122118
"commone" <dechenxu@yahoo.com.cn> wrote in message news:joOdnVEefM8RFgLbRVn_vw@giganews.com... > > Symon: > I am appreciate for your advice. You make me clarify some concepts. Maybe > I am deeply misleaded by some people's design, you know I do not have > enough experience in the field. I think I will take your advice. Thank you > and John_H again. > Leon, > Hi Leon, Cool! I'm sorry if I was a little brusque in my last post; I'm not having a good day with my simulator, I shouldn't take it out on you! Best regards, Syms.Article: 122119
"Nico Coesel" <nico@puntnl.niks> wrote in message news:469f8a9c.905465200@news.planet.nl... > > Different values have a different self-inductance. If the PQ208 is > already bad lets not make it worse. But keep in mind the Spartan 3 is > not extremely fast. > Hi Nico, An 0402 capacitor has the (almost) the same inductance whether it's 10nF or 100nF. About 0.6nH. Syms.Article: 122120
On 2007-07-19, Xilinx User <anonymous@net.com> wrote: > always @* begin > for ( i = 0; i < DEPTH; i = i + 1 ) begin > ... > "unexpected event in sensitivity-list of always block." Is it including `i' in * and then complaining about it? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 122121
"Symon" <symon_brewer@hotmail.com> wrote in message news:f7o30r$itc$1@aioe.org... > "commone" <dechenxu@yahoo.com.cn> wrote in message > news:joOdnVEefM8RFgLbRVn_vw@giganews.com... >> >> Symon: >> I am appreciate for your advice. You make me clarify some concepts. Maybe >> I am deeply misleaded by some people's design, you know I do not have >> enough experience in the field. I think I will take your advice. Thank >> you >> and John_H again. >> Leon, >> > Hi Leon, > Cool! I'm sorry if I was a little brusque in my last post; I'm not having > a good day with my simulator, I shouldn't take it out on you! > Best regards, Syms. > Check this out http://www.elecdesign.com/Articles/Print.cfm?AD=1&ArticleID=5944 This guys agrees with me! Wooo! Warning:- Other people may have different opinions! Cheers, Syms.Article: 122122
Hi John, I know you don't believe the return current stuff, but I found this while chatting in another thread and thought you'd be interested. http://www.elecdesign.com/Articles/Print.cfm?AD=1&ArticleID=5944 BTW., I respectfully disagree that "Planes themselves are the best bypass caps, so we try to not "route" power, but pour it.". The planes give a little (maybe a few pF) of capacitance that has admittedly very small inductance associated with it. However, the vias and IC packaging band-limit the power connection to the die, which is where it matters, so that this 'wonder' capacitance does you no good. Furthermore, I find it's easier to isolate noise between ICs with a routed power scheme. But that's my opinion, I'm sure your boards work just fine also! :-) Cheers, Syms.Article: 122123
On 18 Jul., 07:55, "Ssa" <s...@djfs.com> wrote: > I've figured out how to compile the RTL in Xilinx ISE Webpack9.2i and Altera > Quurtus II 7.1. (It just took a few simple RTL-edits.) > > But what about the JTAG-debug unit? It seems to use the Lattice's > JTAG-block. > Can I just replace this with a generic JTAG TAP-controller, and then use a > Xilinx-hosted Mico32 with a Lattice download-cable? if you rebuild the lattice jtag-tap then yes. but you have to use fpga regular io pads, not xilinx bscan anttiArticle: 122124
Hello everybody,
I am trying to capture input video data using the Digilent Video
Decoder board (VDEC1) connected to the Xilinx XUPV2P board. I am
trying to use the EDK based example provided by Digilent on their
site. But when I try to build the design I am getting a licensing
error for the I2C IP used internally in the design. I have reproduced
the error below for reference.
Does anybody has any experience with something like this? I was
wondering if I had to buy the I2C Logicore IP separately from Xilinx.
Does digilent provide any evaluation license for this IP along with
the board or the example design?
Kindly share any experiences/suggestions you have with this. The
project I am working on critically depends on capturing the video data
from a camera. I will really appreciate any sort of help.
Thanks in advance,
Koustav
INFO:coreutil - Valid license for feature opb_iic_v1 not found.
You may use the customization GUI for this core but you will
not be able to generate any implementation or simulation files.
Contact Xilinx to obtain a full license for this LogiCORE. For more
information please refer to www.xilinx.com/ipcenter/ipevaluation/
FLEXlm Error: No such feature exists (-5,21)
ERROR:MDT - opb_iic (i2c) - C:\video_capture_rev_1_1\system.mhs line
193 -
invalid license or no license found!
plb_v34 (plb) - C:\video_capture_rev_1_1\system.mhs line 99 - 2
master(s) : 2
slave(s)
opb_v20 (opb) - C:\video_capture_rev_1_1\system.mhs line 108 - 1
master(s) : 2
slave(s)
Running UPDATE Tcl procedures for OPTION
PLATGEN_SYSLEVEL_UPDATE_PROC...
ERROR:MDT - platgen failed with errors!
make: *** [implementation/ppc405_0_wrapper.ngc] Error 2
Done!
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