ALTASMI_PARALLEL Timequest Constraints

[Altera_Forum]

I'm using the ALTASMI_PARALLEL megafunction in a Cyclone III design and would like to know if anyone has SDC constraints for the DCLK, SDO, SCE outputs and DATA0 input. I've had a go myself, but being new to Timequest am struggling to write them. Here's what I've got so far (which may be way off track!): 

 # ALTASMI_PARALLEL.# Create clock for ALTASMI_PARALLEL constraints. create_generated_clock -name asmi_dclk -source }] # ALTASMI_PARALLEL input constraints. set asmi_inputs set_input_delay -clock asmi_dclk -clock_fall -min 0 $asmi_inputs set_input_delay -clock asmi_dclk -clock_fall -max 0 $asmi_inputs # ALTASMI_PARALLEL output constraints. set asmi_outputs set_output_delay -clock asmi_dclk -min 0 $asmi_outputs set_output_delay -clock asmi_dclk -max 0 $asmi_outputs   For anyone who is not familiar with this interface, it is basically a simple SPI master. In my design DCLK is 16MHz and fed directly from a PLL output. The megafunction keeps DCLK running all the time. The master (FPGA) launches and latches data on falling edges of the clock feeding DCLK. The slave (configuration device) launches data on the falling edge of DCLK and latches data on the rising edge.  Timequest reports that DCLK is unconstrained. Given that (I think) it is a generated clock, how can it be constrained? The waveforms for setup look about right, but those for hold have the data being launched on rising rather than falling edges.  Any help clearing up my confusion would be much appreciated.

[Altera_Forum]

After several days of trying different constraints, reading the TimeQuest User Guide and several other documents I'm still unable to figure out why TimeQuest keeps reporting that DCLK in unconstrained. When synthesizing the design the following warning is produced: 

 Warning: PLL "pll:pll0|altpll:altpll_component|pll_altpll:auto_generated|pll1" output port clk feeds output pin "flash_ctrl:flash_ctrl0|flash_if:flash_if0|flash_if_altasmi_parallel_f182:flash_if_altasmi_parallel_f182_component|cycloneii_asmiblock2~ALTERA_DCLK_OBUF" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance   Running Report Unconstrained Paths in TimeQuest returns:  [from] pll0|altpll_component|auto_generated|pll1|clk[1] [to] flash_ctrl:flash_ctrl0|flash_if:flash_if0|flash_if_altasmi_parallel_f182:flash_if_altasmi_parallel_f182_component|cycloneii_asmiblock2~ALTERA_DCLK [from clocks] clk  is unconstrained in the Unconstrained Output Port Paths under both Setup and Hold Analysis.  Under Unconstrained Output Ports under both Setup and Hold Analysis:  [Output Port] flash_ctrl:flash_ctrl0|flash_if:flash_if0|flash_if_altasmi_parallel_f182:flash_if_altasmi_parallel_f182_component|cycloneii_asmiblock2~ALTERA_DCLK [Comment] No output delay, min/max delays, false-path exceptions, or max skew assignments found. This port has clock assignment.  Looking at the technology map viewer, this signal comes from the pll output, through an IO_BUF and to the pin.  Is this a bug in TimeQuest? Why would a generated clock need an output delay constraint? Should I just set it as a false path?

[Altera_Forum]

The DCLK is sourced by PLL but is viewed as different timing node from its source since it is at pin level. So add it as separate clk statement in sdc.

[Altera_Forum]

I'm not sure what you mean by 'add it as separate clk statement in sdc'. The derive_generated_clocks command produces the PLL clock and then I used a create_generated_clock for the DCLK pin. I was basing this on user dwh's 'TimeQuest Quad-SPI Flash Constraints Analysis' report. 

 Edit: That should be 'derive_pll_clocks command'

[Altera_Forum]

--- Quote Start ---  I'm not sure what you mean by 'add it as separate clk statement in sdc'. The derive_generated_clocks command produces the PLL clock and then I used a create_generated_clock for the DCLK pin. I was basing this on user dwh's 'TimeQuest Quad-SPI Flash Constraints Analysis' report.  Edit: That should be 'derive_pll_clocks command'  --- Quote End ---    where is your statement for dclk pin as a generated clk The one above does not seem to refer to the dclk pin.

[Altera_Forum]

# ALTASMI_PARALLEL. # Create clock for ALTASMI_PARALLEL constraints. create_generated_clock -name asmi_dclk -source }]  

 From what I can see from the technology map viewer the 'dclk' pin is named 'flash_ctrl:flash_ctrl0|flash_if:flash_if0|flash_if_altasmi_parallel_f182:flash_if_altasmi_parallel_f182_component|cycloneii_asmiblock2~ALTERA_DCLK'.

[Altera_Forum]

well dclk pin is a pin on your fpga, isn't it, so refer to the pin itself and not to its internal name.

[Altera_Forum]

I have no idea how to get the name of the pin; the cycloneii_asmiblock component is defined in cycloneii.vhd (in quartus\eda\synthesis directory). 

 component cycloneii_asmiblock generic ( lpm_type : string := "cycloneii_asmiblock" ); port( data0out : out std_logic; dclkin : in std_logic; oe : in std_logic := '1'; scein : in std_logic; sdoin : in std_logic ); end component;  This is fed from the altasmi_parallel megafunction and the ports are 'magically' (as far as I can tell) mapped to the active serial configuration device pins on the FPGA.  Using DCLK or dclk in TimeQuest does not work. Using Report Path... in TimeQuest from: * to: *DCLK returns the cycloneii_asmiblock2~ALTERA_DCLK as being at location PIN_12, which is the active serial DCLK pin and the last item in the list.  Any ideas anyone? I realise that this interface will probably work whether it is constrained or not, as it runs at less than 20MHz.  More generally it would be good if Altera put some actual examples for SPI-like peripherals and 'asynchronous' interfaces such as SRAMs that need to be constrained. Rysc's user guide is good, but has typos and does not look like it is going to be updated anytime soon to fix these or add content to the empty chapters.  Even better would be if the Quartus II Megawizard also produced a template SDC file for the IO of the ALTASMI_PARALLEL megafunction to the configuration device.