Xilinx DCM and Timing Constraints

Hi folks,

I have outputs being driven by a fast internal clock generated by a DCM. It would seem to me that I should be able to set up a clock to pad timing constraint for this animal. But the Xilinx tools says I need to specify a pad as the clock, and the DCM outputs don't show up as a viable clock source in the drop down menus, I would assume because they are not pads. What is the right procedure here?

Brad Smallridge b r a d @ A i V i s i o n . c o m

415-661-8068
Reply to
Brad Smallridge
Loading thread data ...

It

source

Why do you need to specify the clock-to-pad timing? Because you're interfacing with other chips in your system? Since they don't have access to the DCM inside the FPGA, they need an external clock as a reference. At least this is the case with most systems. The clock that's used as the DCM reference would be the appropriate clock to use in the timing constraints.

Reply to
John_H

Well, I drive the SRAM clock with a synthesized higher frequency. Shouldn't the timing from the output registers of the FPGA, going to the address lines and control lines of the SRAM, be constrained relative to the higher clock frequency that is clocking these registers?

Reply to
Brad Smallridge

Shouldn't

lines

If you're using IOB registers, the timing would be contained defacto.

The timing still ends up needing to be relative to something. The SRAM clock comes from a synthesized higher frequency. Do you have a common reference between the SRAM clock synthesizer and the DCM? Your timing budget ends up being relative to that common reference. If you're using the DCM in frequency synthesis mode, the relationship between the clocks becomes less obvious, particularly to the SRAM. The clock to the SRAM and the data to/from the FPGA either are related or your data and SRAM clock will be random relative to each other.

Reply to
John_H

That is another issue I am working on. The tristate DQs have been properly assigned to the IOBs, probably since they can only really live there. For some reason, however, the XST tool wants to put the address register in slices rather than IOBs. I am a newbie to this stuff and haven't been able to figure out how to get them into the IOBs. One way, I thought, would be to constrain the clock to pad timing, but it doesn't seem to work.

I'm not sure what you are saying. I am driving the SRAM clock from the DCM through an output pad.

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity v6 is port( oscin : in std_logic ; sramclk : out std_logic; coreclk : inout std_logic; srama : out std_logic_vector(20 downto 0); -- address sramdqa : inout std_logic_vector(9 downto 1); -- data a sramdqb : inout std_logic_vector(9 downto 1); -- data b srame1 : out std_logic; -- chip enable 1 sramba : out std_logic; -- a data write enable srambb : out std_logic; -- b data write enable sramw : out std_logic; -- write enable tpaup : in std_logic; -- switch tpadown : in std_logic; -- switch fx2fd : out std_logic_vector(15 downto 0); -- here used as a test bnc : out std_logic ); end v6;

architecture v6behave of v6 is

COMPONENT sramdcm PORT( RST_IN : IN std_logic; CLKIN_IN : IN std_logic; LOCKED_OUT : OUT std_logic; CLKFX_OUT : OUT std_logic; CLKFX180_OUT : OUT std_logic; CLK0_OUT : OUT std_logic); END COMPONENT;

type sram_state_type is ( sram_state_write, sram_state_read, sram_state_reset, sram_state_idle );

signal sram_state : sram_state_type; signal sram_state_1 : sram_state_type; signal sram_state_2 : sram_state_type; signal sram_state_3 : sram_state_type; signal sram_state_4 : sram_state_type; signal sram_state_5 : sram_state_type;

signal sram_addr_delay_1 : std_logic_vector(20 downto 0); signal sram_addr_delay_2 : std_logic_vector(20 downto 0); signal sram_addr_delay_3 : std_logic_vector(20 downto 0); signal sram_addr_delay_4 : std_logic_vector(20 downto 0); signal sram_w_1 : std_logic; -- mirrors sramw output pin signal sram_w_2 : std_logic; -- mirrors sramw output pin signal sram_w_3 : std_logic; -- mirrors sramw output pin signal sram_w_4 : std_logic; -- mirrors sramw output pin

signal sram_input_a : std_logic_vector(9 downto 1); signal sram_input_b : std_logic_vector(9 downto 1);

signal sram_dqa_2 : std_logic_vector(9 downto 1); signal sram_dqa_1 : std_logic_vector(9 downto 1); signal sram_dqa_0 : std_logic_vector(9 downto 1); signal sram_dqb_2 : std_logic_vector(9 downto 1); signal sram_dqb_1 : std_logic_vector(9 downto 1); signal sram_dqb_0 : std_logic_vector(9 downto 1); signal sramclk180 : std_logic;

signal tpaselect_1: std_logic; signal tpaup_1 : std_logic; signal tpadown_1 : std_logic;

signal vga_col : std_logic_vector(9 downto 0); signal vga_row : std_logic_vector(9 downto 0); signal image_col : std_logic_vector(9 downto 0); signal image_row : std_logic_vector(9 downto 0);

signal test_a123 : std_logic; signal test_a456 : std_logic; signal test_a789 : std_logic; signal test_b123 : std_logic; signal test_b456 : std_logic; signal test_b789 : std_logic; signal test_a : std_logic; signal test_b : std_logic;

begin -- sram dcm set for frequency systhesis Inst_sramdcm: sramdcm PORT MAP( RST_IN => '0', CLKIN_IN => OscIn, LOCKED_OUT => open, CLKFX_OUT => sramclk, CLKFX180_OUT => sramclk180, CLK0_OUT => coreclk );

sram_states_process:process(sramclk180) begin if(sramclk180'event and sramclk180='1') then case sram_state is when sram_state_read =>

-- branch frm here to all other states if( tpadown_1 = '0' ) then sram_state

Reply to
Brad Smallridge

DCM

First, I'd see if I could drive the SRAM clock from a *register* driven by the DCM allowing matched delays for the clock and data. The phasing might make that unreasonable but it's a suggestion.

The clock that serves as the reference for the DCM has a clk-to-out for the SRAM clock relative to the reference clock. The clock that drives the data has a clock-to-out for that data relative to the reference clock.

These reference clocks to output are where the constraints would be.

As for your VHDL, my apologies: I'm a Verilog guy and parsing through VHDL would give me a headache. I'm hoping someone else can help you find how to get your registers into the IOBs.

Reply to
John_H

Well, thanks for all your help. I am new to VHDL and totally unequipped in Verilog.

I just found the problem with the IOB's. Seems as both the Synthesize tool and the Map tool, both have a pack register command. Turning these both on seems to have packed all the IOBs.

SRAM

the

to

VHDL

to

Reply to
Brad Smallridge

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.