Dual edge detection

Hi newsgroup,

As shown in the VHDL code I am feeding two flip flop chains with the same input. The chains use complementary clocks (200Mhz).

In the process "rise_fall" I do some combinational logic to detect rising and falling of the sampled input.

Now I want to use one of the combinational signals as a clock in a process "clksel" to sample the second combinationl signal.

Speaking in terms of functional simulation the function of the hardware description is the following: The signal which gets active first is used for ClockSel.

The output ClockSel is then used to feed a DCS module.

The problem I see in this hardware description is that the clock in the process "clksel" is a gated clock.

What is your opinion about the desription ? How can I modify it to make it synthesizable ? Is there some need for additional constraints ?

library ieee; use ieee.std_logic_1164.all;

entity ana is port( Reset : in std_logic; Clk : in std_logic; DataIn : in std_logic; ClockSel : out std_logic ); end ana;

architecture arch_ana of ana is

signal r_p1, r_p2, r_p3 : std_logic; signal f_p1, r_p2, r_p3 : std_logic;

signal trig_rise, trig_fall : std_logic;

begin

------------------------------------ sync_redge: process(Reset, Clk) begin if Reset='1' then r_p1

Reply to
ALuPin
Loading thread data ...

Why do you need to make the clksel process asynchronous to Clk? It would seem to me that trig_fall can only change as a result of a negative edge of Clk. So unless you really want a lot of delay from the negative clock edge to the ClockSel signal, I would think you'd just use the falling edge of Clk and the f_p1 and f_p2 signals as clock enables. Or did you do this to avoid a clock delay? Is DataIn asynchronous to Clk?

Reply to
Gabor

Reply to
Peter Alfke

Wouldn't hurt. Usenet is a very poor simulator.

-- Mike Treseler

Reply to
Mike Treseler

ALuPin,

Rather than using two chains on two different edges, how about changing both input phases to one domain? The clocking is much easier and the delay penalty is only a half clock (2.5 ns in your case). When the data comes together in the common domain, an edge at the front of this domain occurs if the transition is in the two sampled bits: current and half-delayed; an edge (half-cycle earlier) at the start of the delayed domain is indicated by a data change between the previous cycle's normal sample and the current cycle's delayed sample. There's two phases of algorithm in one domain rather than two phase domains for one algorithm. You could keep all processing in this common time domain until you're ready to interface back to the external world where you can directly apply DDR IOB registers. Clean, friendly.

The technique can push internal DDR at full Xilinx global clock rates - 330 MHz for the Spartan 3E for 660 Mb/s DDR processing - by using a latch rather than a register to transfer the delayed data (with appropriately altered timing constraints) if the time between opposite clock edges is too small for Tcko+Tnet+Tsu in a simple register delay.

- John_H

Reply to
John_H

Hi John,

yes that what the approach I was thinking of: changing to one clock domain. The point is to constraint the timing when changing from one clock domain to the other. Thank you for your opinion.

Mike, usenet is sometimes also poor in answering with more than a couple of single words.

Rgds Andre

Reply to
ALuPin

Hi John,

yes, your proposal seems to be a good approach. Setting a timing constraint to achieve setup time margin when changing the clock domain is the point which should be kept clearly in mind.

Thank you for your opinion.

Rgds Andre

-

Wouldn't it be nice to read serious answers consisting of more then just snatches of sudden inspirations ? Usenet is sometimes poor in respect thereof.

Reply to
ALuPin

Sounds like a job for TechXclusives! Or XAPPs for that matter. I was impressed with how some of my more unusual work already had a couple of application notes dealing with the techniques I was developing.

Reply to
John_H

Reply to
Peter Alfke

As long as you are using just different edges of the same clock, a period timing constraint will automatically take into consideration that you have changed clock edges.

Reply to
Duane Clark

That is true, indeed, as long as you're using registers. If you use a latch to provide more generous timing margins to synchronize between two time domains, the timing analyzer needs to by "nudged" to get the proper set of constraints. "ENABLE=lat_d_q;" is insufficient to get the setup to the trailing edge of the latch clear pulse at the correct clock edge if memory serves.

- John_H

Reply to
John_H

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.