how to constraint the reset signal？

You don't have to. The "Recovery" and "Removal" analysis will automatically analyze the path from your reset_out register to the .clr of all destination registers.

-David

--- Quote Start ---

You don't have to. The "Recovery" and "Removal" analysis will automatically analyze the path from your reset_out register to the .clr of all destination registers.

-David

--- Quote End ---

thanks for your help!

I have synchronized my asynchronous power on reset.

(It is described on the following site.)

--- Quote Start ---

quartushelp.altera.com/12.1/master.htm#mergedProjects/verify/da/comp_file_rules_reset_external.htm?GSA_pos=7&WT.oss_r=1&WT.oss=syncronizing%20asynchronous%20reset

--- Quote End ---

-- Reset einsynchronisieren und zugleich invertieren
process (TiClkout50_i, PowerResetn_i)    
begin
    if PowerResetn_i = '0' then
        rstSync <= '1';
        rstSync2 <= '1';
    elsif rising_edge(TiClkout50_i) then
        rstSync <= '0';
        rstSync2 <= rstSync;
    end if;    
end process;
PowerReset <= rstSync2;

Timequest is complaining that it is a clock:

--- Quote Start ---

Warning: Node: TopFpga:TopFpga_inst|rstSync2 was determined to be a clock but was found without an associated clock assignment.

--- Quote End ---

does anybody know how to constrain the generated reset?

--- Quote Start ---

I have synchronized my asynchronous power on reset.

(It is described on the following site.)

-- Reset einsynchronisieren und zugleich invertieren
process (TiClkout50_i, PowerResetn_i)    
begin
    if PowerResetn_i = '0' then
        rstSync <= '1';
        rstSync2 <= '1';
    elsif rising_edge(TiClkout50_i) then
        rstSync <= '0';
        rstSync2 <= rstSync;
    end if;    
end process;
PowerReset <= rstSync2;

Timequest is complaining that it is a clock:

does anybody know how to constrain the generated reset?

--- Quote End ---

It must be you are (some where) using it as clock in a process edge rather than reset.

--- Quote Start ---

If looking at VHDL doesn't help, try looking at the RTL netlist and see where rstSync2 is connected to a flip-flop's clock pin.

--- Quote End ---

Well, I discovered, that at some registers my reset is used as "clk enable", see attachment.

I suppose, the tool did that, because the data comes from a register clocked with 83 MHz to aregister clocked with 50 MHz. (I synchronize the data coming from the 83 MHz part with two 50 MHz registers, before using it.)

So, any ideas how I have to constrain rstsync2?

Thanks for your support!

--- Quote Start ---

Well, I discovered, that at some registers my reset is used as "clk enable", see attachment.

I suppose, the tool did that, because the data comes from a register clocked with 83 MHz to aregister clocked with 50 MHz. (I synchronize the data coming from the 83 MHz part with two 50 MHz registers, before using it.)

So, any ideas how I have to constrain rstsync2?

Thanks for your support!

--- Quote End ---

That still does not explain the warning. see if you have connected rstSync2 to clock through some logic.

Regarding timing constraint, you don't need any for 1st reset section. The path from reset pin to rstSync1 register is not going to be checked because it is not between two registers and a false statement there is useless. The path after rstSync2 is now known to tool and it will check it. The path between rstSync1 & rstSync2 need a false statement.

As a side note, the reset vhdl code above does not implement a circuit according to diagram per your link, though I think it is equivalent. I believe that circuit is realisable only by instantiating a flip and not coding.

--- Quote Start ---

Well, I discovered, that at some registers my reset is used as "clk enable", see attachment.

I suppose, the tool did that, because the data comes from a register clocked with 83 MHz to aregister clocked with 50 MHz. (I synchronize the data coming from the 83 MHz part with two 50 MHz registers, before using it.)

So, any ideas how I have to constrain rstsync2?

--- Quote End ---

The reset signal should be re-timed into the 50MHz clock domain as if it's an asynchronous input the way you've done with the reset input at the top level!

Nial