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 157425

Article: 157425
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 4 Dec 2014 16:24:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 4, 2014 7:17:19 PM UTC-5, rickman wrote:
> > It was free.  I ordered it as a sample.
> Why would you *order* a chip that isn't on a board?  I have lots of 
> "sample" chips I've never used because they aren't on a board.

I liked the API and documentation.  It's a beautiful product.  If I
ever create my own mainboard, I'll probably use two or three of that
component for those reasons.

Best regards,
Rick C. Hodgin

Article: 157426
Subject: Re: Which Altera to buy?
From: rickman <gnuarm@gmail.com>
Date: Thu, 04 Dec 2014 19:44:34 -0500
Links: << >>  << T >>  << A >>
On 12/4/2014 7:24 PM, Rick C. Hodgin wrote:
> On Thursday, December 4, 2014 7:17:19 PM UTC-5, rickman wrote:
>>> It was free.  I ordered it as a sample.
>> Why would you *order* a chip that isn't on a board?  I have lots of
>> "sample" chips I've never used because they aren't on a board.
>
> I liked the API and documentation.  It's a beautiful product.  If I
> ever create my own mainboard, I'll probably use two or three of that
> component for those reasons.

I can't say I follow your reasoning.  You are using this chip which 
requires you to find a board to mount it on... but just for a few weeks. 
  Then you will use the "PHY" that you have ordered.  Then at a latter 
time you will use this chip again?  Why not just stick with this chip? 
Once you figure out how to mount it where's the down side?

-- 

Rick

Article: 157427
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 4 Dec 2014 16:59:38 -0800 (PST)
Links: << >>  << T >>  << A >>
rickman writes:
> I can't say I follow your reasoning. You are
> using this chip which requires you to find a
> board to mount it on... but just for a few
> weeks. Then you will use the "PHY" that you
> have ordered. Then at a latter time you will
> use this chip again? Why not just stick with
> this chip? Once you figure out how to mount
> it where's the down side?

You misunderstand because we're not having a
conversation, but only back-and-forth across a
written form where assumption and guesswork
enter in. And you already seem to have either a
natural bias against me, or are having difficulties
in understanding me, or both.

Don't worry about it though. It will all work out.

Best regards,
Rick C. Hodgin

Article: 157428
Subject: Re: Which Altera to buy?
From: rickman <gnuarm@gmail.com>
Date: Thu, 04 Dec 2014 21:08:17 -0500
Links: << >>  << T >>  << A >>
On 12/4/2014 7:59 PM, Rick C. Hodgin wrote:
> rickman writes:
>> I can't say I follow your reasoning. You are
>> using this chip which requires you to find a
>> board to mount it on... but just for a few
>> weeks. Then you will use the "PHY" that you
>> have ordered. Then at a latter time you will
>> use this chip again? Why not just stick with
>> this chip? Once you figure out how to mount
>> it where's the down side?
>
> You misunderstand because we're not having a
> conversation, but only back-and-forth across a
> written form where assumption and guesswork
> enter in. And you already seem to have either a
> natural bias against me, or are having difficulties
> in understanding me, or both.

I don't have any bias.  I read what you write.  If that is not clear I 
ask questions.  But like this time you often don't answer them.  So I am 
left not knowing what is in your mind.  This part of the conversation 
was so disjointed that I reviewed the messages you wrote, so I'm pretty 
sure I am reading it correctly.

If you don't want to discuss this with me, that's fine.  If you don't 
respond I'll stop asking. :)

-- 

Rick

Article: 157429
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 4 Dec 2014 20:47:04 -0800 (PST)
Links: << >>  << T >>  << A >>
Theo Markettos wrotes:
> There are two Altera components that might
> be useful...

Theo, a lot of useful information. Thank you very much.

Best regards,
Rick C. Hodgin

Article: 157430
Subject: Re: Which Altera to buy?
From: HT-Lab <hans64@htminuslab.com>
Date: Fri, 05 Dec 2014 10:40:38 +0000
Links: << >>  << T >>  << A >>
On 04/12/2014 23:00, Rick C. Hodgin wrote:
> On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
>> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:
>>> I ended up ordering this board:
>>>      http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
>>>
>>> If anyone has advice on how to get communication running most easily
>>> on this board, I would appreciate it.  Thank you in advance.
>>
>> Doesn't look like you have a lot of options on this board.  UART serial
>> to USB is the one comms choice.  I thought you were going to use
>> Ethernet.
>
> I plan to.  I won't receive the PHY board I bought until the end of
> December though.  If there's another option I'll use that in the time
> in-between, and possible after that.
>
> I have one of the Silicon Labs chips arriving this week, but I'll need
> to get a converter from its TQFP48 form factor to something usable by
> human beings. I may go ahead and do that anyway.  The Silicon Labs API
> is very clean and straight-forward.
>
>      http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx
>

I would look at Microchip's 28j60 controller, you only need a few wires 
to talk to it (SPI) and there are lots of low cost eval boards available 
on eBay and other places.

http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9

Hans
www.ht-lab.com


>> That seems to be another $250, wow, more than the FPGA board.
>> I guess you can add one via the Arduino interface for next to
>> nothing.
>
> Best regards,
> Rick C. Hodgin
>


Article: 157431
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 5 Dec 2014 05:17:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 5, 2014 5:40:46 AM UTC-5, HT-Lab wrote:
> I would look at Microchip's 28j60 controller, you only need a few wires 
> to talk to it (SPI) and there are lots of low cost eval boards available 
> on eBay and other places.
> 
> http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9
> 
> Hans
> www.ht-lab.com

Thank you, Hans.

Best regards,
Rick C. Hodgin

Article: 157432
Subject: Re: Which Altera to buy?
From: "vanepp" <92554@embeddedrelated>
Date: Fri, 05 Dec 2014 13:42:33 -0600
Links: << >>  << T >>  << A >>
>On 04/12/2014 23:00, Rick C. Hodgin wrote:
>> On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
>>> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:
<snip>
>
>I would look at Microchip's 28j60 controller, you only need a few wires 
>to talk to it (SPI) and there are lots of low cost eval boards available 
>on eBay and other places.
>
>http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9
>
>Hans
>www.ht-lab.com
>
>

   One issue to note on the ENC28J60 is that it does not do
autonegotiation.. Thus if
you want/need full duplex you need to manually set the speed and duplex on
the
receiving port or you will get duplex mismatch and difficult to debug
problems. You
can not manually set the ports on most cheap network switches and they will
(as 
the standard requires) usually default to 10 half duplex. This is pointed
out in the ENC28J60 data sheet but the implications to duplex mismatch may
not be obvious to a non network person. Using one to connect to a PC isn't
a problem as you can manually set the speed and duplex on the PC port to
match that of the ENC28J60 and run 100 full duplex (modulo spi speed of
course, I think max spi speed is 25 megabits or so on the
ENC28J60) on both ends. None the less a very cheap simple ethernet solution
if you 
pay attention to its limitations. 

Peter Van Epp	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157433
Subject: ICE40 Logic Cells
From: rickman <gnuarm@gmail.com>
Date: Fri, 05 Dec 2014 15:16:03 -0500
Links: << >>  << T >>  << A >>
I was aware that the ICE40 devices have some limitations compared to 
other devices that are not so cost and power constrained.  Until now the 
apparent lack of LUT RAM escaped me.  I guess it is one of those 
features that is so ingrained in my mind that I never noticed they don't 
talk about it.  The LP family has a very low end member with only 384 
LUTs and *no* block RAM, so I was considering what I might do with the 
LUT RAM.  Not much.  They don't mention the LUT RAM anywhere and barely 
mention the LUTs as ROM only peripherally, but I'm pretty sure that is 
available since it is the same as logic.

Wow, the 384 LUT part has no RAM at all, so it ends up being incredibly 
limited.

-- 

Rick

Article: 157434
Subject: Re: ICE40 Logic Cells
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Fri, 5 Dec 2014 12:54:52 -0800
Links: << >>  << T >>  << A >>
On Fri, 05 Dec 2014 15:16:03 -0500
rickman <gnuarm@gmail.com> wrote:

> I was aware that the ICE40 devices have some limitations compared to 
> other devices that are not so cost and power constrained.  Until now the 
> apparent lack of LUT RAM escaped me.  I guess it is one of those 
> features that is so ingrained in my mind that I never noticed they don't 
> talk about it.  The LP family has a very low end member with only 384 
> LUTs and *no* block RAM, so I was considering what I might do with the 
> LUT RAM.  Not much.  They don't mention the LUT RAM anywhere and barely 
> mention the LUTs as ROM only peripherally, but I'm pretty sure that is 
> available since it is the same as logic.
> 
> Wow, the 384 LUT part has no RAM at all, so it ends up being incredibly 
> limited.
> 
> -- 
> 
> Rick

At that point it's basically just a CPLD killer.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157435
Subject: Re: ICE40 Logic Cells
From: rickman <gnuarm@gmail.com>
Date: Fri, 05 Dec 2014 16:36:54 -0500
Links: << >>  << T >>  << A >>
On 12/5/2014 3:54 PM, Rob Gaddi wrote:
> On Fri, 05 Dec 2014 15:16:03 -0500
> rickman <gnuarm@gmail.com> wrote:
>
>> I was aware that the ICE40 devices have some limitations compared to
>> other devices that are not so cost and power constrained.  Until now the
>> apparent lack of LUT RAM escaped me.  I guess it is one of those
>> features that is so ingrained in my mind that I never noticed they don't
>> talk about it.  The LP family has a very low end member with only 384
>> LUTs and *no* block RAM, so I was considering what I might do with the
>> LUT RAM.  Not much.  They don't mention the LUT RAM anywhere and barely
>> mention the LUTs as ROM only peripherally, but I'm pretty sure that is
>> available since it is the same as logic.
>>
>> Wow, the 384 LUT part has no RAM at all, so it ends up being incredibly
>> limited.
>>
>> --
>>
>> Rick
>
> At that point it's basically just a CPLD killer.

Yes, you are exactly right.  Lowest possible price.

They have an ICE40LM line that only uses configuration RAM with no 
internal configuration storage.  Funny how you can read the data sheet 
looking for the raison d'etre of a part but can't see it because of the 
marketing crap.  I've seen this sub family for a while  now and always 
thought it was about the hard cores (I2C, SPI, etc).  It is about the 
lowest possible cost meaning no config storage.  I guess the assumption 
is the configuration is stored elsewhere for pennies.

-- 

Rick

Article: 157436
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 8 Dec 2014 11:40:11 -0800 (PST)
Links: << >>  << T >>  << A >>
The board has arrived!
The board has arrived!
Shout from the roofs, "The board has arrived!"

:-)

Best regards,
Rick C. Hodgin

Article: 157437
Subject: VHDL Synchronization- two stage FF on all inputs?
From: "hvo" <91991@embeddedrelated>
Date: Tue, 09 Dec 2014 18:22:41 -0600
Links: << >>  << T >>  << A >>
Hello,

I know this topic is beaten to death but I am a bit unlcear some things.

I've recently encountered metastability issues that caused my FPGA to do
unpredictable things.  Someone suggested that I synchronize my inputs to
the clock domain and that seemed to solve the issue.  Googling this topic
showed that a two stage Flip Flop is sufficient to increase MTBF for
metastability.  My question is do I need to do this for all input signals? 
How would one do this with a design containing 30 to 40 input signals? 
Which types of inputs can I get away with not using two stage FF?  

So in the sample code below, both INA or INB can change state while the clk
is transitioning and this could lead to metastability.  Synchronizing INA
and INB would help, but what about INC and IND?

Would the experts just synchronize everything and forget about it?

-----------------------------------------------------------------------------------------
--  Sample code with asynchronous inputs
-----------------------------------------------------------------------------------------
entity blackbox is
port ( 
Clk : in std_logic;
RST : in std_logic;
INA : in std_logic;
INB : in std_logic;
INC : in std_logic;
IND : in std_logic;
Out : out std_logic
);
end blackbox;

architecture Behavioral of blackboxis
begin

BB: process(Clk, RST) is 
begin

if(RST = '1') then
  Out <= '0';
elsif(Clk'event and Clk = '1') then
  if(INA = '1' and INB = '1') then
    Out <= INC;
  else
    Out <= IND;
  end if;
end if;
end process BB;
-----------------------------------------------------------------------------------------

Any feedback is much appreciated.
Thanks
HV.
 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157438
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Tue, 9 Dec 2014 17:35:23 -0800
Links: << >>  << T >>  << A >>
On Tue, 09 Dec 2014 18:22:41 -0600
"hvo" <91991@embeddedrelated> wrote:

> Hello,
> 
> I know this topic is beaten to death but I am a bit unlcear some things.
> 
> I've recently encountered metastability issues that caused my FPGA to do
> unpredictable things.  Someone suggested that I synchronize my inputs to
> the clock domain and that seemed to solve the issue.  Googling this topic
> showed that a two stage Flip Flop is sufficient to increase MTBF for
> metastability.  My question is do I need to do this for all input signals? 
> How would one do this with a design containing 30 to 40 input signals? 
> Which types of inputs can I get away with not using two stage FF?  
> 
> So in the sample code below, both INA or INB can change state while the clk
> is transitioning and this could lead to metastability.  Synchronizing INA
> and INB would help, but what about INC and IND?
> 
> Would the experts just synchronize everything and forget about it?
> 
> -----------------------------------------------------------------------------------------
> --  Sample code with asynchronous inputs
> -----------------------------------------------------------------------------------------
> entity blackbox is
> port ( 
> Clk : in std_logic;
> RST : in std_logic;
> INA : in std_logic;
> INB : in std_logic;
> INC : in std_logic;
> IND : in std_logic;
> Out : out std_logic
> );
> end blackbox;
> 
> architecture Behavioral of blackboxis
> begin
> 
> BB: process(Clk, RST) is 
> begin
> 
> if(RST = '1') then
>   Out <= '0';
> elsif(Clk'event and Clk = '1') then
>   if(INA = '1' and INB = '1') then
>     Out <= INC;
>   else
>     Out <= IND;
>   end if;
> end if;
> end process BB;
> -----------------------------------------------------------------------------------------
> 
> Any feedback is much appreciated.
> Thanks
> HV.
>  	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Congratulations, you're asking a fundamentally difficult question.
Expect to struggle with this answer.

What you're looking for is what I call a "single point" of clock domain
crossing.  What that means is that, for any set of signals that are
theoretically time-aligned, you need to have a single point (i.e. one
flip-flop) where those signals all neck down to, then all fan back out
from in your internal logic.

Take a UART receiver.  You've got several things inside of the state
machine that all need to have the same simultaneous opinion of the
state of the RX line.  So you resynchronize the RX line with a dual
flop synchronizer, and everything inside of your synchronous state
machine works off of this synchronized version.  If your clock rate is,
for instance, 100 MHz, then everything on your synchronous side knows
that whatever state the sync_rx signal is in, it'll be constant for 10
ns after each clock.  Since everyone is only looking at that signal at
the clock edge, and the timing analysis tools make sure that the signal
is settled at each destination in under 10 ns, you're guaranteed that
everything using sync_rx believes it's got the same state.

Now let's say you hadn't resynchronized it.  RX can change any time it
likes, let's say 5 ns before your clock edge.  If it takes 3 ns to get
to point A in your state machine, point A will see the new value when
the clock edge hits.  But if it takes 6 ns to get to point B, it will
still see the old value.  You've violated the fundamental rule of
synchronous design, which is that come the clock edge all data signals
are static, and as a result your circuit will behave unpredictably, and
unsimulateably.

So, given your example, you don't need to resynchronize any of that
necessarily.  However, given two copies of your example and the desire
to have them always have the same output, you would need to
resynchronize those inputs, then split the resyncronized signals off to
be the inputs to your logic.

Though keep in mind that your reset is asynchronous as well.  For all
the same reasons that any other asynchronous signal can be squirrely
around the clock edges, you may well find that one of your two copies
of that logic comes out of reset one clock cycle before the other
does.  Does that matter?  That's fundamentally a question of your
application.  But it's why you see people generate reset signals that
are asynchronous on their assertion, but synchronous on their
deassertion.

There's a lot more to the topic than just this, but that's at least a
quick introduction to the sorts of things that come up.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157439
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 10 Dec 2014 06:55:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> On Tue, 09 Dec 2014 18:22:41 -0600
> "hvo" <91991@embeddedrelated> wrote:

(snip)
>> I've recently encountered metastability issues that caused my FPGA to do
>> unpredictable things.  

(snip)

> Congratulations, you're asking a fundamentally difficult question.
> Expect to struggle with this answer.
 
> What you're looking for is what I call a "single point" of clock domain
> crossing.  What that means is that, for any set of signals that are
> theoretically time-aligned, you need to have a single point (i.e. one
> flip-flop) where those signals all neck down to, then all fan back out
> from in your internal logic.

Yes. 

While metastability can be a problem, much more common is the multiple
signals crossing time domains without appropriate synchronization.
 
> Take a UART receiver.  You've got several things inside of the state
> machine that all need to have the same simultaneous opinion of the
> state of the RX line.  So you resynchronize the RX line with a dual
> flop synchronizer, and everything inside of your synchronous state
> machine works off of this synchronized version.  If your clock rate is,
> for instance, 100 MHz, then everything on your synchronous side knows
> that whatever state the sync_rx signal is in, it'll be constant for 10
> ns after each clock.  Since everyone is only looking at that signal at
> the clock edge, and the timing analysis tools make sure that the signal
> is settled at each destination in under 10 ns, you're guaranteed that
> everything using sync_rx believes it's got the same state.

Also, metastability decreases exponentially with decreasing clock rate.

Multiple signal crossing a time domain can fail easily even
at low clock rates.
 
> Now let's say you hadn't resynchronized it.  RX can change any time it
> likes, let's say 5 ns before your clock edge.  If it takes 3 ns to get
> to point A in your state machine, point A will see the new value when
> the clock edge hits.  But if it takes 6 ns to get to point B, it will
> still see the old value.  You've violated the fundamental rule of
> synchronous design, which is that come the clock edge all data signals
> are static, and as a result your circuit will behave unpredictably, and
> unsimulateably.
 
> So, given your example, you don't need to resynchronize any of that
> necessarily.  However, given two copies of your example and the desire
> to have them always have the same output, you would need to
> resynchronize those inputs, then split the resyncronized signals off to
> be the inputs to your logic.

There is also the case when multiple signals have to cross a
clock domain and remain consistent. One favorite case is the
counter for a RAM based FIFO.  Converting to gray code (or 
counting in gray code) means that only one signal changes
at any count transition. Either the before or after value
will be seen on the other side, but not any other miscombination
of bits.
 
> Though keep in mind that your reset is asynchronous as well.  For all
> the same reasons that any other asynchronous signal can be squirrely
> around the clock edges, you may well find that one of your two copies
> of that logic comes out of reset one clock cycle before the other
> does.  Does that matter?  That's fundamentally a question of your
> application.  But it's why you see people generate reset signals that
> are asynchronous on their assertion, but synchronous on their
> deassertion.
 
> There's a lot more to the topic than just this, but that's at least a
> quick introduction to the sorts of things that come up.

-- glen

Article: 157440
Subject: Re: Problems with Xilinx SDK and LwIP
From: josephbarrymore <josephbarrymore@gmail.com>
Date: Wed, 10 Dec 2014 01:08:16 -0600
Links: << >>  << T >>  << A >>
This is an old thread, but I had the same errors. Turns out I didn't have the hardware configured correctly. When I finally did a clean build on my project, the BSP didn't compile and threw an error telling me that I didn't have the interrupt enabled on the ethernet controller. 

tl;dr
Try doing a clean build and checking errors.



Article: 157441
Subject: Re: Problems with Xilinx SDK and LwIP
From: josephbarrymore <josephbarrymore@gmail.com>
Date: Wed, 10 Dec 2014 01:08:22 -0600
Links: << >>  << T >>  << A >>
I had the same error of not having the correctly included files. Turns out I had an error while compiling the BSP. I didn't have the interrupt checkbox enabled on the ethernet controller, causing the error. Do a clean build and it will be easier to spot any errors.



Article: 157442
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Wed, 10 Dec 2014 02:17:59 -0500
Links: << >>  << T >>  << A >>
On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:
>
> Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim?  I can't think of any reason why 
metastability would be anything but linear with clock rate if the same 
slack time is available.

-- 

Rick

Article: 157443
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: Allan Herriman <allanherriman@hotmail.com>
Date: 10 Dec 2014 10:30:10 GMT
Links: << >>  << T >>  << A >>
On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

> On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:
>>
>> Also, metastability decreases exponentially with decreasing clock rate.
> 
> Can you explain this claim?  I can't think of any reason why
> metastability would be anything but linear with clock rate if the same
> slack time is available.


http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf

Note the straight lines on the log/linear graph in Figure 2.

For this particular family (V2P) the constants are such that with only a 
modest number of ns slack, the probability of failure drops to less than 
once in the lifetime of the universe.


Regards,
Allan

Article: 157444
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Wed, 10 Dec 2014 06:17:53 -0500
Links: << >>  << T >>  << A >>
On 12/10/2014 5:30 AM, Allan Herriman wrote:
> On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:
>
>> On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:
>>>
>>> Also, metastability decreases exponentially with decreasing clock rate.
>>
>> Can you explain this claim?  I can't think of any reason why
>> metastability would be anything but linear with clock rate if the same
>> slack time is available.
>
>
> http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf
>
> Note the straight lines on the log/linear graph in Figure 2.
>
> For this particular family (V2P) the constants are such that with only a
> modest number of ns slack, the probability of failure drops to less than
> once in the lifetime of the universe.

That's what I thought.  You are confusing the time allowed for the 
metastable event to settle with clock speed.  The two are not the same 
thing at all.  I can lay out a circuit with a design goal of 100 MHz and 
end up with 2 ns slack on the critical route while I lay it out with a 
design goal of 50 MHz and end up with 1 ns slack on the critical path. 
The *only* thing that is important is the slack time where the output 
has time to settle.

It is interesting that the labeling of the two graphs and the text in 
the body of the document all describe this data differently and *none* 
of them can be interpreted as "slack" time by what I am reading.  But 
I'm sure that is what they mean.

"Metastable measurement results are listed in Table 1 and are plotted in
Figure 2. The time plotted on the horizontal axis includes the 
clock-to-out delay of QA, plus a short interconnect delay, plus the 
setup time at the input of the QC flip-flop"

"Cloc-to-Q + Setup + Metastable Delay (ns)"

"Cloc-to-Q + Setup Metastable Delay (ns)"

I expect the label in Figure 3 is just a typo.  But given that the label 
doesn't make sense either way I'm not sure I care.

-- 

Rick

Article: 157445
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 10 Dec 2014 07:00:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, December 9, 2014 7:22:46 PM UTC-5, hvo wrote:
> Hello,
>=20
> I know this topic is beaten to death but I am a bit unlcear some things.
>=20
> I've recently encountered metastability issues that caused my FPGA to do
> unpredictable things.  Someone suggested that I synchronize my inputs to
> the clock domain and that seemed to solve the issue.

Actually, it is much more likely that the problem you saw has absolutely no=
thing to do with metastability.  What you described and how you fixed it so=
unds like either a clock domain crossing or possibly clock skew between the=
 part generating the input signal and your internal design clock...in short=
 it is a setup/hold time problem.  What you added to fix your design sounds=
 like a single flip flop per input signal, then that also suggests the prob=
lem is not metastability.  The point here is not to belabor terminology, bu=
t to help you understand it.

Any of your inputs that lead through logic that ends in a flip flop (which =
will be every input signal in nearly any design) will have setup and hold t=
ime requirements that must be met.  To find out what your requirements are =
review the timing analysis report for your design where the setup and hold =
time requirements for each input will be listed.  Those timing requirements=
 are relative to some clock signal in your design.  Do those signals actual=
ly get generated in the same clock domain?  If so, is Tco + PCB prop delay =
+ Setup time requirement + Clock Skew less than the clock period?  If those=
 signals are not generated in the same clock domain, then ask yourself how =
is that input going to be able to meet the setup and hold time requirements=
?  (Hint:  The answer is that it will not).  This is the situation where yo=
u are crossing clock domains and the synchronizing flip flop that you added=
 is needed.

The setup/hold time requirements will still not be met at the input to that=
 flip flop but that is 'OK', since the rest of your design uses the output =
of the flip flop, not the input.  Now that synchronizing flip flop might mi=
sbehave (i.e. take a longer than normal time to settle) because the inputs =
did not meet the setup/hold time requirements, so the solution there is to =
add a second flip flop and then the rest of your design uses the output of =
the second flip flop.  The first flip flop 'misbehavior' is what is called =
metastability.  Generally, a two flip flop chain is all that is required to=
 cross the clock domain and reduce metastability to an acceptably low numbe=
r.

The short answer to your question though is that whenever an input signal d=
oes not meet the setup and hold time requirements of your design, you will =
need to synchronize it first before using it elsewhere in your design.

Kevin Jennings

Article: 157446
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Wed, 10 Dec 2014 12:05:21 -0600
Links: << >>  << T >>  << A >>
On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

> On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:
>>
>> Also, metastability decreases exponentially with decreasing clock rate.
> 
> Can you explain this claim?  I can't think of any reason why
> metastability would be anything but linear with clock rate if the same
> slack time is available.

If you clock a FF at time t, and you don't use the result until time t + 
Ts (Ts being your clock period), then the FF has that whole Ts-long period 
to resolve the metastability one way or another.  That part will be 
exponential with Ts.

But yes, you would expect a linear part, too.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 157447
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Wed, 10 Dec 2014 12:10:01 -0600
Links: << >>  << T >>  << A >>
On Tue, 09 Dec 2014 18:22:41 -0600, hvo wrote:

> Hello,
> 
> I know this topic is beaten to death but I am a bit unlcear some things.
> 
> I've recently encountered metastability issues that caused my FPGA to do
> unpredictable things.  Someone suggested that I synchronize my inputs to
> the clock domain and that seemed to solve the issue.  Googling this
> topic showed that a two stage Flip Flop is sufficient to increase MTBF
> for metastability.  My question is do I need to do this for all input
> signals?
> How would one do this with a design containing 30 to 40 input signals?

By having lots of such inputs -- but see the other, more detailed answers 
for a better idea.

> Which types of inputs can I get away with not using two stage FF?

Any input that is guaranteed to be settled when you clock it in.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 157448
Subject: Re: Which Altera to buy?
From: sbattazzo@gmail.com
Date: Wed, 10 Dec 2014 10:37:51 -0800 (PST)
Links: << >>  << T >>  << A >>
> 
> It's up to Him though.  I've been working on this project for over
> 28 months.  I haven't found anyone to help me yet, though several
> people have been interested at various times, none of them had the
> necessary C/C++ coding skills to contribute.  I've contacted
> Christian universities, posted on forums, etc.  But, I am hopeful.
> :-)
> 
> Best regards,
> Rick C. Hodgin

Perhaps Terry Davis would be interested in your project. 

http://www.templeos.org/Wb/Doc/Charter.html

Article: 157449
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 10 Dec 2014 11:09:41 -0800 (PST)
Links: << >>  << T >>  << A >>
He's been suggested before at various times.

The Temple OS guy records responses he says
came from God when asked. His skills are most
adequate, but his general relationship with God
is keeping me at a distance.

Best regards,
Rick C. Hodgin



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