Trouble with rising edge signals in functional simulation

A

arkaitz

Guest
Hi,

I have a FF in my design whose reset and set are separate conditions:

process( rst, clk )
begin
if ( rst = '1' ) then
output <= '0';
elsif ( clk'event and clk = '1' ) then
if ( set = '1' ) then
output <= '1';
end if;
if ( reset = '1' ) then
output <= '0';
end if;
end if;
end process;

This works fine but now I want the reset condition to be a rising edge
detector signal, so:

process( rst, clk )
begin
if ( rst = '1' );
aux <= '0';
if ( clk'event and clk = '1' ) then
aux <= input;
end if;
end process;

reset <= not(aux) and input;

The "input" signal is synchronous to my design and periodical but its
period is about 16 times the clock period. When I execute the
functional simulationwith ModelSim SE 5.6f, the "reset" signal appears
as a glitch since the "input" and "aux" signals change their values in
the same clock edge.

Because of this, the "output" signal is never reseted.

I believe that the timing simulation may vary and the design could
work correctly because of the "clock to output" of the FFs, but I'n
not sure.

Any suggestions?

Thanks in advance,

Arkaitz.

---------------------------
Electronics Area
IKERLAN
Pş J. M. Arizmendiarrieta, 2
20500 Arrasate (Gipuzkoa)
---------------------------
 
"arkaitz" <arkagaz@yahoo.com> escribió en el mensaje
news:c1408b8c.0404200442.645ab522@posting.google.com...
Hi,

I have a FF in my design whose reset and set are separate conditions:

process( rst, clk )
begin
if ( rst = '1' ) then
output <= '0';
elsif ( clk'event and clk = '1' ) then
if ( set = '1' ) then
output <= '1';
end if;
if ( reset = '1' ) then
output <= '0';
end if;
end if;
end process;
you have two resets on the same FF?
one synchronous and another one asynchronous, but i guess you know that :)
what are you using "output" for?

This works fine but now I want the reset condition to be a rising edge
detector signal, so:

process( rst, clk )
begin
if ( rst = '1' );
aux <= '0';
if ( clk'event and clk = '1' ) then
aux <= input;
end if;
end process;

reset <= not(aux) and input;
so you want to reset the first FF on a rising edge of "input"?
then why dont you write the code like that then?


The "input" signal is synchronous to my design and periodical but its
period is about 16 times the clock period. When I execute the
functional simulationwith ModelSim SE 5.6f, the "reset" signal appears
as a glitch since the "input" and "aux" signals change their values in
the same clock edge.

Because of this, the "output" signal is never reseted.

I believe that the timing simulation may vary and the design could
work correctly because of the "clock to output" of the FFs, but I'n
not sure.

Any suggestions?
if you think it'd work in the reality because of the delays, you could use
"after" on the signal assignations.

you could also try using the asynchronous reset of the first FF

but still, i dont think i understand what you're trying to do

Thanks in advance,

Arkaitz.

---------------------------
Electronics Area
IKERLAN
Pş J. M. Arizmendiarrieta, 2
20500 Arrasate (Gipuzkoa)
---------------------------
 
arkagaz@yahoo.com (arkaitz) wrote in message news:<c1408b8c.0404200442.645ab522@posting.google.com>...
Hi,

I have a FF in my design whose reset and set are separate conditions:

process( rst, clk )
begin
if ( rst = '1' ) then
output <= '0';
elsif ( clk'event and clk = '1' ) then
if ( set = '1' ) then
output <= '1';
end if;
if ( reset = '1' ) then
output <= '0';
end if;
end if;
end process;
Ask yourself: "What happens when both set and reset are simultaneously
asserted?" You may have a problem here.

This works fine but now I want the reset condition to be a rising edge
detector signal, so:

process( rst, clk )
begin
if ( rst = '1' );
aux <= '0';
if ( clk'event and clk = '1' ) then
aux <= input;
end if;
end process;

reset <= not(aux) and input;

The "input" signal is synchronous to my design and periodical but its
period is about 16 times the clock period. When I execute the
functional simulationwith ModelSim SE 5.6f, the "reset" signal appears
as a glitch since the "input" and "aux" signals change their values in
the same clock edge.
I notice that the second process doesn't have "elsif (clk'event ...),"
rather, it's simply an "if" in parallel with the async reset. What
does the signal "aux" look like in your simulation?

Because of this, the "output" signal is never reseted.

I believe that the timing simulation may vary and the design could
work correctly because of the "clock to output" of the FFs, but I'n
not sure.
No, it looks like a coding error to me.

--a
 
Arkaitz,

Logic looks OK except I would have used elsif clause. I suspect
that your "input" signal, although synchronous, is external to
the block you're simulating. If so, assert it _in_the_simulation_
on a falling clock edge. Think of it this way. Label the rising
edges T=0,1,2,3. Then if input goes high on clk T=2, it really
goes high "a little while after" T=2 but well before T=3 (we hope!
but timing is outside the scope of functional simulation). So
by asserting it at T=2.5 (ie falling edge) you're telling the
simulator that "input" was low at T=2 but high at T=3... which is
(hopefully) what you want. I found it confusing at first but
got used to it after a while. Other people may think of it
differently and perhaps more elegantly.

Hope this helps,
-rajeev-
---------------
arkagaz@yahoo.com (arkaitz) wrote in message news:<c1408b8c.0404200442.645ab522@posting.google.com>...
Hi,

I have a FF in my design whose reset and set are separate conditions:

process( rst, clk )
begin
if ( rst = '1' ) then
output <= '0';
elsif ( clk'event and clk = '1' ) then
if ( set = '1' ) then
output <= '1';
end if;
if ( reset = '1' ) then
output <= '0';
end if;
end if;
end process;

This works fine but now I want the reset condition to be a rising edge
detector signal, so:

process( rst, clk )
begin
if ( rst = '1' );
aux <= '0';
if ( clk'event and clk = '1' ) then
aux <= input;
end if;
end process;

reset <= not(aux) and input;

The "input" signal is synchronous to my design and periodical but its
period is about 16 times the clock period. When I execute the
functional simulationwith ModelSim SE 5.6f, the "reset" signal appears
as a glitch since the "input" and "aux" signals change their values in
the same clock edge.

Because of this, the "output" signal is never reseted.

I believe that the timing simulation may vary and the design could
work correctly because of the "clock to output" of the FFs, but I'n
not sure.

Any suggestions?

Thanks in advance,

Arkaitz.

---------------------------
Electronics Area
IKERLAN
Pş J. M. Arizmendiarrieta, 2
20500 Arrasate (Gipuzkoa)
---------------------------
 
Hi,

Sorry. Was my fault when typewriting; I also use "elsif" clause in the
second process instead of "if" clause.


Logic looks OK except I would have used elsif clause. I suspect
that your "input" signal, although synchronous, is external to
the block you're simulating.
Yes, the input signal is external to my block, it's a clock divider
output and 3 clock period wide.

If so, assert it _in_the_simulation_
on a falling clock edge. Think of it this way. Label the rising
edges T=0,1,2,3. Then if input goes high on clk T=2, it really
goes high "a little while after" T=2 but well before T=3 (we hope!
but timing is outside the scope of functional simulation). So
by asserting it at T=2.5 (ie falling edge) you're telling the
simulator that "input" was low at T=2 but high at T=3... which is
(hopefully) what you want. I found it confusing at first but
got used to it after a while.
It could be a solution; I'll try it. But I cannot see why doesn't my
design work. I have created another design where the input signal is
an input port instead of an output of an internal register. I have
simulated it functionally changing the input value from 0 to 1
together with a rising edge of the clock. As in the other case a
glitch is appeared in the functional simulation but now the design
works and the FF is reseted.

I cannot see why ModelSim works fine with an input port and not with
the output of an internal FF.

Thanks in advance,

Arkaitz.

---------------------------
Electronics Area
IKERLAN
Pş J. M. Arizmendiarrieta, 2
20500 Arrasate (Gipuzkoa)
---------------------------
 
arkagaz@yahoo.com (arkaitz) wrote in message news:<c1408b8c.0404202314.7f0c710e@posting.google.com>...
Hi,

Sorry. Was my fault when typewriting; I also use "elsif" clause in the
second process instead of "if" clause.


Logic looks OK except I would have used elsif clause. I suspect
that your "input" signal, although synchronous, is external to
the block you're simulating.

Yes, the input signal is external to my block, it's a clock divider
output and 3 clock period wide.

If so, assert it _in_the_simulation_
on a falling clock edge. Think of it this way. Label the rising
edges T=0,1,2,3. Then if input goes high on clk T=2, it really
goes high "a little while after" T=2 but well before T=3 (we hope!
but timing is outside the scope of functional simulation). So
by asserting it at T=2.5 (ie falling edge) you're telling the
simulator that "input" was low at T=2 but high at T=3... which is
(hopefully) what you want. I found it confusing at first but
got used to it after a while.

It could be a solution; I'll try it. But I cannot see why doesn't my
design work. I have created another design where the input signal is
an input port instead of an output of an internal register. I have
simulated it functionally changing the input value from 0 to 1
together with a rising edge of the clock. As in the other case a
glitch is appeared in the functional simulation but now the design
works and the FF is reseted.

I cannot see why ModelSim works fine with an input port and not with
the output of an internal FF.
Back to your code:

I have a FF in my design whose reset and set are separate conditions:

process( rst, clk )
begin
if ( rst = '1' ) then
output <= '0';
elsif ( clk'event and clk = '1' ) then
if ( set = '1' ) then
output <= '1';
end if;
if ( reset = '1' ) then
output <= '0';
end if;
end if;
end process;
I re-iterate again: Ask yourself: "What happens when both set and
reset are simultaneously
asserted?" You may have a problem here.

Does your simulation drive both set and reset at the same time?

--a
 
Hi Andy,

I re-iterate again: Ask yourself: "What happens when both set and
reset are simultaneously
asserted?" You may have a problem here.

Does your simulation drive both set and reset at the same time?

No, firstly is driven the set signal and later (after some clk periods
the reset signal). I now what I am doing when writing like this; in my
design the reset has more priority than the set signal.

Thanks,

Arkaitz.
 
"arkaitz" <arkagaz@yahoo.com> escribió en el mensaje
news:c1408b8c.0404212258.1d6531ef@posting.google.com...
Hi Andy,

I re-iterate again: Ask yourself: "What happens when both set and
reset are simultaneously
asserted?" You may have a problem here.

Does your simulation drive both set and reset at the same time?


No, firstly is driven the set signal and later (after some clk periods
the reset signal). I now what I am doing when writing like this; in my
design the reset has more priority than the set signal.

Thanks,

Arkaitz.

in that case wouldnt be the reset "if" before the set "if"?
 

Welcome to EDABoard.com

Sponsor

Back
Top