positive edge trigger rtl

[sun_ray]

positive edge to pulse rtl

Can anybody please write the rtl for a module which can generate a pulse on getting a positive edge ?

 

[mail4idle2]

Represent what you need in diagram.

 

[sun_ray]

Represent what you need in diagram.

It is a familiar circuit so no need to represent in a diagram.

 

[morris_mano]

module pulse_rise(
   input clk,
   input rst,
   input signal_a,
   output signal_rise);

reg  signal_reg1, signal_reg2;
wire signal_rise;

always @ (posedge clk, posedge rst) begin
     if(rst) begin
         signal_reg1 <= 1'b0;
         signal_reg2 <= 1'b0;
     end else begin
         signal_reg1 <= signal_a;
         signal_reg2 <= signal_reg1;
     end
end

assign signal_rise = signal_reg1 & ~signal_reg2;

endmodule

 

[Prashanthanilm]

Hey Morris,


assign signal_rise = signal_reg1 & ~signal_reg2;

Since signal_reg1 and signal_reg2 are wires carrying different signals, it wont effect signal_rise output huh?

 

[rca]

Morris_mano write a code to generate a pulse for the rising edge of signal_a.
A question for sun_ray, if it is so simple that no diagram or schematic is needed why he could not write the rtl code?

 

[sun_ray]

Morris_mano code will work with a little change.

But Morris_mano uses a AND gate and also an inverted output in the following line:
assign signal_rise = signal_reg1 & ~signal_reg2;

But, can anybody provide a solution at more behavioural level so that the code does not contain this and and inversion signs? The code should be such that it will automatically infer the AND gate and the inverter at its input.

 

[morris_mano]

Sun_ray,

Simply replace assign statements with

always @ (*) begin
   if((signal_reg1== 1'b1) && (signal_reg2 == 1'b0)) begin
       signal_rise = 1'b1;
   end else begin
       signal_rise = 1'b0;
   end
end

@rca: signal_rise is indeed a pulse.

 

[sun_ray]

Sun_ray,

Simply replace assign statements with

always @ (*) begin
   if((signal_reg1== 1'b1) && (signal_reg2 == 1'b0)) begin
       signal_rise = 1'b1;
   end else begin
       signal_rise = 1'b0;
   end
end

@rca: signal_rise is indeed a pulse.

Morris_mano

Here in your code, it will synthesize to two flops. Is it necessary to use two flipflops?
Here, one flipflop should be sufficient.

 

[morris_mano]

It is safer to use two flipflops so that your signal_rise will change only on clock edge. If you use only one flops, and your input signal_a is not a registered signal, then glitch on signal_a may glitch your signal_rise output.

If your signal_a is a registered signal in same clock domain then you could get away with one flop edge detection.

 

[FvM]

Here in your code, it will synthesize to two flops. Is it necessary to use two flipflops?
Here, one flipflop should be sufficient.

It turns out that the original question is not clear at all, because it doesn't mention the timing relation between clk and input signal.

In the general case (timing unrelated), you need three flip-flops to handle possible metastable events, two synchronizers and one edge differentiator.

I didn't yet consider the case that the input signal is smaller than a clock cycle. In this case, a toggle synchronizer would be suggested.

 

[onion2014]

Do you mean this?

My code can only detect the pulses that are one clock away from each other. the signal drive the first flip flop,FF1, which toggles its output when signal has risedge. and then the output of the FF1 works as input of FF2, FF2 works as input of FF3, output= D_{ff2} xor D_{ff3};

I don't know how to detect random signal waveform, which i mean the timing distance between two risedges of the signal is less than one clock cycle.
anyone has idea?

module pulsegenerateonposedge(
clk,
signal,
rst_output,
out
);

input clk,signal;
input rst_output;
output out;

reg reg1,reg2,reg3;
wire out;

assign out = reg2^reg3;

always @(posedge signal or negedge rst_output)
begin
if (rst_output == 1'b0)
reg1 <= 1'b0;
else
reg1 <= ~reg1;
end


always @(posedge clk or negedge rst_output)
begin
if(rst_output == 1'b0)
{reg3,reg2} <= 2'b00;
else
{reg3,reg2} <= {reg2,reg1};
end

endmodule

sorry i don't know how to wrap the code like above, which has a scroll bar.

It turns out that the original question is not clear at all, because it doesn't mention the timing relation between clk and input signal.

In the general case (timing unrelated), you need three flip-flops to handle possible metastable events, two synchronizers and one edge differentiator.

I didn't yet consider the case that the input signal is smaller than a clock cycle. In this case, a toggle synchronizer would be suggested.

 

[FvM]

sorry i don't know how to wrap the code like above, which has a scroll bar

Use a code tag (# symbol in tool bar)

My code can only detect the pulses that are one clock away from each other. the signal drive the first flip flop,FF1, which toggles its output when signal has risedge. and then the output of the FF1 works as input of FF2, FF2 works as input of FF3, output= D_{ff2} xor D_{ff3};

Your code shows a classical toggle synchronizer.

I don't know how to detect random signal waveform, which i mean the timing distance between two risedges of the signal is less than one clock cycle.
anyone has idea?

The answer depends on the exact meaning of detect? Count the number of clock edges (up to a certain number), or detect the presence of at least one clock edge?

Counting edges can work with a gray encoded counter on the source clock domain. Detecting the presence of at least one edge requires some kind of handshake between both clock domains. Random signal waveforms must respect the minimum pulse width specification of the used logic family anyway.

 

[onion2014]

Use a code tag (# symbol in tool bar)


Your code shows a classical toggle synchronizer.


The answer depends on the exact meaning of detect? Count the number of clock edges (up to a certain number), or detect the presence of at least one clock edge?

Counting edges can work with a gray encoded counter on the source clock domain. Detecting the presence of at least one edge requires some kind of handshake between both clock domains. Random signal waveforms must respect the minimum pulse width specification of the used logic family anyway.

Thanks.I agree with you that the timing between the signal and the clk should be specified. I don't understand your comment

Counting edges can work with a gray encoded counter on the source clock domain. Detecting the presence of at least one edge requires some kind of handshake between both clock domains.

can you recommend some articles about this(preferred :-D) or give more details.
my question is "do you mean using a gray counter in the source clock domain and then send the counter value to the receiving domain"? the received gray number is used to compared with another number in the received clock domain and then generate the pulse.

for example, the source clock domain has a gray count 0110 and the destination domain has a gray count of 0001, then it in the destination clock domain, it will generate three pulse width?

i read articles about asynchrous fifo and handsaking is included there. but i can not understand how hand shaking is applied here.

 

[FvM]

I don't have literature at hand, I'm designing these things according to the respective requirements, or use stanadard IP like domain crossing FIFO where applicable.

Your requirement isn't clear yet, counting multiple pulses or just detect presence of >=1 pulse?

 

[onion2014]

I don't have literature at hand, I'm designing these things according to the respective requirements, or use stanadard IP like domain crossing FIFO where applicable.

Your requirement isn't clear yet, counting multiple pulses or just detect presence of >=1 pulse?

sorry for the confusion, how about counting the edges? is that what you mean in #13. you said "counting edge can work with a gray code counter....",

using gray code mean every moment at most one bit is changing. no matter whether that toggling bit passed to the new clk domain or not, it will not be a problem. while using binary code, multi-bits area changing at the same time, so the value passed to the new clk domain might has a large error. but using gray code can only introduce a small error, which results from one bit in gray code. is this right?

thanks.

 

[FvM]

I almost agree with the explanation, except for the term "error". In my view, the essential point in clock domain synchronization is that the unavoidable timing uncertainty isn't allowed to cause errors.

For the perviously discussed problem of not more than one pulse per clock cycle error-free synchronization means that one pulse must be counted exactly as one. Timing uncertainty can cause that a pulse near the clock edge is "seen" in the next cycle, but it must neither be lost nor double counted.

By using a gray encoded counter this kind of error-free synchronization can be extended to multiple pulses per clock cycle or generally speaking to multi-valued signals. It can work as long as the timing uncertainty caused by jitter and bit delay skew is sufficiently smaller than the count period.