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 131375

Article: 131375
Subject: Re: Survey: FPGA PCB layout
From: krw <krw@att.bizzzzzzzzzz>
Date: Sun, 20 Apr 2008 22:20:11 -0400
Links: << >>  << T >>  << A >>
In article <6PQOj.21063$%41.8783@nlpi064.nbdc.sbc.com>, 
notthisjoergsch@removethispacbell.net says...
> John Larkin wrote:
> > On Sun, 20 Apr 2008 14:13:21 -0700, Joerg
> > <notthisjoergsch@removethispacbell.net> wrote:
> > 
> >> John Larkin wrote:
> >>> On Sat, 19 Apr 2008 14:17:44 -0700, Joerg
> >>> <notthisjoergsch@removethispacbell.net> wrote:
> >>>
> >>>> Nico Coesel wrote:
> >>>>> Dave <dhschetz@gmail.com> wrote:
> >>>>>
> >>>>>> Does anybody out there have a good methodology for determining your
> >>>>>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean?
> >>>>>> The brute force method is fairly maddening. I'd be curious to hear if
> >>>>>> anybody has any 'tricks of the trade' here.
> >>>>> I start thinking about how the PCB should be routed the minute I start
> >>>>> to draw a schematic. I always draw components with their actual
> >>>>> pin-outs. This helps to group pins together and it helps to
> >>>>> troubleshoot the circuit when the prototype is on your bench (no need
> >>>>> to lookup the pinouts because they are in your diagram).
> >>>>>
> >>>> For quad opamps like the LM324 as well? That can make a schematic harder 
> >>>> to read and will also cause a nightmare if the layouter wants to swap 
> >>>> amp A with amp C and stuff like that.
> >>>>
> >>>> [...]
> >>> A quad opamp doesn't have 1738 pins!
> >>>
> >> Well, yes, I was just wondering about whether Nico really always draws 
> >> the physical package. Looks like he doesn't for smaller stuff.
> >>
> >> With 1738 pins you can only hope that the FPGA has enough routing 
> >> resources. That used to be a major pain in the early 90's. Don't know 
> >> about nowadays since other guys design the parts with the big FPGAs. And 
> >> I am glad I don't have to deal with BGA, at least not with large ones ...
> > 
> > The biggest ones we use are Sparten 3's with 456 balls on 1 mm
> > centers. We haven't had any routing problems so far, doing pretty
> > complex stuff at 128 MHz clock rates. Our in-house BGA soldering
> > yield, to date, is exactly 100%. BGAs seem to be a lot easier to
> > solder reliably than fine-pitch leaded parts. Easier to inspect, too,
> > since you can't inspect them at all.
> > 
> 
> The latter is a concern in my field (medical). We need to be able to 
> inspect. The other concern is involuntary board flexing. Most of my 
> designs have to sustain under tortures such as freighter pilots 
> ploughing through a storm in the Carribean in airplanes as old as a DC-3 
> or a trucker in Africa who is lead-footing it over a few hundred miles 
> of washboard road.
> 
X-Rays?

-- 
Keith

Article: 131376
Subject: Re: Survey: FPGA PCB layout
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 20 Apr 2008 19:42:26 -0700
Links: << >>  << T >>  << A >>
On Sun, 20 Apr 2008 18:10:04 -0400, "Michael A. Terrell"
<mike.terrell@earthlink.net> wrote:

>
>John Larkin wrote:
>> 
>> On Sun, 20 Apr 2008 17:33:16 -0400, "Michael A. Terrell"
>> <mike.terrell@earthlink.net> wrote:
>> 
>> >
>> >John Larkin wrote:
>> >>
>> >> A quad opamp doesn't have 1738 pins!
>> >
>> >
>> >   That will only happen if Bloggs designs it. :(
>> 
>> Bloggs has several times stated that he doesn't design electronics. He
>> hasn't stated what he actually does.
>
>



>  He stated that he does absolutely nothing.  It might be the only time
>he has ever told the truth.

Sounds boring. No wonder he's usually bummed.

John


Article: 131377
Subject: Re: Problem writing quadrature decoder
From: Michael <nleahcim@gmail.com>
Date: Sun, 20 Apr 2008 20:09:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 7:12=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> Michael, you might prefer my much simpler solution, as described in a
> recent blog on the Xilinx forums website.
>
> http://forums.xilinx.com/xlnx/blog/article?message.uid=3D9394
>
> I designed this a few years ago, and we use it in our programmable
> frequency gererator, that I have mentioned here a few times.
> Ken Chapman then took the exact same shaft encoder for the Spartan
> eval board.
> The design is absolutely bounce-proof, no Mickey Mouse low-pass
> filters or other analog nonsense.
> I hope the explanation is sufficient.
>
> Viel Spa=DF
> Peter Alfke

Hi Peter - I didn't see any code attached to the post. Does this look
right?

signal Q1, Q2 : std_logic;
process (A, B)
begin
	if (A =3D '1' and B =3D '1') then
		Q1 <=3D '1';
	elsif (A =3D '0' and B =3D '0') then
		Q1 <=3D '0';
	elsif (A =3D '0' and B =3D '1') then
		Q2 <=3D '1';
	elsif (A =3D '1' and B =3D '0') then
		Q2 <=3D '0';
	end if;

	D1 <=3D (A and B) or ((A or B) and Q1);
	D2 <=3D ((not A) and B) or (((not A) or B) and Q2);
end process;

So then I would take say D1 and call it the clock, and call D2 the
direction, and then increment the count on every edge of D1 when D2
was high and decrement it for every D1 edge when D2 was low? At least,
that was my understanding from your post.

However, I just simulated it by hand (on a piece of paper- haven't
figured out how to use a simulator just yet) - and I set it up to have
B 90 degrees behind A, and then I found Q1 =3D A, Q2 =3D B, D1 =3D A, and D2=

=3D B. So I suspect I'm misunderstanding something...

-Michael

Article: 131378
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 20 Apr 2008 20:14:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 8:09=A0pm, Michael <nleah...@gmail.com> wrote:
> On Apr 20, 7:12=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > Michael, you might prefer my much simpler solution, as described in a
> > recent blog on the Xilinx forums website.
>
> >http://forums.xilinx.com/xlnx/blog/article?message.uid=3D9394
>
> > I designed this a few years ago, and we use it in our programmable
> > frequency gererator, that I have mentioned here a few times.
> > Ken Chapman then took the exact same shaft encoder for the Spartan
> > eval board.
> > The design is absolutely bounce-proof, no Mickey Mouse low-pass
> > filters or other analog nonsense.
> > I hope the explanation is sufficient.
>
> > Viel Spa=DF
> > Peter Alfke
>
> Hi Peter - I didn't see any code attached to the post. Does this look
> right?
>
> signal Q1, Q2 : std_logic;
> process (A, B)
> begin
> =A0 =A0 =A0 =A0 if (A =3D '1' and B =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '1';
> =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '0') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '0';
> =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '1';
> =A0 =A0 =A0 =A0 elsif (A =3D '1' and B =3D '0') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '0';
> =A0 =A0 =A0 =A0 end if;
>
> =A0 =A0 =A0 =A0 D1 <=3D (A and B) or ((A or B) and Q1);
> =A0 =A0 =A0 =A0 D2 <=3D ((not A) and B) or (((not A) or B) and Q2);
> end process;
>
> So then I would take say D1 and call it the clock, and call D2 the
> direction, and then increment the count on every edge of D1 when D2
> was high and decrement it for every D1 edge when D2 was low? At least,
> that was my understanding from your post.
>
> However, I just simulated it by hand (on a piece of paper- haven't
> figured out how to use a simulator just yet) - and I set it up to have
> B 90 degrees behind A, and then I found Q1 =3D A, Q2 =3D B, D1 =3D A, and =
D2
> =3D B. So I suspect I'm misunderstanding something...
>
> -Michael

Check it with pencil and paper.
Yes, A and B are 90 degree offset, that's why it's called a quadrature
decoder.
Then check if for a monotonic "friendly" rotation, and you see how it
works. The trickery is that it also works for any non-monotonic move.
Peter

Article: 131379
Subject: Re: synchronous reset problems on FPGA
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 20 Apr 2008 20:20:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 7:01=A0pm, chrisde...@gmail.com wrote:
> Hi Peter,
> =A0 =A0I do not have this luxury. The core which is running at f/4 clock
> is a core originally written in Handel C and given to me as a ngc file
> and not in VHDL. The maximum synthesizable speed of this core is only
> at f/4 MHz. The core thus has to run at an f/4 clock.
> =A0 =A0With this set of restrictions in mind, could there still be a
> solution to the reset problem?
>
> Chris

There must be a limited number of flip-flops in that part of the
design. Just clock each of them with the fast clock, and drive CE with
the slower clock. And forget all about asynchronous FIFOs.
Do you understand hardware, or are you just patching cores together ?
Peter Alfke

Article: 131380
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 20 Apr 2008 20:39:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 8:14=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Apr 20, 8:09=A0pm, Michael <nleah...@gmail.com> wrote:
>
>
>
> > On Apr 20, 7:12=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > Michael, you might prefer my much simpler solution, as described in a
> > > recent blog on the Xilinx forums website.
>
> > >http://forums.xilinx.com/xlnx/blog/article?message.uid=3D9394
>
> > > I designed this a few years ago, and we use it in our programmable
> > > frequency gererator, that I have mentioned here a few times.
> > > Ken Chapman then took the exact same shaft encoder for the Spartan
> > > eval board.
> > > The design is absolutely bounce-proof, no Mickey Mouse low-pass
> > > filters or other analog nonsense.
> > > I hope the explanation is sufficient.
>
> > > Viel Spa=DF
> > > Peter Alfke
>
> > Hi Peter - I didn't see any code attached to the post. Does this look
> > right?
>
> > signal Q1, Q2 : std_logic;
> > process (A, B)
> > begin
> > =A0 =A0 =A0 =A0 if (A =3D '1' and B =3D '1') then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '1';
> > =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '0') then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '0';
> > =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '1') then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '1';
> > =A0 =A0 =A0 =A0 elsif (A =3D '1' and B =3D '0') then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '0';
> > =A0 =A0 =A0 =A0 end if;
>
> > =A0 =A0 =A0 =A0 D1 <=3D (A and B) or ((A or B) and Q1);
> > =A0 =A0 =A0 =A0 D2 <=3D ((not A) and B) or (((not A) or B) and Q2);
> > end process;
>
> > So then I would take say D1 and call it the clock, and call D2 the
> > direction, and then increment the count on every edge of D1 when D2
> > was high and decrement it for every D1 edge when D2 was low? At least,
> > that was my understanding from your post.
>
> > However, I just simulated it by hand (on a piece of paper- haven't
> > figured out how to use a simulator just yet) - and I set it up to have
> > B 90 degrees behind A, and then I found Q1 =3D A, Q2 =3D B, D1 =3D A, an=
d D2
> > =3D B. So I suspect I'm misunderstanding something...
>
> > -Michael
>
> Check it with pencil and paper.
> Yes, A and B are 90 degree offset, that's why it's called a quadrature
> decoder.
> Then check if for a monotonic "friendly" rotation, and you see how it
> works. The trickery is that it also works for any non-monotonic move.
> Peter

Michael,
you start simply by ignoring the clock, just assume that it is always
there, and is very fast, so each look-up table output is immediately
registered.
Then you move A and B, realizing that they are 90 degree offset. Then
you just inspect the two Qs, and you see that you can consider one of
them (either one) as the outgoing clock, and the other as the
direction. Seems trivial, but the beauty is that it also works for any
and every kind of irregular operation. It's not "rocket science" but
it is simple and clever, if i may say so.
Peter

Article: 131381
Subject: Re: Problem writing quadrature decoder
From: Michael <nleahcim@gmail.com>
Date: Sun, 20 Apr 2008 21:27:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 11:39=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Apr 20, 8:14=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
>
>
> > On Apr 20, 8:09=A0pm, Michael <nleah...@gmail.com> wrote:
>
> > > On Apr 20, 7:12=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > Michael, you might prefer my much simpler solution, as described in =
a
> > > > recent blog on the Xilinx forums website.
>
> > > >http://forums.xilinx.com/xlnx/blog/article?message.uid=3D9394
>
> > > > I designed this a few years ago, and we use it in our programmable
> > > > frequency gererator, that I have mentioned here a few times.
> > > > Ken Chapman then took the exact same shaft encoder for the Spartan
> > > > eval board.
> > > > The design is absolutely bounce-proof, no Mickey Mouse low-pass
> > > > filters or other analog nonsense.
> > > > I hope the explanation is sufficient.
>
> > > > Viel Spa=DF
> > > > Peter Alfke
>
> > > Hi Peter - I didn't see any code attached to the post. Does this look
> > > right?
>
> > > signal Q1, Q2 : std_logic;
> > > process (A, B)
> > > begin
> > > =A0 =A0 =A0 =A0 if (A =3D '1' and B =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '1';
> > > =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '0') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '0';
> > > =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '1';
> > > =A0 =A0 =A0 =A0 elsif (A =3D '1' and B =3D '0') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '0';
> > > =A0 =A0 =A0 =A0 end if;
>
> > > =A0 =A0 =A0 =A0 D1 <=3D (A and B) or ((A or B) and Q1);
> > > =A0 =A0 =A0 =A0 D2 <=3D ((not A) and B) or (((not A) or B) and Q2);
> > > end process;
>
> > > So then I would take say D1 and call it the clock, and call D2 the
> > > direction, and then increment the count on every edge of D1 when D2
> > > was high and decrement it for every D1 edge when D2 was low? At least,=

> > > that was my understanding from your post.
>
> > > However, I just simulated it by hand (on a piece of paper- haven't
> > > figured out how to use a simulator just yet) - and I set it up to have=

> > > B 90 degrees behind A, and then I found Q1 =3D A, Q2 =3D B, D1 =3D A, =
and D2
> > > =3D B. So I suspect I'm misunderstanding something...
>
> > > -Michael
>
> > Check it with pencil and paper.
> > Yes, A and B are 90 degree offset, that's why it's called a quadrature
> > decoder.
> > Then check if for a monotonic "friendly" rotation, and you see how it
> > works. The trickery is that it also works for any non-monotonic move.
> > Peter
>
> Michael,
> you start simply by ignoring the clock, just assume that it is always
> there, and is very fast, so each look-up table output is immediately
> registered.
> Then you move A and B, realizing that they are 90 degree offset. Then
> you just inspect the two Qs, and you see that you can consider one of
> them (either one) as the outgoing clock, and the other as the
> direction. Seems trivial, but the beauty is that it also works for any
> and every kind of irregular operation. It's not "rocket science" but
> it is simple and clever, if i may say so.
> Peter- Hide quoted text -
>
> - Show quoted text -

So this is what I got (for the two different directions):

A  _--__--__-
B  --__--__--
Q1 _--__--__-
Q2 --__--__--
D1 _--__--__-
D2 --__--__--

A  _--__--__-
B  __--__--__
Q1 __--__--__
Q2 -__--__--_
D1 __--__--__
D2 _--__--__-

I want to be able to count every edge. I think this method will give
me half (or a quarter?) of the resolution that I want, unless I'm
missing something?

Either way - what exactly is the idea here... I really don't
understand the post you linked to. Is it saying that one of these
signals can be used as a direction and one as the clock. However - if
one of these was a direction signal - I'd expect it to be constant as
my quadrature signals are just going in one direction...

-Michael

Article: 131382
Subject: Re: synchronous reset problems on FPGA
From: chrisdekoh@gmail.com
Date: Sun, 20 Apr 2008 21:40:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Peter,
    I understand exactly what you are saying. Unfortunately I am just
patching cores together. As mentioned, what I get is an ngc file which
I do not have any control of the core.

Chris

Article: 131383
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 20 Apr 2008 22:07:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 9:27=A0pm, Michael <nleah...@gmail.com> wrote:
> On Apr 20, 11:39=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
> > On Apr 20, 8:14=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On Apr 20, 8:09=A0pm, Michael <nleah...@gmail.com> wrote:
>
> > > > On Apr 20, 7:12=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > > Michael, you might prefer my much simpler solution, as described i=
n a
> > > > > recent blog on the Xilinx forums website.
>
> > > > >http://forums.xilinx.com/xlnx/blog/article?message.uid=3D9394
>
> > > > > I designed this a few years ago, and we use it in our programmable=

> > > > > frequency gererator, that I have mentioned here a few times.
> > > > > Ken Chapman then took the exact same shaft encoder for the Spartan=

> > > > > eval board.
> > > > > The design is absolutely bounce-proof, no Mickey Mouse low-pass
> > > > > filters or other analog nonsense.
> > > > > I hope the explanation is sufficient.
>
> > > > > Viel Spa=DF
> > > > > Peter Alfke
>
> > > > Hi Peter - I didn't see any code attached to the post. Does this loo=
k
> > > > right?
>
> > > > signal Q1, Q2 : std_logic;
> > > > process (A, B)
> > > > begin
> > > > =A0 =A0 =A0 =A0 if (A =3D '1' and B =3D '1') then
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '1';
> > > > =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '0') then
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q1 <=3D '0';
> > > > =A0 =A0 =A0 =A0 elsif (A =3D '0' and B =3D '1') then
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '1';
> > > > =A0 =A0 =A0 =A0 elsif (A =3D '1' and B =3D '0') then
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Q2 <=3D '0';
> > > > =A0 =A0 =A0 =A0 end if;
>
> > > > =A0 =A0 =A0 =A0 D1 <=3D (A and B) or ((A or B) and Q1);
> > > > =A0 =A0 =A0 =A0 D2 <=3D ((not A) and B) or (((not A) or B) and Q2);
> > > > end process;
>
> > > > So then I would take say D1 and call it the clock, and call D2 the
> > > > direction, and then increment the count on every edge of D1 when D2
> > > > was high and decrement it for every D1 edge when D2 was low? At leas=
t,
> > > > that was my understanding from your post.
>
> > > > However, I just simulated it by hand (on a piece of paper- haven't
> > > > figured out how to use a simulator just yet) - and I set it up to ha=
ve
> > > > B 90 degrees behind A, and then I found Q1 =3D A, Q2 =3D B, D1 =3D A=
, and D2
> > > > =3D B. So I suspect I'm misunderstanding something...
>
> > > > -Michael
>
> > > Check it with pencil and paper.
> > > Yes, A and B are 90 degree offset, that's why it's called a quadrature=

> > > decoder.
> > > Then check if for a monotonic "friendly" rotation, and you see how it
> > > works. The trickery is that it also works for any non-monotonic move.
> > > Peter
>
> > Michael,
> > you start simply by ignoring the clock, just assume that it is always
> > there, and is very fast, so each look-up table output is immediately
> > registered.
> > Then you move A and B, realizing that they are 90 degree offset. Then
> > you just inspect the two Qs, and you see that you can consider one of
> > them (either one) as the outgoing clock, and the other as the
> > direction. Seems trivial, but the beauty is that it also works for any
> > and every kind of irregular operation. It's not "rocket science" but
> > it is simple and clever, if i may say so.
> > Peter- Hide quoted text -
>
> > - Show quoted text -
>
> So this is what I got (for the two different directions):
>
> A =A0_--__--__-
> B =A0--__--__--
> Q1 _--__--__-
> Q2 --__--__--
> D1 _--__--__-
> D2 --__--__--
>
> A =A0_--__--__-
> B =A0__--__--__
> Q1 __--__--__
> Q2 -__--__--_
> D1 __--__--__
> D2 _--__--__-
>
> I want to be able to count every edge. I think this method will give
> me half (or a quarter?) of the resolution that I want, unless I'm
> missing something?
>
> Either way - what exactly is the idea here... I really don't
> understand the post you linked to. Is it saying that one of these
> signals can be used as a direction and one as the clock. However - if
> one of these was a direction signal - I'd expect it to be constant as
> my quadrature signals are just going in one direction...
>
> -Michael

Michael, you get one increment or decrement for every complete cycle,
not for every edge.
Since the direction polarity only matters exactly at the rising edge
of Q1 (assuming you use Q1 as the clock) there is no need for Q2 to be
stable at any other time. It just indicaates direction when it is
needed.
You can look at Q1 and Q2 just as cleaned up versions of A and B,
without any bounce, but also insensitive to small changes in
direction.
There may be a way to double the resolution, by running Q1 through a
frequency doubler while conditionally inverting Q2. That would double
the total LUT count, but would still be quite simple. I had no need
for the increased resolution in my application, but I'll take a look
at it.
The fundamental issue is to ignore the unavoidable contact bounce, and
also to count correctly (up and down) even when the shaft encoder
moves in any crazy way. You have to solve both these different issues:
contact bounce and strange reversal of direction at any time.
Otherwise any solution is worthless and just gives you a headache. And
a digital designer wants to stay away from capacitors and filters and
other analog stuff...
Peter

Article: 131384
Subject: Re: Problem writing quadrature decoder
From: Michael <nleahcim@gmail.com>
Date: Sun, 20 Apr 2008 22:10:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 8:02=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> > Hi Frank - I thought about debouncing and - unless I'm being dumb - I
> > think as long as only one input is changing at a time, bounce won't
> > affect this approach in the steady state. I mean that if I turn it 4
> > counts, it might count something like 0 1 2 3 2 3 4 3 4. But the final
> > value will be correct.
>
> There are different classes of Quad encoder.
> The Simplest feed one phase into a CLK and the
> other into DIRN, but that counts only once per whole cycle.
>
> The best designs can count on every edge, and can tolerate
> a chattering edge. You might also want to catch
> illegal state jumps (missed states), as that indicates
> something is amiss in your design.
> One easy to understand way to code this, is to create
> a internal 2 bit phase engine, and lock it to the
> external sampled edges. That design makes illegal
> state jumps easy to catch.
> You have a simple state engine, with 2 IP bits,
> 2 Present bits, [16 combinations] and output =A0CE, DIRN, and ERR,
> as well as 2 bits for Next state.
>
> -jg

I'm looking to count every single edge. I had another idea about how
to do it:

process(enc_a, enc_b)
begin
	if enc_a'event then
		case prevstate is
			when "00"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when "01"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when "10"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when "11"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when others =3D>
				enc_cnt <=3D enc_cnt;
		end case;
	else
		case prevstate is
			when "00"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when "01"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when "10"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when "11"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when others =3D>
				enc_cnt <=3D enc_cnt;
		end case;
	end if;

	prevstate <=3D enc_a & enc_b;
end process;

Unfortunately - apparently the "if enc_a'event then" line is not
synthesizable - you can't trigger on both edges. So once again I'm
stuck.

Any suggestions?

Thanks!

-Michael

Article: 131385
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 20 Apr 2008 22:49:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 10:10=A0pm, Michael <nleah...@gmail.com> wrote:
> On Apr 20, 8:02=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
>
>
>
> > > Hi Frank - I thought about debouncing and - unless I'm being dumb - I
> > > think as long as only one input is changing at a time, bounce won't
> > > affect this approach in the steady state. I mean that if I turn it 4
> > > counts, it might count something like 0 1 2 3 2 3 4 3 4. But the final=

> > > value will be correct.
>
> > There are different classes of Quad encoder.
> > The Simplest feed one phase into a CLK and the
> > other into DIRN, but that counts only once per whole cycle.
>
> > The best designs can count on every edge, and can tolerate
> > a chattering edge. You might also want to catch
> > illegal state jumps (missed states), as that indicates
> > something is amiss in your design.
> > One easy to understand way to code this, is to create
> > a internal 2 bit phase engine, and lock it to the
> > external sampled edges. That design makes illegal
> > state jumps easy to catch.
> > You have a simple state engine, with 2 IP bits,
> > 2 Present bits, [16 combinations] and output =A0CE, DIRN, and ERR,
> > as well as 2 bits for Next state.
>
> > -jg
>
> I'm looking to count every single edge. I had another idea about how
> to do it:
>
> process(enc_a, enc_b)
> begin
> =A0 =A0 =A0 =A0 if enc_a'event then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case prevstate is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "00"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "01"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "10"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "11"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end case;
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case prevstate is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "00"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "01"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "10"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "11"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end case;
> =A0 =A0 =A0 =A0 end if;
>
> =A0 =A0 =A0 =A0 prevstate <=3D enc_a & enc_b;
> end process;
>
> Unfortunately - apparently the "if enc_a'event then" line is not
> synthesizable - you can't trigger on both edges. So once again I'm
> stuck.
>
> Any suggestions?
>
> Thanks!
>
> -Michael

Michael, when you say: count every single edge", do you mean every
edge of A, or every edge of either A or B ?
One is 2 edges per 360 deegrees, the other one is 4. Mine is 1.
Incidentally, why is this important? For manual control, you have too
many edges to start with...
Peter

Article: 131386
Subject: Re: Problem writing quadrature decoder
From: Michael <nleahcim@gmail.com>
Date: Sun, 20 Apr 2008 23:03:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 1:49=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Apr 20, 10:10=A0pm, Michael <nleah...@gmail.com> wrote:
>
>
>
>
>
> > On Apr 20, 8:02=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
>
> > > > Hi Frank - I thought about debouncing and - unless I'm being dumb - =
I
> > > > think as long as only one input is changing at a time, bounce won't
> > > > affect this approach in the steady state. I mean that if I turn it 4=

> > > > counts, it might count something like 0 1 2 3 2 3 4 3 4. But the fin=
al
> > > > value will be correct.
>
> > > There are different classes of Quad encoder.
> > > The Simplest feed one phase into a CLK and the
> > > other into DIRN, but that counts only once per whole cycle.
>
> > > The best designs can count on every edge, and can tolerate
> > > a chattering edge. You might also want to catch
> > > illegal state jumps (missed states), as that indicates
> > > something is amiss in your design.
> > > One easy to understand way to code this, is to create
> > > a internal 2 bit phase engine, and lock it to the
> > > external sampled edges. That design makes illegal
> > > state jumps easy to catch.
> > > You have a simple state engine, with 2 IP bits,
> > > 2 Present bits, [16 combinations] and output =A0CE, DIRN, and ERR,
> > > as well as 2 bits for Next state.
>
> > > -jg
>
> > I'm looking to count every single edge. I had another idea about how
> > to do it:
>
> > process(enc_a, enc_b)
> > begin
> > =A0 =A0 =A0 =A0 if enc_a'event then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case prevstate is
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "00"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt + 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "01"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt - 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "10"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt - 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "11"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt + 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when others =3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end case;
> > =A0 =A0 =A0 =A0 else
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case prevstate is
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "00"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt - 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "01"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt + 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "10"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt + 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "11"=3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt - 1;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when others =3D>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt =
<=3D enc_cnt;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end case;
> > =A0 =A0 =A0 =A0 end if;
>
> > =A0 =A0 =A0 =A0 prevstate <=3D enc_a & enc_b;
> > end process;
>
> > Unfortunately - apparently the "if enc_a'event then" line is not
> > synthesizable - you can't trigger on both edges. So once again I'm
> > stuck.
>
> > Any suggestions?
>
> > Thanks!
>
> > -Michael
>
> Michael, when you say: count every single edge", do you mean every
> edge of A, or every edge of either A or B ?
> One is 2 edges per 360 deegrees, the other one is 4. Mine is 1.
> Incidentally, why is this important? For manual control, you have too
> many edges to start with...
> Peter

I'm looking for 4 counts/360 degrees. My final use for quadrature
decoding will be with motor control - so increasing the resolution of
my encoder counting is very beneficial.

-Michael

Article: 131387
Subject: Re: Problem writing quadrature decoder
From: Michael <nleahcim@gmail.com>
Date: Sun, 20 Apr 2008 23:10:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 1:10=A0am, Michael <nleah...@gmail.com> wrote:
> On Apr 20, 8:02=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
>
>
>
>
>
> > > Hi Frank - I thought about debouncing and - unless I'm being dumb - I
> > > think as long as only one input is changing at a time, bounce won't
> > > affect this approach in the steady state. I mean that if I turn it 4
> > > counts, it might count something like 0 1 2 3 2 3 4 3 4. But the final=

> > > value will be correct.
>
> > There are different classes of Quad encoder.
> > The Simplest feed one phase into a CLK and the
> > other into DIRN, but that counts only once per whole cycle.
>
> > The best designs can count on every edge, and can tolerate
> > a chattering edge. You might also want to catch
> > illegal state jumps (missed states), as that indicates
> > something is amiss in your design.
> > One easy to understand way to code this, is to create
> > a internal 2 bit phase engine, and lock it to the
> > external sampled edges. That design makes illegal
> > state jumps easy to catch.
> > You have a simple state engine, with 2 IP bits,
> > 2 Present bits, [16 combinations] and output =A0CE, DIRN, and ERR,
> > as well as 2 bits for Next state.
>
> > -jg
>
> I'm looking to count every single edge. I had another idea about how
> to do it:
>
> process(enc_a, enc_b)
> begin
> =A0 =A0 =A0 =A0 if enc_a'event then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case prevstate is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "00"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "01"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "10"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "11"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end case;
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case prevstate is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "00"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "01"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "10"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "11"=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt - 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enc_cnt <=
=3D enc_cnt;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end case;
> =A0 =A0 =A0 =A0 end if;
>
> =A0 =A0 =A0 =A0 prevstate <=3D enc_a & enc_b;
> end process;
>
> Unfortunately - apparently the "if enc_a'event then" line is not
> synthesizable - you can't trigger on both edges. So once again I'm
> stuck.
>
> Any suggestions?
>
> Thanks!
>
> -Michael

A-ha! I realized I could get rid of the edge checking and just compare
with my saved previous state. It synthesizes! Unfortunately, it gives
me some warnings during synthesization, and then (I believe due to the
warnings) it won't give me a programming file. The warnings are:

the following signal(s) form a combinatorial loop: led<7>, enc_cnt<7>,
Maddsub_enc_cnt14.

(for led<7> - led<0>)

Then it gives me a bunch of errors during mapping, like this one:

ERROR:MapLib:661 - LUT4 symbol "Maddsub_enc_cnt41" (output
   signal=3DMaddsub_enc_cnt4) has input signal "Maddsub_enc_cnt" which
will be
   trimmed. See the t


I'm so close now (I think!) Can anybody tell me what is wrong with my
code? I've never had a problem with mapping before - so this is very
odd for me. I've posted the full code below. Thanks so much!

-Michael



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.all;

entity hello_world is
port (
	clk, enc_a, enc_b : in std_logic;
	switches : in std_logic_vector (3 downto 0);
	led : out std_logic_vector (7 downto 0)
);
end hello_world;

architecture rtl of hello_world is
	signal cnt : unsigned (30 downto 0);
	signal encval : unsigned (7 downto 0);
	signal enc_cnt : unsigned (7 downto 0);
	signal prevstate : std_logic_vector (1 downto 0);
begin
	process(clk)
	begin
		if rising_edge(clk) then
			cnt <=3D cnt + 1;
			encval <=3D "000000" & enc_b & enc_a;
		end if;
	end process;

process(enc_a, enc_b)
begin
	if prevstate(0) /=3D enc_a then
		case prevstate is
			when "00"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when "01"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when "10"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when "11"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when others =3D>
				enc_cnt <=3D enc_cnt;
		end case;
	else
		case prevstate is
			when "00"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when "01"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when "10"=3D>
				enc_cnt <=3D enc_cnt + 1;
			when "11"=3D>
				enc_cnt <=3D enc_cnt - 1;
			when others =3D>
				enc_cnt <=3D enc_cnt;
		end case;
	end if;

	prevstate(0) <=3D enc_a;
	prevstate(1) <=3D enc_b;
end process;

	led <=3D std_logic_vector(cnt(30 downto 23)) when switches(0)=3D'0' else
std_logic_vector(enc_cnt);

end rtl;

Article: 131388
Subject: Re: Very simple VHDL problem
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 21 Apr 2008 08:32:18 +0200
Links: << >>  << T >>  << A >>
Michael a écrit :

> So is a cast in VHDL just like a cast in C? I must admit this is the
> first I've heard of VHDL having that ability.

In VHDL you can only cast between "closely related types". You can not 
cast an integer to a signed vector, for example. This requires a 
conversion function.

In the previous example, I used a cast to convert an unsigned to a 
std_logic_vector. This is allowed because both types are arrays of 
std_logic.

Nicolas

Article: 131389
Subject: Re: Problem writing quadrature decoder
From: -jg <Jim.Granville@gmail.com>
Date: Sun, 20 Apr 2008 23:40:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

<snip>
> The fundamental issue is to ignore the unavoidable contact bounce, and
> also to count correctly (up and down) even when the shaft encoder
> moves in any crazy way. You have to solve both these different issues:
> contact bounce and strange reversal of direction at any time.

In a full precision (one count per edge) you cannot ignore bounce,
you have to accept it, and 'count with it, so the counter goes
+1,-1 +1 as it follows the bounce. Similarly with edge jitter (also
possible in control systems) you need to follow.
That's why it is a good idea to sample the IPs, and the CLK
speed needs to be no more than the total counter speed
(normally well over 10MHz)

Did you look at the links I gave before on the HCTL-2001 etc. ?

Jim Granville,


Article: 131390
Subject: Re: Problem writing quadrature decoder
From: -jg <Jim.Granville@gmail.com>
Date: Mon, 21 Apr 2008 00:03:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Michael wrote:

> Unfortunately - apparently the "if enc_a'event then" line is not
> synthesizable - you can't trigger on both edges. So once again I'm
> stuck.

you only have 2 state bits, once you get 4, you can do it on a faster
clock edge,


So if you consider a quad-state/johnson counter, as a first pass.
[easier to follow than binary], and what you are coding is a phase
lock, or
tracking system counter (TSC) that spins that counter to match the
Quad IP.
It CAN spin at any speed, normally it will do one phase click, and
then
many,many idle states until the next phase click is needed


IP.TSC
00.00
01.01
11.11
10.10   are all HOLD or do nothing states, MOST clocks will be here

00.01
01.11
11.10
10.00 are all DEC(TSC) by one, and output DEC_EN to the long counter

00.10
01.00
11.01
10.11 are all INC(TSC) by one, and output INC_EN to the long counter

which leaves 4 other states
00.11
01.10
11.00
10.01 as different by TWO clocks, so these are illegal
and should never happen in a correct margin design.
Take them to a sticky-led, perhaps ?.

Once you have that working, you can compact the two TSC bits into the
Long counter, two LSBs, by change to binary coding, if you really want
to
save two FFs  :)
In a FPGA tho,  why bother ?
( In a small CPLD, you might take the effort. )

Also, on read/compare of the long counter, if the system WORD size
is less than the counter size, you need to capture ALL bits
in one clock, in case the counter rolls over between byte/word reads.

Jim Granville,

Article: 131391
Subject: Re: Survey: FPGA PCB layout
From: "Michael A. Terrell" <mike.terrell@earthlink.net>
Date: Mon, 21 Apr 2008 03:24:37 -0400
Links: << >>  << T >>  << A >>

John Larkin wrote:
> 
> On Sun, 20 Apr 2008 18:10:04 -0400, "Michael A. Terrell"
> <mike.terrell@earthlink.net> wrote:
> 
> >
> >John Larkin wrote:
> >>
> >> On Sun, 20 Apr 2008 17:33:16 -0400, "Michael A. Terrell"
> >> <mike.terrell@earthlink.net> wrote:
> >>
> >> >
> >> >John Larkin wrote:
> >> >>
> >> >> A quad opamp doesn't have 1738 pins!
> >> >
> >> >
> >> >   That will only happen if Bloggs designs it. :(
> >>
> >> Bloggs has several times stated that he doesn't design electronics. He
> >> hasn't stated what he actually does.
> >
> >
> 
> >  He stated that he does absolutely nothing.  It might be the only time
> >he has ever told the truth.
> 
> Sounds boring. No wonder he's usually bummed.


   No reason to live if you have nothing to do. :(


-- 
http://improve-usenet.org/index.html


Use any search engine other than Google till they stop polluting USENET
with porn and junk commercial SPAM

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm

Article: 131392
Subject: Re: synchronous reset problems on FPGA
From: "HT-Lab" <hans64@ht-lab.com>
Date: Mon, 21 Apr 2008 07:56:23 GMT
Links: << >>  << T >>  << A >>

<chrisdekoh@gmail.com> wrote in message
news:6ee86d42-4111-4a7c-8a85-30011b78a244@q27g2000prf.googlegroups.com...
> Hi,
>   I am wondering if anyone of you have experienced this before. Here
> goes the reset problem I am facing now. asynchronous reset in FPGAs
> are usually a big NO-NO. from the articles I am reading, the async
> reset, normally results in more logic being used to stitch up LUTs
> together.
>  However, the design I am currently working on requires only one of
> the blocks to run at 1/4 that of the original clock speed. I am using
> a DCM to clock divide the master clock, and the output goes into this
> block. The problem happens when
>
> - the reset signal which resets the DCM, is the same reset which goes
> into this same block.
> - This will result in a problem, as the clock-divide-by-4 as I call
> it, will not emit a clock pulse in reset state, as the DCM has not
> locked yet. the synchronous reset will thus not work for this block.
>
> 1) Any ideas of how to circumvent this problem? I would like to use
> synchronous resets, but also use the divide by 4 clock for the block.
> 2) Are my concepts of synchronous resets correct? that synchronous
> resets on FPGA are better than asynchronous resets?

I believe this only applies to Xilinx FPGA's and not to any other vendors.

>From  http://www.xilinx.com/support/documentation/white_papers/wp248.pdf :

Use of Synchronous Sets/Resets
If a set or reset is necessary for the proper operation of the circuit, a
synchronous reset
should always be coded. Synchronous sets/resets not only have improved
timing
characteristics and stability but can also result in smaller, better
utilization within the
FPGA. Synchronous sets/resets can result in less logic (fewer LUTs), fewer
restrictions on packing, and, often, faster circuits.

Hans
www.ht-lab.com




>
> thanks
>
> Chris
>




Article: 131393
Subject: Re: attached a 2nd peripheral to FSL bus. how to use it in software?
From: "Göran Bilski" <goran.bilski@xilinx.com>
Date: Mon, 21 Apr 2008 10:57:44 +0200
Links: << >>  << T >>  << A >>
Hi,

SFSL0 and MFSL0 has the same ID which is 0.

What version of EDK are you using?

Göran

<chrisdekoh@gmail.com> wrote in message 
news:2a8aade4-dfe3-4ddc-846c-fb6900ef3c6f@a23g2000hsc.googlegroups.com...
> Hi,
>   does anyone know how to use a 2nd FSL peripheral attached to
> microblaze? This is what I did. I have attached 2 peripherals, let's
> say we call it peripheral1 and peripheral2 to the microblaze's FSL
> bus.
>
> now here comes the problem. Using the commands
> putfsl(val,0) and getfsl(val,1), I am able to write and read from
> peripheral 1 respectively.
>
> However, when I do
> putfsl(val,2) and getfsl(val,3), nothing happens from peripheral2; I
> thought i was supposed to write and read from peripheral 2
> respectively by these commands.
>
> I have been struggling with this for a while...any of your inputs
> would really be great. :D
>
>
>
> --- excerpt from system.mhs file
>
>
> BEGIN microblaze
> PARAMETER INSTANCE = microblaze_0
> PARAMETER HW_VER = 4.00.a
> PARAMETER C_DEBUG_ENABLED = 1
> PARAMETER C_NUMBER_OF_PC_BRK = 2
> PARAMETER C_NUMBER_OF_RD_ADDR_BRK = 1
> PARAMETER C_NUMBER_OF_WR_ADDR_BRK = 1
> PARAMETER C_FSL_LINKS = 2
> PARAMETER C_USE_FPU = 1
> BUS_INTERFACE DLMB = dlmb
> BUS_INTERFACE ILMB = ilmb
> BUS_INTERFACE DOPB = mb_opb
> BUS_INTERFACE IOPB = mb_opb
> BUS_INTERFACE SFSL0 = peripheral1_to_microblaze_0  ## IS THE ID 1?
> BUS_INTERFACE MFSL0 = microblaze_0_to_peripheral1 ## IS THE ID 0?
> BUS_INTERFACE SFSL1 = peripheral2_0_to_microblaze_0 ## IS THE ID 3?
> BUS_INTERFACE MFSL1 = microblaze_0_to_peripheral2    ## IS THE ID 2?
> PORT CLK = sys_clk_s
> PORT DBG_CAPTURE = DBG_CAPTURE_s
> PORT DBG_CLK = DBG_CLK_s
> PORT DBG_REG_EN = DBG_REG_EN_s
> PORT DBG_TDI = DBG_TDI_s
> PORT DBG_TDO = DBG_TDO_s
> PORT DBG_UPDATE = DBG_UPDATE_s
> END
>
>
> otherwise, how to determine the corresponding ID of the FSL
> peripherals? I have looked through fsl_v20.pdf but dun see anything
> useful.
>
> thanks a million!
> Chris 



Article: 131394
Subject: ANNOUNCE: Maia 0.8.2: module-level HDL verification tool
From: Evan Lavelle <nospam@nospam.com>
Date: Mon, 21 Apr 2008 10:11:20 +0100
Links: << >>  << T >>  << A >>
Maia is a new tool which automatically creates HDL(*) testbenches from
a vector-style description. The trivial test case below, for example,
is a complete testbench for a 4-bit up-counter with reset.

The tool compiles a test vector file into HDL output, runs the output
and the module sources on a specified simulator, and reports the
results, together with details of any failures. You don't need to know
or write *any* HDL code to use Maia; if you can write vectors for your
module, then you can verify it.

You can download a free compiler and documentation from maia-eda.net.

(*) Apologies to VHDL'ers; 0.8.2 only creates Verilog output. I hope
to have VHDL output before too long.

// ------------------------------------------------------------
// trivial complete testbench example: 4-bit counter with reset
DUT {
  module counter(input CLK, RST; output [3:0] Q)
  create_clock CLK         // define the clock
  [CLK, RST] -> [Q]        // define the test vector format
}
main() {
  [.C, 1] -> [0];          // reset
  for(i=1; i <= 16; i++)
    [.C, 0] -> [i];        // count, with rollover
}

Article: 131395
Subject: XmdStub fails when connecting via JTAG.
From: Pablo <pbantunez@gmail.com>
Date: Mon, 21 Apr 2008 02:14:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I would like to know if anyone has received this message when he
tries to start XMD.

This message appears some times and I have to close Xmd Windows and
start again so the message doesn't appear. I use Xilinx Parallel IV
Cable and version 8.2 for EDK.

Thanks.



PowerPC405(1) : ppc405_0
Address Map for Processor ppc405_0
  (0x00000000-0x01ffffff) opb_ddr_0     plb->plb2opb->opb
  (0x41200000-0x4120ffff) opb_intc_0    plb->plb2opb->opb
  (0x41400000-0x4140ffff) opb_mdm_0     plb->plb2opb->opb
  (0x41c00000-0x41c0ffff) opb_timer_1   plb->plb2opb->opb
  (0xfffe0000-0xffffffff) plb_bram_if_cntlr_1   plb

PowerPC405(2) : ppc405_1
Address Map for Processor ppc405_1

Connecting to cable (Parallel Port - LPT1).
Checking cable driver.
 Driver windrvr6.sys version = 8.1.1.0. LPT base address = 0378h.
 ECP base address = 0778h.
 ECP hardware is detected.
Cable connection established.
Connecting to cable (Parallel Port - LPT1) in ECP mode.
Checking cable driver.
 Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h.
-------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------
 DeviceIoControl LPT_READ_BUFFER Failed.
Loopback test failed. Sent character = 7F, Received character = FF.
The hardware may be malfunctioning or the BIOS setting for the
Parallel port is
not set to ECP mode.
Cable connection failed.
-------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------
Connecting to cable (Parallel Port - LPT1).
Checking cable driver.
 Driver windrvr6.sys version = 8.1.1.0. LPT base address = 0378h.
 ECP base address = 0778h.
Cable connection established.
ECP port test failed. Using download cable in compatibility mode.
INFO:MDT - Assumption: Selected Device 1 for debugging.

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       0127e093          14        XC2VP30

XMD: Connected to PowerPC target. Processor Version No : 0x200108a0
Address mapping for accessing special PowerPC features from XMD/GDB:
    I-Cache (Data)  :  Disabled
    I-Cache (Tag)   :  Disabled
    D-Cache (Data)  :  Disabled
    D-Cache (Tag)   :  Disabled
    ISOCM           :  Disabled
    TLB             :  Disabled
    DCR             :  Disabled

Connected to "ppc" target. id = 0
Starting GDB server for "ppc" target (id = 0) at TCP port no 1234
XMD%

Article: 131396
Subject: Re: synchronous reset problems on FPGA
From: Lars <noreply.larthe@gmail.com>
Date: Mon, 21 Apr 2008 02:34:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 21 Apr, 06:40, chrisde...@gmail.com wrote:
> Hi Peter,
> =A0 =A0 I understand exactly what you are saying. Unfortunately I am just
> patching cores together. As mentioned, what I get is an ngc file which
> I do not have any control of the core.
>
> Chris

There is an obvious answer that nobody seems to have mentioned: Use
the "LOCKED" signal from the DCM as reset to the logic that is clocked
by the clock from the DCM. I am not quite sure about the numbers, but
there ought to be at least one clock edge from the DCM before that
goes active. If you need more clock edges, delay the "LOCKED" signal
in a shift register (one SLR16 will give you 16 clock cycles delay
from just one LUT).

Hope this helps!

/Lars

Article: 131397
Subject: OPB_MDM functionality
From: Pablo <pbantunez@gmail.com>
Date: Mon, 21 Apr 2008 03:44:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi, this is my question:

Is opb_mdm used to load C code (from executable.elf) from SDRAM?. I
have downloaded an aplication (executable.elf) to the Sdram. Due to
the fault of a RS232 peripheral, I use opb_mdm as uart. This design
seems to work fine with xil_printf and standalone powerpc, but it
fails when I use printf or xilkernel. I have increased heap and stack,
but problem goes on. So I am thinking that it could be a interference
in opb_mdm functionality.

Could anyone tell me if it is possible?.

Regards

Article: 131398
Subject: Re: How to instantiate macro in verilog
From: Jim Wu <jimwu88NOOOSPAM@yahoo.com>
Date: Mon, 21 Apr 2008 03:45:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 12:15 pm, "Haile Yu (Harry)" <h...@cse.cuhk.edu.hk> wrote:
> Dear all,
>
> I've designed a macro, and put "ring.nmc" file in my project dir.
> In my verilog module file, I wrote
> ...
> ring r1(.en(en),.ro(ro));
> ...
> to instantiate ring macro, but failed.
>
> Any one could give some hint?
>
> Thank you!

Can you copy the exact error message here? That may give some hint?

Cheers,
Jim
http://home.comcast.net/%7Ejimwu88/tools/

Article: 131399
Subject: Re: Xilinx DDR2 Interface
From: Jim Wu <jimwu88NOOOSPAM@yahoo.com>
Date: Mon, 21 Apr 2008 03:47:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 18, 11:32 pm, b...@hometoolong.inv wrote:
> I used the latest version of MIG to generate pinouts for a Virtex 4
> DDR2 interface. In addition to all the usual Address, Data, and
> Control I/Os, MIG assigned an I/O pin for a signal called
> SYS_RESET_IN_N.  What is the function of this pin?

At the risk of stating the obvious, it is a reset pin.

Cheers,
Jim
http://home.comcast.net/%7Ejimwu88/tools/





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