Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 122100

Article: 122100
Subject: Enterpoint Web Site
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 19 Jul 2007 05:45:49 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Bypass caps for Spartan 3, PQ208, 4-layer board... Educational Project
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 19 Jul 2007 13:51:24 +0100
Links: << >>  << T >>  << A >>

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
Subject: Re: BD
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 19 Jul 2007 13:07:06 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 19 Jul 2007 13:23:07 GMT
Links: << >>  << T >>  << A >>
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_H

Article: 122104
Subject: Xilinx XST 9.2i.01 - still incomplete support for always @*
From: "Xilinx User" <anonymous@net.com>
Date: Thu, 19 Jul 2007 06:39:14 -0700
Links: << >>  << T >>  << A >>
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: 122105
Subject: Re: Xilinx S3 Starterkit, how hot it is supposed to be?
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 19 Jul 2007 07:09:49 -0700
Links: << >>  << T >>  << A >>
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: 122106
Subject: Re: Latches
From: Andy <jonesandy@comcast.net>
Date: Thu, 19 Jul 2007 07:10:07 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 19 Jul 2007 09:10:26 -0500
Links: << >>  << T >>  << A >>
>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
Subject: Re: Actel. Libero. Synplify
From: merche <dorama2@gmail.com>
Date: Thu, 19 Jul 2007 14:27:53 -0000
Links: << >>  << T >>  << A >>
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
Subject: Interfacing the EDK based video decoder
From: Koustav <koustav79@gmail.com>
Date: Thu, 19 Jul 2007 07:34:34 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 19 Jul 2007 15:55:14 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 19 Jul 2007 09:55:43 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx S3 Starterkit, how hot it is supposed to be?
From: austin <austin@xilinx.com>
Date: Thu, 19 Jul 2007 08:18:02 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx XST 9.2i.01 - still incomplete support for always @*
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 19 Jul 2007 08:21:03 -0700
Links: << >>  << T >>  << A >>
"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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 19 Jul 2007 08:36:28 -0700
Links: << >>  << T >>  << A >>
"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
Subject: Re: Bypass caps for Spartan 3, PQ208, 4-layer board... Educational Project
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 19 Jul 2007 08:47:15 -0700
Links: << >>  << T >>  << A >>
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.


John


Article: 122116
Subject: Re: Bypass caps for Spartan 3, PQ208, 4-layer board... Educational Project
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 19 Jul 2007 16:04:03 GMT
Links: << >>  << T >>  << A >>
"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.nl

Article: 122117
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 19 Jul 2007 11:04:28 -0500
Links: << >>  << T >>  << A >>
>"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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 19 Jul 2007 17:19:36 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: Bypass caps for Spartan 3, PQ208, 4-layer board... Educational Project
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 19 Jul 2007 17:24:23 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: Xilinx XST 9.2i.01 - still incomplete support for always @*
From: Ben Jackson <ben@ben.com>
Date: Thu, 19 Jul 2007 11:36:41 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 19 Jul 2007 17:43:47 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: Bypass caps for Spartan 3, PQ208, 4-layer board... Educational Project
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 19 Jul 2007 17:52:59 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: How do I use Lattice Mico32's debug-engine on a non-Lattice FPGA?
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 19 Jul 2007 17:26:14 -0000
Links: << >>  << T >>  << A >>
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

antti


Article: 122124
Subject: Using the EDK based video decoder
From: Koustav <koustav79@gmail.com>
Date: Thu, 19 Jul 2007 11:08:07 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search