Xilinx XST 6.3i: Typo in generics, silent failure?

The only way I could see this happening is if 1) you do not simulate the circuit and 2) You have synthesis translate_off / translate_on's around the generics in the instantiation code. The reason I say this is if you attempt to simulate this with a bad generic regardless of whether you use translate_off / on in the code, you should see binding errors. If you did not use any translate_off / ons in the code, you should have seen errors during either XST or NGDBUILD as it would have identified the incorrect parameter and properly warned but if those are in the code, the tools ignore them as you are instructing with those commands. I highly suggest to use the HDL Templates (Edit --> Language Templates

--> VHDL --> Device Primitive Instantiation --> FPGA --> Clocking Components --> Digital Clock Manager --> DCM) or the Architecture Wizard (Project --> New Source --> IP --> Clocking) to form the instantiation of the DCM. As a beginner, you may want to look at Architecture Wizard as it provides a graphical way to configure the component which helps out in understating this if you are unfamiliar with it. If you prefer doing it yourself, I suggest grabbing the DCM instantiation from the HDL Templates. Using that predefines all attributes so there is no mistakes in typing and also notice there are no "--synthesis translate_off" in there which can also cause the issue as I explained. Either way would likely help avoid this situation.

-- Brian

Marius Vollmer wrote:

This is not my experience. Timing constraint: NET clkgen_clk_100_buf PERIOD = 10 nS HIGH 5 nS

But par does not see this constraint, I think. If I put the constraint in a .ucf file, then par does see it. Hmmm.

Thanks a lot, Brian!

Here is the code fragment:

-- clock_generator -- generates deskewed system clocks and handles reset

library ieee; use ieee.std_logic_1164; library unisim; use unisim.vcomponents.all;

use work.common.all;

entity clock_generator is

generic ( clk_var_mult : positive; -- Frequency multiplier for variable clock clk_var_div : positive); -- Frequency divider port ( -- external connections clk_100_in : in u1; -- 100MHz Clock from external oscillator clk_sd_out : out u1; -- 100MHz to SDRAM clk_sd_in : in u1; -- 100MHz feedback from SDRAM reset_in : in u1; -- Reset input from switch

-- global clock and reset clk_100 : out u1; -- Deskewed 100MHz clock, suitable for the -- SDRAM controller, for example. clk_var : out u1; -- Variable frequency clock, see generics. reset : out u1); -- Reset end entity;

architecture syn of clock_generator is signal clk_sd_in_buf, clk_100_deskewed, clk_100_buf : u1; signal clk_var_unbuf, clk_var_buf : u1; signal locked : u1;

attribute period : string; attribute period of clk_100 : signal is "10 ns"; -- XXX - no effect attribute period of clk_var : signal is "40 ns"; -- XXX - no effect begin

-- The 100MHz clock is directly routed to the SDRAM. The clock for -- internal logic is deskewed with respect to the clock coming back -- from the SDRAM. clk_sd_out clk_sd_in, o => clk_sd_in_buf); deskew: DCM generic map ( clkfx_mult => clk_var_mult, -- XXX - no error for this clkfx_div => clk_var_div, -- XXX - no error for this hi_xst_how_is_your_day => 0, -- XXX - no error for this clkin_period => 10.0) port map ( rst => reset_in, clkin => clk_sd_in_buf, clkfb => clk_100_buf, clk0 => clk_100_deskewed, clkfx => clk_var_unbuf, locked => locked);

buf_clk_100: BUFG port map ( i => clk_100_deskewed, o => clk_100_buf);

buf_clk_var: BUFG port map ( i => clk_var_unbuf, o => clk_var_buf);

clk_100

Hmmm. That is not how it is supposed to work. We are looking into this and either I or someone else will get back to you. XST is supposed to catch this but perhaps something strange is happening.

-- Brian

Marius Vollmer wrote:

Excellent! Thank you very much.

If you need more information to reproduce this bug, I will be happy to provide it, of course.

Marius,

I have reproduced the behaviour you are seeing and I agree that this is indeed a defect that needs to be addressed. If pin names are misspelled, an error is generated, and we don't see the same behaviour when defparams are used in Verilog to perform the equivalent function. I will check to see how soon the XST team can build a fix.

In the meantime, one solution would be to copy the DCM component declaration found in $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd into your HDL source and remove all the generics you are not using in that architecture (leave all the pins though). This will allow XST to compare your instantiation's generics to this local declaration and will cause your testcase to produce an error (3 errors actually).

This is correct. Any timing specifications applied during synthesis either through an .XCF file or within the HDL source will not be sent to implementation by default. To enable this feature use the "Write Timing Constraints" command line / ISE option. We determined that users were more likely to start their timing constraints in UCF for implementation, then go back and add them to synthesis if necessary (in an XST flow), so we didn't want to add the extra or redundant constraints the implementation flow without the user's explicit consent.

thanks, david.

David Dye Xilinx Technical Marketing