Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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. AnsonArticle: 118552
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
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
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: 118555On 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, amitArticle: 118556
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
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, AnsonArticle: 118558
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
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
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.nlArticle: 118561
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
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: 118563Colin 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.htmlArticle: 118564
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.htmlArticle: 118565
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 rodayArticle: 118566
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
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. -jgArticle: 118568
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, MichaelArticle: 118569
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
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. AnttiArticle: 118571
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 SulimmaArticle: 118572
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
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
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:
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