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

Reply to
Thomas Stanka
Loading thread data ...

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.

Reply to
John_H

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

Reply to
Andy

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 =>'0')); elsif rising_edge(clk) then

Reply to
Thomas Stanka

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 =>'0')); cnt :=0; elsif rising_edge(clk) then if load = '1' then my_array(cnt)

Reply to
Thomas Stanka

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

Tommy

Reply to
Tommy Thorn

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.

Reply to
Ray Andraka

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

Reply to
Andy

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

Reply to
Andy

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

Reply to
Thomas Stanka

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

Reply to
Thomas Stanka

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

process (rst, clk) is begin if rst = '1' then reg

Reply to
Andy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.