如何在Vivado中解释简单计数器上的异步与同步复位

我一直在试验如何在Vivado中“解释”简单计数器上的异步与同步复位。
这是我的（10位）计数器模板：
图书馆IEEE;
使用IEEE.STD_LOGIC_1164.ALL;
使用IEEE.NUMERIC_STD.ALL;
实体counter_universal是
港口
（
时钟：STD_LOGIC;
reset：在STD_LOGIC中;  
clear_count：在STD_LOGIC中;
enable：在STD_LOGIC中;  
counter_out：输出STD_LOGIC_VECTOR（9 downto 0）
）;
end counter_universal;
建筑反行为的行为是  
signal s_count：unsigned（9 downto 0）;
- ：=（其他=>'0'）;
开始
过程（时钟，重置）
开始
如果reset ='1'则 -  async reset  - >将'reset'置于灵敏度列表中
s_count'0'）;
elsif rising_edge（时钟）然后
如果clear_count ='1'则 - （synchr）清除计数优先于启用
s_count'0'）;
elsif enable ='1'然后
S_COUNT
所以，如果我是正确的，复位在这里是异步的（因此必须在灵敏度列表中），而clear是异步的。
如果我打开精心设计的原理图，则确认 - 请参见第一个附件：复位线进入FF的'RST'输入，如果我是正确的则是异步输入。
'clear'行最终通过'D'输入上的逻辑结束，因此它被同步解释为清晰。
但是我尝试了一个略有不同版本的计数器过程：
- 同步'重置'和'清除'
处理（时钟）
开始
如果rising_edge（时钟）那么
if（reset ='1'）或（clear_count ='1'）然后
s_count'0'）;
elsif enable ='1'然后
S_COUNT
所以现在我希望'reset'和'clear_count'都是同步输入。
一世
然而，当我打开详细的原理图 - 参见附件2时，现在'reset'和'clear'都连接到DFF的async'RST'引脚......
我无法解释为什么......这是因为每个FF至少需要一个异步复位，而且由于我没有指定它，Vivado会使它异步，虽然它在过程中被描述为同步？
注意：必须承认看起来我可以忍受1次重置，我可以，但是我想连接（不是AXIRESETN）到'重置'，'clear'输入将来自其他模块/信号，到
保持清醒。
**如果答案是有帮助的话，那就是kudo。
如果您的问题得到解答，请接受解决方案



以下为原文

I've been experimenting on how a asynchronous vs synchronous reset on a simple counter is 'interpreted' in Vivado.

Here's my (10 bit) counter template :

library IEEE;use IEEE.STD_LOGIC_1164.ALL;use IEEE.NUMERIC_STD.ALL;entity counter_universal isport (     clock       : in STD_LOGIC;    reset       : in STD_LOGIC;        clear_count : in STD_LOGIC;    enable      : in STD_LOGIC;        counter_out : out STD_LOGIC_VECTOR (9 downto 0));end counter_universal;architecture Behavioral of counter_universal is        signal s_count : unsigned(9 downto 0); -- := (others => '0');    begin    process(clock, reset)    begin        if reset = '1' then                     -- async reset -> put 'reset in sensitivity list            s_count <= (others => '0');        elsif rising_edge(clock) then            if clear_count = '1' then           -- (synchr) clear count takes precedence over enable                s_count <= (others => '0');            elsif enable = '1' then                s_count <= s_count + 1;            end if;         end if;            end process;    -- connect internal signal to output    counter_out <= std_logic_vector(s_count);end Behavioral;so if I'm correct, reset is asynchronous here (and hence must be in the sensitivity list), and clear is asynchronous. If I open the elaborated schematic, this is confirmed - see first attachment : the reset line goes to the FF's 'RST' input, which if I'm correct is the asynchronous input. The 'clear' line finally ends up through logic on the 'D' input, hence it's syncronously interpreted as a clear.

however I experimented with a slightly different version of the counter process :

    -- sync 'reset' and 'clear'    process(clock)    begin        if rising_edge(clock) then            if (reset = '1') or (clear_count = '1') then                s_count <= (others => '0');            elsif enable = '1' then                s_count <= s_count + 1;            end if;         end if;            end process;so now I would expect both 'reset' and 'clear_count' would be synchronous inputs. I

However when I open the elaborated schematic - see attachment 2 , now both 'reset' and 'clear' are connected to the async 'RST' pin of the DFF ...

I cannot explain why .. is this because at least an async reset is needed for each FF, and since I'm not specifying it, Vivado makes it async, although it's described as synchronous in the process?

note :  must admit it looks like I could live with 1 reset, and I could, however I'd like to connect  (not AXIRESETN) to 'reset', and the 'clear' input would come from some other module/signal, to keep things clear.



** kudo if the answer was helpfull. Accept as solution if your question is answered **