How to describe a process with asynchronous reset in VHDL for the ARRIA 10 FPGA

[SSenn]

Hello,

i have some trouble with the reset signal. I use VHDL to describe my logic. The target FPGA is an ARRIA 10.

I have realized that the reset signal is connected as a global enable signal (ENA) to registers which aren't in the reset case. Here is an example process:

process(arst_n, clk) begin if arst_n = '0' then -- reset case s_valid <= '0'; elsif rising_edge(clk) then -- normal case s_valid <= valid; s_data <= data; --[511:0] -- no reset end if; end process:

<s_data> is only valid if <s_valid> is high. Therefore <s_data> doesn't need a reset. In reset state <s_data> can be random.

Problem:

Quartus connects <arst_n> with <s_data>. This is the reason why I have a high fan-out on the reset signal and my timing is bad.

Here a part of the Quartus report

Total registers   513

Number of registers using Synchronous Clear   0

Number of registers using Synchronous Load   0

Number of registers using Asynchronous Clear   1

Number of registers using Asynchronous Load   0

Number of registers using Clock Enable   512 <----- problem

Number of registers using Preset   0

Maximum fan-out   513 <----- problem

Question:

How can I describe the given logic in VHDL without the global enable signals being generated by Quartus?

I want this (only one async clear):

Total registers   513

Number of registers using Synchronous Clear   0

Number of registers using Synchronous Load   0

Number of registers using Asynchronous Clear   1

Number of registers using Asynchronous Load   0

Number of registers using Clock Enable   0

Number of registers using Preset   0

[KhaiChein_Y_Intel]

Hi,

Could you use Synchronized Asynchronous Reset to avoid metastability issue?

You may refer to Example 57 for HDL Code for Synchronized Asynchronous Reset

https://www.intel.la/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-design-recommendations.pdf

Thanks.

[SSenn]

Hello YY

Thank you for your quick answer. We already use synchronized asynchronous resets. The <arst_n> signal is generated with the following logic:

p_rst: process(pll_lock_n, s_clk) begin if pll_lock_n = '0' then s_arst_n <= (others => '0'); elsif rising_edge(s_clk) then s_arst_n <= s_arst_n(s_arst_n'high-1 downto 0) & '1'; end if; end process p_rst; arst_n <= s_arst_n(s_arst_n'high);

I can describe the logic in two processes, but in my opinion this makes the code confusing.

process(arst_n, clk) begin if arst_n = '0' then s_valid <= '0'; elsif rising_edge(clk) then s_valid <= valid; end if; end process:   process(clk) begin if rising_edge(clk) then s_data <= data; end if; end process:

Is there a way to describe the logic in one process without the disadvantage of the Global Enables?

[sstrell]

Does s_data even need to be in a clocked process? If s_data can be anything and it's only used when s_valid is valid, could you simply do:

s_data <= data;

or some type of conditional assignment to decide when s_data should be updated?

#iwork4intel

[SSenn]

Hi

Yes, <s_data> needs a clocked process. The given process is only a simplified example. For example, we have Avalon-Stream Pipeline modules which are very similar to the given example.

[KhaiChein_Y_Intel]

Hi,

Could you see if the below changes fit your design requirements?

process(arst_n, clk)

begin

  if arst_n = '0' then -- reset case

   s_valid <= '0';

  elsif rising_edge(clk) then -- normal case

   s_valid <= valid;

  end if;

end process;

process(clk)

begin

if rising_edge(clk) then

s_data <= data; --[511:0] -- no reset

end if; 

end process;

Thanks.

[SSenn]

Hello YY

Everything is fine if I describe the logic in two processes. Than no clock enbales are synthesized.

But I was hoping somebody would have a better solution. When the logic becomes more complex (this logic is a very simple example), the description with two processes can be hard for other developers to read/understand.

[KhaiChein_Y_Intel · Accepted solution]

Hi,

If you put s_data <= data; in the if-else condition, the data will be controlled by arst_n = '0'.

Thanks.

[SSenn]

Hello,

Thank for your support. I think we can mark this case as solved.

[jorva]

Hello,

I did some testing and Quartus Prime Standard (20.1) will allow registers without a reset to be used in processes together with registers having an asynchronous reset. However, Quartus Prime Pro (20.2) presents the issue discussed here.

Is there any other means to support both types of registers (with/without reset) in Quartus Prime Pro?

This would certainly render the code more coherent and avoid issues with legacy code.

Thanks!