asynchronous reset, simulator doesn't support

Hello there,

Here is a challenge for all of us.

I have a simulator (proof from alliance) that doesn't support
asynchronous reset. Alliance can work with using only one clock (and
not any synchronous set or reset).

Nevertheless I want to simulation asynchronous reset dff from its
behavioral description.

What would you recommend me to change in my .vhd file in terms of
asynchronous reset ?


-- D flip flop with asynchronous reset
library IEEE;
use IEEE.std_logic_1164.all;

entity dff_asynchrone is
port (
data, re_set, cp : IN std_logic ;
q : OUT std_logic
);
end dff_asynchrone;

architecture behave of dff_asynchrone is
begin
process(cp,re_set)
begin
if re_set = '0' then
q <= '0';
elsif (cp='1' and cp'event) then
q <= data;
end if;
end process;
end behave;

Clunixchit

"Clunixchit" <> wrote in message
news: ps.com...
> Hello there,
>
> Here is a challenge for all of us.
>
> I have a simulator (proof from alliance) that doesn't support
> asynchronous reset. Alliance can work with using only one clock (and
> not any synchronous set or reset).
>
> Nevertheless I want to simulation asynchronous reset dff from its
> behavioral description.
>
> What would you recommend me to change in my .vhd file in terms of
> asynchronous reset ?

I'd recommend keeping the .vhd file and changing your simulator. For a
simulator to 'not support asynchronous resets' really means that it doesn't
support 'if/elsif/end if' VHDL statements. Why waste time with such a tool?

KJ

KJ

It may be the target device, some devices do not support asynchronous
reset..


"Clunixchit" <> wrote in message
news: ps.com...
> Hello there,
>
> Here is a challenge for all of us.
>
> I have a simulator (proof from alliance) that doesn't support
> asynchronous reset. Alliance can work with using only one clock (and
> not any synchronous set or reset).
>
> Nevertheless I want to simulation asynchronous reset dff from its
> behavioral description.
>
> What would you recommend me to change in my .vhd file in terms of
> asynchronous reset ?
>
>
> -- D flip flop with asynchronous reset
> library IEEE;
> use IEEE.std_logic_1164.all;
>
> entity dff_asynchrone is
> port (
> data, re_set, cp : IN std_logic ;
> q : OUT std_logic
> );
> end dff_asynchrone;
>
> architecture behave of dff_asynchrone is
> begin
> process(cp,re_set)
> begin
> if re_set = '0' then
> q <= '0';
> elsif (cp='1' and cp'event) then
> q <= data;
> end if;
> end process;
> end behave;
>

David Binnie

On Sep 2, 10:22 pm, "KJ" wrote:
> I'd recommend keeping the .vhd file and changing your simulator. For a
> simulator to 'not support asynchronous resets' really means that it doesn't
> support 'if/elsif/end if' VHDL statements. Why waste time with such a tool?
>
> KJ

I've modelsim and ghdl at my disposal as alternative simulation tools.
However it does support 'if/elsif/end if' VHDL statements, but not
asynchronous reset. The counter (see code below) does simulate
successfully.

My question wasn't about time, but about possible ways of coding
asynchronous reset.


entity count1 is
port ( clk, clear : in bit;
qc : out integer range 0 to 255
);
end count1;

architecture behavioral of count1 is
begin
process (clk)
variable cnt : integer range 0 to 255;
begin
if (clk'EVENT and clk= '1') then
if clear = '0' then
cnt := 0;
else
cnt := cnt +1;
end if;
end if;
qc <= cnt;
end process;
end behavioral;

Clunixchit

"Clunixchit" <> wrote in message
news: ups.com...
> On Sep 2, 10:22 pm, "KJ" wrote:
>> I'd recommend keeping the .vhd file and changing your simulator. For a
>> simulator to 'not support asynchronous resets' really means that it
>> doesn't
>> support 'if/elsif/end if' VHDL statements. Why waste time with such a
>> tool?
>>
>> KJ
>
> I've modelsim and ghdl at my disposal as alternative simulation tools.
> However it does support 'if/elsif/end if' VHDL statements, but not
> asynchronous reset.

Both of those tools do support 'asynchronous reset' (aka if/elsif/end if)

> The counter (see code below) does simulate
> successfully.
>
> My question wasn't about time, but about possible ways of coding
> asynchronous reset.
>

Your original post (entity dff_asynchrone) is one correct way of coding an
asynchronous reset. Why do you think it.they do not simulate correctly?

KJ

KJ

On Sep 3, 4:05 pm, "KJ" wrote:

> Both of those tools do support 'asynchronous reset' (aka if/elsif/end if)
I was referring to alliance here. it doesn't support 'asynchronous
reset'. but it does support the counter (see code in previous emails)


> Your original post (entity dff_asynchrone) is one correct way of coding an
> asynchronous reset. Why do you think it.they do not simulate correctly?

Again I meant alliance doesn't simulate correctly. Modelsim and ghdl
works.
It fails with:
Compiling 'dff_asynchrone' ...
VHDL : Error - bad usage of the 'stable' attribut
*** Compilation aborted...
make: *** [PROOF] Error 255

By referring Modelsim and ghdl above, I meant that I can use either
Modelsim or ghdl for my simulations. But it's curiosity on for
alliance that drove me to start this topic here.

regards,
Chitlesh

Clunixchit

"Clunixchit" <> wrote in message
news: ps.com...
> On Sep 3, 4:05 pm, "KJ" wrote:
>
>> Both of those tools do support 'asynchronous reset' (aka if/elsif/end if)
> I was referring to alliance here. it doesn't support 'asynchronous
> reset'. but it does support the counter (see code in previous emails)
>
>
>> Your original post (entity dff_asynchrone) is one correct way of coding
>> an
>> asynchronous reset. Why do you think it.they do not simulate correctly?
>
> Again I meant alliance doesn't simulate correctly. Modelsim and ghdl
> works.
> It fails with:
> Compiling 'dff_asynchrone' ...
> VHDL : Error - bad usage of the 'stable' attribut
> *** Compilation aborted...
> make: *** [PROOF] Error 255
>
> By referring Modelsim and ghdl above, I meant that I can use either
> Modelsim or ghdl for my simulations. But it's curiosity on for
> alliance that drove me to start this topic here.
>
> regards,
> Chitlesh

Then re-read my original post about not using such a simulator. Next open a
service request against Alliance and tell them you won't be using their
lame tool.

KJ

KJ

"Clunixchit" <> wrote in message
news: ps.com...
> On Sep 3, 4:05 pm, "KJ" wrote:
>
>> Both of those tools do support 'asynchronous reset' (aka if/elsif/end if)
> I was referring to alliance here. it doesn't support 'asynchronous
> reset'. but it does support the counter (see code in previous emails)
>
>
>> Your original post (entity dff_asynchrone) is one correct way of coding
>> an
>> asynchronous reset. Why do you think it.they do not simulate correctly?
>
> Again I meant alliance doesn't simulate correctly. Modelsim and ghdl
> works.
> It fails with:
> Compiling 'dff_asynchrone' ...
> VHDL : Error - bad usage of the 'stable' attribut
> *** Compilation aborted...
> make: *** [PROOF] Error 255
>
> By referring Modelsim and ghdl above, I meant that I can use either
> Modelsim or ghdl for my simulations. But it's curiosity on for
> alliance that drove me to start this topic here.

I would agree with KJ, this looks like a serious bug in the Alliance VHDL
parser, it complains about the 'stable attribute but you are using 'event?

I actually question this bug since if the parser can't handle 'event then
probably most designs will fail, do you get the same error with rising_edge?

Hans
www.ht-lab.com


>
> regards,
> Chitlesh
>

HT-Lab

On Sep 4, 3:28 am, "HT-Lab" <han...@ht-lab.com> wrote:
> "Clunixchit" <chitl...@gmail.com> wrote in message
>
> news: ps.com...
>
>
>
> > On Sep 3, 4:05 pm, "KJ" wrote:
>
> >> Both of those tools do support 'asynchronous reset' (aka if/elsif/end if)
> > I was referring to alliance here. it doesn't support 'asynchronous
> > reset'. but it does support the counter (see code in previous emails)
>
> >> Your original post (entity dff_asynchrone) is one correct way of coding
> >> an
> >> asynchronous reset. Why do you think it.they do not simulate correctly?
>
> > Again I meant alliance doesn't simulate correctly. Modelsim and ghdl
> > works.
> > It fails with:
> > Compiling 'dff_asynchrone' ...
> > VHDL : Error - bad usage of the 'stable' attribut
> > *** Compilation aborted...
> > make: *** [PROOF] Error 255
>
> > By referring Modelsim and ghdl above, I meant that I can use either
> > Modelsim or ghdl for my simulations. But it's curiosity on for
> > alliance that drove me to start this topic here.
>
> I would agree with KJ, this looks like a serious bug in the Alliance VHDL
> parser, it complains about the 'stable attribute but you are using 'event?
>
> I actually question this bug since if the parser can't handle 'event then
> probably most designs will fail, do you get the same error with rising_edge?
>
> Hanswww.ht-lab.com
>
>
>
> > regards,
> > Chitlesh

Perhaps this tool is a cycle (clock) based simulator? And maybe the
parser only accepts rising_edge() or falling_edge() calls for clock
edge "detection". Change your "(cp = '1' and cp'event)" to
"rising_edge(cp)". IINM, 'stable can be a more general case of the
opposite of 'event, and could be being used for it.

If this is really a true cycle based simulator, you're pretty much out
of luck trying to code an asynchronous reset, the simulator can
probably only handle things happening at the next clock edge. You
could convert to synchronous reset:

process(cp)
begin
if rising_edge(cp) then
if re_set = '0' then
q <= '0';
else
q <= data;
end if;
end if;
end process;

Andy

Andy

On Sep 4, 10:28 am, "HT-Lab" wrote:
> I actually question this bug since if the parser can't handle 'event then
> probably most designs will fail, do you get the same error with rising_edge?

Yes I still have the error.

On Sep 4, 3:14 pm, Andy wrote:
> If this is really a true cycle based simulator, you're pretty much out
> of luck trying to code an asynchronous reset, the simulator can
> probably only handle things happening at the next clock edge. You
> could convert to synchronous reset:

So be it. As for a synchronous reset, the simulator does the job.

Thanks for your help.

Chitlesh

Clunixchit