How to constraint my design using TimeQuest?

You probably need the following constraints;

1) A clock frequency constraint for the FPGA clock. This constrains the register-to-register paths inside the FPGA. Quartus/TimeQuest use this constraint to check that your internal logic can operate at the frequency of the clock.

2) The SPI inputs are run through synchronizers correct? In that case, you can set them as false-paths. This tells TimeQuest; "These inputs do not need to be analyzed".

3) For the SPI outputs, you can give it a constraint "that the FPGA can meet". How do you know what it can meet? You put it to 10ns to start with, and then look at the report to see if it failed, and then increase it a little.

4) Where is your parallel input coming from? If you have an external device that is writing to the FPGA, then it will have a clock-to-output delay. Its that delay that you need to tell TimeQuest about, so that it can look at the timing at the FPGA input registers to see if the register setup and hold time can be met.

There's a tutorial and references in this thread:

http://www.alteraforum.com/forum/showthread.php?t=31457

Cheers,

Dave

Hi Dave, was hoping you'd reply. :)

Yes, SCK and CS are run through synchronizers but not MISO and MOSI. I'll set CS and SCK as false paths. I'll try what you suggested about MISO. Should I also sync MOSI? [actually, currently, I'm not even using MOSI but would like to know for future reference.]

Regarding the parallel input. The parallel input comes from another FPGA/CPLD. How can I find out the clock-to-output delay? Where do I tell TimeQuest about this?

I already went through that thread and also your PDF. I've done followed through the TimeQuest Tutorial and that also was a big help.

--- Quote Start ---

Yes, SCK and CS are run through synchronizers but not MISO and MOSI. I'll set CS and SCK as false paths. I'll try what you suggested about MISO. Should I also sync MOSI? [actually, currently, I'm not even using MOSI but would like to know for future reference.]

--- Quote End ---

Since you know that MISO is only ever registered based on a synchronized version of SCK, you can also set that as a false path.

--- Quote Start ---

Regarding the parallel input. The parallel input comes from another FPGA/CPLD. How can I find out the clock-to-output delay? Where do I tell TimeQuest about this?

--- Quote End ---

TimeQuest for the 'other FPGA' will tell you. Look at the 'datasheet' report. Bring up the TimeQuest GUI and you'll see that report listed. The PDF that I linked to above has plenty of examples of reading that information.

The clock-to-output delay from that report can also be used as your requested setting for the MOSI output, just set the requirement for the clock-to-output delay to be slightly larger than the largest value reported, and TimeQuest will be able to 'meet' that requirement. The clock-to-output delay can be adjusted slightly by Quartus by using the IOE output registers. Quartus has much more flexibility in adjusting the input delays, since there are programmable delay cells in FPGA IOE inputs.

Cheers,

Dave

OK, I have an update.

Here is what I did, for the 'other FPGA', step by step (I did this so I could get an actual figure for the clock to output delay). The overall input/outputs are very similar to that of the design I described in my initial post except the CPLD has 72 outputs instead of inputs. It also has a fully functional SPI interface and a active-low RESET.

I followed the TimeQuest Tutorial as I did this.

1) I went and created a clock of time period 50 ns (20 Mhz) and assigned the port to CLK. I named this SYSTEM_CLOCK.

2) I then went to the Set Output Delay dialog box and entered a delay of 2 ns. I chose SYSTEM_CLOCK as the clock and chose my 72 outputs.

3) I went into the Contraints menu and chose "Set False Paths". In the FROM field I put in SYSTEM_CLOCK and in the TO field I put in SCK. I did this again for CS and MOSI. I don't think I did this step quite right because in the reports I'm still told that I have 4 unconstrained inputs. Where do I tell TimeQuest that these are False Paths?

http://i.imgur.com/ncyOp.png

4) I'm also told that MISO (which I call DO in the design) isn't constrained even though I did set an output delay for it. Infact, SDC Assignments/ Set Output Delay has it in the report as well.

http://i.imgur.com/2eVq6.png

5) I found the clock to output delay for my outputs. Do I just use these for my other design which has 72 inputs? Will 17.968 ~= 20 ns become the input delay?

http://i.imgur.com/GzPWk.png

Thanks for taking the time to respond! Would have never gotten to where I am without your help!

--- Quote Start ---

1) I went and created a clock of time period 50 ns (20 Mhz) and assigned the port to CLK. I named this SYSTEM_CLOCK.

2) I then went to the Set Output Delay dialog box and entered a delay of 2 ns. I chose SYSTEM_CLOCK as the clock and chose my 72 outputs.

3) I went into the Contraints menu and chose "Set False Paths". In the FROM field I put in SYSTEM_CLOCK and in the TO field I put in SCK. I did this again for CS and MOSI. I don't think I did this step quite right because in the reports I'm still told that I have 4 unconstrained inputs. Where do I tell TimeQuest that these are False Paths?

--- Quote End ---

If you are creating new constraints, then you have to re-run the analysis.

Personally I create the .sdc file directly, and only use the GUI for analyzing the timing.

--- Quote Start ---

5) I found the clock to output delay for my outputs. Do I just use these for my other design which has 72 inputs? Will 17.968 ~= 20 ns become the input delay?

--- Quote End ---

I forget whether you enter them directly, or indirectly via a calculated input delay, that is why I wrote the other tutorial. Read it. The answer should be in there :)

Cheers,

Dave

Thanks, I found what I did wrong with the Set False Paths step - I put in the path backwards! Also, why are we setting the synced signals as False Paths? Why do they not need a timing analysis?

One more question, what do I do with RESET? Is that also a false path? The RESET goes to a lot input paths it seems.

--- Quote Start ---

why are we setting the synced signals as False Paths? Why do they not need a timing analysis?

--- Quote End ---

They are asynchronous signals, and you expect metastable states on those signals, right? That is why you have put a synchronizer on those signals. A timing analysis of those asynchronous inputs is meaningless, since the timing of a transition on the input is completely arbitrary with respect to the clock used by your FPGA logic. Once you have synchronized that signal, it is synchronized to the FPGA clock, and the FPGA clock constraint takes over.

--- Quote Start ---

One more question, what do I do with RESET? Is that also a false path? The RESET goes to a lot input paths it seems.

--- Quote End ---

You should run reset through a reset synchronizer, i.e., a synchronizer that asserts reset asynchronously, but deasserts it synchronously, and then apply a false path. The reset and recovery time for the registers internal to the design will then be analyzed with respect to the synchronous deassertion of the reset signal.

Cheers,

Dave

--- Quote Start ---

You should run reset through a reset synchronizer, i.e., a synchronizer that asserts reset asynchronously, but deasserts it synchronously, and then apply a false path. The reset and recovery time for the registers internal to the design will then be analyzed with respect to the synchronous deassertion of the reset signal.

Cheers,

Dave

--- Quote End ---

Could you provide an example? At the moment, I'm syncing signals like this:

sync1 : sync
		generic map(
			RESET_STATE => '0'
		)
		port map(
			clk  => clk,
			rstN => nRESET,
			d    => sck,
			q    => SCK_sync
		);

I also read up on your byteblaster example but I don't think that implements a reset synchronizer.

--- Quote Start ---

Could you provide an example?

--- Quote End ---

Sure, you use the same component, with a slightly different connection:

sync1 : sync
        generic map(
            RESET_STATE => '0'
        )
        port map(
            clk  => clk,
            rstN => nRESET,
            d    => '1',
            q    => nRESET_sync
        );

So how does this work?

Well, when nRESET is low (active), the registers internal to this synchronizer are immediately cleared and output '0', i.e., the nRESET_sync signal is asynchronously asserted. When nRESET is high (deasserted), the synchronizer chain starts to synchronize the input d, which in this case is a '1'. After a couple of clocks, the '1' appears at the synchronizer output, and viola, the nRESET_sync signal deasserts synchronously.

Cheers,

Dave

That makes sense. So from now on, the entire design uses statements like

if nRESET_sync = '0' then

---do stuff

Right?