1. Home
  2. Field-Programmable Gate Arrays
  3. DIFFICULT MULTICYCLE PATH WITH QUARTUS II

DIFFICULT MULTICYCLE PATH WITH QUARTUS II

Hallo to everybody, i'm trying to map a very large design onto a stratix EP1S80B956C7 device. After timing analysis with Quartus II 5.0 i have a "lot of high setup violations" on paths between registers of the such type of FF1 and FF2 (see vhdl below that is pheraps only a simplification of the entire project). These paths are multicycle 2 period wide. Apart from clock settings, in the Assignment Editor i gave to Quartus the subsequent constraints:

set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -from ENA -to ENA set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -from internal_EN1 -to internal_EN1 set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -to internal_EN1 set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -from internal_ENA -to internal_ENA set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -from internal_ENA -to *

and after i ran timing analysis again, i got the Ignored Timing Assignments in the report:

-------- option ---------------- setting ---- from --------- to

----------------- help ----------- Clock Enable Multicycle 2 internal_EN1 No timing path applicable to specified destination Clock Enable Multicycle 2 internal_EN1 internal_EN1 No timing path applicable to specified source and destination Clock Enable Multicycle 2 internal_ENA * Destination wildcard does not match any nodes Clock Enable Multicycle 2 internal_ENA internal_ENA No timing path applicable to specified source and destination Clock Enable Multicycle 2 ENA ENA No timing path applicable to specified source and destination

How can i force Quartus to consider paths enabled by ENA signal and clocked by CLK as multicycle paths without specifying all registers interested (it would be difficult for me to built a list, because of their huge number)?

Thanks in advance. Salva

------------------ VHDL ------------------

library ieee; use ieee.std_logic_1164.all;

entity PROVA is port ( RSTN : in std_logic; CLK : in std_logic; IN1 : in std_logic; IN2 : in std_logic; EN1 : in std_logic; EN2 : in std_logic; OUT1 : out std_logic; OUT2 : out std_logic ); end entity PROVA;

architecture ARCH_1 of PROVA is

component GLOBAL is port ( A_IN : in std_logic; A_OUT: out std_logic ); end component GLOBAL;

signal internal_CLK : std_logic; signal internal_EN1 : std_logic; signal internal_EN2 : std_logic; signal internal_ENA : std_logic;

signal ENA : std_logic; signal FF1 : std_logic; signal FF2 : std_logic; signal FF3 : std_logic;

begin

-- clock is assigned to a global resource GLOBAL_STRATIX1: GLOBAL port map(CLK, internal_CLK);

-- enable is assigned to a global resource GLOBAL_STRATIX2: GLOBAL port map(internal_ENA, ENA);

-- internally latched signals internal_CLK_P: process (RSTN, internal_CLK) begin if (RSTN = '0') then internal_EN1

Reply to
pippo
Loading thread data ...

pippo,

What you describe is a classical timing closure problem.

The only way I was able to make sure I closed the timing on the right paths, and not break the timing on others, was to make an exhaustive list of multi-cycle paths so that the synthesis tool did not make any assumptions of its own.

The tool I used did have wildcards, which helped a great deal, as I had all the paths in question (mostly buses) with easily recognized names with bit numbers.

Austin

Reply to
Austin Lesea

Hi Pippo,

Here are some guidelines and hints when using multicycle assignments.

"After timing analysis with Quartus II 5.0 i have a "lot of high setup violations" on paths between registers of the such type of FF1 and FF2 "

In the example design, there are no paths between FF1 and FF2, so any timing assignment will be ignored. But assuming such a path exists:

- The clock_enable_multicycle constraint must be related to a hard timing edge(flop/pin) that derives the clock enable. This could be either internal_EN1 or internal_EN2. This is usually good practice anyway, since making assignments to nets like internal_ENA can be dangerous, since synthesis tools often change combinatorial node names(yes, there are ways around this, but for now it's easier to use the flop)

- Think of the clock_enable_multicycle as a way to make a group and then apply a constraint. So everything that EN1 fans out to as a clock enable, even if it goes through logic, will be added to that group. So all that needs to be added is:

set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -to internal_EN1

- Note that the -from/-to version of this constraint is best applied when there are multiple clock enables feeding different groups of registers, and the user is trying to constrain paths between those groups. The Quartus Help -> Index -> clock_enable_multicycle shows this.

Hope this helps, Subroto Datta Altera Corp.

pippo wrote:

Reply to
Subroto Datta

Thanks Austin, I'd like to know what is the tool you're speaking about and if this tool act on vhdl or edif netlist. Salva

Reply to
pippo

Hi Salva,

Have a look at fishtail

formatting link
not cheap but very powerful. As far as I know they support FPGA tools (ISE/Quartus/Precision/Synplify) although the main market is obviously ASICs. You just give it your RTL files and specify your clock and mode pins and the tool will then automatically create an SDC file listing all the FPs and MCP's found in your design.

Hans

formatting link

Reply to
Hans

pipo,

I was using DC compiler for Verilog (or VHDL, but I was using verilog) from Synopsis.

This was for the DCM's DFS "brain" which has a number of clock crossings, and quite a few multi-cycle paths. It was hell until we just figured out how to state all the constraints properly.

Multi-cycle paths were the worst, because any general statement seemed like permission to ignore the critical single cycle paths!

I am sure this is not unique to DC, as constraining a design during synthesis is probably the hardest step (after creating a design that simulates properly), and once taken, is even harder to verify that it was done properly (especially in a large complex design).

Aust> Thanks Austin,

Reply to
Austin Lesea

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.