signal change not detected

Discussion in 'VHDL' started by koyel.aphy@gmail.com, Aug 25, 2008.

  1. Guest

    Following is the code... Though in the process "process_count", I have
    the signal "count" in the sensitivity list, reset1 is not going to '0'
    after the desired count value as is given below in the code. What is
    the problem? I am using modelsim.


    library ieee;
    use ieee.std_logic_1164.all;
    use ieee.std_logic_unsigned.all;
    use ieee.numeric_std.all;
    use work.myram1024.all;
    entity acmdat is
    port(clk: in std_logic;
    reset: in std_logic;
    indexin : out std_logic_vector(ADDRESS_WIDTH - 1 downto 0);
    xr,yr,xi,yi : out std_logic_vector(21 downto 0):=(others=>'0'));
    end acmdat;
    architecture archi of acmdat is
    component acmadd
    port(clk,reset:in std_logic;
    q1: out std_logic_vector(9 downto 0):=(others=>'0'));
    end component;
    signal count : std_logic_vector(12 downto 0):=(others=>'0');
    signal reset1 : std_logic;
    begin
    process(clk,reset,count)
    begin
    if reset = '1' then
    if(clk'event and clk='1') then
    xr <= std_logic_vector(to_signed(2,22));
    xi <= std_logic_vector(to_signed(1,22));
    yr <= std_logic_vector(to_signed(1,22));
    yi <= std_logic_vector(to_signed(2,22));
    count<= count + "0000000000001";
    end if;
    end if;
    end process;
    u1: acmadd port map(clk,reset,indexin);
    process_count:process(count,clk,reset)
    begin
    reset1 <= reset;
    if count = "1000000000001"and(clk'event and clk='1') then
    reset1 <= '0';
    end if;
    ---end if;
    end process;
    end archi;

    The above module has one component and it's code is....

    use ieee.numeric_std.all;
    use ieee.std_logic_arith.all;
    use ieee.std_logic_unsigned.all;
    entity acmadd is
    port(clk,reset:in std_logic;
    q1: out std_logic_vector(9 downto 0):=(others=>'0'));
    end acmadd;
    architecture archi of acmadd is
    signal s1 : std_logic_vector(9 downto 0):=(others=>'0');
    signal count: std_logic_vector(9 downto 0):="0000000000";
    signal b: std_logic_vector(9 downto 0) :="0000000001";
    begin
    process_count: process(clk,reset)
    begin
    if(reset ='1') then
    if(clk'event and clk='1') then
    s1<= "0000000000";
    count<= (count+b);
    s1<= count;
    end if;
    end if;
    end process;
    q1<=s1;
    end archi;
    , Aug 25, 2008
    #1
    1. Advertising

  2. Guest

    process_count:process(count,clk,reset)
    begin
    reset1 <= reset;
    if count = "1000000000001"and(clk'event and clk='1') then
    reset1 <= '0';
    end if;
    ---end if;
    end process;

    The problem is I want the signal reset1 to be continuously low after
    the count "1000000000001" which is 4097. I found that it only goes to
    0 at the rising edge of clock pulse with the count 4097 and again goes
    high which is probably due to the reset1<=reset otherwise. Hence, I
    modifies the code as below

    process(count,clk,reset)
    begin
    if count < "1000000000001" then
    reset1 <= reset;
    elsif count >= "1000000000001"and(clk'event and clk='1') then
    reset1 <= '0';
    end if;
    ---end if;
    end process;

    that works fine in simulation but please let me know if these
    operators can be used in harware implementation or not?

    Best Regards
    , Aug 25, 2008
    #2
    1. Advertising

  3. Guest

    final code is

    process(count,clk,reset)
    begin
    if count < 4097 then
    reset1 <= reset;
    elsif count >= 4097 and(clk'event and clk='1') then
    reset1 <= '0';
    end if;
    ---end if;
    end process;

    I declared count as an integer with 0 initialization since the range
    for a 13 bit std_logic_vector is limited. It's just a data generator
    for one of my design modules which should stop after 4097th data. I am
    not going to implement it on harware but still the question about the
    > and < operator is not known to me.
    , Aug 25, 2008
    #3
  4. KJ Guest

    On Aug 25, 10:45 am, wrote:
    > process_count:process(count,clk,reset)
    > begin
    > reset1 <= reset;
    > if count = "1000000000001"and(clk'event and clk='1') then
    > reset1 <= '0';
    > end if;
    > ---end if;
    > end process;
    >
    > The problem is I want the signal reset1 to be continuously low after
    > the count "1000000000001" which is 4097. I found that it only goes to
    > 0 at the rising edge of clock pulse with the count 4097 and again goes
    > high which is probably due to the reset1<=reset otherwise. Hence, I
    > modifies the code as below
    >
    > process(count,clk,reset)
    > begin
    > if count < "1000000000001" then
    > reset1 <= reset;
    > elsif count >= "1000000000001"and(clk'event and clk='1') then
    > reset1 <= '0';
    > end if;
    > ---end if;
    > end process;
    >
    > that works fine in simulation but please let me know if these
    > operators can be used in harware implementation or not?
    >


    It likely won't reliably work in hardware. The problem is that signal
    'reset1' will be asynchronously set to the value of 'reset' when
    'count' hits the magic value. In order to implement this, the
    hardware would have to check all of the bits of count and use that to
    either asynchronously preset the flop for reset1 (if reset is '1') or
    asynchronously reset the flop for reset1 (if reset is '0').

    Consider rewriting your code a bit to be a straight synchronous
    process as shown below and don't use asynchronous inputs at all. By
    doing so you'll be avoiding a whole slew of "it works in sim, but not
    in hardware" types of problems.

    process(clk)
    begin
    if rising_edge(clk) then
    -- Put your logic here
    end if;
    end process;

    KJ
    KJ, Aug 25, 2008
    #4
  5. Guest

    Okay thank you very much for this information. I didn't know this. I
    will keep my inputs synchronous now onwards. But please let me know
    about the operators. Can we use them in hardware implementation. If
    yes, then why do we have comparators in the ip cores of the
    configuring softwares.

    Best Regards
    , Aug 25, 2008
    #5
  6. KJ Guest

    On Aug 25, 11:33 am, wrote:
    > I am
    > not going to implement it on harware but still the question about the
    > > and < operator is not known to me.

    >


    The > and < operators will synthesize just fine in hardware.

    As I mentioned in the other post though your use of async logic is
    pretty dicey when it comes to being implemented in hardware...although
    between your last two posts it's not clear if you want this in
    hardware or not (you've implied both 'yes' and 'no'). If it's not
    intended for hardware then whether or not hardware implements the
    operators is moot (but I answered it above anyway).

    KJ
    KJ, Aug 25, 2008
    #6
  7. KJ Guest

    On Aug 25, 11:46 am, wrote:
    > Okay thank you very much for this information. I didn't know this. I
    > will keep my inputs synchronous now onwards. But please let me know
    > about the operators. Can we use them in hardware implementation.


    Yes you can use the >, < and = operators to implement hardware.

    > If
    > yes, then why do we have comparators in the ip cores of the
    > configuring softwares.
    >


    I'm not sure which cores and software you're talking about but as a
    general statement I'd say that having different ways of doing things
    is a good thing.

    KJ
    KJ, Aug 25, 2008
    #7
  8. Guest

    > I'm not sure which cores and software you're talking about but as a
    > general statement I'd say that having different ways of doing things
    > is a good thing.


    for example xilinx.

    Thanks. No I do not want this particular design to be implemented in
    hardware. It's just for testing another block in simulation as this is
    simpler than writing a test bench and also saves from forcing inputs
    at each clock pulse when running the simulation. But at some point I
    will need a more appropriate data source to test the designs in
    hardware and then it is highly probable that I use the > and <
    operators. That is why it is also useful for me to know that the
    inputs must be synchronous.In my other codes, I didn't have to use
    asynchronous inputs so probably didn't get into this problem before.

    Thanks again.
    , Aug 26, 2008
    #8
    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. Michael Pronath
    Replies:
    1
    Views:
    1,158
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    462
    Jack Orenstein
    Sep 18, 2005
  3. Weng Tianxiang
    Replies:
    2
    Views:
    654
    Jonathan Bromley
    Jan 30, 2007
  4. Nicolas Moreau
    Replies:
    9
    Views:
    3,126
  5. dibacco73
    Replies:
    1
    Views:
    645
    joris
    Feb 12, 2009
Loading...

Share This Page