Help With simple DCM VHDL

[loki3118]

Hello,

I'm a noob to VHDL and FPGA

I've written a simple code consisting of two counters that count down from 15. Both the clocks functioned as planned. Next wanted to implement DCM into the code in order to
phase shift the clock signals 90 degrees and run them both at 32MHz. I've run into some problems implementing the DCM code into my existing code. When I try to use the new output
clock signals I get some error and I'm not sure why. I tried to feed the output clocks directly into my counter code. This gave the following error: Parameter clk0/clk90 of mode in cannot be
associated with a formal port of mode out.

My questions are what does this error mean?
Is it possible to directly feed the two counting functions the output from the DCM if not what would be the best way to control the counters?

This code is just a starting place for a more complicated system that uses all four of the DCM outputs.

The code was written on ISE 14.5, eventually intended for spartan 3e.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
entity Counter2_DCM is
    Port ( clk : in  STD_LOGIC;
           reset : in STD_LOGIC;
           clk0 : in  STD_LOGIC;
           clk90 : in  STD_LOGIC;
           DIRECTION0 : in  STD_LOGIC;
           DIRECTION90 : in  STD_LOGIC;
           COUNT_OUT0 : out  STD_LOGIC_VECTOR (3 downto 0);
           COUNT_OUT90 : out  STD_LOGIC_VECTOR (3 downto 0));
end Counter2_DCM;

----------------------------------------------------------------------------------
architecture Behavioral of Counter2_DCM is

	COMPONENT DCM1
	PORT(
		CLKIN_IN : IN std_logic;
		RST_IN : IN std_logic;          
		CLKIN_IBUFG_OUT : OUT std_logic;
		CLK0_OUT : OUT std_logic;
		CLK2X_OUT : OUT std_logic;
		CLK90_OUT : OUT std_logic;
		LOCKED_OUT : OUT std_logic
		);
	END COMPONENT;

signal count_int0 : std_logic_vector(3 downto 0) := "0000";
signal count_int90 : std_logic_vector(3 downto 0) := "0000";
signal locked : std_logic;
----------------------------------------------------------------------------------
begin

	Inst_DCM1: DCM1 PORT MAP(
		CLKIN_IN => clk,
		RST_IN => reset,
		CLKIN_IBUFG_OUT => open,
		CLK0_OUT => clk0, 
		CLK2X_OUT => open,
		CLK90_OUT => clk90,
		LOCKED_OUT => locked
	);

----------------------------------------------------------------------------------
process (clk0)

--ERROR:HDLParsers:1411 - "E:/Taylor/FPGA/DMC_counter/Counter1_DCM.vhd" Line 48. Parameter clk0 of mode in can not be associated with a formal port of mode out.

begin
	if clk0='1' and clk0'event then
		if DIRECTION0='1' then
			count_int0 <= count_int0 + 1;
		else
			count_int0 <= count_int0 - 1;
		end if;
	end if;
end process;
COUNT_OUT0 <= count_int0;
----------------------------------------------------------------------------------

process (clk90)

--ERROR:HDLParsers:1411 - "E:/Taylor/FPGA/DMC_counter/Counter1_DCM.vhd" Line 50. Parameter clk90 of mode in can not be associated with a formal port of mode out.
 
begin
	if clk90='1' and clk90'event then
		if DIRECTION90='1' then
			count_int90 <= count_int90 + 1;
		else
			count_int90 <= count_int90 - 1;
		end if;
	end if;
end process;
COUNT_OUT90 <= count_int90;
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
end Behavioral;

 

[K-J]

Hello,

I tried to feed the output clocks directly into my counter code. This gave the following error: Parameter clk0/clk90 of mode in cannot be
associated with a formal port of mode out.

My questions are what does this error mean?

It means that you have an input that you are trying to drive as an output. In your case
- The entity defines clk0 and clk90 as inputs
- When you instantiate the DCM, you've connected the clk0 signal to the CLK0_OUT port of component DCM1, but this component defines the CLK0_OUT port as being an output.

Is it possible to directly feed the two counting functions the output from the DCM?

Yes, you have two choices:
1. Change the entity to remove 'clk0' and make it a signal within the architecture instead.
2. Move the instantiation of the DCM to a new entity/architecture that instantiates both the DCM as well as your counter2_dcm. Then connect up the signals appropriately.

Option #1 you should be able to implement with a few keystrokes. Option #2 will take more work. Option #2 makes the DCM clock available to other stuff that you may (or may not) have going on. Option #1 does not let you use the DCM clock outside of your counter entity.

A variation on #1 that is even less work (but is a sloppy way of doing it) is to change clk0 from 'in' to 'buffer'. Ports of mode 'buffer' can be both driven as outputs and read from as an input.

Kevin Jennings

 

[loki3118]

Thank you Mr. Jennings for the quick response!

I appreciate the explanation of the error I was having. I went with your first suggestion and it work wonderfully. I'll keep in mind your second suggestion as I may encounter more problems in the future.

I do have another question regarding the fixed code. I ran a simulation through ISim with a computer generated test bench. It appears to be functional however there was some strange behavior that occurred during the beginning of the simulation, around 60ns. I've read about the DCM taking several cycles to lock, is this evidence of the delay in locking? Also what would cause the counter to extend over a standard period as in the first instant of 11.

 

[K-J]

I do have another question regarding the fixed code. I ran a simulation through ISim with a computer generated test bench. It appears to be functional however there was some strange behavior that occurred during the beginning of the simulation, around 60ns. I've read about the DCM taking several cycles to lock, is this evidence of the delay in locking? Also what would cause the counter to extend over a standard period as in the first instant of 11.

Since your waveforms don't include 'clk0' and 'clk90' it is impossible to say for sure but I suspect that the behavior is simply caused by the DCM not being locked yet as you surmised. You should be able to verify this by adding 'locked', 'clk0' and 'clk90' to the wave window. What you'll likely see is
- 'locked' is inactive until at least 70 ns (based on what you have shown, possibly longer)
- 'clk0' and 'clk90' stop toggling between approximately 50 and 70 ns (or at most they switch low during that time).

All of this is normal behavior for any sort of PLL or DCM. Those circuits need to essentially 'figure out' the exact frequency of the input before they are able to generate valid outputs. That is the reason why the 'locked' signal is always available as an output signal. In a design, you would likely want to use 'not(locked)' as a reset condition to all of your logic. Until 'locked' is active, the output clocks could potentially be running too fast and violate setup and hold times into your device which could then get state machines or counters into illegal states that are not recoverable short of a power cycle or some form of hard reset if your design supports it.

The simulation model is simply giving a simplified version of this locking function.

Kevin Jennings