Alternatives to always@(posedge clk, negedge clk)

[promach]

How would using this Dual Edge FF result in glitches ?

Could anyone advise other alternatives circuit to trigger on both posedge clk and negedge clk in the case of DDR memory?

Note: clk signal being 90 degrees phase-shifted is similar to negedge clk

 

[BradtheRad]

alternatives circuit to trigger on both posedge clk and negedge clk?

Simple circuit converts positive-going edge to positive spike. Do the same to the Qbar output (which is inversion of Q output). Then combine them through diodes to a single output.

 

[promach]

Thanks for your idea, I am trying to do this in verilog coding

What do you think about https://patentimages.storage.googleapis.com/0e/94/46/6fdcafc946e940/US5297181.pdf#page=3 ?

 

[dpaul]

You can use structural modeling with Verilog and implement the above logic.
What is the problem with Verilog coding? Where is the code you have tried?

There above excerpt seems very old to me. All modern FPGAs have IDDRs and ODDRs (these are flops capable of working with dual edges of the clock) and you simply use them rather than trying to re-invent the wheel (if the design is meant to be implemented with a FPGA).

always(@posedge clock) or always(@negedge clock) would also work and functional verification will also work. But modeling a design with RTL and simulating it is just the 1st step. It is very difficult to perform STA and write timing constraints for a design modeled with pos and neg edges.

 

[promach]

@dpaul See https://gist.github.com/promach/2c4...d678c#file-ddr3_memory_controller-v-L126-L171

 

[dpaul]

Yes I know DDR interfaces must have dual edge flops. But have you written a timing constrain for your design? That's when the complexity will come in.

 

[promach]

how to generate 90 degree phase-shifted (which is equivalent to negedge clk) clock using clock divider mechanism ?

 

[dpaul]

how to generate 90 degree phase-shifted (which is equivalent to negedge clk) clock using clock divider mechanism ?
In FPGAs it is relatively easy to do it. But here were are in the ASIC sub-forum.

If you want to have an answer to the above you have to tell me which FPGA you are using/intend to use (if your design is intended for FPGA implementation).

 

[promach]

Someone told me the following, but I am bit confused with his sentence wordings.

the CK has a positive edge at clockDivider=4 and a negative edge at clockDivider=12, so 90 degrees after the positive edge is at clockDivider=8 and 90 degrees after the negative edge is at clockDivider=0

 

[FvM]

Most DDR in- and output circuits I have seen don't use dual edge FFs but combination of positive and negative clocked FFs. See e.g. functional schematics of decicated DDR circuits in Intel FPGA.

It's not clear which hardware is targeted by this thread. The initial quote is e.g. talking about infeasibility of synthesizing dual edge FFs in FPGA and thus suggesting an emulation circuit. The existence of dedicated DDR circuit blocks in FPGA doesn't change anything to this fact.

 

[promach]

Yes I know DDR interfaces must have dual edge flops. But have you written a timing constrain for your design? That's when the complexity will come in.

For DDR3 memory controller. See DQS and DQ signal pair which is basically DDR (require both posedge clk and negedge clk)

As for CK and Command bus signal pair, I have a side question: do these two signal require 90 degree phase shift as DQS and DQ signal pair ?
In other words, should Command bus signal be strictly aligned with CK , not 90 degree out-of-phase with respect to CK ?

 

[dpaul]

@promach,

As for CK and Command bus signal pair, I have a side question: do these two signal require 90 degree phase shift as DQS and DQ signal pair ?
In other words, should Command bus signal be strictly aligned with CK , not 90 degree out-of-phase with respect to CK ?
In order to answer this question, I need to study the DDR spec first and then think about how the signals can be implemented.
I have only used DDR* controller IP cores in my designs and do not have in depth knowledge regarding their internal working.

Once again, as FvM and me have pointed out, the implementation details depends a lot on the target hardware implementation, FPGA or ASIC.