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 118550

Article: 118550
Subject: Re: debounce state diagram FSM
From: Amit <amit.kohan@gmail.com>
Date: 29 Apr 2007 18:00:59 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote:
>
>
>
> > Amit wrote:
> > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote:
> > >> Anson.Stugg...@gmail.com wrote:
> > >>> I'm designing a debounce filter using Finite State Machine. The FSM
> > >>> behavior is it follows the inital input bit and thinks that's real
> > >>> output until it receives 3 consecutive same bits and it changes output
> > >>> to that 3 consecutive bit until next 3 consecutive bits are received.
> > >>> A reset will set the FSM to output 1s until it receives the correct
> > >>> input and ouput.
> > >>> This is the test sequence with input and correct output.
> > >>> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> > >>> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
> > >>> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> > >>> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> > >>> the input. Because it just came from SEE1 and before SEE1, it came
> > >>> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> > >>> have specified that state's ouput to be.
> > >>> Anyone knows how to solve this problem? Or maybe there's other better
> > >>> ways to design the state diagram?
> > >> I'm not sure I understand your terminology, but I am
> > >> assuming that that state neames mean:
>
> > >> SEE1 = output = 0 after 1 has been input 1 times in a row.
>
> > >> SEE11 = output = 0 after 1 has been input 2 times in a row.
>
> > >> SEE111 = output = 1 after 1 has been input 3 times in a row
> > >>           (or a 1 is input after 0 has been input less than 3
> > >>           times in a row).
>
> > >> SEE0 = output = 1 after 0 has been input 1 times in a row.
>
> > >> SEE00 = output = 1 after 0 has been input 2 times in a row.
>
> > >> SEE000 = output = 0 after 0 has been input 3 times in a row
> > >>           (or a 0 is input after 1 has been input less than 3
> > >>           times in a row).
>
> > >> If this is the case, then the 12 transitions are:
>
> > >> before input after
> > >> SEE1   1     SEE11
> > >> SEE1   0     SEE000
> > >> SEE11  1     SEE111
> > >> SEE11  0     SEE000
> > >> SEE111 1     SEE111
> > >> SEE111 0     SEE0
> > >> SEE0   1     SEE111
> > >> SEE0   0     SEE00
> > >> SEE00  1     SEE111
> > >> SEE00  0     SEE000
> > >> SEE000 1     SEE1
> > >> SEE000 0     SEE000
>
> > > Hi John,
>
> > > It is not that I'm saying the table is wrong (since I'm new to this
> > > and trying to learn) but how do you say: SEE1 with input 0 goes to
> > > SEE11 state? because then our state must be SEE01!
>
> > The 6 states are defined above the transition table.  There
> > is no SEE01 state, because there is no reason to keep track
> > of that sequence.  If you are at SEE1 a single 1 input has
> > been seen since the output was decided to be zero), and a
> > zero arrives, you just go back to state SEE000 (the one
> > where the output was decided to be changed to zero) since
> > the required 3 1s in a row cannot occur till at least a
> > single 1 arrives.  Any zero arriving before that triple 1 is
> > received just starts the count over.
>
> Thank you so much for your answer but before I complete the reading I
> have a problem with this:
>
> >If you are at SEE1 a single 1 input has
>
> been seen since the output was decided to be zero), and a
> zero arrives
>
> Question: let's say we are at SEE1 and input is 1. How should I know
> the system expects 0? why not 1?
>
> Regards,
> amit

The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.



Article: 118551
Subject: Re: debounce state diagram FSM
From: Anson.Stuggart@gmail.com
Date: 29 Apr 2007 19:17:08 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote:
>
>
>
>
>
> > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote:
>
> > > Amit wrote:
> > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote:
> > > >> Anson.Stugg...@gmail.com wrote:
> > > >>> I'm designing a debounce filter using Finite State Machine. The FSM
> > > >>> behavior is it follows the inital input bit and thinks that's real
> > > >>> output until it receives 3 consecutive same bits and it changes output
> > > >>> to that 3 consecutive bit until next 3 consecutive bits are received.
> > > >>> A reset will set the FSM to output 1s until it receives the correct
> > > >>> input and ouput.
> > > >>> This is the test sequence with input and correct output.
> > > >>> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> > > >>> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
> > > >>> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> > > >>> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> > > >>> the input. Because it just came from SEE1 and before SEE1, it came
> > > >>> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> > > >>> have specified that state's ouput to be.
> > > >>> Anyone knows how to solve this problem? Or maybe there's other better
> > > >>> ways to design the state diagram?
> > > >> I'm not sure I understand your terminology, but I am
> > > >> assuming that that state neames mean:
>
> > > >> SEE1 = output = 0 after 1 has been input 1 times in a row.
>
> > > >> SEE11 = output = 0 after 1 has been input 2 times in a row.
>
> > > >> SEE111 = output = 1 after 1 has been input 3 times in a row
> > > >>           (or a 1 is input after 0 has been input less than 3
> > > >>           times in a row).
>
> > > >> SEE0 = output = 1 after 0 has been input 1 times in a row.
>
> > > >> SEE00 = output = 1 after 0 has been input 2 times in a row.
>
> > > >> SEE000 = output = 0 after 0 has been input 3 times in a row
> > > >>           (or a 0 is input after 1 has been input less than 3
> > > >>           times in a row).
>
> > > >> If this is the case, then the 12 transitions are:
>
> > > >> before input after
> > > >> SEE1   1     SEE11
> > > >> SEE1   0     SEE000
> > > >> SEE11  1     SEE111
> > > >> SEE11  0     SEE000
> > > >> SEE111 1     SEE111
> > > >> SEE111 0     SEE0
> > > >> SEE0   1     SEE111
> > > >> SEE0   0     SEE00
> > > >> SEE00  1     SEE111
> > > >> SEE00  0     SEE000
> > > >> SEE000 1     SEE1
> > > >> SEE000 0     SEE000
>
> > > > Hi John,
>
> > > > It is not that I'm saying the table is wrong (since I'm new to this
> > > > and trying to learn) but how do you say: SEE1 with input 0 goes to
> > > > SEE11 state? because then our state must be SEE01!
>
> > > The 6 states are defined above the transition table.  There
> > > is no SEE01 state, because there is no reason to keep track
> > > of that sequence.  If you are at SEE1 a single 1 input has
> > > been seen since the output was decided to be zero), and a
> > > zero arrives, you just go back to state SEE000 (the one
> > > where the output was decided to be changed to zero) since
> > > the required 3 1s in a row cannot occur till at least a
> > > single 1 arrives.  Any zero arriving before that triple 1 is
> > > received just starts the count over.
>
> > Thank you so much for your answer but before I complete the reading I
> > have a problem with this:
>
> > >If you are at SEE1 a single 1 input has
>
> > been seen since the output was decided to be zero), and a
> > zero arrives
>
> > Question: let's say we are at SEE1 and input is 1. How should I know
> > the system expects 0? why not 1?
>
> > Regards,
> > amit
>
> The thing I'm trying to say is that regarding what Anson says the
> first input 1 has an output as 1 and .... so the system in this phase
> believes "1" is the right output and we haven't got to "000" yet to
> switch to "0" output.- Hide quoted text -
>
> - Show quoted text -

Amit,

I admit it is a little messy to understand. Basically, to come up with
state diagram, usually try to focus on the objective. In this case, it
is to detect 3 consecutive 1s or 0s and result a change on the output.
Therefore, case SAW01 or SAW10 will be not important enough to be
named a state.

Before the logic detects 3 of consecutive 1s or 0s, it will just keep
output bits with the inital bit received at power on or 1s in the case
if there has been a reset. There are only two logic states which
logically change the output: SEE000 and SEE111. All other states don't
really changes the outputs. These are only internal states.

I must mention that the state diagram doesn't address the issue when
the logic is first turned on and is it 1 or 0 at the input port. You
can verify this with the the state diagram John Popelish provided
earlier. The first bit is a 1 and if you follow the state diagram, you
will get 0s all the way until 9th bit and it's still a 0 so it will
continue until the last bit received. Infact, you will have to provide
additional logic for the first 8 bits.

Correct me if I'm wrong, but this is what I think.

Anson


Article: 118552
Subject: Re: debounce state diagram FSM
From: John Popelish <jpopelish@rica.net>
Date: Sun, 29 Apr 2007 22:34:43 -0400
Links: << >>  << T >>  << A >>
Amit wrote:

> Question: let's say we are at SEE1 and input is 1. How should I know
> the system expects 0? why not 1?

The system does not expect anything.  It reacts to the input 
sequence as it arrives (at clocked intervals).  The purpose 
of the algorithm is to remove any state changes that remain 
less than 3 clocks in a row (bounces).

Article: 118553
Subject: Re: debounce state diagram FSM
From: John Popelish <jpopelish@rica.net>
Date: Sun, 29 Apr 2007 22:36:53 -0400
Links: << >>  << T >>  << A >>
Amit wrote:

> The thing I'm trying to say is that regarding what Anson says the
> first input 1 has an output as 1 and .... so the system in this phase
> believes "1" is the right output and we haven't got to "000" yet to
> switch to "0" output.

I ignored that part.  The initial power up state is 
arbitrary.  Choose it as you wish, and initialize the state 
to SEE000 if you choose 0 or SEE111 if you choose 1.

Article: 118554
Subject: Re: debounce state diagram FSM
From: Amit <amit.kohan@gmail.com>
Date: 29 Apr 2007 19:47:59 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
> On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote:
>
>
>
> > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote:
>
> > > > Amit wrote:
> > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote:
> > > > >> Anson.Stugg...@gmail.com wrote:
> > > > >>> I'm designing a debounce filter using Finite State Machine. The FSM
> > > > >>> behavior is it follows the inital input bit and thinks that's real
> > > > >>> output until it receives 3 consecutive same bits and it changes output
> > > > >>> to that 3 consecutive bit until next 3 consecutive bits are received.
> > > > >>> A reset will set the FSM to output 1s until it receives the correct
> > > > >>> input and ouput.
> > > > >>> This is the test sequence with input and correct output.
> > > > >>> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> > > > >>> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
> > > > >>> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> > > > >>> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> > > > >>> the input. Because it just came from SEE1 and before SEE1, it came
> > > > >>> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> > > > >>> have specified that state's ouput to be.
> > > > >>> Anyone knows how to solve this problem? Or maybe there's other better
> > > > >>> ways to design the state diagram?
> > > > >> I'm not sure I understand your terminology, but I am
> > > > >> assuming that that state neames mean:
>
> > > > >> SEE1 = output = 0 after 1 has been input 1 times in a row.
>
> > > > >> SEE11 = output = 0 after 1 has been input 2 times in a row.
>
> > > > >> SEE111 = output = 1 after 1 has been input 3 times in a row
> > > > >>           (or a 1 is input after 0 has been input less than 3
> > > > >>           times in a row).
>
> > > > >> SEE0 = output = 1 after 0 has been input 1 times in a row.
>
> > > > >> SEE00 = output = 1 after 0 has been input 2 times in a row.
>
> > > > >> SEE000 = output = 0 after 0 has been input 3 times in a row
> > > > >>           (or a 0 is input after 1 has been input less than 3
> > > > >>           times in a row).
>
> > > > >> If this is the case, then the 12 transitions are:
>
> > > > >> before input after
> > > > >> SEE1   1     SEE11
> > > > >> SEE1   0     SEE000
> > > > >> SEE11  1     SEE111
> > > > >> SEE11  0     SEE000
> > > > >> SEE111 1     SEE111
> > > > >> SEE111 0     SEE0
> > > > >> SEE0   1     SEE111
> > > > >> SEE0   0     SEE00
> > > > >> SEE00  1     SEE111
> > > > >> SEE00  0     SEE000
> > > > >> SEE000 1     SEE1
> > > > >> SEE000 0     SEE000
>
> > > > > Hi John,
>
> > > > > It is not that I'm saying the table is wrong (since I'm new to this
> > > > > and trying to learn) but how do you say: SEE1 with input 0 goes to
> > > > > SEE11 state? because then our state must be SEE01!
>
> > > > The 6 states are defined above the transition table.  There
> > > > is no SEE01 state, because there is no reason to keep track
> > > > of that sequence.  If you are at SEE1 a single 1 input has
> > > > been seen since the output was decided to be zero), and a
> > > > zero arrives, you just go back to state SEE000 (the one
> > > > where the output was decided to be changed to zero) since
> > > > the required 3 1s in a row cannot occur till at least a
> > > > single 1 arrives.  Any zero arriving before that triple 1 is
> > > > received just starts the count over.
>
> > > Thank you so much for your answer but before I complete the reading I
> > > have a problem with this:
>
> > > >If you are at SEE1 a single 1 input has
>
> > > been seen since the output was decided to be zero), and a
> > > zero arrives
>
> > > Question: let's say we are at SEE1 and input is 1. How should I know
> > > the system expects 0? why not 1?
>
> > > Regards,
> > > amit
>
> > The thing I'm trying to say is that regarding what Anson says the
> > first input 1 has an output as 1 and .... so the system in this phase
> > believes "1" is the right output and we haven't got to "000" yet to
> > switch to "0" output.- Hide quoted text -
>
> > - Show quoted text -
>
> Amit,
>
> I admit it is a little messy to understand. Basically, to come up with
> state diagram, usually try to focus on the objective. In this case, it
> is to detect 3 consecutive 1s or 0s and result a change on the output.
> Therefore, case SAW01 or SAW10 will be not important enough to be
> named a state.
>
> Before the logic detects 3 of consecutive 1s or 0s, it will just keep
> output bits with the inital bit received at power on or 1s in the case
> if there has been a reset. There are only two logic states which
> logically change the output: SEE000 and SEE111. All other states don't
> really changes the outputs. These are only internal states.
>
> I must mention that the state diagram doesn't address the issue when
> the logic is first turned on and is it 1 or 0 at the input port. You
> can verify this with the the state diagram John Popelish provided
> earlier. The first bit is a 1 and if you follow the state diagram, you
> will get 0s all the way until 9th bit and it's still a 0 so it will
> continue until the last bit received. Infact, you will have to provide
> additional logic for the first 8 bits.
>
> Correct me if I'm wrong, but this is what I think.
>
> Anson


Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
that is right we won't need them and I read what John had said before
again and he is right.

But let's get back to the first input in the string which is "1" .
There, we can get to this conclusion that the previous value that
system was expecting to have as output has been "0" so the first input
(1) must be the third "1" of triple 1 string. Maybe following lines
explain it better:


                                              hidden               We
see
input:                                         11
10010100010111
output:                                       00
11111111000001

Right?


next question I have is regarding your very first question. What
happens to the state that once outputs "1" and in another situation it
outputs "0"?

how do you present this in your state diagram? If I'm not wrong this
is what you has asked in the first place.

Regards,
amit





Article: 118555
Subject: Re: debounce state diagram FSM
From: Amit <amit.kohan@gmail.com>
Date: 29 Apr 2007 19:52:27 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
>
>
>
> > On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote:
>
> > > > > Amit wrote:
> > > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote:
> > > > > >> Anson.Stugg...@gmail.com wrote:
> > > > > >>> I'm designing a debounce filter using Finite State Machine. The FSM
> > > > > >>> behavior is it follows the inital input bit and thinks that's real
> > > > > >>> output until it receives 3 consecutive same bits and it changes output
> > > > > >>> to that 3 consecutive bit until next 3 consecutive bits are received.
> > > > > >>> A reset will set the FSM to output 1s until it receives the correct
> > > > > >>> input and ouput.
> > > > > >>> This is the test sequence with input and correct output.
> > > > > >>> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> > > > > >>> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
> > > > > >>> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> > > > > >>> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> > > > > >>> the input. Because it just came from SEE1 and before SEE1, it came
> > > > > >>> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> > > > > >>> have specified that state's ouput to be.
> > > > > >>> Anyone knows how to solve this problem? Or maybe there's other better
> > > > > >>> ways to design the state diagram?
> > > > > >> I'm not sure I understand your terminology, but I am
> > > > > >> assuming that that state neames mean:
>
> > > > > >> SEE1 = output = 0 after 1 has been input 1 times in a row.
>
> > > > > >> SEE11 = output = 0 after 1 has been input 2 times in a row.
>
> > > > > >> SEE111 = output = 1 after 1 has been input 3 times in a row
> > > > > >>           (or a 1 is input after 0 has been input less than 3
> > > > > >>           times in a row).
>
> > > > > >> SEE0 = output = 1 after 0 has been input 1 times in a row.
>
> > > > > >> SEE00 = output = 1 after 0 has been input 2 times in a row.
>
> > > > > >> SEE000 = output = 0 after 0 has been input 3 times in a row
> > > > > >>           (or a 0 is input after 1 has been input less than 3
> > > > > >>           times in a row).
>
> > > > > >> If this is the case, then the 12 transitions are:
>
> > > > > >> before input after
> > > > > >> SEE1   1     SEE11
> > > > > >> SEE1   0     SEE000
> > > > > >> SEE11  1     SEE111
> > > > > >> SEE11  0     SEE000
> > > > > >> SEE111 1     SEE111
> > > > > >> SEE111 0     SEE0
> > > > > >> SEE0   1     SEE111
> > > > > >> SEE0   0     SEE00
> > > > > >> SEE00  1     SEE111
> > > > > >> SEE00  0     SEE000
> > > > > >> SEE000 1     SEE1
> > > > > >> SEE000 0     SEE000
>
> > > > > > Hi John,
>
> > > > > > It is not that I'm saying the table is wrong (since I'm new to this
> > > > > > and trying to learn) but how do you say: SEE1 with input 0 goes to
> > > > > > SEE11 state? because then our state must be SEE01!
>
> > > > > The 6 states are defined above the transition table.  There
> > > > > is no SEE01 state, because there is no reason to keep track
> > > > > of that sequence.  If you are at SEE1 a single 1 input has
> > > > > been seen since the output was decided to be zero), and a
> > > > > zero arrives, you just go back to state SEE000 (the one
> > > > > where the output was decided to be changed to zero) since
> > > > > the required 3 1s in a row cannot occur till at least a
> > > > > single 1 arrives.  Any zero arriving before that triple 1 is
> > > > > received just starts the count over.
>
> > > > Thank you so much for your answer but before I complete the reading I
> > > > have a problem with this:
>
> > > > >If you are at SEE1 a single 1 input has
>
> > > > been seen since the output was decided to be zero), and a
> > > > zero arrives
>
> > > > Question: let's say we are at SEE1 and input is 1. How should I know
> > > > the system expects 0? why not 1?
>
> > > > Regards,
> > > > amit
>
> > > The thing I'm trying to say is that regarding what Anson says the
> > > first input 1 has an output as 1 and .... so the system in this phase
> > > believes "1" is the right output and we haven't got to "000" yet to
> > > switch to "0" output.- Hide quoted text -
>
> > > - Show quoted text -
>
> > Amit,
>
> > I admit it is a little messy to understand. Basically, to come up with
> > state diagram, usually try to focus on the objective. In this case, it
> > is to detect 3 consecutive 1s or 0s and result a change on the output.
> > Therefore, case SAW01 or SAW10 will be not important enough to be
> > named a state.
>
> > Before the logic detects 3 of consecutive 1s or 0s, it will just keep
> > output bits with the inital bit received at power on or 1s in the case
> > if there has been a reset. There are only two logic states which
> > logically change the output: SEE000 and SEE111. All other states don't
> > really changes the outputs. These are only internal states.
>
> > I must mention that the state diagram doesn't address the issue when
> > the logic is first turned on and is it 1 or 0 at the input port. You
> > can verify this with the the state diagram John Popelish provided
> > earlier. The first bit is a 1 and if you follow the state diagram, you
> > will get 0s all the way until 9th bit and it's still a 0 so it will
> > continue until the last bit received. Infact, you will have to provide
> > additional logic for the first 8 bits.
>
> > Correct me if I'm wrong, but this is what I think.
>
> > Anson
>
> Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
> that is right we won't need them and I read what John had said before
> again and he is right.
>
> But let's get back to the first input in the string which is "1" .
> There, we can get to this conclusion that the previous value that
> system was expecting to have as output has been "0" so the first input
> (1) must be the third "1" of triple 1 string. Maybe following lines
> explain it better:
>
>                                               hidden               We
> see
> input:                                         11
> 10010100010111
> output:                                       00
> 11111111000001
>
> Right?
>
> next question I have is regarding your very first question. What
> happens to the state that once outputs "1" and in another situation it
> outputs "0"?
>
> how do you present this in your state diagram? If I'm not wrong this
> is what you has asked in the first place.
>
> Regards,
> amit

it seems what I have typed above is messy and mixed. This is what I
was trying to show:

hidden         We only see

  11            10010100010111  <- input
  00            11111111000001  <- output

regards,
amit


Article: 118556
Subject: Re: physical chip size
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sun, 29 Apr 2007 23:12:32 -0400
Links: << >>  << T >>  << A >>
Pasacco wrote:
> Hi
> 
> I found one article in FPGA 2006 conference.
> 
> They calculated  "number of logic blocks" x "area of each block".
> 
> They state that the area ratio is around 33 for logic, for a number of
> benchmarks.
> 
> Then probably I also need information on LUT (or slice) actual size.
> 
> If anyone knows how to obtain this information, let me know.
> 
> Thank you in advance.
> 

Any such numbers are useful only for very rough guesstimates.

Many constructs like multiplexers can be implemented as extremely compact 
and fast wired-OR instead of FPGA-style cascaded 2:1/4:1 LUT multiplexers. 
Other components like memories sit at the other end of the spectrum with 
nearly 1:1 correspondence.

One design may have a 33:1 FPGA:ASIC ratio, another may be over 40:1 and 
yet another may be below 20:1... it all really depends on how the logic was 
designed, how it got synthesized, what resources were available to map the 
design onto, etc. Results WILL vary CONSIDERABLY depending on several 
design/tool/etc.-specific details, many of which may be beyond your (or 
anybody else's for that matter) control.

Article: 118557
Subject: Re: debounce state diagram FSM
From: Anson.Stuggart@gmail.com
Date: 29 Apr 2007 20:13:09 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
>
>
>
>
>
> > On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote:
>
> > > > > Amit wrote:
> > > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote:
> > > > > >> Anson.Stugg...@gmail.com wrote:
> > > > > >>> I'm designing a debounce filter using Finite State Machine. The FSM
> > > > > >>> behavior is it follows the inital input bit and thinks that's real
> > > > > >>> output until it receives 3 consecutive same bits and it changes output
> > > > > >>> to that 3 consecutive bit until next 3 consecutive bits are received.
> > > > > >>> A reset will set the FSM to output 1s until it receives the correct
> > > > > >>> input and ouput.
> > > > > >>> This is the test sequence with input and correct output.
> > > > > >>> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> > > > > >>> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
> > > > > >>> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> > > > > >>> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> > > > > >>> the input. Because it just came from SEE1 and before SEE1, it came
> > > > > >>> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> > > > > >>> have specified that state's ouput to be.
> > > > > >>> Anyone knows how to solve this problem? Or maybe there's other better
> > > > > >>> ways to design the state diagram?
> > > > > >> I'm not sure I understand your terminology, but I am
> > > > > >> assuming that that state neames mean:
>
> > > > > >> SEE1 = output = 0 after 1 has been input 1 times in a row.
>
> > > > > >> SEE11 = output = 0 after 1 has been input 2 times in a row.
>
> > > > > >> SEE111 = output = 1 after 1 has been input 3 times in a row
> > > > > >>           (or a 1 is input after 0 has been input less than 3
> > > > > >>           times in a row).
>
> > > > > >> SEE0 = output = 1 after 0 has been input 1 times in a row.
>
> > > > > >> SEE00 = output = 1 after 0 has been input 2 times in a row.
>
> > > > > >> SEE000 = output = 0 after 0 has been input 3 times in a row
> > > > > >>           (or a 0 is input after 1 has been input less than 3
> > > > > >>           times in a row).
>
> > > > > >> If this is the case, then the 12 transitions are:
>
> > > > > >> before input after
> > > > > >> SEE1   1     SEE11
> > > > > >> SEE1   0     SEE000
> > > > > >> SEE11  1     SEE111
> > > > > >> SEE11  0     SEE000
> > > > > >> SEE111 1     SEE111
> > > > > >> SEE111 0     SEE0
> > > > > >> SEE0   1     SEE111
> > > > > >> SEE0   0     SEE00
> > > > > >> SEE00  1     SEE111
> > > > > >> SEE00  0     SEE000
> > > > > >> SEE000 1     SEE1
> > > > > >> SEE000 0     SEE000
>
> > > > > > Hi John,
>
> > > > > > It is not that I'm saying the table is wrong (since I'm new to this
> > > > > > and trying to learn) but how do you say: SEE1 with input 0 goes to
> > > > > > SEE11 state? because then our state must be SEE01!
>
> > > > > The 6 states are defined above the transition table.  There
> > > > > is no SEE01 state, because there is no reason to keep track
> > > > > of that sequence.  If you are at SEE1 a single 1 input has
> > > > > been seen since the output was decided to be zero), and a
> > > > > zero arrives, you just go back to state SEE000 (the one
> > > > > where the output was decided to be changed to zero) since
> > > > > the required 3 1s in a row cannot occur till at least a
> > > > > single 1 arrives.  Any zero arriving before that triple 1 is
> > > > > received just starts the count over.
>
> > > > Thank you so much for your answer but before I complete the reading I
> > > > have a problem with this:
>
> > > > >If you are at SEE1 a single 1 input has
>
> > > > been seen since the output was decided to be zero), and a
> > > > zero arrives
>
> > > > Question: let's say we are at SEE1 and input is 1. How should I know
> > > > the system expects 0? why not 1?
>
> > > > Regards,
> > > > amit
>
> > > The thing I'm trying to say is that regarding what Anson says the
> > > first input 1 has an output as 1 and .... so the system in this phase
> > > believes "1" is the right output and we haven't got to "000" yet to
> > > switch to "0" output.- Hide quoted text -
>
> > > - Show quoted text -
>
> > Amit,
>
> > I admit it is a little messy to understand. Basically, to come up with
> > state diagram, usually try to focus on the objective. In this case, it
> > is to detect 3 consecutive 1s or 0s and result a change on the output.
> > Therefore, case SAW01 or SAW10 will be not important enough to be
> > named a state.
>
> > Before the logic detects 3 of consecutive 1s or 0s, it will just keep
> > output bits with the inital bit received at power on or 1s in the case
> > if there has been a reset. There are only two logic states which
> > logically change the output: SEE000 and SEE111. All other states don't
> > really changes the outputs. These are only internal states.
>
> > I must mention that the state diagram doesn't address the issue when
> > the logic is first turned on and is it 1 or 0 at the input port. You
> > can verify this with the the state diagram John Popelish provided
> > earlier. The first bit is a 1 and if you follow the state diagram, you
> > will get 0s all the way until 9th bit and it's still a 0 so it will
> > continue until the last bit received. Infact, you will have to provide
> > additional logic for the first 8 bits.
>
> > Correct me if I'm wrong, but this is what I think.
>
> > Anson
>
> Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
> that is right we won't need them and I read what John had said before
> again and he is right.
>
> But let's get back to the first input in the string which is "1" .
> There, we can get to this conclusion that the previous value that
> system was expecting to have as output has been "0" so the first input
> (1) must be the third "1" of triple 1 string. Maybe following lines
> explain it better:
>
>                                               hidden               We
> see
> input:                                         11
> 10010100010111
> output:                                       00
> 11111111000001
>
> Right?
>
> next question I have is regarding your very first question. What
> happens to the state that once outputs "1" and in another situation it
> outputs "0"?
>
> how do you present this in your state diagram? If I'm not wrong this
> is what you has asked in the first place.
>
> Regards,
> amit- Hide quoted text -
>
> - Show quoted text -

Amit,

My first question came up because I draw the state diagram differently
or wrong. From state SEE000 and if a 1 is input, it will go to state
SEE1 and if another 0 comes in, it should go back to SEE000, not on to
SEE0 (where I get the wrong output).

Try to draw or map out the state diagram John has posted earlier. And
try to trace it with the input you have and you will get the correct
outputs at every single state or bit.  However, I must highlight what
John wrote earlier. During the initial input at power-on, the first
bit should go to: if 1 go to state SEE111 and if 0 go to SEE000. As
you can see, state SEE111 and SEE000 serve two function. One is when
it sees 3 consecutive same bits it will change the output and other is
during initial bit at power-on (maybe they should be renamed to
Init_1&SEE111, Init_0&SEE000). Don't forget the reset which will set
output to 1 regardless of what's on the line but this will be changed
with sequences of bits streaming in later.

Hope this helps,

Anson


Article: 118558
Subject: Re: debounce state diagram FSM
From: billwang05@gmail.com
Date: 29 Apr 2007 20:42:30 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 7:52 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.com> wrote:
>
>
>
>
>
> > On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
>
> > > On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > > > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote:
>
> > > > > > Amit wrote:
> > > > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote:
> > > > > > >> Anson.Stugg...@gmail.com wrote:
> > > > > > >>> I'm designing adebouncefilter using FiniteStateMachine. The FSM
> > > > > > >>> behavior is it follows the inital input bit and thinks that's real
> > > > > > >>> output until it receives 3 consecutive same bits and it changes output
> > > > > > >>> to that 3 consecutive bit until next 3 consecutive bits are received.
> > > > > > >>> A reset will set the FSM to output 1s until it receives the correct
> > > > > > >>> input and ouput.
> > > > > > >>> This is the test sequence with input and correct output.
> > > > > > >>> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> > > > > > >>> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
> > > > > > >>> ThestatediagramI came up has 6 states and it's named SEE1, SEE11,
> > > > > > >>> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> > > > > > >>> the input. Because it just came from SEE1 and before SEE1, it came
> > > > > > >>> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> > > > > > >>> have specified thatstate'souput to be.
> > > > > > >>> Anyone knows how to solve this problem? Or maybe there's other better
> > > > > > >>> ways to design thestatediagram?
> > > > > > >> I'm not sure I understand your terminology, but I am
> > > > > > >> assuming that thatstateneames mean:
>
> > > > > > >> SEE1 = output = 0 after 1 has been input 1 times in a row.
>
> > > > > > >> SEE11 = output = 0 after 1 has been input 2 times in a row.
>
> > > > > > >> SEE111 = output = 1 after 1 has been input 3 times in a row
> > > > > > >>           (or a 1 is input after 0 has been input less than 3
> > > > > > >>           times in a row).
>
> > > > > > >> SEE0 = output = 1 after 0 has been input 1 times in a row.
>
> > > > > > >> SEE00 = output = 1 after 0 has been input 2 times in a row.
>
> > > > > > >> SEE000 = output = 0 after 0 has been input 3 times in a row
> > > > > > >>           (or a 0 is input after 1 has been input less than 3
> > > > > > >>           times in a row).
>
> > > > > > >> If this is the case, then the 12 transitions are:
>
> > > > > > >> before input after
> > > > > > >> SEE1   1     SEE11
> > > > > > >> SEE1   0     SEE000
> > > > > > >> SEE11  1     SEE111
> > > > > > >> SEE11  0     SEE000
> > > > > > >> SEE111 1     SEE111
> > > > > > >> SEE111 0     SEE0
> > > > > > >> SEE0   1     SEE111
> > > > > > >> SEE0   0     SEE00
> > > > > > >> SEE00  1     SEE111
> > > > > > >> SEE00  0     SEE000
> > > > > > >> SEE000 1     SEE1
> > > > > > >> SEE000 0     SEE000
>
> > > > > > > Hi John,
>
> > > > > > > It is not that I'm saying the table is wrong (since I'm new to this
> > > > > > > and trying to learn) but how do you say: SEE1 with input 0 goes to
> > > > > > > SEE11state? because then ourstatemust be SEE01!
>
> > > > > > The 6 states are defined above the transition table.  There
> > > > > > is no SEE01state, because there is no reason to keep track
> > > > > > of that sequence.  If you are at SEE1 a single 1 input has
> > > > > > been seen since the output was decided to be zero), and a
> > > > > > zero arrives, you just go back tostateSEE000 (the one
> > > > > > where the output was decided to be changed to zero) since
> > > > > > the required 3 1s in a row cannot occur till at least a
> > > > > > single 1 arrives.  Any zero arriving before that triple 1 is
> > > > > > received just starts the count over.
>
> > > > > Thank you so much for your answer but before I complete the reading I
> > > > > have a problem with this:
>
> > > > > >If you are at SEE1 a single 1 input has
>
> > > > > been seen since the output was decided to be zero), and a
> > > > > zero arrives
>
> > > > > Question: let's say we are at SEE1 and input is 1. How should I know
> > > > > the system expects 0? why not 1?
>
> > > > > Regards,
> > > > > amit
>
> > > > The thing I'm trying to say is that regarding what Anson says the
> > > > first input 1 has an output as 1 and .... so the system in this phase
> > > > believes "1" is the right output and we haven't got to "000" yet to
> > > > switch to "0" output.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Amit,
>
> > > I admit it is a little messy to understand. Basically, to come up with
> > >statediagram, usually try to focus on the objective. In this case, it
> > > is to detect 3 consecutive 1s or 0s and result a change on the output.
> > > Therefore, case SAW01 or SAW10 will be not important enough to be
> > > named astate.
>
> > > Before the logic detects 3 of consecutive 1s or 0s, it will just keep
> > > output bits with the inital bit received at power on or 1s in the case
> > > if there has been a reset. There are only two logic states which
> > > logically change the output: SEE000 and SEE111. All other states don't
> > > really changes the outputs. These are only internal states.
>
> > > I must mention that thestatediagramdoesn't address the issue when
> > > the logic is first turned on and is it 1 or 0 at the input port. You
> > > can verify this with the thestatediagramJohn Popelish provided
> > > earlier. The first bit is a 1 and if you follow thestatediagram, you
> > > will get 0s all the way until 9th bit and it's still a 0 so it will
> > > continue until the last bit received. Infact, you will have to provide
> > > additional logic for the first 8 bits.
>
> > > Correct me if I'm wrong, but this is what I think.
>
> > > Anson
>
> > Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
> > that is right we won't need them and I read what John had said before
> > again and he is right.
>
> > But let's get back to the first input in the string which is "1" .
> > There, we can get to this conclusion that the previous value that
> > system was expecting to have as output has been "0" so the first input
> > (1) must be the third "1" of triple 1 string. Maybe following lines
> > explain it better:
>
> >                                               hidden               We
> > see
> > input:                                         11
> > 10010100010111
> > output:                                       00
> > 11111111000001
>
> > Right?
>
> > next question I have is regarding your very first question. What
> > happens to thestatethat once outputs "1" and in another situation it
> > outputs "0"?
>
> > how do you present this in yourstatediagram? If I'm not wrong this
> > is what you has asked in the first place.
>
> > Regards,
> > amit
>
> it seems what I have typed above is messy and mixed. This is what I
> was trying to show:
>
> hidden         We only see
>
>   11            10010100010111  <- input
>   00            11111111000001  <- output
>
> regards,
> amit- Hide quoted text -
>
> - Show quoted text -

Do you mean a 1 in the input string at power-up or after reset? If so,
state Init_1&SEE111 is where it should go.


Article: 118559
Subject: Re: DS18B20 connection on FPGA?
From: Jeff Cunningham <jcc@sover.net>
Date: Mon, 30 Apr 2007 00:08:06 -0400
Links: << >>  << T >>  << A >>
Mad I.D. wrote:
> Hello all.
> I'm new to FPGA and I need a little help with connecting Dallas 1-wire
> temperture DS18B20 sensor.
> 
> I used that sensor many times with ARM and AVR MCU but never with
> FPGA. What I want to know is how to connect it?
> DS needs to have an external pull up resistor. So sometimes I need to
> release line so that line is pulled high. DS and FPGA can only drive
> line low, high must come from pull up.
> 
> So..how to do that? How to use IN/OUT pin that I can "realase"? To MCU
> I would simple say "pin input" and it would be released, but in VHDL I
> define in entity
> pin : inout  STD_LOGIC;
> 
> Hmm..any ideas?
> 
> Thanks.
> 

pin <= '0' when driveitlow = '1' else 'Z';

Article: 118560
Subject: Re: driving Spartan-3 input from 74LS TTL
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 30 Apr 2007 07:12:07 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <alfke@sbcglobal.net> wrote:

>I think 5 mA is an unnecessaily low limit. 10 mA is pefectly safe,
>even if it lasts forever.
>Don't forget, there is also a diode drop between the input and Vcco.
>The resistor value is a trade-off between speed (low resistor value)
>and "safety" (high value)
>Pick 300 to 1000 Ohm, any value will be ok. Consider the input a 10 pF
>load and put the resistor close to it.. Then 1kilohm means a 10 ns
>time constant...
>Peter Alfke

Given the LS series is slow compared to modern logic, a resistor with
a higher value may even be a better choice. Less emitted radiation and
lower power consumption.


>On Apr 29, 3:09 pm, Eric Smith <e...@brouhaha.com> wrote:
>> Peter Alfke <a...@sbcglobal.net> writes:
>> > I remember well that all real TTL LS devices have an effective two-
>> > diode drop on the output.
>>
>> That was the part I wasn't sure about.
>>
>> > Then the question is whether 5 V minus 1.4 V is higher than your 3.3
>> > V, and really higher than your 3.3 V plus a diode drop.
>> > You can easily try it out, and measure the current flowing into the
>> > FPGAinput when the LS output is High. Probably is it les than a few
>> > microamps.
>> > But then the question is about tolerances: can your 5V bw high while
>> > your 3.3 V is low,
>>
>> Yes.  That would have to be taken into account.
>>
>> > and what about the start-up condition?
>>
>> Oooh, I hadn't considered that.
>>
>> > The resistor pck avoids all these headaches.
>>
>> I wasn't trying to avoid the resistor, just trying to determine whether
>> the value could be lower.  I don't actually need it to be lower, but
>> I wanted to understand the actual requirement.
>>
>> Even with 300 ohms, won't there be a problem if the 5V comes up first,
>> or there is a fault and the Vcco isn't present?  If the 5V is really
>> 5.5V and Vcco is at/near 0V, the TTL output could be as much as 4.1V
>> above Vcco.  That would allow 11.7 nA, while answer record 19146
>> suggests that the current through the protection diode should not be
>> more than 5.51 mA.  To limit the current to 5.51 mA, the resistor
>> would need to be 635.2 ohms (680 ohm 5%).  That seems pretty high,
>> but since TTL is slow stuff anyhow, it looks like it won't introduce
>> enough delay to be a problem.
>>
>> Should answer record 19146 be revised to cover startup and Vcco fault
>> conditions?  Or is it safe to allow the I/O pin to power Vcco through
>> the clamp diodes provided that it doesn't rise above Vcco(max)?
>>
>> Thanks,
>> Eric
>
>

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 118561
Subject: Serial FPDP
From: eapen.abraham@gmail.com
Date: 30 Apr 2007 00:16:36 -0700
Links: << >>  << T >>  << A >>
Hi,

Does anyone have details regarding the sFPDP protocol and its
implementation? Would be very grateful for any info. I have the doc
from VITA, but not much given in there.


Article: 118562
Subject: SAE j1850 pwm protocol controller ip core
From: ashasravanthi@gmail.com
Date: 30 Apr 2007 00:18:08 -0700
Links: << >>  << T >>  << A >>
hi all,
         can any one send me information about SAE j1850 pwm protocol
controller.can i get free verilog or vhdl sources or free ip core any
where.
i have seen j1850 pwm BDLC controller data sheet by drivven software.
can any one give me free ip core like that j1850 pwm BDLC controller.

Thank you,
ASHA.


Article: 118563
Subject: Re: VHDL editing with UltraEdit
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 30 Apr 2007 09:27:50 +0100
Links: << >>  << T >>  << A >>
Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

>
> I agree that indenting with tabs is a bad idea, which is more evidence
> that Emacs is not configured by default to be a good source code
> editor.
>

in my experience, Emacs is configured out of the box to behave as if
code indenting is done with tabs, but when it saves out it converts
tham all back to spaces, as you would hope.

I can't think of a time when Emacs has failed to do the "right thing"
out of the box, when there clearly is a right thing to do...  when
there's debate about what would be right - that's a different story
:-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 118564
Subject: Re: VHDL editing with UltraEdit
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 30 Apr 2007 09:30:45 +0100
Links: << >>  << T >>  << A >>
Joseph Samson <jsamson@the-company-name.com> writes:

> How fortunate for me that this thread has evolved into a discussion
> about emacs. I am using Xemacs in Windows with the verilog mode. I
> want to insert spaces in place of tabs. I put
> (setq-default indent-tabs-mode nil);
>
> in my custom.el and in verilog.el, but tabs are not being implemented
> as spaces in my verilog files (but they are implemented as spaces in
> other files). Any ideas?
>

I don't know if it helps, but the debate is summarised here:
http://www.jwz.org/doc/tabs-vs-spaces.html

And at the bottom, there's some configuration stuff...

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 118565
Subject: Re: TigerSHARC TS201 to PLX 9656
From: colin <colin_toogood@yahoo.com>
Date: 30 Apr 2007 01:45:32 -0700
Links: << >>  << T >>  << A >>
On 28 Apr, 09:24, eapen.abraham@gmail.com wrote:
> Hi,
>
> Has anyone tried bridging the TS201 TigerSHARC with the PLX 9656
> device? I'm trying to implement this in a current project and need
> details. The bridging is done via an Altera FPGA which also has to
> have custom logic for other functions such as Ethernet, sFPDP,etc.
>
> I know that the TS201 core runs at 600 MHz and the I/O bus at around
> 83.5 MHz. But at what speed does the PLX 9656 local bus run? Can the
> TS201 be connected directly to  the PLX chip? Are there anyother
> alternatives to the PLX chip?

If your budget can cope, I suggest www.vmetro.com for both of your
threads roday


Article: 118566
Subject: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 30 Apr 2007 01:55:46 -0700
Links: << >>  << T >>  << A >>
Hi

I really dont understand why Xilinx isnt hiring people who can develop
and test software?
Is the world-wide shortage of engineers really that bad?

Latest example:
MicroBlaze Working Design with EDK 8.1
Update to EDK 8.2 -> DDR Memory failing (was working with 8.1)
Update to EDK 9.1 -> :

./synthesis.sh: line 2: $'\r': command not found

!?

If Xilinx really does ANY software testing before release things like
that should no happen.
With ALL latest major releases the "time to first fatal error" from
the new install has been
less than 20 minutes. This is not acceptable for software that is to
be used to develop
commercial products.

Should i go back to EDK 8.1 for this one design?

Antti,
who really doesnt want to start another fight to get the buggy xilinx
sw to work.


Article: 118567
Subject: Re: driving Spartan-3 input from 74LS TTL
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 30 Apr 2007 21:51:52 +1200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> Peter Alfke <alfke@sbcglobal.net> wrote:
> 
> 
>>I think 5 mA is an unnecessaily low limit. 10 mA is pefectly safe,
>>even if it lasts forever.
>>Don't forget, there is also a diode drop between the input and Vcco.
>>The resistor value is a trade-off between speed (low resistor value)
>>and "safety" (high value)
>>Pick 300 to 1000 Ohm, any value will be ok. Consider the input a 10 pF
>>load and put the resistor close to it.. Then 1kilohm means a 10 ns
>>time constant...
>>Peter Alfke
> 
> 
> Given the LS series is slow compared to modern logic, a resistor with
> a higher value may even be a better choice. Less emitted radiation and
> lower power consumption.

Yes, but beware going too high, or the edges slew so slowly, that noise 
immunity suffers. You can use a parallel R/ small C for lowest power 
consumption, and little speed penalty. Same principle as Scope Probes.

-jg


Article: 118568
Subject: Re: Problem cascading 2 DCMs
From: MNiegl <Michael.Niegl@cern.ch>
Date: 30 Apr 2007 02:57:38 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 6:15 pm, Gabor <g...@alacron.com> wrote:
> On Apr 29, 7:56 am, MNiegl <Michael.Ni...@cern.ch> wrote:
>
>
>
> > Hi everyone,
>
> > A quick update (I haven't been through everything yet, after all it's
> > supposed to be a weekend...):
> > I checked all the FX60 erratas, there are no (known) ones concerning
> > the DCMs.
> > I tried the same design on an identical board, showed exactly the same
> > behaviour, so there really is something wrong with the design and not
> > with the chip.
> > I checked my VHDL code over and over again, couldn't find any errors,
> > but I will do the same in FPGA editor as well, just to be sure.
>
> > Furthermore I will try to reset the first DCM after config is done and
> > see if that helps matters. And then I think I will admit defeat and
> > try to source the 200 MHz externally. I also opened a WebCase, maybe
> > that gets me some more information.
>
> > Nevertheless, big thanks already to everybody who helped.
>
> > Cheers,
> > Michael
>
> It's been a while since I looked into this (Virtex II series) so
> I'm not sure about V4.  However in the other DCM's there
> was a "high frequency" mode that needed to be specified
> for the DLL to work at higher frequencies.  The HF mode
> also disabled the CLK2X output.  Could it be you need
> to use HF mode after some frequency (higher than
> 160 but less than 200 MHz)?
>
> Another thought.  If you wait for the first DCM to lock
> before releasing GSR, do you really reset the second
> DCM?  How do you initialize the SRL16 to ensure
> you get a minimum reset length if the first DCM
> is locked after config?  Normally without an INIT
> attribute the SRL would come up all zeroes after
> config.  If your reset signal is active high you'd
> want to init the SRL to all ones.
>
> HTH,
> Gabor

Hi,

About the Init of the SRL16, I make sure it is initialized to x"ffff".
I also checked the frequency ranges once again, they are all within
the specs. But a couple of minutes ago I made a discovery when I
wanted to create a similar file using the Core Generator. There in the
GUI it would only let me select an input freq betw 32 and 75 MHz for
the first DCM, saying only low-frequency DLL mode is supported. But in
the V4 DC specs paper it says that this mode has a range of 32 to 150
MHz, where my 100 would fall right in. So apparently my mode is simply
not possible and the DCMs are simply not as good as they should be
according to Xilinx own specification.
I'm now trying to source the 200 MHz externally and then use a sole
DCM for the 90 deg phase shift as well as a division by 4. I hope that
at least that will work...

Thanks and Cheers,
Michael


Article: 118569
Subject: Re: Xilinx software quality - how low can it go ?!
From: Tim <tim@nooospam.roockyloogic.com>
Date: Mon, 30 Apr 2007 11:09:08 +0100
Links: << >>  << T >>  << A >>
Antti wrote:
> Hi
> 
> I really dont understand why Xilinx isnt hiring people who can develop
> and test software?
> Is the world-wide shortage of engineers really that bad?

First level team leaders have the toughest job and are the most 
difficult to find/hire/promote. A lot of the bugs seem to reflect 
overstretch at that level.

Article: 118570
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 30 Apr 2007 03:20:09 -0700
Links: << >>  << T >>  << A >>
On 30 Apr., 12:09, Tim <t...@nooospam.roockyloogic.com> wrote:
> Antti wrote:
> > Hi
>
> > I really dont understand why Xilinx isnt hiring people who can develop
> > and test software?
> > Is the world-wide shortage of engineers really that bad?
>
> First level team leaders have the toughest job and are the most
> difficult to find/hire/promote. A lot of the bugs seem to reflect
> overstretch at that level.

maybe.

this latest issue with EDK 9.1 wasnt so bad in terms of finding a bug-
fix workaround
this time I found a workaround without spending more then 2 minutes.

workaround:
1) Start build in EDK, wait it comes to the error...
2) run XST from commandline...
3) Run again build in EDK, it will now continue with the build...

of course every time the netlist build is triggered the manual
invokation of XST has to be done... :(

In most of the cases I can find workarounds to make failing software
to not fail -but this shouldnt be necessary.

Antti


Article: 118571
Subject: Re: Xilinx software quality - how low can it go ?!
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 30 Apr 2007 04:49:25 -0700
Links: << >>  << T >>  << A >>
Well, I find I quite normal, that software has bugs. Even stupid bugs
are a reality.
OTOH, what really pisses me of are bugs that are known and easy to fix
but remain
in the software for years anyway.

An example like this is the lack of support for the default windows
install directory "program files".
And the lack of support for the german default user directory "Eigene
Dateien".
If it really is that hard to support file names with spaces, at least
the install script should prevent
me from installing to that location.

Kolja Sulimma


Article: 118572
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 30 Apr 2007 05:06:51 -0700
Links: << >>  << T >>  << A >>
On 30 Apr., 13:49, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> Well, I find I quite normal, that software has bugs. Even stupid bugs
> are a reality.
> OTOH, what really pisses me of are bugs that are known and easy to fix
> but remain
> in the software for years anyway.
>
> An example like this is the lack of support for the default windows
> install directory "program files".
> And the lack of support for the german default user directory "Eigene
> Dateien".
> If it really is that hard to support file names with spaces, at least
> the install script should prevent
> me from installing to that location.
>
> Kolja Sulimma

Ehe..

I remember that I once entered =E4 letter in the comment field of
schematic header in the Xilinx Schematic editor.
As result the all file was seen as invalid.. Had to use hex editor to
change =E4 to a, then it did open again.

The EDK 9.1 story isnt ended unfortunatly... I am using now the manual
XST trick to pass the build...
but the once working 8.1 design, in 9.1 there is not even console
printout anymore (it worked in 8.2)
and whats even worse the XMD is not able to connect either so cant
debug at all...

Antti

And yes, if anybody asks, I just installed all 9.1 service packs 1.7
GBYTE download!


Article: 118573
Subject: weird PACE Error, not one google result
From: mludwig <gyelod@gmail.com>
Date: 30 Apr 2007 05:13:44 -0700
Links: << >>  << T >>  << A >>
I get the following error in PACE after starting "Assign Package Pins"
in ISE 9.1 SP3:
ERROR:HDLParsers:3562 - pepExtractor.prj line 1  Expecting 'vhdl' or
'verilog'   keyword,  found 'work'.
It happens with a clean new project and a single top-level VHDL module
and its constraint file.
It seems that nobody encountered this issue before. Any ideas?


Article: 118574
Subject: Re: Is microblaze able to change heap_size?
From: Pablo <pbantunez@gmail.com>
Date: 30 Apr 2007 05:22:40 -0700
Links: << >>  << T >>  << A >>
On 27 abr, 14:50, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> "Pablo" <pbantu...@gmail.com> wrote in message
>
> news:1177660639.155725.195000@t38g2000prd.googlegroups.com...
>
>
>
> >> Forget about xil_malloc() and just use malloc().
>
> > But malloc doesn't work in Microblaze.
>
> Since when? I have never had any problems with it.
>
> From the "LibXil Standard C Libraries" documentation:
> The MicroBlaze and PPC405 C libraries support all the standard memory
> management functions such as malloc(), calloc(), free()
>
> There is nothing magical about malloc(). It's just an interface to a
> dynamically-allocatable wodge of memory. It doesn't have any dependencies on
> special processor features; in some environments it can make a system call
> to request more memory from the underlying OS, but with an embedded system
> it's more common just to have a fixed heap size.
>
>     -Ben-

Well I have increased heap_size and it seems ok, but when I add more
code to my project it fails again and I know I have quite a lot memory
since I have downloaded the app to the sdram with 32MB. I think malloc
works abnormally. In some cases I have seen it work fine and in
anothers it doesn`t work.

I suppose it has a reason but I don`t know what.

Thanks again for your help.




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