Signal high for a specific time - vhdl

Question

I made a VHDL Design which consists of 2 Modules. One handles the communication and runs at 100 Mhz (I can't change this). The other module does the calculation and has to run at 45 Mhz because of timing.
The second module has an input pin called "newPair" which I want to set to high when new data is ready and can be processed by the second module. Now my second module only works on the rising edge of the clock so I need to set this pin one 45 Mhz clock cycle high and then pull it down low. This has to be done from the module which runs at 45 Mhz. How can I accomplish this? I though about creating a DCM for this purpose but this seems a little bit overpowered for this.
Thanks!
Update:
I'm working on a Spartan-6 (xc6slx150)

Answer 1

Your design has 2 clock domains, so you'll need synchronizer circuits to transfer information from one clock domain to the other.
Part 1 - Synchronizers
The basic synchronizer is build of 2 chained D-FF. This synchronizer can be used for flag signals (these are signals not changing very often). It can not be used for strobe signals (these are signals, which are high for 1 cycle), because strobes can be missed or double seen on the destination clock domain.
2 D-FF synchronizer:
genLoop : for i in Input'range generate
signal Data_async : STD_LOGIC;
signal Data_meta : STD_LOGIC := '0');
signal Data_sync : STD_LOGIC := '0' ;
begin
Data_async <= Input(i);
process(Clock)
begin
if rising_edge(Clock) then
Data_meta <= Data_async;
Data_sync <= Data_meta;
end if;
end process;
Output(i) <= Data_sync;
end generate;
This code can be improved by vendor specific VHDL attributes. See my linked source for a generic, an Altera and a Xilinx variant.
Source: PoC.misc.sync.Bits
See also these timing constraints stored in UCF files for Xilinx ISE designs:
- https://github.com/VLSI-EDA/PoC/blob/master/ucf/MetaStability.ucf
- https://github.com/VLSI-EDA/PoC/blob/master/ucf/misc/sync/sync_Bits_Xilinx.ucf
Part 2 - Building a synthesizer circuit for strobe signals
A strobe capable cross clock synchronizer is build of:
1 T-FF to encode signal changes in the source clock domain
2 D-FF as a flag synchronizer, as described in part 1
a change detector to restore the original value in the destination clock domain (1 D-FF and an XOR)
This synchronizer can be used to transfer your newPair signal to the 45 MHz clock domain. You will need the same circuit for the way back :)
The following example implements a busy signal to indicate the transfer process. Asserting Input while Busy is high leads to ignored strobes.
entity sync_Strobe IS
generic (
BITS : POSITIVE := 1; -- number of bit to be synchronized
GATED_INPUT_BY_BUSY : BOOLEAN := TRUE -- use gated input (by busy signal)
);
port (
Clock1 : in STD_LOGIC; -- <Clock> input clock domain
Clock2 : in STD_LOGIC; -- <Clock> output clock domain
Input : in STD_LOGIC_VECTOR(BITS - 1 downto 0); -- #Clock1: input bits
Output : out STD_LOGIC_VECTOR(BITS - 1 downto 0); -- #Clock2: output bits
Busy : out STD_LOGIC_VECTOR(BITS - 1 downto 0) -- #Clock1: busy bits
);
end entity;
architecture rtl of sync_Strobe is
attribute SHREG_EXTRACT : STRING;
signal syncClk1_In : STD_LOGIC_VECTOR(BITS - 1 downto 0);
signal syncClk1_Out : STD_LOGIC_VECTOR(BITS - 1 downto 0);
signal syncClk2_In : STD_LOGIC_VECTOR(BITS - 1 downto 0);
signal syncClk2_Out : STD_LOGIC_VECTOR(BITS - 1 downto 0);
begin
gen : for i in 0 to BITS - 1 generate
signal D0 : STD_LOGIC := '0';
signal T1 : STD_LOGIC := '0';
signal D2 : STD_LOGIC := '0';
signal Changed_Clk1 : STD_LOGIC;
signal Changed_Clk2 : STD_LOGIC;
signal Busy_i : STD_LOGIC;
-- Prevent XST from translating two FFs into SRL plus FF
attribute SHREG_EXTRACT OF D0 : signal is "NO";
attribute SHREG_EXTRACT OF T1 : signal is "NO";
attribute SHREG_EXTRACT OF D2 : signal is "NO";
begin
process(Clock1)
begin
if rising_edge(Clock1) then
-- input delay for rising edge detection
D0 <= Input(I);
-- T-FF to converts a strobe to a flag signal
if (GATED_INPUT_BY_BUSY = TRUE) then
T1 <= (Changed_Clk1 and not Busy_i) xor T1;
else
T1 <= Changed_Clk1 xor T1;
end if;
end if;
end process;
-- D-FF for level change detection (both edges)
D2 <= syncClk2_Out(I) when rising_edge(Clock2);
-- assign syncClk*_In signals
syncClk2_In(I) <= T1;
syncClk1_In(I) <= syncClk2_Out(I); -- D2
Changed_Clk1 <= not D0 and Input(I); -- rising edge detection
Changed_Clk2 <= syncClk2_Out(I) xor D2; -- level change detection; restore strobe signal from flag
Busy_i <= T1 xor syncClk1_Out(I); -- calculate busy signal
-- output signals
Output(I) <= Changed_Clk2;
Busy(I) <= Busy_i;
end generate;
syncClk2 : entity PoC.sync_Bits
generic map (
BITS => BITS -- number of bit to be synchronized
)
port map (
Clock => Clock2, -- <Clock> output clock domain
Input => syncClk2_In, -- #async: input bits
Output => syncClk2_Out -- #Clock: output bits
);
syncClk1 : entity PoC.sync_Bits
generic map (
BITS => BITS -- number of bit to be synchronized
)
port map (
Clock => Clock1, -- <Clock> output clock domain
Input => syncClk1_In, -- #async: input bits
Output => syncClk1_Out -- #Clock: output bits
);
end architecture;
Source: PoC.misc.sync.Strobe
Part 2 - Special synthesizer circuits
I assume you'll also transfer data from one clock domain to the other one. So you'll need either a multi bit synchronizer (build upon the strobe synchronizer) or a cross clock capable FIFO.
The PoC-Library, I'm contributing to, has also multi bit/vector synchronizers. See the other modules in the linked source folder. And there is a cross clock / independent clock (ic) FIFO, too.

Answer 2

You don't need to assert some signal for a specific amount of time.
If the data exchange between first and second modules happens sparsely, you can use level triggering to let the second block know the data is ready. (You can read this answer to understand the difference between level and edge triggering).
If you need to handle streaming data, you'll need to use an asynchronous FIFO. (This answer may give you more info on this).
As an advice, I wouldn't use the signal assertion for a specific number of cycles approach because it's not a good practice for reusable code (it works for this specific design but you may need to recalibrate the number of cycles if the period of your clocks change for some reason).