Bug in Synplify?

On 28 Sep., 23:24, Andy <jonesa...@comcast.net> wrote:
> I've also seen Synplify put a feedback mux around a ram that did not
> have a reset, but was inferred from a process that did have an async
> reset (due to the 'elsif rising_edge()' not executing during reset).
> I wonder if that could be related to what's going on? Without code, it
> is really hard to tell.

Seems to be realted to me. Could you say, which technology you used
to have synplicity infering a ram out of a process with asynch reset?

bye Thomas

On Oct 2, 4:37 pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> On 28 Sep., 23:24, Andy <jonesa...@comcast.net> wrote:
>
> > I've also seen Synplify put a feedback mux around a ram that did not
> > have a reset, but was inferred from a process that did have an async
> > reset (due to the 'elsif rising_edge()' not executing during reset).
> > I wonder if that could be related to what's going on? Without code, it
> > is really hard to tell.
>
> Seems to be realted to me. Could you say, which technology you used
> to have synplicity infering a ram out of a process with asynch reset?
>
> bye Thomas

Xilinx. The process had an asynchronous reset, but the ram array was
not reset:

process (rst, clk) is
begin
if rst = '1' then
  reg <= '0';
elsif rising_edge(clk) then
  reg <= something;
  ram(addr) <= something_else;
end if;
end process;

If reset is asserted, the rising_edge() condition is not evaluated or
run for any of the other assignments. So even though ram() is not
reset, it is not updated on clock cycles when reset is asserted
either.

A better way to code it is:

process (rst, clk) is
begin
if rising_edge(clk) then
  reg <= something;
  ram(addr) <= something_else;
end if;
if rst = '1' then
  reg <= '0';
end if;
end process;

Andy