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

Discussion in 'VHDL' started by sudha, Jan 3, 2005.

  1. sudha

    sudha Guest

    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, Jan 3, 2005
    #1
    1. Advertising

  2. sudha

    zinga Guest

    there is no max limit but the minimum should be greater than the frequency
    of pulses/unit time.
    zinga, Jan 4, 2005
    #2
    1. Advertising

  3. 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, Jan 4, 2005
    #3
  4. sudha

    sudha Guest

    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, Jan 10, 2005
    #4
  5. sudha

    sudha Guest

    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, Jan 10, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hamed
    Replies:
    3
    Views:
    3,309
    Richard Grimes [MVP]
    Feb 15, 2004
  2. sudha
    Replies:
    0
    Views:
    602
    sudha
    Jan 3, 2005
  3. adam8024
    Replies:
    0
    Views:
    737
    adam8024
    May 24, 2007
  4. Replies:
    9
    Views:
    811
    Mike Treseler
    May 26, 2007
  5. Zabin
    Replies:
    2
    Views:
    1,347
    Zabin
    Dec 20, 2009
Loading...

Share This Page