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 157475

Article: 157475
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 11 Dec 2014 14:26:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 11, 2014 5:11:44 PM UTC-5, Tim Wescott wrote:
> On Thu, 11 Dec 2014 11:55:14 -0800, Rick C. Hodgin wrote:
> 
> > Would it be possible to connect an FPGA up to an 80386 (or other) CPU,
> > to respond to memory and port requests, and leverage it as a resource?
> > 
> > I'm thinking software runs on the 80386, given it by the FPGA,
> > instructing it as a type of co- processor, which does things on command.
> > 
> > I see voltage differences as an issue.
> > 
> > Best regards,
> > Rick C. Hodgin
> 
> Are you doing this to have fun playing with obsolete processors, or do you 
> have a job to do?
> 
> If it's the former -- have fun.
> 
> If it's the latter -- you are aware that there are all sorts of far more 
> modern solutions to this general problem than the one you're proposing, 
> yes?

It's a mental exercise right now.  I have never considered anything about
hardware in my past.  I'm a software guy, and always thought of hardware
as being outside of my reach.  However, a short time ago I was introduced
to Verilog and the FPGA.  Since then I've had this flood of ideas on how
things might work ... so, I ask questions. :-)

I do have an old 80386-16 MHz ceramic CPU (several actually), along
with 80486 through Pentium various models (some of which are 3.3V),
along with AMD K5, etc.

I was basically just thinking through the process.

Best regards,
Rick C. Hodgin

Article: 157476
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Fri, 12 Dec 2014 00:59:56 +0100
Links: << >>  << T >>  << A >>
On 2014-12-10 hvo wrote in comp.arch.fpga:
> 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?  

But why would you want to save a few FFs? Are you running short? Or is
the added delay too much for you? Adding the FFs can also help the tools
place your design more easily.

Okay my current design is in a luxury position. I needed the Xilinx
Zynq for it's dual core processor and a little bit of FPGA. I'm left
with a huge amount of unused FFs even after using triple synchronizers
on all inputs. 

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Children are like cats, they can tell when you don't like them.  That's
when they come over and violate your body space.

Article: 157477
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 11 Dec 2014 17:06:21 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 4, 2014 6:36:37 PM UTC-5, Theo Markettos wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > If anyone has advice on how to get communication running most easily
> > on this board, I would appreciate it.  Thank you in advance.
> 
> There are two Altera components that might be useful:
> 
> The JTAG UART is something that looks like a UART device, but runs via JTAG
> which is connected to your PC using USB.  That means it's very simple to get
> a text terminal up from your FPGA.  It isn't a 16550-style UART, it has a
> somewhat simpler interface (and if you're using a NIOS-II processor Altera's
> tools generate libraries so that printf() etc works).  That means you don't
> need any extra hardware to get a serial port - you just run 'nios2-terminal'
> on your PC and you get a console of whatever comes out of the JTAG UART.
> 
> System Console is an Altera (Java) app that allows you to get debug access
> to your FPGA, assuming your FPGA uses AXI or Altera's Avalon interconnect,
> which can be built with Altera's Qsys GUI tool for building systems-on-chip. 
> Your components have AXI or Avalon interfaces, and you join them together in
> Qsys GUI (wiring up buses, interrupts, setting addresses, etc).  Qsys
> synthesises a network on chip for you that implements the interconnect you
> wanted (so the 'buses' are actually packet switched networks).  Once you've
> done that you can just drop in a debug module that allows access to those
> buses from System Console via JTAG via USB.  In System Console on your PC
> you can write TCL scripts to access memory, change peripheral registers,
> etc.  Since it's plugged into your existing interconnect it can access
> whatever is connected to it.
> 
> In our case we have both System Console and a CPU debug unit.  The debug
> unit is inside the CPU and allows insertion of instructions into the
> pipeline, which means we can force it to execute code to set registers etc.
> We use both that mechanism and System Console to access memory.  The debug
> unit is implemented using a JTAG UART, but using it as a pipe to convey
> debug instructions rather than as a text terminal (we have another JTAG UART
> as the console).
> 
> 
> I'd suggest first taking the example projects supplied with the board, which
> use the NIOS-II CPU, and making yourself familiar with the toolchain:
> Quartus compilation
> Megawizard [1]
> Qsys (system-on-chip generator)
> NIOS-II bare-metal software world (Eclipse editor, C compiler, Board Support
> Package (BSP) of drivers for the FPGA hardware)
> Programming
> 
> and only then go 'off piste'.  For an example, this is the FPGA practical
> course that I teach that goes through the basics (from no HDL experience to
> building a heterogenous multicore system-on-chip in 24 hours of lab time):
> http://www.cl.cam.ac.uk/teaching/1415/ECAD+Arch/labs/
> You don't have the same board but many of the concepts should still apply.
> 
> Theo
> 
> [1] Megawizard (a tool for configuring standalone IP blocks such as PLLs) is
> being phased out and rolled into Qsys, but it's still relevant at the moment

This is where I'm at right now.

Am I able to do everything I need from Linux?  Or do I need to setup a
Windows partition?

I tried to run the Control Panel software which came with the board in
WINE.  It launched, but said I needed to have Quartus installed for it
to work properly.  I don't particularly want to install Quartus for
Windows in WINE as it's pretty hefty. :-)

Quartus for Linux is working just fine, as is Qsys in Linux.

The "NIOS-II bare-metal software world" you mention ... what is it?
And why Eclipse?  Can I use Netbeans? :-)

And how does the C compiler enter into it?  And what is the BSP for
the FPGA hardware?  I was able to install my board in Quartus in Linux,
and Qsys was able to prepare for it.

I've found a few Altera videos on getting started, but the host goes
through several settings too quickly and does not go into details as
to why he's chosen what he's chosen.

Would anyone be available to get on chat with me some evening or weekend
and help get me kickstarted?

Thank you in advance.

Best regards,
Rick C. Hodgin

Article: 157478
Subject: Re: Which Altera to buy?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 11 Dec 2014 17:12:03 -0800 (PST)
Links: << >>  << T >>  << A >>
Basically here are my goals:

(1) Altera examples (get them working correctly, learn the toolset).
(2) Create or find a simple CPU and get it working correctly.
(3) Using that simple CPU, add hardware support for my Ethernet board, and
(4) (on the host) write software to read data from the Ethernet packets.

And finally:
(5) Begin working on my LibSF 386-x40 CPU in Oppie-1 through Oppie-6 stages.

Best regards,
Rick C. Hodgin

Article: 157479
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 12 Dec 2014 02:11:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Wed, 10 Dec 2014 14:21:01 -0500, rickman wrote:
 
>> On 12/10/2014 1:05 PM, Tim Wescott wrote:
>>> On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

(snip on metastability and slack time)

>>> 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.
 
>> You are forgetting about the time required for the signal to propagate
>> to the output, through the logic, and the setup time for the next FF.
>> These times all need to be subtracted from the clock cycle time yielding
>> the slack time.  This is the only number important to resolving
>> metastability.
 
> I suspect that the paper (which doesn't sound very thorough) is 
> presupposing that you take a design with a given propagation delay, and 
> just start turning the frequency down on the clock.

Much easier than increasing the propagation delay. If your clock is
1MHz, it takes a lot of logic and routing to make a significant fraction
of that in propagation delay. 

-- glen


Article: 157480
Subject: Re: Using FPGA to feed 80386
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 12 Dec 2014 02:15:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> Would it be possible to connect an FPGA up to
> an 80386 (or other) CPU, to respond to memory
> and port requests, and leverage it as a resource?

The 80286 was designed to work with the 80287 or 80387
math coprocessor. That interface is a little less general
than the 8086, but it could be possible that way.

Otherwise, yes, you could do it as an ordinary I/O device on
memory or I/O space.
 
> I'm thinking software runs on the 80386, given
> it by the FPGA, instructing it as a type of co-
> processor, which does things on command.
 
> I see voltage differences as an issue.

I think the 386 has TTL level I/O pins.  There are a few
different ways to do that. One is a resistor big enough not to
hurt the input when the protection diode conducts.

-- glen

Article: 157481
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 00:17:45 -0500
Links: << >>  << T >>  << A >>
On 12/11/2014 9:08 AM, GaborSzakacs wrote:
> hvo wrote:
>> I think by popular opinion, my issue is not metastability but rather
>> clock
>> domain crossing as many have pointed out.  This explains why adding a
>> single synchronizing FF fixed my issue as Kevin pointed out.  Also, an
>> interesting point on the conclusion of Xilinx's XAPP094 stating that
>> "Modern CMOS circuits are so fast that this metastable delay can
>> safely be
>> ignored for clock rates below 200 MHz."  This also support why I Also
>> don't
>> think its a metastable problem since my CLK rate is 20MHz.
>>
>> I guess what I am taking out of all this is that not all signals need
>> to be
>> synchronized with a FF.  Only those who fan out to multiple processes
>> that
>> are time aligned.  This ensures two identical process to have the same
>> output given the same input.
>> Now the synchronized FF output can be metastable, in which case a
>> second FF
>> will reduce it probability significantly.
>>
>> Am I on the right path? or completely out on left field?
>>
>> PS: is there a way to attach a picture in this forum?
>> Thanks
>> HV.
>> ---------------------------------------
>> Posted through http://www.FPGARelated.com
>
> Your original problem was most definitely *not* metastability.
> However mitigating the probability of metastability is still
> worth while.  It's important to understand the mechanisms involved.
>  From a simple perspective, you can consider that any flip-flop
> has a "window" near the sampling clock edge where metastability
> can happen.  For modern CMOS, that window is very small, probably
> less than 1 ps.  In any case it's *much* smaller than the window
> you normally try to stay out of between setup and hold when using
> synchronous logic.
>
> The chances of getting a metastable event at the first flip-flop
> when introducing an asynchronous signal is simply the probability
> that an edge of the incoming signal falls within this metastability
> window.  Note that the expected failure rate is related to both
> the clock rate, which determines how often in time a window is
> "open" and the edge rate of the incoming signal.

I agree with everything you've said up to this point.


> Now we come to why you want a second flip-flop.  A metastable
> event has the effect of increasing the clock to output timing
> of the first flip-flop.  There is theoretically no upper bound
> on the amount of time that the event can last, but the chances
> of the event lasting any particular length of time go down
> *very* quickly as the length of time goes up.  In real world
> applications, there are secondary processes (mostly system
> noise) that "help" an event to end in a way similar to a
> coin standing on edge on a bar where there are a lot of
> patrons picking up and setting down mugs.  In any case you
> can see that you want "slack" time in the path from this
> first flip-flop to all other synchronous elements.

This all sounds right except the part about the noise.  Is there a way 
to prove that?  I have never heard an analysis that proves that noise 
has any real impact on the rate of resolution of metastability.  I'm not 
saying this is wrong, I just haven't seen anything like a proof.


> The second flop is an easy way to ensure the ease of adding a
> lot of slack in the path.  However it has a secondary impact
> on the chance of failure.  When the first flop has an event
> that increases its time such that all subsequent flops no
> longer meet setup requirements, your circuit will fail.  With
> the second flip-flop in place, instead of having an upper
> bound after which the circuit will fail, what you need for
> failure is an event that causes the second flip-flop to go
> metastable.  This means that instead of the probability of
> an event being greater than "x" you now are looking at the
> probability of an event being exactly "x" +/- something
> very small.  So even if the first path doesn't have the
> slack to prevent a metastable event from violating the
> setup/hold of the second flop, the system won't actually
> fail unless the event is within a very small range.  This
> dramatically reduces the MTBF.

I don't follow this at all.  The same reasoning applies to one case as 
the other and any metastability resolution time of the first FF greater 
than "x" will make the second FF go metastable.  However, not the second 
FF also has a chance of resolving before time "y" before impacting 
functional circuitry.  The problem is mitigated both by the fact that 
both FFs have to persist in metastable state as well as the fact that 
the slack time for the "empty" path is typically *much* longer than 
needed to resolve the metastable event and *not* propagate it to the 
second FF other than as an exceedingly rare event (billions of operating 
years).


> Now deciding whether you really need a second flop depends
> on requirements for MTBF and the amount of slack you can
> give between the first flop and all of its loads.  At a low
> clock frequency it's likely that you can ensure enough slack
> that you don't need the second flop to meet the MTBF requirements.
> A slower clock also means that you add more delay by inserting
> another flop.  If latency is an issue, you probably don't want
> to do that.  It's a bit counterintuitive, but in this case you
> could actually improve MTBF without adding delay by using a
> second flop on the opposite clock edge, assuming you can meet
> timing to subsequent flops in 1/2 clock period.

I don't agree.  You are better off with one looooong period than two 
short ones.  Part of the reason is that the added FF has delays that 
subtract from the slack time, but more importantly the exponential term 
is multiplicative, er... exponential actually, while having two delays 
is just additive.  e^2n >> 2*e^n

-- 

Rick

Article: 157482
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 00:20:31 -0500
Links: << >>  << T >>  << A >>
On 12/11/2014 6:59 PM, Stef wrote:
> On 2014-12-10 hvo wrote in comp.arch.fpga:
>> 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?
>
> But why would you want to save a few FFs? Are you running short? Or is
> the added delay too much for you? Adding the FFs can also help the tools
> place your design more easily.
>
> Okay my current design is in a luxury position. I needed the Xilinx
> Zynq for it's dual core processor and a little bit of FPGA. I'm left
> with a huge amount of unused FFs even after using triple synchronizers
> on all inputs.

Triple!!!  You are aware that using synchronizers in odd numbers puts 
the metastability back into the circuit, right?


April Fools!  Er, December Fools.

-- 

Rick

Article: 157483
Subject: Re: Using FPGA to feed 80386
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 00:54:31 -0500
Links: << >>  << T >>  << A >>
On 12/11/2014 5:21 PM, Rick C. Hodgin wrote:
> Tim Wescott wrote:
>> "Support" as in it will let you power a GPIO
>> block from 5V? Or does it just mean that a
>> 3.3V GPIO pin is 5V tolerant?
>
> It says you can assign 5V to each pin, which I
> assume means true I/O. I would use externally
> regulated 5V power supply, as from an old case,
> for all CPU Vcc inputs. The GPIO would only
> power data and a handful of switches.
>
>> If the latter, then you need to make sure that
>> the '386 has TTL-level inputs (V_HI < 3V or so).
>
> Definitely a 5V part circa 1986. Ceramic 16 MHz
> package.

I suggest you dig harder on this issue.  It has been a long time since 
FPGAs were 5 volt tolerant.  The only way I know to make the FPGA 5 volt 
tolerant is to either use a current limiting resistor on the input pin 
(a very poor solution because the pin capacitance and the series 
resistance create a low pass filter that prevents any fast changes) or 
level shifters which come in many forms.

I use Quick Switch shifters on my current design.  They are really just 
analog switches with Vcc driven by 5 volts with an internal diode drop. 
  This puts the gate drive at a voltage so that nothing over about 3.3 
volts will pass though the switch.  So it clamps the 5 volt side to 3.3 
volts when connecting to your FPGA I/Os.  Since 5 volt TTL type logic 
levels are compatible with 3.3 volt TTL logic levels all is good.  The 
delay through the switches is a lot less than the prop delays through a 
logic gate so they are faster too.

Check to see if they are using some type of voltage conversion devices 
between the FGPA and the I/O pins.  It would be very unusual if they do. 
  Otherwise the FPGA I/Os are designed for multiple voltage standards up 
to 3.3 volts.

-- 

Rick

Article: 157484
Subject: Re: Using FPGA to feed 80386
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 12 Dec 2014 01:20:31 -0600
Links: << >>  << T >>  << A >>
On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:

> Tim Wescott wrote:
>> "Support" as in it will let you power a GPIO block from 5V? Or does it
>> just mean that a 3.3V GPIO pin is 5V tolerant?
> 
> It says you can assign 5V to each pin, which I assume means true I/O. I
> would use externally regulated 5V power supply, as from an old case,
> for all CPU Vcc inputs. The GPIO would only power data and a handful of
> switches.

You're not answering my question.  "Supports 5V" can mean one of two 
things, both of which meanings I've stated.  "Assign 5V to each pin" 
essentially carries the same two meanings.

Can you power the FPGA GPIO from 5V, so that you get 5V out?  Or can it 
just stand to get 5V on an input without the FPGA operating incorrectly?

>> If the latter, then you need to make sure that the '386 has TTL-level
>> inputs (V_HI < 3V or so).
> 
> Definitely a 5V part circa 1986. Ceramic 16 MHz package.

Great.  Wonderful.  5V logic comes in a lot of different flavors.  For the 
purposes of our discussion, you can break it into the set of all parts 
that need a full 5V on a logic input to correctly interpret the answer as 
a '1', and parts that can get by with 3.3V.  So which is it?

-- 

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

Article: 157485
Subject: Re: Using FPGA to feed 80386
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 03:13:50 -0500
Links: << >>  << T >>  << A >>
On 12/12/2014 2:20 AM, Tim Wescott wrote:
> On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:
>
>> Tim Wescott wrote:
>>> "Support" as in it will let you power a GPIO block from 5V? Or does it
>>> just mean that a 3.3V GPIO pin is 5V tolerant?
>>
>> It says you can assign 5V to each pin, which I assume means true I/O. I
>> would use externally regulated 5V power supply, as from an old case,
>> for all CPU Vcc inputs. The GPIO would only power data and a handful of
>> switches.
>
> You're not answering my question.  "Supports 5V" can mean one of two
> things, both of which meanings I've stated.  "Assign 5V to each pin"
> essentially carries the same two meanings.
>
> Can you power the FPGA GPIO from 5V, so that you get 5V out?  Or can it
> just stand to get 5V on an input without the FPGA operating incorrectly?

Not directly from the FPGA.  He said he is using the "Cyclone V GX 
Starter Kit".  This board puts a 47 ohm resistor in series with the I/Os 
to the header along with Schotkey diodes to 3.3 volts and ground.  If 
this is driven from 5 volt logic it may pop the diodes and the 47 ohm 
resistor won't protect the FPGA inputs.   This board is *not* 5 volt 
tolerant.


>>> If the latter, then you need to make sure that the '386 has TTL-level
>>> inputs (V_HI < 3V or so).
>>
>> Definitely a 5V part circa 1986. Ceramic 16 MHz package.
>
> Great.  Wonderful.  5V logic comes in a lot of different flavors.  For the
> purposes of our discussion, you can break it into the set of all parts
> that need a full 5V on a logic input to correctly interpret the answer as
> a '1', and parts that can get by with 3.3V.  So which is it?

If he is going to use the 386 he has to build a board anyway.  So that 
board can contain 5 volt to 3.3 volt converters to make it all work 
properly.

Interesting that the starter kit has Arduino compatible headers on it. 
I wonder if anyone has built an Arduino compatible CPU board with a 386, 
lol

-- 

Rick

Article: 157486
Subject: Re: Which Altera to buy?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 12 Dec 2014 18:27:01 +0000 (GMT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> This is where I'm at right now.
> 
> Am I able to do everything I need from Linux?  Or do I need to setup a
> Windows partition?

Linux is fine.  In fact, Linux is better than Windows in some ways.

> I tried to run the Control Panel software which came with the board in
> WINE.  It launched, but said I needed to have Quartus installed for it
> to work properly.  I don't particularly want to install Quartus for
> Windows in WINE as it's pretty hefty. :-)

The System Builder software just generates some template Verilog files that
can go into Quartus.  I usually run it in WINE when it's necessary. 
Generally you just use that software to make a template once, and then
everything happens in Quartus so you can forget about the System Builder. 
The Control Panel is just 'click a Windows button, and oh look the LED
lights' kind of thing - handy for checking the board you bought works, but
not that useful beyond your first 5 minutes.

> Quartus for Linux is working just fine, as is Qsys in Linux.
> 
> The "NIOS-II bare-metal software world" you mention ... what is it?
> And why Eclipse?  Can I use Netbeans? :-)

NIOS-II Eclispe is a (very old) version of Eclipse with some of the NIOS
tools integrated.  That means there's menu options for making sample
projects, regenerating drivers, etc.  It quite handy as a means of learning
what the tools do.  Now I understand how it works I generally drive all of
that from Makefiles because there's less IDE magic in between me and the
build process.  So I'd suggest using Eclipse just to get familiar with the
tools then you can do what you want after.

> And how does the C compiler enter into it?  And what is the BSP for
> the FPGA hardware?  I was able to install my board in Quartus in Linux,
> and Qsys was able to prepare for it.

A lot of the software-land tools assume you're going to put a NIOS-II
processor on your FPGA:

Qsys (the network-on-chip builder) -> BSP builder (generates a pile of C
code drivers for the Altera IP on your FPGA) -> NIOS II C compiler ->
download ELF to FPGA -> terminal to monitor your software

If you're just doing FPGA-hard-stuff you don't have any software and you can
ignore this.  If you don't have a NIOS the BSP, C and ELF steps are
irrelevant, however it's worth understanding the tool flow...  the best
revolutionary understands the system before they undermine it ;)

The NIOS environment is also handy as a reasonably lightweight processor to
have on hand when you want to do things that are easy in software and a pain
in hardware (like 'printf').  This comes up surprisingly often - it's just
another tool in the box.

> I've found a few Altera videos on getting started, but the host goes
> through several settings too quickly and does not go into details as
> to why he's chosen what he's chosen.

I'd start with the demos that come with your board: test them, then see if
you can rebuild them and they still work, then extend them.  In the FPGA
world there are so many finicky details that, if you get them wrong, will
stop your project working - so it's worth starting with an existing working
project and building on that.

Theo

Article: 157487
Subject: Re: Which Altera to buy?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 12 Dec 2014 18:36:12 +0000 (GMT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> And finally:
> (5) Begin working on my LibSF 386-x40 CPU in Oppie-1 through Oppie-6 stages.

On that one, I'd strongly suggest a preliminary:

Write or otherwise obtain a testsuite.  This has been absolutely critical to
getting our CPU off the ground and keeping it there.  When you have a
testsuite, run it against each commit of your CPU code.

Particularly when you get to more complex situations (MMU, interrupts,
exceptions, concurrency, booting a real OS), the testsuite becomes
invaluable to stamping out bugs in your design.

Theo

Article: 157488
Subject: Re: Using FPGA to feed 80386
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 12 Dec 2014 13:13:11 -0600
Links: << >>  << T >>  << A >>
On Fri, 12 Dec 2014 03:13:50 -0500, rickman wrote:

> On 12/12/2014 2:20 AM, Tim Wescott wrote:
>> On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:
>>
>>> Tim Wescott wrote:
>>>> "Support" as in it will let you power a GPIO block from 5V? Or does
>>>> it just mean that a 3.3V GPIO pin is 5V tolerant?
>>>
>>> It says you can assign 5V to each pin, which I assume means true I/O.
>>> I would use externally regulated 5V power supply, as from an old case,
>>> for all CPU Vcc inputs. The GPIO would only power data and a handful
>>> of switches.
>>
>> You're not answering my question.  "Supports 5V" can mean one of two
>> things, both of which meanings I've stated.  "Assign 5V to each pin"
>> essentially carries the same two meanings.
>>
>> Can you power the FPGA GPIO from 5V, so that you get 5V out?  Or can it
>> just stand to get 5V on an input without the FPGA operating
>> incorrectly?
> 
> Not directly from the FPGA.  He said he is using the "Cyclone V GX
> Starter Kit".  This board puts a 47 ohm resistor in series with the I/Os
> to the header along with Schotkey diodes to 3.3 volts and ground.  If
> this is driven from 5 volt logic it may pop the diodes and the 47 ohm
> resistor won't protect the FPGA inputs.   This board is *not* 5 volt
> tolerant.
> 
> 
>>>> If the latter, then you need to make sure that the '386 has TTL-level
>>>> inputs (V_HI < 3V or so).
>>>
>>> Definitely a 5V part circa 1986. Ceramic 16 MHz package.
>>
>> Great.  Wonderful.  5V logic comes in a lot of different flavors.  For
>> the purposes of our discussion, you can break it into the set of all
>> parts that need a full 5V on a logic input to correctly interpret the
>> answer as a '1', and parts that can get by with 3.3V.  So which is it?
> 
> If he is going to use the 386 he has to build a board anyway.  So that
> board can contain 5 volt to 3.3 volt converters to make it all work
> properly.
> 

I think the OP needs to learn a bit more about the wonderful world of 
logic levels (and Rick H. -- feel free to ask).

My inclination is that if the guy needs to make a board anyway, he may as 
well put the FPGA on it, and not mess around trying to make a board to 
stick onto the starter kit.  I don't know enough about the parts involved 
to know if, at that point, he can get away with putting them together 
without level translators or not.  I suspect not -- I'll bet that 386 has 
5V CMOS-level inputs, and that the Altera part can't be run with 5V on the 
I/O.  But I am NOT going to take the time to dig through data sheets -- 
the OP can do that as part of his education in digital hardware design.

-- 

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

Article: 157489
Subject: Re: Monitor connections
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 12 Dec 2014 19:22:39 +0000 (GMT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> Is there a way to monitor signals in existing
> wires? For example, with an oscilloscope and
> probe I can watch voltage changes. Is there a
> standard way to connect to an existing, working
> device, and monitor and record its switching
> over time? Such would seem to be desirable for
> peeking at proprietary "wake up" chirps, and to
> monitor device communications to establish its
> protocol interface.

Xilinx has ChipScope and Altera has SignalTap.  These are logic analysers
that you can put inside the FPGA and attach to signals to monitor the state
of your design.

There are some caveats:
Typically changing the probe state requires a recompile of your design
(which can take hours)
The amount of state you can record is limited by the internal memory in your
device

but it's still far better than trying to route signals outside and using a
real logic analyser.

If you want better visibility and quicker turnaround you'll have to run
things in simulation rather than on the FPGA.

Theo

Article: 157490
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 12 Dec 2014 11:25:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 12, 2014 2:20:35 AM UTC-5, Tim Wescott wrote:
> On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:
> > It says you can assign 5V to each pin, which I assume means true I/O. I
> > would use externally regulated 5V power supply, as from an old case,
> > for all CPU Vcc inputs. The GPIO would only power data and a handful of
> > switches.
> 
> You're not answering my question.  "Supports 5V" can mean one of two 
> things, both of which meanings I've stated.  "Assign 5V to each pin" 
> essentially carries the same two meanings.

The Starter Kit says 5V, 1 amp max.  I assume that means drive current,
if that's the correct phrase. :-)

> Can you power the FPGA GPIO from 5V, so that you get 5V out?  Or can it 
> just stand to get 5V on an input without the FPGA operating incorrectly?

I don't know. :-)  So far as my thinking goes:  I assign a meaning to
some of the GPIO pins, and whatever magic needs to happen under the
hood to get that particular pin to work at 3.3V or 5V happens without
me having to worry about it at this level.

> > Definitely a 5V part circa 1986. Ceramic 16 MHz package.
> 
> Great.  Wonderful.  5V logic comes in a lot of different flavors.  For the 
> purposes of our discussion, you can break it into the set of all parts 
> that need a full 5V on a logic input to correctly interpret the answer as 
> a '1', and parts that can get by with 3.3V.  So which is it?

I don't know.  I looked at the data sheet on the 1986 80386DX, and it
showed a number of pins being used which indicated 5V.  I assumed the
entire chip was 5V because I later remember receiving a Pentium-233
chip that was labeled 3.3V explicitly on the case, which made me think
that this later chip was something new at that voltage.

But, I could be wrong on all counts.

Best regards,
Rick C. Hodgin

Article: 157491
Subject: Re: Using FPGA to feed 80386
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 12 Dec 2014 19:33:27 +0000 (GMT)
Links: << >>  << T >>  << A >>
Tim Wescott <seemywebsite@myfooter.really> wrote:
> I think the OP needs to learn a bit more about the wonderful world of 
> logic levels (and Rick H. -- feel free to ask).

My feeling would be to try and avoid using 5V parts.  For instance, the
Intel Quark 1000 is a 400MHz Pentium-class CPU being aimed at
microcontroller applications.  It probably isn't quite as easy to manage
(it's a BGA package not a PLCC) but is rather more modern.

The Quark itself is a bit of a camel, but it's the modern equivalent of a
386.  The alternative would be an Atom, VIA or some other 'embedded' x86
processor.  All of these might be harder to handle than the slower 386
though.  The Quark comes on the Intel Galileo board which can be connected
to the Cyclone V GX via PCIe, which is one way to join them.

> My inclination is that if the guy needs to make a board anyway, he may as 
> well put the FPGA on it, and not mess around trying to make a board to 
> stick onto the starter kit.  I don't know enough about the parts involved 
> to know if, at that point, he can get away with putting them together 
> without level translators or not.  I suspect not -- I'll bet that 386 has 
> 5V CMOS-level inputs, and that the Altera part can't be run with 5V on the 
> I/O.  But I am NOT going to take the time to dig through data sheets -- 
> the OP can do that as part of his education in digital hardware design.

I'd suggest the OP avoid making an FPGA board: a 6/8 layer board with a ton
of low-voltage high-current FPGA power supplies, BGA escapes, signal
integrity etc, is a somewhat more complex endeavour than a basic-ish 2/4
layer board to hook into an expansion header on the existing board.  Not
least because you can design that in a free/cheap tool, you don't have to
pay for fancy PCB tools, and you can get it fabbed anywhere.

I very much doubt it'll be possible without level translators, which doubles
the complexity of the addon board.

Theo

Article: 157492
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 12 Dec 2014 11:38:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 12, 2014 2:13:15 PM UTC-5, Tim Wescott wrote:
> I think the OP needs to learn a bit more about the wonderful world of 
> logic levels (and Rick H. -- feel free to ask).

I have no plans to make a board at the present time.  Just some
interfacing cabling between the Altera Cyclone V GX starter kit
I purchased and the ethernet board I bought.  The rest I plan to
do in the native kit.

Eventually (whenever I get the CPU designed and working), I would
like to see about getting an actual device manufactured with its
own real hardware.  And ultimately, I would like to even create my
own CPUs from raw silicon (epitaxial processes up through packaging).
Big dream though. :-)

> My inclination is that if the guy needs to make a board anyway, he may as 
> well put the FPGA on it, and not mess around trying to make a board to 
> stick onto the starter kit.  I don't know enough about the parts involved 
> to know if, at that point, he can get away with putting them together 
> without level translators or not.  I suspect not -- I'll bet that 386 has 
> 5V CMOS-level inputs, and that the Altera part can't be run with 5V on the 
> I/O.  But I am NOT going to take the time to dig through data sheets -- 
> the OP can do that as part of his education in digital hardware design.

The whole FPGA to feed an 80386 was me thinking about whether or not such
a thing were possible.  I do not plan to do it.  Once I began thinking
about it I saw that the 80386 used 5V, and that I had only remembered the
Altera documentation saying 1.1V?? to 3.3V.  I did not remember where it
said 5V anywhere.

Best regards,
Rick C. Hodgin

Article: 157493
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 12 Dec 2014 14:45:11 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> On 12/11/2014 9:08 AM, GaborSzakacs wrote:

[snip]

> 
> I agree with everything you've said up to this point.
> 
> 
>> Now we come to why you want a second flip-flop.  A metastable
>> event has the effect of increasing the clock to output timing
>> of the first flip-flop.  There is theoretically no upper bound
>> on the amount of time that the event can last, but the chances
>> of the event lasting any particular length of time go down
>> *very* quickly as the length of time goes up.  In real world
>> applications, there are secondary processes (mostly system
>> noise) that "help" an event to end in a way similar to a
>> coin standing on edge on a bar where there are a lot of
>> patrons picking up and setting down mugs.  In any case you
>> can see that you want "slack" time in the path from this
>> first flip-flop to all other synchronous elements.
> 
> This all sounds right except the part about the noise.  Is there a way 
> to prove that?  I have never heard an analysis that proves that noise 
> has any real impact on the rate of resolution of metastability.  I'm not 
> saying this is wrong, I just haven't seen anything like a proof.
> 

No I don't have proof, but it stands to reason that noise would help
to give a finite upper bound to a metastable event even if it is still
only cutting off a statistically small tail

> 
>> The second flop is an easy way to ensure the ease of adding a
>> lot of slack in the path.  However it has a secondary impact
>> on the chance of failure.  When the first flop has an event
>> that increases its time such that all subsequent flops no
>> longer meet setup requirements, your circuit will fail.  With
>> the second flip-flop in place, instead of having an upper
>> bound after which the circuit will fail, what you need for
>> failure is an event that causes the second flip-flop to go
>> metastable.  This means that instead of the probability of
>> an event being greater than "x" you now are looking at the
>> probability of an event being exactly "x" +/- something
>> very small.  So even if the first path doesn't have the
>> slack to prevent a metastable event from violating the
>> setup/hold of the second flop, the system won't actually
>> fail unless the event is within a very small range.  This
>> dramatically reduces the MTBF.
> 
> I don't follow this at all.  The same reasoning applies to one case as 
> the other and any metastability resolution time of the first FF greater 
> than "x" will make the second FF go metastable.  However, not the second 
> FF also has a chance of resolving before time "y" before impacting 
> functional circuitry.  The problem is mitigated both by the fact that 
> both FFs have to persist in metastable state as well as the fact that 
> the slack time for the "empty" path is typically *much* longer than 
> needed to resolve the metastable event and *not* propagate it to the 
> second FF other than as an exceedingly rare event (billions of operating 
> years).
> 

No.  The second flip-flop has the same sort of metastable window as the
first.  If the first flop misses that window because the metastability
was longer, then the second flop will resolve on the following clock
cycle.  I think you may be under the misapprehension that the metastable
state means that the first flop is outputing a "1/2" rather that "0"
or "1" logic level and any sampling during that time would cause
metastability in the second flop.  In fact that's not the case.

> 
>> Now deciding whether you really need a second flop depends
>> on requirements for MTBF and the amount of slack you can
>> give between the first flop and all of its loads.  At a low
>> clock frequency it's likely that you can ensure enough slack
>> that you don't need the second flop to meet the MTBF requirements.
>> A slower clock also means that you add more delay by inserting
>> another flop.  If latency is an issue, you probably don't want
>> to do that.  It's a bit counterintuitive, but in this case you
>> could actually improve MTBF without adding delay by using a
>> second flop on the opposite clock edge, assuming you can meet
>> timing to subsequent flops in 1/2 clock period.
> 
> I don't agree.  You are better off with one looooong period than two 
> short ones.  Part of the reason is that the added FF has delays that 
> subtract from the slack time, but more importantly the exponential term 
> is multiplicative, er... exponential actually, while having two delays 
> is just additive.  e^2n >> 2*e^n
> 

Your reasoning only follows if you still believe that the second flop
goes metastable when the first event lasts any amount greater than "x".

-- 
Gabor

Article: 157494
Subject: Re: Using FPGA to feed 80386
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 12 Dec 2014 14:51:08 -0500
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:
> On Friday, December 12, 2014 2:20:35 AM UTC-5, Tim Wescott wrote:
>> On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:
>>> It says you can assign 5V to each pin, which I assume means true I/O. I
>>> would use externally regulated 5V power supply, as from an old case,
>>> for all CPU Vcc inputs. The GPIO would only power data and a handful of
>>> switches.
>> You're not answering my question.  "Supports 5V" can mean one of two 
>> things, both of which meanings I've stated.  "Assign 5V to each pin" 
>> essentially carries the same two meanings.
> 
> The Starter Kit says 5V, 1 amp max.  I assume that means drive current,
> if that's the correct phrase. :-)

That's pretty clearly the input power to the board.  You can be very
sure that there are a number of DC-DC point-of-load converters to
make lower voltages from this, and the 5V itself is unlikely to power
any other board-level component directly.


-- 
Gabor

Article: 157495
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 12 Dec 2014 12:02:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 12, 2014 2:50:16 PM UTC-5, Gabor wrote:
> Rick C. Hodgin wrote:
> > On Friday, December 12, 2014 2:20:35 AM UTC-5, Tim Wescott wrote:
> >> On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:
> >>> It says you can assign 5V to each pin, which I assume means true I/O. I
> >>> would use externally regulated 5V power supply, as from an old case,
> >>> for all CPU Vcc inputs. The GPIO would only power data and a handful of
> >>> switches.
> >> You're not answering my question.  "Supports 5V" can mean one of two 
> >> things, both of which meanings I've stated.  "Assign 5V to each pin" 
> >> essentially carries the same two meanings.
> > 
> > The Starter Kit says 5V, 1 amp max.  I assume that means drive current,
> > if that's the correct phrase. :-)
> 
> That's pretty clearly the input power to the board.  You can be very
> sure that there are a number of DC-DC point-of-load converters to
> make lower voltages from this, and the 5V itself is unlikely to power
> any other board-level component directly.

If you go here:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830&PartNo=4

And download the C5G User Manual, and look on page 52, you'll find
this quote:

-----[ Start ]-----
The The 40-pin header connects header connects header connects directly to
36 pins of the Cyclone V GX FPGA, and also provides DC +5V (VCC5), DC 3.3V VCC3
and two GND pins. Figure 3-25 shows the I/O distribution of the GPIO connector.
The maximum power consumption of the daughter card that connects to GPIO port
is shown in Table 3-18:

Table 3-18:
Power Supply of the Expansion Header
Supplied Voltage   Max Current Limit
5V                 1A
3.3V               1.5A 1.5A
-----[ End ]-----

Best regards,
Rick C. Hodgin

Article: 157496
Subject: Re: Using FPGA to feed 80386
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 12 Dec 2014 15:08:52 -0500
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:
> On Friday, December 12, 2014 2:50:16 PM UTC-5, Gabor wrote:
>> Rick C. Hodgin wrote:
>>> On Friday, December 12, 2014 2:20:35 AM UTC-5, Tim Wescott wrote:
>>>> On Thu, 11 Dec 2014 14:21:20 -0800, Rick C. Hodgin wrote:
>>>>> It says you can assign 5V to each pin, which I assume means true I/O. I
>>>>> would use externally regulated 5V power supply, as from an old case,
>>>>> for all CPU Vcc inputs. The GPIO would only power data and a handful of
>>>>> switches.
>>>> You're not answering my question.  "Supports 5V" can mean one of two 
>>>> things, both of which meanings I've stated.  "Assign 5V to each pin" 
>>>> essentially carries the same two meanings.
>>> The Starter Kit says 5V, 1 amp max.  I assume that means drive current,
>>> if that's the correct phrase. :-)
>> That's pretty clearly the input power to the board.  You can be very
>> sure that there are a number of DC-DC point-of-load converters to
>> make lower voltages from this, and the 5V itself is unlikely to power
>> any other board-level component directly.
> 
> If you go here:
> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830&PartNo=4
> 
> And download the C5G User Manual, and look on page 52, you'll find
> this quote:
> 
> -----[ Start ]-----
> The The 40-pin header connects header connects header connects directly to
> 36 pins of the Cyclone V GX FPGA, and also provides DC +5V (VCC5), DC 3.3V VCC3
> and two GND pins. Figure 3-25 shows the I/O distribution of the GPIO connector.
> The maximum power consumption of the daughter card that connects to GPIO port
> is shown in Table 3-18:
> 
> Table 3-18:
> Power Supply of the Expansion Header
> Supplied Voltage   Max Current Limit
> 5V                 1A
> 3.3V               1.5A 1.5A
> -----[ End ]-----
> 
> Best regards,
> Rick C. Hodgin

Fine, then its a power supply output.  It makes no implication that
the I/O pins can drive to 5V, only that 5V is supplied to power
your add-on module.  While you could use that to power a 5V component
like your antique CPU, it was probably intended as a source for
circuitry or additional supplies that don't directly connect to
the I/O pins.  For example you might want to add a USB interface
which requires 5V for its connector, even though any modern PHY
chip will run at 3.3V for all logic I/O.

By the way, the I/O pins won't drive at 1A either.

-- 
Gabor

Article: 157497
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 15:16:34 -0500
Links: << >>  << T >>  << A >>
On 12/12/2014 2:45 PM, GaborSzakacs wrote:
> rickman wrote:
>> On 12/11/2014 9:08 AM, GaborSzakacs wrote:
>
> [snip]
>
>>
>> I agree with everything you've said up to this point.
>>
>>
>>> Now we come to why you want a second flip-flop.  A metastable
>>> event has the effect of increasing the clock to output timing
>>> of the first flip-flop.  There is theoretically no upper bound
>>> on the amount of time that the event can last, but the chances
>>> of the event lasting any particular length of time go down
>>> *very* quickly as the length of time goes up.  In real world
>>> applications, there are secondary processes (mostly system
>>> noise) that "help" an event to end in a way similar to a
>>> coin standing on edge on a bar where there are a lot of
>>> patrons picking up and setting down mugs.  In any case you
>>> can see that you want "slack" time in the path from this
>>> first flip-flop to all other synchronous elements.
>>
>> This all sounds right except the part about the noise.  Is there a way
>> to prove that?  I have never heard an analysis that proves that noise
>> has any real impact on the rate of resolution of metastability.  I'm
>> not saying this is wrong, I just haven't seen anything like a proof.
>>
>
> No I don't have proof, but it stands to reason that noise would help
> to give a finite upper bound to a metastable event even if it is still
> only cutting off a statistically small tail

That is why I asked.  I don't agree that "it stands to reason".  I would 
at least like to hear a mechanism proposed if not proof which could be 
in the form of measurement if nothing else.


>>> The second flop is an easy way to ensure the ease of adding a
>>> lot of slack in the path.  However it has a secondary impact
>>> on the chance of failure.  When the first flop has an event
>>> that increases its time such that all subsequent flops no
>>> longer meet setup requirements, your circuit will fail.  With
>>> the second flip-flop in place, instead of having an upper
>>> bound after which the circuit will fail, what you need for
>>> failure is an event that causes the second flip-flop to go
>>> metastable.  This means that instead of the probability of
>>> an event being greater than "x" you now are looking at the
>>> probability of an event being exactly "x" +/- something
>>> very small.  So even if the first path doesn't have the
>>> slack to prevent a metastable event from violating the
>>> setup/hold of the second flop, the system won't actually
>>> fail unless the event is within a very small range.  This
>>> dramatically reduces the MTBF.
>>
>> I don't follow this at all.  The same reasoning applies to one case as
>> the other and any metastability resolution time of the first FF
>> greater than "x" will make the second FF go metastable.  However, not
>> the second FF also has a chance of resolving before time "y" before
>> impacting functional circuitry.  The problem is mitigated both by the
>> fact that both FFs have to persist in metastable state as well as the
>> fact that the slack time for the "empty" path is typically *much*
>> longer than needed to resolve the metastable event and *not* propagate
>> it to the second FF other than as an exceedingly rare event (billions
>> of operating years).
>>
>
> No.  The second flip-flop has the same sort of metastable window as the
> first.  If the first flop misses that window because the metastability
> was longer, then the second flop will resolve on the following clock
> cycle.  I think you may be under the misapprehension that the metastable
> state means that the first flop is outputing a "1/2" rather that "0"
> or "1" logic level and any sampling during that time would cause
> metastability in the second flop.  In fact that's not the case.

I don't think that is correct.  A metastable event can create all sorts 
of problems on the output including oscillations and indeterminate 
levels.  These can produce metastability in the second stage without 
having to hit a bullet with a bullet.


>>> Now deciding whether you really need a second flop depends
>>> on requirements for MTBF and the amount of slack you can
>>> give between the first flop and all of its loads.  At a low
>>> clock frequency it's likely that you can ensure enough slack
>>> that you don't need the second flop to meet the MTBF requirements.
>>> A slower clock also means that you add more delay by inserting
>>> another flop.  If latency is an issue, you probably don't want
>>> to do that.  It's a bit counterintuitive, but in this case you
>>> could actually improve MTBF without adding delay by using a
>>> second flop on the opposite clock edge, assuming you can meet
>>> timing to subsequent flops in 1/2 clock period.
>>
>> I don't agree.  You are better off with one looooong period than two
>> short ones.  Part of the reason is that the added FF has delays that
>> subtract from the slack time, but more importantly the exponential
>> term is multiplicative, er... exponential actually, while having two
>> delays is just additive.  e^2n >> 2*e^n
>>
>
> Your reasoning only follows if you still believe that the second flop
> goes metastable when the first event lasts any amount greater than "x".

Correct.  But regardless, you are ignoring the impact of the longer time 
period on the exponential.  It is *ginormous*.

-- 

Rick

Article: 157498
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 12 Dec 2014 17:05:47 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> On 12/12/2014 2:45 PM, GaborSzakacs wrote:
>> rickman wrote:
>>> On 12/11/2014 9:08 AM, GaborSzakacs wrote:
>>
>> [snip]

>>
>> No.  The second flip-flop has the same sort of metastable window as the
>> first.  If the first flop misses that window because the metastability
>> was longer, then the second flop will resolve on the following clock
>> cycle.  I think you may be under the misapprehension that the metastable
>> state means that the first flop is outputing a "1/2" rather that "0"
>> or "1" logic level and any sampling during that time would cause
>> metastability in the second flop.  In fact that's not the case.
> 
> I don't think that is correct.  A metastable event can create all sorts 
> of problems on the output including oscillations and indeterminate 
> levels.  These can produce metastability in the second stage without 
> having to hit a bullet with a bullet.
> 
> 

Think again.  A flip-flop has positive feedback gain.  Oscillation
is definitely not a possibility.  Somewhere inside the flop you
could sit at a threshold voltage for a while, but once you start
to resolve, the swing will be monotonic.  The next flop doesn't
get fed directly by the node sitting at its threshold, but from
a buffered copy.  You'd need a buffer that oscillates when its
input sits near a threshold for a nanosecond or two.  You won't
find anything like that in an FPGA.

-- 
Gabor

Article: 157499
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 17:16:45 -0500
Links: << >>  << T >>  << A >>
On 12/12/2014 5:05 PM, GaborSzakacs wrote:
> rickman wrote:
>> On 12/12/2014 2:45 PM, GaborSzakacs wrote:
>>> rickman wrote:
>>>> On 12/11/2014 9:08 AM, GaborSzakacs wrote:
>>>
>>> [snip]
>
>>>
>>> No.  The second flip-flop has the same sort of metastable window as the
>>> first.  If the first flop misses that window because the metastability
>>> was longer, then the second flop will resolve on the following clock
>>> cycle.  I think you may be under the misapprehension that the metastable
>>> state means that the first flop is outputing a "1/2" rather that "0"
>>> or "1" logic level and any sampling during that time would cause
>>> metastability in the second flop.  In fact that's not the case.
>>
>> I don't think that is correct.  A metastable event can create all
>> sorts of problems on the output including oscillations and
>> indeterminate levels.  These can produce metastability in the second
>> stage without having to hit a bullet with a bullet.
>>
>>
>
> Think again.  A flip-flop has positive feedback gain.  Oscillation
> is definitely not a possibility.  Somewhere inside the flop you
> could sit at a threshold voltage for a while, but once you start
> to resolve, the swing will be monotonic.  The next flop doesn't
> get fed directly by the node sitting at its threshold, but from
> a buffered copy.  You'd need a buffer that oscillates when its
> input sits near a threshold for a nanosecond or two.  You won't
> find anything like that in an FPGA.

There is some 40 years of experience and documentation showing the 
effects of metastability.  Please do a little research on the topic.

-- 

Rick



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