Bug in Synplify?

Hi,

I have a behavior in Synplify Pro for Actel Fpgas I would call a bug
(seen in each old version I could find up to the newest 9.0)

If having a register file which is accessed only in words with fixed
width and an asynchronous reset, synplify detects a ram structure in
the compile step. If the ram isn't used later (due to constrained ram-
style register, or due to resource usage), synplify uses FF without an
asynchronous reset for the register bank and a hell of logic to force
the circuit to behave like it uses asynchnous reset. I have a simple
example(6x8 bit), were synplicity uses twice the register normaly
necessary. This behavior is only seen when using a technology which
provides ram at all. So I like to know if there is a reason to
consider this a problem of the tech library? Is there anybody out
seeing the same behavior in other technologies than Actel (APA, AX)?

regards Thomas

Thomas Stanka wrote:
> Hi,
> 
> I have a behavior in Synplify Pro for Actel Fpgas I would call a bug
> (seen in each old version I could find up to the newest 9.0)
> 
> If having a register file which is accessed only in words with fixed
> width and an asynchronous reset, synplify detects a ram structure in
> the compile step. If the ram isn't used later (due to constrained ram-
> style register, or due to resource usage), synplify uses FF without an
> asynchronous reset for the register bank and a hell of logic to force
> the circuit to behave like it uses asynchnous reset. I have a simple
> example(6x8 bit), were synplicity uses twice the register normaly
> necessary. This behavior is only seen when using a technology which
> provides ram at all. So I like to know if there is a reason to
> consider this a problem of the tech library? Is there anybody out
> seeing the same behavior in other technologies than Actel (APA, AX)?
> 
> regards Thomas

If you don't want a RAM attempted in the first place but the tool is 
trying anyway, use the syn_ramstyle attribute to force flops, allowing a 
clean async reset, perhaps.

On Sep 27, 12:45 am, Thomas Stanka <usenet...@stanka-web.de> wrote:
> Hi,
>
> I have a behavior in Synplify Pro for Actel Fpgas I would call a bug
> (seen in each old version I could find up to the newest 9.0)
>
> If having a register file which is accessed only in words with fixed
> width and an asynchronous reset, synplify detects a ram structure in
> the compile step. If the ram isn't used later (due to constrained ram-
> style register, or due to resource usage), synplify uses FF without an
> asynchronous reset for the register bank and a hell of logic to force
> the circuit to behave like it uses asynchnous reset. I have a simple
> example(6x8 bit), were synplicity uses twice the register normaly
> necessary. This behavior is only seen when using a technology which
> provides ram at all. So I like to know if there is a reason to
> consider this a problem of the tech library? Is there anybody out
> seeing the same behavior in other technologies than Actel (APA, AX)?
>
> regards Thomas

Can you post some code? It is difficult to understand what you want,
let alone the problem with what you are getting, without seeing some
example code. Also, does your target even support async reset on RAMs?

Andy

On 27 Sep., 21:20, Andy <jonesa...@comcast.net> wrote:
> On Sep 27, 12:45 am, Thomas Stanka <usenet...@stanka-web.de> wrote:
>
>
>
> > Hi,
>
> > I have a behavior in Synplify Pro for Actel Fpgas I would call a bug
> > (seen in each old version I could find up to the newest 9.0)
>
> > If having a register file which is accessed only in words with fixed
> > width and an asynchronous reset, synplify detects a ram structure in
> > the compile step. If the ram isn't used later (due to constrained ram-
> > style register, or due to resource usage), synplify uses FF without an
> > asynchronous reset for the register bank and a hell of logic to force
> > the circuit to behave like it uses asynchnous reset. I have a simple
> > example(6x8 bit), were synplicity uses twice the register normaly
> > necessary. This behavior is only seen when using a technology which
> > provides ram at all. So I like to know if there is a reason to
> > consider this a problem of the tech library? Is there anybody out
> > seeing the same behavior in other technologies than Actel (APA, AX)?
>
> > regards Thomas
>
> Can you post some code? It is difficult to understand what you want,
> let alone the problem with what you are getting, without seeing some
> example code. Also, does your target even support async reset on RAMs?

Just to clearify:
I have a code which Synplify detects as Ram in compile step.
If Synplify didn't use a RAM later to implement this structure but a
set of pure registers (either due to resource usage, time contraints
or because I use the pragma" syn_ramstyle register" in VHDL-code.

A example code in VHDL

TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0);
signal my_array : array_type;
...
process (clk, rst)
if rst='0' then
  my_array <= (others => (others =>'0'));
elsif rising_edge(clk) then

Hi,

On 27 Sep., 21:20, Andy <jonesa...@comcast.net> wrote:
> Can you post some code? It is difficult to understand what you want,
> let alone the problem with what you are getting, without seeing some
> example code. Also, does your target even support async reset on RAMs?

Just to clearify:
I have a code which Synplify detects as Ram in compile step.
If Synplify didn't use a RAM later to implement this structure but a
set of pure registers (either due to resource usage, time contraints
or because I use the pragma" syn_ramstyle register" in VHDL-code) I
get some functional correct result but the solution uses way too much
registers.

Below is a sample code in VHDL which will result to ram infering in
the first place(not checked for correctness of syntax)
The example below should fit in 3 bit counter and 6x8 FF with asynch
reset. I got a result which uses nearly twice the number of FF
(without asynch. reset) in order to provide the same functionality
with a slightly more complex code, but no need to have that much
register doubling for load balance or anything like that. A lot of
registers are used in order to manage the "asynch reset" in a synchron
way.

TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0);
signal my_array : array_type;
attribute syn_ramstyle of my_array is register;
...
process (clk, rst)
variable cnt: integer range 0 to 7;
if rst='0' then
  my_array <= (others => (others =>'0'));
  cnt :=0;
elsif rising_edge(clk) then
  if load = '1' then
    my_array(cnt) <= an_input;
  end if;
  .....

> TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0);
> signal my_array : array_type;
> attribute syn_ramstyle of my_array is register;
> ...
> process (clk, rst)
> variable cnt: integer range 0 to 7;
> if rst='0' then
>   my_array <= (others => (others =>'0'));


D'oh. No SRAM can be reset in one cycle.

Tommy

Andy wrote:


> When you let it infer ram, are you getting LUT based rams
> (combinatorial read), or block rams (registered reads)?
> 
> LUT rams cannot be reset. I seem to recall block rams on some devices
> can have a reset. But the results of that reset may be deferred by the
> synchronous read circuitry (depending on whether you registered the
> read address, or registered the read data in the inferring code), so
> implementing that same cycle-accurate behavior may take more flops
> than you thought, but since you did not post how you are reading the
> RAM, I cannot tell.
> 
> Andy
> 
The Block RAM reset does not reset cells in the memory array, it just 
resets bits in the output register forcing the output to the reset 
value.  The contents of the array are left unchanged.

On Sep 28, 1:00 am, Thomas Stanka <usenet...@stanka-web.de> wrote:
> Hi,
>
> On 27 Sep., 21:20, Andy <jonesa...@comcast.net> wrote:
>
> > Can you post some code? It is difficult to understand what you want,
> > let alone the problem with what you are getting, without seeing some
> > example code. Also, does your target even support async reset on RAMs?
>
> Just to clearify:
> I have a code which Synplify detects as Ram in compile step.
> If Synplify didn't use a RAM later to implement this structure but a
> set of pure registers (either due to resource usage, time contraints
> or because I use the pragma" syn_ramstyle register" in VHDL-code) I
> get some functional correct result but the solution uses way too much
> registers.
>
> Below is a sample code in VHDL which will result to ram infering in
> the first place(not checked for correctness of syntax)
> The example below should fit in 3 bit counter and 6x8 FF with asynch
> reset. I got a result which uses nearly twice the number of FF
> (without asynch. reset) in order to provide the same functionality
> with a slightly more complex code, but no need to have that much
> register doubling for load balance or anything like that. A lot of
> registers are used in order to manage the "asynch reset" in a synchron
> way.
>
> TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0);
> signal my_array : array_type;
> attribute syn_ramstyle of my_array is register;
> ...
> process (clk, rst)
> variable cnt: integer range 0 to 7;
> if rst='0' then
>   my_array <= (others => (others =>'0'));
>   cnt :=0;
> elsif rising_edge(clk) then
>   if load = '1' then
>     my_array(cnt) <= an_input;
>   end if;
>   .....

When you let it infer ram, are you getting LUT based rams
(combinatorial read), or block rams (registered reads)?

LUT rams cannot be reset. I seem to recall block rams on some devices
can have a reset. But the results of that reset may be deferred by the
synchronous read circuitry (depending on whether you registered the
read address, or registered the read data in the inferring code), so
implementing that same cycle-accurate behavior may take more flops
than you thought, but since you did not post how you are reading the
RAM, I cannot tell.

Andy

On Sep 28, 12:31 pm, Ray Andraka <r...@andraka.com> wrote:
> Andy wrote:
> > When you let it infer ram, are you getting LUT based rams
> > (combinatorial read), or block rams (registered reads)?
>
> > LUT rams cannot be reset. I seem to recall block rams on some devices
> > can have a reset. But the results of that reset may be deferred by the
> > synchronous read circuitry (depending on whether you registered the
> > read address, or registered the read data in the inferring code), so
> > implementing that same cycle-accurate behavior may take more flops
> > than you thought, but since you did not post how you are reading the
> > RAM, I cannot tell.
>
> > Andy
>
> The Block RAM reset does not reset cells in the memory array, it just
> resets bits in the output register forcing the output to the reset
> value.  The contents of the array are left unchanged.

Thanks for the clarification. Maybe Synplify was trying to create a
shadow register that held a "reset" status bit for each word, that
would drive the ram output reg reset (or AND with it) whenever that
word was read, until it had been written to. Clever trick... maybe
they just forgot to pull it out w hen they go back to registers?

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.

Andy

On 28 Sep., 08:42, Tommy Thorn <tommy.th...@gmail.com> wrote:
> > TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0);
> > signal my_array : array_type;
> > attribute syn_ramstyle of my_array is register;
> > ...
> > process (clk, rst)
> > variable cnt: integer range 0 to 7;
> > if rst='0' then
> >   my_array <= (others => (others =>'0'));
>
> D'oh. No SRAM can be reset in one cycle.

I expect so, but Synplify infers RAM out of this process. So the tools
seems to know a RAM with asynch reset.
The syn_ramstyle pragmas are mainly used, because I like to have
registers used.

bye Thomas