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
2017JanFebMarApr2017

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 127800

Article: 127800
Subject: Re: Real examples of metastability causing bugs
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 8 Jan 2008 08:38:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 6:20=A0am, Eli Bendersky <eli...@gmail.com> wrote:
> Hello,
>
> Suppose that I'm sampling an asynchronous signal with a FF, without
> using any synchronizers before it. This FF will become metastable from
> time to time with a MTBF depending on the device's parameters, the
> clock rate and the input signal change rate.
>
Your item #2 describes the most common problem, exacerbated by
excessive routing delay differences.
Peter Alfke

> Can you please suggest *real life* examples of how this can make me
> fail in a real design, that is, where the time of recovery for the
> metastable event is indeed 0. Here are two off the top of my head:
>
> 1) The output of this FF can be used directly as the output of the
> device, causing an intermediate value on the output for some time,
> which can harm other devices.
>
> 2) If such an input is sampled by two different FFs for different
> purposes, they may end up with different results.
>
> Thanks in advance,
> Eli


Article: 127801
Subject: Re: Bad micro blaze behaviour during power off
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: Tue, 8 Jan 2008 09:08:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 10:58 am, jeroen.cl...@gemidis.be wrote:
> setup:
> On one of our designs we are using a Xilinx partan3 FPGA (XC3S500E -4
> FT(G)256 stepping1) and an spi flash (M25P40-VMN6) to store FPGA code,
> callibration data, board settings,...
>
> Problem description:
> Random SPI commands on the SPI bus from the FPGA to the flash are
> logged during a power down of the board. Sometimes a complete SPI
> write sequense is logged which makes the flash content corrupt.
>
> root cause:
> Power down of the FPGA is not correct accoarding to the spec. The fall
> time of the power supply is to long. this results in a bad behaviour
> of the micro Blaze(uB). During power down the pointer of the uB is
> jumping to a random place in the uB code. From this point the uB
> executes several actions depending on the fall time of the power
> supply. It happens that the pointer jumps to the "write_spi_flash"
> function in the code.
>
> solution:
> The best solution is to make the power off sequense of the FPGA
> according to the spec. It is possible to place a power monitor on the
> board but this results in a redesign of the board and we do not
> prefere to do so.
>
> question:
> Is there somebody who knows another solution that does not require a
> redesign of the board?


Does the microblaze know that it will be shut down ?

If so, you can erase the whole program memory from the BRAM before
shutting down ...
Or add some hardware to disconnect the IOB of the SPI once you
shutdown ...

But it all pretty much implies you know when you shutdown ...

Sylvain

Article: 127802
Subject: Re: passive serial quaestion
From: Zorjak <Zorjak@gmail.com>
Date: Tue, 8 Jan 2008 09:22:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 4:48 pm, Ben Jackson <b...@ben.com> wrote:
> On 2008-01-08, Zorjak <Zor...@gmail.com> wrote:
>
>
>
> > Can flex 8000 series be programed in the same way as cyclone families.
>
> There are differences.  I think FLEX actually has MORE ways to configure,
> eg parallel.
>
> > Which programing file is used when fpga is programed .sof or .pof. Is
> > the programing equipment compatible.
>
> A sof is an "sram object file" and is the actual FPGA bitstream.  A
> pof (programming object file??) is a container for writing flash devices.
> You can put more than one sof in a pof (as well as other data).
> You use the sof if you do direct JTAG programming.
>
> The 'programming equipment' is typically an Altera byteblaster cable.
> The byteblaster MV cannot program flash devices (iirc) while the
> byteblaster II can.
>
> --
> Ben Jackson AD7GD
> <b...@ben.com>http://www.ben.com/

Thank You for your answer, Bob
Zoran

Article: 127803
Subject: Re: Bad micro blaze behaviour during power off
From: austin <austin@xilinx.com>
Date: Tue, 08 Jan 2008 09:32:03 -0800
Links: << >>  << T >>  << A >>
jeroen,

What I would do is add code to the spi_write subroutine that checks who
called it (a list of allowed calling locations is checked before
execution), and/or add a check in the spi_write subroutine that a
specific memory location or register has been written to in order to
allow the operation.

Then before every legitimate call to the spi_write, the special added
register has the "go" command written to it, and that command is
immediately cleared when recognized by the spi_write subroutine (so it
can't happen again without intending it to).  The command should be
something that is different than any powering down condition, something
like 0xAAh, or 0x55h for example.

Austin

Article: 127804
Subject: True Dual Port RAM
From: "Colin Hankins" <Colin.Hankins@touit.com>
Date: Tue, 8 Jan 2008 09:55:25 -0800
Links: << >>  << T >>  << A >>
I am unable to infer a True Dual Port RAM in ispLEVER using VHDL. I'm 
targetting the Lattice ECP2M using Synplify. Even the provided example 
located in 
isptools7_0\examples\fpga\latticexp2\memory\inferencing\true_dual_port\vhdl\true_dual_port.vhd 
does not synthesize successfully. Has anyone else had any better luck at 
this?

Thanks,
Colin 



Article: 127805
Subject: Re: Real examples of metastability causing bugs
From: Eli Bendersky <eliben@gmail.com>
Date: Tue, 8 Jan 2008 09:57:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 6:38 pm, Peter Alfke <pe...@xilinx.com> wrote:
> On Jan 8, 6:20 am, Eli Bendersky <eli...@gmail.com> wrote:> Hello,
>
> > Suppose that I'm sampling an asynchronous signal with a FF, without
> > using any synchronizers before it. This FF will become metastable from
> > time to time with a MTBF depending on the device's parameters, the
> > clock rate and the input signal change rate.
>
> Your item #2 describes the most common problem, exacerbated by
> excessive routing delay differences.
> Peter Alfke
>

Hi Peter, thanks for answering.
Could you provide a piece of VHDL/Verilog code that is realistic and
has this problem ?


Article: 127806
Subject: Re: DDR SDRAM demo for Spartan-3E starter kit?
From: quark.flavour@gmail.com
Date: Tue, 8 Jan 2008 09:59:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 12:53=A0pm, j...@capsec.org wrote:

> Strange, I remember DCM_SP is the DCM variant one should use in
> Spartan3E... Can't remember for sure...

DCM_SP should be correct, it is the Spartan3E DCM.

Andrew

Article: 127807
Subject: Please, help - I have got confused about package type
From: Vagant <vladimir.v.korostelev@rambler.ru>
Date: Tue, 8 Jan 2008 10:04:16 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,
I have Spartan 3E1600E Microblaze Development kit with FPGA marked as:

-----------------------------
Xilinx
SPARTAN
XC3S1600E
FGG320DGQO617
A1408025A1
4C
-----------------------------
KOREA

How I could know its package type? It should be either FG320, or
FG400, or FG484.
Looking at chip's appearance I thought that it is FG484 (as I know how
this looks) but it's marked as FGG320DGQO617 so I am not sure which
package type of my FPGA is?

Article: 127808
Subject: Re: Please, help - I have got confused about package type
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Jan 2008 18:20:00 -0000
Links: << >>  << T >>  << A >>
"Vagant" <vladimir.v.korostelev@rambler.ru> wrote in message 
news:81f5ec31-8be7-49e8-b6df-cfe671cfa232@d70g2000hsb.googlegroups.com...
> Hello,
> I have Spartan 3E1600E Microblaze Development kit with FPGA marked as:
>
> -----------------------------
> Xilinx
> SPARTAN
> XC3S1600E
> FGG320DGQO617
> A1408025A1
> 4C
> -----------------------------
> KOREA
>
> How I could know its package type? It should be either FG320, or
> FG400, or FG484.
> Looking at chip's appearance I thought that it is FG484 (as I know how
> this looks) but it's marked as FGG320DGQO617 so I am not sure which
> package type of my FPGA is?

Hi Vladimir,
The clue is FGG320. Or you could could your balls. ;-)
HTH., Syms 



Article: 127809
Subject: Re: Real examples of metastability causing bugs
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Jan 2008 18:24:50 -0000
Links: << >>  << T >>  << A >>
"Eli Bendersky" <eliben@gmail.com> wrote in message 
news:fa77eae8-4d70-412e-9a85-738b04c50647@1g2000hsl.googlegroups.com...
>
> Hi Peter, thanks for answering.
> Could you provide a piece of VHDL/Verilog code that is realistic and
> has this problem ?
>
Hi Eli,

process(clock)
  begin
   if rising_edge(clock) then
     if bad_input = '1' then
       count <= (count + 2) mod 8;
     else
       count <= (count + 1) mod 8;
     end if;
   end if;
  end process;

It's possible for count to increment by 3 if the bad_input gets to bit 1 of 
count before it gets to bit 0.

HTH., Syms. 



Article: 127810
Subject: Re: Please, help - I have got confused about package type
From: Vagant <vladimir.v.korostelev@rambler.ru>
Date: Tue, 8 Jan 2008 10:48:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 8:20=A0pm, "Symon" <symon_bre...@hotmail.com> wrote:
> "Vagant" <vladimir.v.koroste...@rambler.ru> wrote in message
>
> news:81f5ec31-8be7-49e8-b6df-cfe671cfa232@d70g2000hsb.googlegroups.com...
>
>
>
>
>
> > Hello,
> > I have Spartan 3E1600E Microblaze Development kit with FPGA marked as:
>
> > -----------------------------
> > Xilinx
> > SPARTAN
> > XC3S1600E
> > FGG320DGQO617
> > A1408025A1
> > 4C
> > -----------------------------
> > KOREA
>
> > How I could know its package type? It should be either FG320, or
> > FG400, or FG484.
> > Looking at chip's appearance I thought that it is FG484 (as I know how
> > this looks) but it's marked as FGG320DGQO617 so I am not sure which
> > package type of my FPGA is?
>
> Hi Vladimir,
> The clue is FGG320. Or you could could your balls. ;-)
> HTH., Syms- Hide quoted text -
>
> - Show quoted text -

Okay ;) I just wonder whether FG484 and FG320 chip packages are
similar in appearance?

Article: 127811
Subject: Re: Real examples of metastability causing bugs
From: MikeShepherd564@btinternet.com
Date: Tue, 08 Jan 2008 19:10:20 +0000
Links: << >>  << T >>  << A >>
>...Here are two off the top of my head:
>
>1...
>2)...

Aren't those two reasons enough for avoiding it?

Or are we just doing your homework?

Mike

Article: 127812
Subject: Re: Bad micro blaze behaviour during power off
From: MikeShepherd564@btinternet.com
Date: Tue, 08 Jan 2008 19:17:56 +0000
Links: << >>  << T >>  << A >>
>...before every legitimate call to the spi_write, the special added
>register..."go" command...0xAAh, or 0x55h for example.

Such "write unlock sequences" are intended to prevent a write which
could otherwise be caused by a single spurious signal (e.g. as power
is lost).

They don't help against spurious code execution (whether at power-down
or otherwise), because that's as likely to begin before the "unlock"
as after.

Mike

Article: 127813
Subject: Re: True Dual Port RAM
From: "Maki" <veselic123@eunet.yu>
Date: Tue, 8 Jan 2008 20:24:58 +0100
Links: << >>  << T >>  << A >>
>I am unable to infer a True Dual Port RAM in ispLEVER using VHDL. I'm
> targetting the Lattice ECP2M using Synplify. Even the provided example 
> located in 
> isptools7_0\examples\fpga\latticexp2\memory\inferencing\true_dual_port\vhdl\true_dual_port.vhd 
> does not synthesize successfully. Has anyone else had any better luck at 
> this?

It works fine with Precision. I too had the same problem with Synplify ver 
8.1 IIRC. It appears that template is all wrong for Synplify. Try another 
one from Sunplify user guide...

Happy inferencing  :)

>
> Thanks,
> Colin

Maki.



Article: 127814
Subject: Re: Bad micro blaze behaviour during power off
From: austin <austin@xilinx.com>
Date: Tue, 08 Jan 2008 11:28:11 -0800
Links: << >>  << T >>  << A >>
Mike,

The probability that you branch to the spi-write subroutine AFTER the
check is possible, I agree.

It is also possible the code branches to a valid section that is going
to call the spi_write subroutine.

Hence the reason why I added the check of who calls the spi_write.

Of course, you can jump in right after that check, too.

I think the point is to minimize the probabilities to the point where it
meets the requirements of their customers.  If there is one, and only
one valid address that skips all the checks, then the probabilities are
pretty small, and of no concern.

Another suggestion was to slow things down.  If the spi_write is called,
it waits the power down time before continuing, that helps, too (if it
is a real power down, power is down before you do anything bad).  You
may also call the routine just after the wait, but again, it is the
statistics,

Austin

Article: 127815
Subject: Re: Real examples of metastability causing bugs
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 8 Jan 2008 11:41:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 6:20=A0am, Eli Bendersky <eli...@gmail.com> wrote:
> Hello,
>
> Suppose that I'm sampling an asynchronous signal with a FF, without
> using any synchronizers before it. This FF will become metastable from
> time to time with a MTBF depending on the device's parameters, the
> clock rate and the input signal change rate.
>
Eli, Look at XAPP094 (you can easily google it) It shows the circuit I
have used to quantify metastable delay.
The delay is short, so you have to be quick to catch it...
Peter Alfke

> Can you please suggest *real life* examples of how this can make me
> fail in a real design, that is, where the time of recovery for the
> metastable event is indeed 0. Here are two off the top of my head:
>
> 1) The output of this FF can be used directly as the output of the
> device, causing an intermediate value on the output for some time,
> which can harm other devices.
>
> 2) If such an input is sampled by two different FFs for different
> purposes, they may end up with different results.
>
> Thanks in advance,
> Eli


Article: 127816
Subject: Warning 'clock has been changed'
From: Vagant <vladimir.v.korostelev@rambler.ru>
Date: Tue, 8 Jan 2008 12:19:57 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello All,

I have got a warning (below) during implementation of my design which
uses 50 MHz clock on Spartan 3E 1600E Microblaze Development Kit. What
could be a reason for this warning and how it could be fixed?

WARNING:iMPACT:2257-Startup clock has been changed to 'JtagClk' in the
bitstream stored in memory, but the original bitstream file remains
unchanged.

Article: 127817
Subject: Re: Low Power CPU Implementation
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 8 Jan 2008 20:56:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-01-08, Rgr <rgrworking@hotmail.com> wrote:
> Hi all.
> I am doing a small Processor implementation (with the performance somewhat 
> like an 8051 CPU), and I am designing for "as low power as possible".
> I want to use reconfigurable logic as I am interested in the the flexibility 
> and the possibility of adding additional logic to my design.

I'm no expert in low-power CPLD design, but my first idea is that if you
chose a CPLD without internal memories you will burn quite a lot of power
while communicating with your external program/data memories.
(I could also add the Lattice has a few CPLDs (more like CPLD/FPGA hybrid
 with built in RAM which you also might to look into.)

The question is of course if you are doing this for fun or for a product.
If it is for fun, do whatever you wish and learn from it :) (And if you
learn something interesting while doing this, why not report it to this
newsgroup.)

If it is for a product I am very doubtful about using a processor in a CPLD,
especially if low power is a requirement...

/Andreas

Article: 127818
Subject: Re: Warning 'clock has been changed'
From: John McCaskill <jhmccaskill@gmail.com>
Date: Tue, 8 Jan 2008 13:02:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 2:19 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote:
> Hello All,
>
> I have got a warning (below) during implementation of my design which
> uses 50 MHz clock on Spartan 3E 1600E Microblaze Development Kit. What
> could be a reason for this warning and how it could be fixed?
>
> WARNING:iMPACT:2257-Startup clock has been changed to 'JtagClk' in the
> bitstream stored in memory, but the original bitstream file remains
> unchanged.

You do not need to fix anything unless you just want to make the
warning go away.

This just means that bitgen was told to generate the bitfile with the
startup clock set to CCLK. Since you are downloading with a JTAG
cable, Impact automatically modified the bitfile before downloading it
for you.  In EDK you can edit the project_dir/etc/bitgen.ut file in
your project to change the startup clock option.

If you plan on putting your bitfile into what ever config memory you
have on the card, I would just leave the startup clock set to CCLK
like it is now. Impact will work fine with it that way, but changing
it to use the JtagClk would cause you problems if you forget to change
it back before creating a bitfile for the config memory.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 127819
Subject: Re: Warning 'clock has been changed'
From: Gabor <gabor@alacron.com>
Date: Tue, 8 Jan 2008 13:06:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 3:19 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote:
> Hello All,
>
> I have got a warning (below) during implementation of my design which
> uses 50 MHz clock on Spartan 3E 1600E Microblaze Development Kit. What
> could be a reason for this warning and how it could be fixed?
>
> WARNING:iMPACT:2257-Startup clock has been changed to 'JtagClk' in the
> bitstream stored in memory, but the original bitstream file remains
> unchanged.

This is talking about the configuration startup clock, not the 50 MHz
system clock of your running design.  If your bitstream settings are
default, your CCLK will normally be used to start up the FPGA after
configuration.  When using iMPACT in JTAG mode, this clock is not
available, so iMPACT changes it for you to use the JTAG TCK signal
instead.  This is the normal behavior, and you don't need to worry
about it.  Additional information on configuration is available in the
Spartan 3 Generation Configuration User Guide, ug332.pdf, available
on the Xilinx website.

Article: 127820
Subject: Re: Real examples of metastability causing bugs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 08 Jan 2008 13:49:54 -0800
Links: << >>  << T >>  << A >>
Symon wrote:
(snip)

> process(clock)
>   begin
>    if rising_edge(clock) then
>      if bad_input = '1' then
>        count <= (count + 2) mod 8;
>      else
>        count <= (count + 1) mod 8;
>      end if;
>    end if;
>   end process;

> It's possible for count to increment by 3 if the bad_input
> gets to bit 1 of count before it gets to bit 0.

I would have called this an ordinary setup/hold violation.

If the problem is due to timing of bad_input, propagated
through the MUX that I presume it generates, then it should
be setup/hold violation.

Metastability should occur due to clock rate issues, through
the appropriate propagation delay, but independent of bad_input,
and only if bad_input does satisfy setup/hold.

I would say that the usual cause of option 2 in the previous
post is also setup/hold violation.

Note that this system can fail even with perfect FFs due to
different propagation delays.

-- glen


Article: 127821
Subject: Re: Real examples of metastability causing bugs
From: Andy <jonesandy@comcast.net>
Date: Tue, 8 Jan 2008 14:36:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 3:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Symon wrote:
>
> (snip)
>
> > process(clock)
> >   begin
> >    if rising_edge(clock) then
> >      if bad_input = '1' then
> >        count <= (count + 2) mod 8;
> >      else
> >        count <= (count + 1) mod 8;
> >      end if;
> >    end if;
> >   end process;
> > It's possible for count to increment by 3 if the bad_input
> > gets to bit 1 of count before it gets to bit 0.
>
> I would have called this an ordinary setup/hold violation.
>
> If the problem is due to timing of bad_input, propagated
> through the MUX that I presume it generates, then it should
> be setup/hold violation.
>
> Metastability should occur due to clock rate issues, through
> the appropriate propagation delay, but independent of bad_input,
> and only if bad_input does satisfy setup/hold.
>
> I would say that the usual cause of option 2 in the previous
> post is also setup/hold violation.
>
> Note that this system can fail even with perfect FFs due to
> different propagation delays.
>
> -- glen

I agree, #2 is independent of metastability; it is a parallel
synchronizer, which is a bad thing. If the propagation skew is more
than setup+hold to all of the destination registers, it could meet
setup and hold on all of them (avoiding metastability), while still
failing functionally (incrementing by 3).

Andy

Article: 127822
Subject: Re: Split Plane
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 08 Jan 2008 14:43:25 -0800
Links: << >>  << T >>  << A >>
Symon wrote:
(snip, I wrote)
>>Symon wrote:

>>>Do you not think that the trace inductance and magnetic field are 
>>>important? You don't mention them at all in your post. Just thinking 
>>>about the capacitance is not the whole story...

>>Inductance that is part of an impedance matched transmission
>>line doesn't count.

> And why is that?

For an impedance matched line, the inductance and capacitance
balance out.  This might be easier to see for a line that is
not impedance matched.

It is common for telephone lines to be UTP cable of around
100 ohm impedance driven by a 600 ohm source.  The frequency
has to be low enough, but that isn't a problem for telephone
lines.  What does happen, though, is that the excess capacitance
causes a high frequency drop off.  A 600 ohm line would have
more inductance (per unit length) or less capacitance
(per unit length).  This fix for this is to add series
inductors periodically along the length, maybe every 5000 feet.
This improves the frequency response in the voice band, with
a sharp drop after that.

http://en.wikipedia.org/wiki/Load_coil

>> The situation at the end, where the trace
>>crosses the gap is a little complicated.  As the current spreads
>>out in the split plane, it isn't quite a transmission line anymore.
>>The half plane inductance should be pretty low, but it won't
>>say it doesn't count.

> What about the increased loop area because the current
 > goes around the slot?

At low frequencies it goes around.  As the frequency increases,
the capacitance of the system is enough to support the current.
At really high frequencies (wavelength much shorter than the
dielectric thickness) the problem goes away.

> Does this increase the generation of the magnetic field? Are you only 
> considering the inductance of the plane, or the inductance of the trace 
> also?

The assumption is that the trace is properly impedance
matched to its load and source.

>>At some point I made the assumption that there was something on
>>the other side of the split plane to make a good capacitor.
>>(Another split plane would do.  It would work on either side.)

> You really lost me there. Sorry.

Well, as an example, both split power and ground planes, with the signal
line either between them or on one side.

>>Consider a circular parallel plate capacitor fed at the center.
>>Then consider it as concentric ring capacitors and the radial
>>inductance of those rings.  The inductance per (radial) length
>>decreases with increasing radius, the capacitance per radial
>>distance increases with increasing radius.  I believe that makes
>>capacitance win out over inductance for reasonable frequencies.

> How does the current get from the centre to these "concentric ring 
> capacitors"? I think it travels out radially, and this current
> generates a magnetic field.

And the voltage generates an electric field.

The result is a transmission line in the radial direction.
The impedance, sqrt(L/C), decreases fast with radius, the
velocity, depending on LC, stays constant with radius.
The decreasing impedance makes it look capacitive to
the load for radius greater than the trace width.
(You can also see that through the increasing capacitance
and decreasing inductance with increasing radius.)

The decreasing impedance with distance allows it to support
the needed current, assuming the wires crossing the split
aren't too close together.

-- glen



Article: 127823
Subject: Re: Real examples of metastability causing bugs
From: Andy <jonesandy@comcast.net>
Date: Tue, 8 Jan 2008 14:48:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 3:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Symon wrote:
>
> (snip)
>
> > process(clock)
> >   begin
> >    if rising_edge(clock) then
> >      if bad_input = '1' then
> >        count <= (count + 2) mod 8;
> >      else
> >        count <= (count + 1) mod 8;
> >      end if;
> >    end if;
> >   end process;
> > It's possible for count to increment by 3 if the bad_input
> > gets to bit 1 of count before it gets to bit 0.
>
> I would have called this an ordinary setup/hold violation.
>
> If the problem is due to timing of bad_input, propagated
> through the MUX that I presume it generates, then it should
> be setup/hold violation.
>
> Metastability should occur due to clock rate issues, through
> the appropriate propagation delay, but independent of bad_input,
> and only if bad_input does satisfy setup/hold.
>
> I would say that the usual cause of option 2 in the previous
> post is also setup/hold violation.
>
> Note that this system can fail even with perfect FFs due to
> different propagation delays.
>
> -- glen

Example #1

process (event, out2) is
begin
  if out2= '1' then
    out1 <= '0';
  elsif rising_edge(event) then
    out1 <= '1';
  end if;
end process;

process (clk2) is
begin
  if rising_edge(clk2) then
    out2 <= out1;
  end if;
end process;

A long, long time ago, I once had this problem on a board (74f74 dual
flops), where another circuit running on clk2 was also looking at
out2. The second flop (out2) would go metastable true just long enough
to reset out1, and then settle false, so the other circuit would not
see it on the next clk2. Since out1 had been reset, it was not there
the next clk2, and was lost.

Note these are very poor design practices for FPGAs (use of async
reset for anything but initialization), but were very common on board
level designs (when done properly).

Andy

Article: 127824
Subject: Re: Real examples of metastability causing bugs
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 08 Jan 2008 14:56:27 -0800
Links: << >>  << T >>  << A >>
Eli Bendersky wrote:

> 1) The output of this FF can be used directly as the output of the
> device, causing an intermediate value on the output for some time,
> which can harm other devices.

This FF might be used as an input synchronizer
intended to eliminate logic races.
Setup and hold violations are to be expected
for a synchronizer and in almost all cases
synchronization succeeds anyway.

But maybe once a year, the bowling ball
stops on the speed bump and synchronization fails
and the synchronizer causes a logic race.

The race may or may not cause a bad state transition.

A bad transition may or may not cause
an observable error.

I might be able to improve my odds to say,
one synchronization failure  in 100 years
by using a two stage synchronizer, but
I can't eliminate the possibility.


> 2) If such an input is sampled by two different FFs for different
> purposes, they may end up with different results.

This is the case of the *missing* synchronizer.
This is often confused with metastability,
but it is really a design error.
I don't have to wait nearly as long to
observe an error in this case.

        -- Mike Treseler



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
2017JanFebMarApr2017

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