Re: CAN WE HAVE SIGNALS WITH MULTIPLE SOURCES IN VHDL?

Hi

I wish you all a very happy and prosperous new year-2005.

I need one help from you regarding quadrature encoder.

we are using linear optical incremental encoder
(HEDS-9200 Q00) which gives 180 pulses/inch in my project.

i am implementing the the decoder/counter in my existing ACTEL FPGA
along with some other functinality.

can you please suggest me what should be the suggested minimim/maximum
clock freuency required to do so?


regards,

S.RANGA REDDY

Ray Andraka wrote:
> You might do this as a single process. It would also be easier if
you made this synchronous. You need a
> storage element to resolve the direction, which you have done with a
pair of counters. The direction
> cannot be determined just by the current inputs, you need to know
what they were before the latest change
> too. Normally a quadrature resolver uses a decoder circuit that then
drives a single up-down counter.
> The following code should give you the idea. I've shortened
angle_ch_A to ain and same with b to save my
> fingers. I just typed the code here, so I make no guarantees that
it'll compile without error. ain,
> bin, index are the inputs from the encoder.
>
>
> process(clk)
> variable dir: std_logic_vector(1 downto 0)="00";
> variable aold,bold: std_logic;
> begin
> if index = '1' then
> angle<= (others=> '0');
> else
> if clk'event and clk='1' then
> dir := (ain xor aold) & (bin xor bold);
> aold:=ain;
> bold:=bin;
> case dir is
> when "00" => --no change
> moved <= 0; --leave cw output alone
> when "01" => -- clockwise rotation
> angle <= angle +1;
> moved <= 1;
> cw <= 1;
> when "10" => --ccw rotation
> angle <= angle - 1;
> moved <= 1;
> cw <= 0;
> when "11" => -- this is an error condition...either a
bad sensor or rotation is faster than
> clock
> end case;
> end if;
> end if;
> end process;
>
>
>
>
> Asher C. Martin wrote:
>
> > Greetings,
> >
> > My name is Asher and I am working on some VHDL code to control an
> > optical encoder (HEDS-9100) that will measure the angle that a
device
> > has rotated.
> >
> > Anyhow, I wanted to know how to drive a signal with multiple
sources in
> > VHDL. Here are some technical details. I have two different
processes
> > one called "grab_ch_A_data: PROCESS (angle_ch_A)" that triggers on
the
> > EVENT that angle_ch_A changes and the other "grab_ch_B_data:
PROCESS
> > (angle_ch_B)" triggers on the event that angle_ch_B changes.
> >
> > Inside the first process I am keeping track of whether or not the
device
> > is rotating clockwise or counter clockwise. KEY POINT: I have this
> > variable called "clockwise" in both processes and they both should
be
> > able to set "clockwise" to the direction of rotation. The
direction
> > depends on the current state of the input signals.
> >
> > Could someone please help me out? I would really appreciate it.
> >
> > (SEE ATTACHED CODE)
> >
> > Best regards,
> >
> > >Asher<
> >
> > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
> > Asher C. Martin
> > 805 West Oregon Street
> > Urbana, IL 61801-3825
> > (217) 367-3877
> > E-MAIL:
> > http://fermi.isdn.uiuc.edu
> > telnet://fermi.isdn.uiuc.edu
> > ftp://feynman.isdn.uiuc.edu
> > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
> >
> >
------------------------------------------------------------------------
> > -- Asher C. Martin
> > -- Robotics and Computer Vision Lab
> >
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.all;
> > USE ieee.std_logic_arith.all;
> >
> > ENTITY angle IS
> >
> > PORT
> > (
> > angle_ch_A : IN STD_LOGIC; --
CHANNEL A FROM OPTICAL ENCODER
> > angle_ch_B : IN STD_LOGIC; --
CHANNEL B FROM OPTICAL ENCODER
> > angle_ch_I : IN STD_LOGIC; --
CHANNEL I (HIGH WHEN 360 DEG.)
> > reset_switch : IN STD_LOGIC; -- IF ANGLE
GETS OFFSET THEN RESET THIS LINE
> > output_a : OUT INTEGER RANGE 0 TO
255; --STD_LOGIC_VECTOR(7 downto 0)
> > output_b : OUT INTEGER RANGE 0 TO
255; --STD_LOGIC_VECTOR(7 downto 0)
> > clockwise : INOUT STD_LOGIC
> > );
> >
> > END angle;
> >
> > ARCHITECTURE angle_architecture OF angle IS
> >
> > SIGNAL a_counter : INTEGER RANGE 0 TO 255;
> > SIGNAL b_counter : INTEGER RANGE 0 TO 255;
> >
> > BEGIN
> >
> > -- THE FOLLOWING FIGURES OUT IF THE USER IS MOVING LEFT OR RIGHT
> > --direction: PROCESS ()
> > -- BEGIN
> >
> > --END PROCESS direction;
> >
> > -- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
> > grab_ch_A_data: PROCESS (angle_ch_A)
> > BEGIN
> >
> > IF reset_switch = '0' THEN -- FOR TESTING WITH THE
PB_1 MAKE THIS ZERO FOR RESET
> >
> > a_counter <= 0;
> >
> > ELSIF (angle_ch_A'EVENT AND angle_ch_A = '1') THEN
> >
> > a_counter <= a_counter + 1;
> >
> > ELSE
> >
> > a_counter <= a_counter;
> >
> > END IF;
> >
> > -- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER
CLOCKWISE
> > IF (angle_ch_A = '1' AND angle_ch_B = '0')
THEN
> >
> > clockwise <= '1';
> >
> > ELSE
> >
> > clockwise <= clockwise;
> >
> > END IF;
> >
> > END PROCESS grab_ch_A_data;
> >
> > -- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
> > grab_ch_B_data: PROCESS (angle_ch_B)
> > BEGIN
> >
> > IF reset_switch = '0' THEN -- W/ B_1 MAKE '0'
OTHERWISE KEEP '1'
> >
> > b_counter <= 0;
> >
> > ELSIF (angle_ch_B'EVENT AND angle_ch_B = '1') THEN
> >
> > b_counter <= b_counter + 1;
> >
> > ELSE
> >
> > b_counter <= b_counter;
> >
> > END IF;
> >
> > -- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER
CLOCKWISE
> > IF (angle_ch_A = '0' AND angle_ch_B = '1')
THEN
> >
> > clockwise <= '0';
> >
> > ELSE
> >
> > clockwise <= clockwise;
> >
> > END IF;
> >
> > END PROCESS grab_ch_B_data;
> >
> > -- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT"
> > output_a <= a_counter;
> > output_b <= b_counter;
> >
> > END angle_architecture;
>
>
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email
> http://users.ids.net/~randraka

sudha

there is no max limit but the minimum should be greater than the frequency
of pulses/unit time.

zinga

On 3 Jan 2005 00:38:08 -0800, "sudha" <> wrote:

>Hi
>
>I wish you all a very happy and prosperous new year-2005.
>
>I need one help from you regarding quadrature encoder.
>
>we are using linear optical incremental encoder
>(HEDS-9200 Q00) which gives 180 pulses/inch in my project.
>
>i am implementing the the decoder/counter in my existing ACTEL FPGA
>along with some other functinality.
>
>can you please suggest me what should be the suggested minimim/maximum
>clock freuency required to do so?

180 pulses per inch, but how many inches per second?

Obviously the system clock period must be shorter than the minimum
expected time between encoder transitions. However, you will
certainly want to oversample the encoders - partly to deal with
any metastability issues in the input flip-flops, but mainly
because you should have some kind of glitch filter on the
inputs. I would suggest that 4x oversampling is the minimum.

When you say 180 pulses per inch, do you mean 180 transitions
per inch or 180 cycles per inch? Each complete cycle of the
encoder will give 4 transitions. Be sure to get this right.

For some applications it may be more interesting to know the
time of occurrence of encoder transitions. In this situation
you will need a much larger oversampling factor.

Finally, don't forget that various factors can cause jitter
or asymmetry in the encoder pulses. This can have the effect
of shortening the time between some transitions by a factor
of 2 or more, so that you need a higher clock frequency to
get reliable oversampling. A really smart encoder processor
can "learn" about this asymmetry, giving significantly
better accuracy for velocity measurements.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Hi

Thanks for ur reply.

these are my answers to your queries.

1.180 pulses per inch, but how many inches per second?

** count frequency : 100 Khz

2.Obviously the system clock period must be shorter than the
minimum expected time between encoder transitions. However,
you will certainly want to oversample the encoders - partly
to deal with any metastability issues in the input flip-
flops, but mainly because you should have some kind of
glitch filter on the inputs. I would suggest that 4x
oversampling is the minimum.

** since my count frequency is 100Khz i will get 2.5us as a
transition period. so my system clock period should be less
than 2.5us. so i decided to take a clock of >= 500Khz. please
correct me if i am wrong.

3.When you say 180 pulses per inch, do you mean 180 transitions
per inch or 180 cycles per inch?

** 180 cycles per inch.

right now i feel that single transition per cycle is sufficient for our
application. But we are giving the provision to have 2 or 4 transitions
per cycles also, if we need in future

iam even implementing the glitch filter at the input of the decoder to
avoid the spikes/Glitches on the quadrature inputs.

4.> Finally, don't forget that various factors can cause jitter
> or asymmetry in the encoder pulses. This can have the effect
> of shortening the time between some transitions by a factor
> of 2 or more, so that you need a higher clock frequency to
> get reliable oversampling. A really smart encoder processor
> can "learn" about this asymmetry, giving significantly
> better accuracy for velocity measurements.

do you think the implementation of digital filter can avoid this kind
of jitter or assymetry?

please reply me..

regards,

S.RANGA REDDY

Jonathan Bromley wrote:
> On 3 Jan 2005 00:38:08 -0800, "sudha" <>
wrote:
>
> >Hi
> >
> >I wish you all a very happy and prosperous new year-2005.
> >
> >I need one help from you regarding quadrature encoder.
> >
> >we are using linear optical incremental encoder
> >(HEDS-9200 Q00) which gives 180 pulses/inch in my project.
> >
> >i am implementing the the decoder/counter in my existing ACTEL FPGA
> >along with some other functinality.
> >
> >can you please suggest me what should be the suggested
minimim/maximum
> >clock freuency required to do so?
>
> 180 pulses per inch, but how many inches per second?
>
> Obviously the system clock period must be shorter than the minimum
> expected time between encoder transitions. However, you will
> certainly want to oversample the encoders - partly to deal with
> any metastability issues in the input flip-flops, but mainly
> because you should have some kind of glitch filter on the
> inputs. I would suggest that 4x oversampling is the minimum.
>
> When you say 180 pulses per inch, do you mean 180 transitions
> per inch or 180 cycles per inch? Each complete cycle of the
> encoder will give 4 transitions. Be sure to get this right.
>
> For some applications it may be more interesting to know the
> time of occurrence of encoder transitions. In this situation
> you will need a much larger oversampling factor.
>
> Finally, don't forget that various factors can cause jitter
> or asymmetry in the encoder pulses. This can have the effect
> of shortening the time between some transitions by a factor
> of 2 or more, so that you need a higher clock frequency to
> get reliable oversampling. A really smart encoder processor
> can "learn" about this asymmetry, giving significantly
> better accuracy for velocity measurements.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail:
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

sudha

Hi

Thanks for ur reply.

these are my answers to your queries.

1.180 pulses per inch, but how many inches per second?

** count frequency : 100 Khz

2.Obviously the system clock period must be shorter than the
minimum expected time between encoder transitions. However,
you will certainly want to oversample the encoders - partly
to deal with any metastability issues in the input flip-
flops, but mainly because you should have some kind of
glitch filter on the inputs. I would suggest that 4x
oversampling is the minimum.

** since my count frequency is 100Khz i will get 2.5us as a
transition period. so my system clock period should be less
than 2.5us. so i decided to take a clock of >= 500Khz. please
correct me if i am wrong.

3.When you say 180 pulses per inch, do you mean 180 transitions
per inch or 180 cycles per inch?

** 180 cycles per inch.

right now i feel that single transition per cycle is sufficient for our
application. But we are giving the provision to have 2 or 4 transitions
per cycles also, if we need in future

iam even implementing the glitch filter at the input of the decoder to
avoid the spikes/Glitches on the quadrature inputs.

4.> Finally, don't forget that various factors can cause jitter
> or asymmetry in the encoder pulses. This can have the effect
> of shortening the time between some transitions by a factor
> of 2 or more, so that you need a higher clock frequency to
> get reliable oversampling. A really smart encoder processor
> can "learn" about this asymmetry, giving significantly
> better accuracy for velocity measurements.

do you think the implementation of digital filter can avoid this kind
of jitter or assymetry?

please reply me..

regards,

S.RANGA REDDY

Jonathan Bromley wrote:
> On 3 Jan 2005 00:38:08 -0800, "sudha" <>
wrote:
>
> >Hi
> >
> >I wish you all a very happy and prosperous new year-2005.
> >
> >I need one help from you regarding quadrature encoder.
> >
> >we are using linear optical incremental encoder
> >(HEDS-9200 Q00) which gives 180 pulses/inch in my project.
> >
> >i am implementing the the decoder/counter in my existing ACTEL FPGA
> >along with some other functinality.
> >
> >can you please suggest me what should be the suggested
minimim/maximum
> >clock freuency required to do so?
>
> 180 pulses per inch, but how many inches per second?
>
> Obviously the system clock period must be shorter than the minimum
> expected time between encoder transitions. However, you will
> certainly want to oversample the encoders - partly to deal with
> any metastability issues in the input flip-flops, but mainly
> because you should have some kind of glitch filter on the
> inputs. I would suggest that 4x oversampling is the minimum.
>
> When you say 180 pulses per inch, do you mean 180 transitions
> per inch or 180 cycles per inch? Each complete cycle of the
> encoder will give 4 transitions. Be sure to get this right.
>
> For some applications it may be more interesting to know the
> time of occurrence of encoder transitions. In this situation
> you will need a much larger oversampling factor.
>
> Finally, don't forget that various factors can cause jitter
> or asymmetry in the encoder pulses. This can have the effect
> of shortening the time between some transitions by a factor
> of 2 or more, so that you need a higher clock frequency to
> get reliable oversampling. A really smart encoder processor
> can "learn" about this asymmetry, giving significantly
> better accuracy for velocity measurements.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail:
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

sudha