signal change not detected

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_countrocess(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;

process_countrocess(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

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.

On Aug 25, 10:45*am, koyel.a...@gmail.com wrote:
> process_countrocess(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

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

On Aug 25, 11:33*am, koyel.a...@gmail.com 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

On Aug 25, 11:46*am, koyel.a...@gmail.com 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

> 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.