Xilinx doesn't detect setup/hold violations on synchronous reset

Hi all,

I am facing some problems with Xilinx ISE 8.2 not taking into account synchronous reset setup/hold violations on FFs. My code looks like this:

Inst_my_dcm_a: my_dcm PORT MAP( CLKIN_IN => dsp_clk_pad_a, RST_IN => "not"(nreset), CLKDV_OUT => dsp_clk_a_div, CLKIN_IBUFG_OUT => open, CLK0_OUT => dsp_clk_a, LOCKED_OUT => LOCKED_a ); i_locked_a_reg : FDE port map (Q => locked_a_reg, C => dsp_clk_a, CE => '1', D => LOCKED_a); nreset_and_locked

Reply to
Frai
Loading thread data ...

The timing analysis is configured by default to ignore asynchronous set/reset paths and latch element d->q propagation. You can enable these elements with the ENABLE constraint. Please see your constraints guide for more information.

Reply to
John_H

Hi John.

I knew that. That's one of the reasons why I'm using synchronous reset. As far as I know Xilinx is enabled by default to trace synchronous inputs, including set/reset.

Reply to
Frai

Is your reset source synchronous? If not it won't go into anything other than setup and hold analysis even if it is used synchronously.

John Adair Enterpoint Ltd.

Reply to
John Adair

Where are you expecting it to fail? Between the DCM and the FF? You can use the timing analyser tool to see what paths the tool is checking. As to your approach, probably will work fine, but you might consider using LOCKED to asynchronously reset the FD you instantiated, and then synchronously release reset. However, I think the CLK0 from the DCM is still going throughout the DCM locking phase so your circuit should be fine too. HTH, Syms.

Reply to
Symon

I'm using a clock with 10 ns period. The delay of the path between "locked_a_reg" and the synchronous reset of some FFs happens to be very close to 10 ns. Therefore, the clock signal from the DCM "dsp_clk_a" arrives at the FF almost at the same time as the reset signal is released, throwing a SETUP violation in Modelsim. In the real world, the FFs would just recover from this, but Modelsim doesn't seem to handle this, and it stays with many unknown values at FFs that prevent me from simulating my design.

I've done quite much research on this topic with no success. I would appreciate any information about why Xilinx doesn't detect such a violation.

Regards.

Reply to
Frai

Hi Frai, So, here are some more questions. Apologies if they sound obvious, I'm unsure of your experience with the (often painful) world of FPGA design! :-)

1) Are you doing a timing simulation after place and route? I assume you are, otherwise you wouldn't have delays in your simulation! 2) Have you told the Xilinx software the period of the clock in your UCF file? The software can only detect timing errors if it knows the frequency of the clock. 3) Have you used the Xilinx timing analyser tool? As I said in my previous post, this will tell you what paths the P&R software is checking. 4) Also, is the clock buffered with a BUFG or somesuch onto a global clock net? If not, hang your head in shame! The skew on a clock routed in the general routing resource will make meeting timing a nightmare.

I'm surprised that the net has delays of 10ns. That's quite a long time in today's parts. (You can try duplicating the FF that generates the reset to reduce this delay, but that doesn't address your question as to why the tools don't report timing errors.)

HTH, Syms.

Reply to
Symon

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.