Is this wrong behavior?

N

Neo

Guest
I have code something like this -

always @(posedge pclk or negedge presetn)
if (!presetn) begin
state <= IDLE;
r_ready <= 1'b0;
end
else begin
case(state)
IDLE: begin
r_ready <= 1'b0;
if(t_ready)
state <= START;
end
START: begin
-----
-----
endcase
end

The weird thing is that state is changing to start in the same clock
as t_ready is asserted.
Is this a possible behavior from the code above?


Thanks,
Neo
 
Neo wrote:
I have code something like this -

always @(posedge pclk or negedge presetn)
if (!presetn) begin
state <= IDLE;
r_ready <= 1'b0;
end
else begin
case(state)
IDLE: begin
r_ready <= 1'b0;
if(t_ready)
state <= START;
end
START: begin
-----
-----
endcase
end

The weird thing is that state is changing to start in the same clock
as t_ready is asserted.
Is this a possible behavior from the code above?


Thanks,
Neo
Click to expand...
Is the problem you're having in simulation only, not in the synthesized
circuit?

Is t_ready generated in logic clocked by pclk?

If you could zoom in to the relation of pclk to t_ready, what would be
their timing relationship?

May of the issues of "same cycle" behavior where the simulation output
changes in the same cycle as the input is because of clocking issues
where the input gets scheduled just before the clock transition events
are triggered.

Try changing your inputs to be out of phase from the clock. If you have
more than one clock though the edges are supposed to be concurrent, the
clock that generates t_ready may be scheduled one simulation event
before the pclk-triggered always block.

- John_H
 
On Sep 17, 11:43 pm, John_H <newsgr...@johnhandwork.com> wrote:
Neo wrote:
I have code something like this -

always @(posedge pclk or negedge presetn)
if (!presetn) begin
state <= IDLE;
r_ready <= 1'b0;
end
else begin
case(state)
IDLE: begin
r_ready <= 1'b0;
if(t_ready)
state <= START;
end
START: begin
-----
-----
endcase
end

The weird thing is that state is changing to start in the same clock
as t_ready is asserted.
Is this a possible behavior from the code above?

Thanks,
Neo

Is the problem you're having in simulation only, not in the synthesized
circuit?

Is t_ready generated in logic clocked by pclk?

If you could zoom in to the relation of pclk to t_ready, what would be
their timing relationship?

May of the issues of "same cycle" behavior where the simulation output
changes in the same cycle as the input is because of clocking issues
where the input gets scheduled just before the clock transition events
are triggered.

Try changing your inputs to be out of phase from the clock. If you have
more than one clock though the edges are supposed to be concurrent, the
clock that generates t_ready may be scheduled one simulation event
before the pclk-triggered always block.

- John_H
Click to expand...

Also make sure t_ready is assigned with a non-blocking <=
if it is clocked by pclk.
 
On Sep 18, 8:43 am, John_H <newsgr...@johnhandwork.com> wrote:
Neo wrote:
I have code something like this -

always @(posedge pclk or negedge presetn)
if (!presetn) begin
state <= IDLE;
r_ready <= 1'b0;
end
else begin
case(state)
IDLE: begin
r_ready <= 1'b0;
if(t_ready)
state <= START;
end
START: begin
-----
-----
endcase
end

The weird thing is that state is changing to start in the same clock
as t_ready is asserted.
Is this a possible behavior from the code above?

Thanks,
Neo

Is the problem you're having in simulation only, not in the synthesized
circuit?

Is t_ready generated in logic clocked by pclk?

If you could zoom in to the relation of pclk to t_ready, what would be
their timing relationship?

May of the issues of "same cycle" behavior where the simulation output
changes in the same cycle as the input is because of clocking issues
where the input gets scheduled just before the clock transition events
are triggered.

Try changing your inputs to be out of phase from the clock. If you have
more than one clock though the edges are supposed to be concurrent, the
clock that generates t_ready may be scheduled one simulation event
before the pclk-triggered always block.

- John_H
Click to expand...
Actually t_ready is input from outside so I don't control it. Guess,
the only way out is to do it in on neg phase of pclk as you said.

Neo
 
"Neo" <zingafriend@yahoo.com> wrote in message
news:1190127000.066671.307080@q5g2000prf.googlegroups.com...
Actually t_ready is input from outside so I don't control it. Guess,
the only way out is to do it in on neg phase of pclk as you said.

Neo
Click to expand...
You're not answering the questions and you may be completely missing the
point here.

If you ARE in a simulation environment, that "external" t_ready needs to
work with the "external" pclk.

If you AREN'T in a simulation environment, you have timing issues with the
hold time for t_ready relative to pclk.

It's rarely a good thing to use the negedge of a clock though the use
certainly has its place. The negedge I suggested was for simulation control
so that visually (and for any inter-domain clock issues) you have an OBVIOUS
difference between your stimulus and the internal signals.
 
John_H wrote:

(snip)

It's rarely a good thing to use the negedge of a clock though the use
certainly has its place. The negedge I suggested was for simulation control
so that visually (and for any inter-domain clock issues) you have an OBVIOUS
difference between your stimulus and the internal signals.
Click to expand...
I thought negedge was always more popular than posedge.

That is, from the TTL days where the pull down was stronger
than the pull up it made more reliable logic.

-- glen
 
glen herrmannsfeldt wrote:

I thought negedge was always more popular than posedge.

That is, from the TTL days where the pull down was stronger
than the pull up it made more reliable logic.
Click to expand...
TTL inputs other than clock are usually
active low because unconnected inputs
tended to float high.

However, TTL clock inputs are rising edge
with only a few exceptions.

The fact that "edge" is used at all in the
sensitivity list for a level sensitive preset
or reset input is an artifact of the verilog language.

-- Mike Treseler
 
Mike Treseler wrote:

(I wrote)
I thought negedge was always more popular than posedge.
(snip)
Click to expand...

TTL inputs other than clock are usually
active low because unconnected inputs
tended to float high.

However, TTL clock inputs are rising edge
with only a few exceptions.
Click to expand...
It seems that in my TTL book 32 are negedge and 41 are posedge.

More than a few, but less than half.

-- glen
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top