regarding "posedge"

Mon Mar 14, 2011 11:29 am   

Hi,

does "posedge" samples the transition from "x" to "1" or only from "0"
to "1" ?

Thanks
-Amir

Mon Mar 14, 2011 10:15 pm   

On Mon, 14 Mar 2011 02:29:30 -0700 (PDT), Amir wrote:


Anything in a vaguely upward direction. 0->X, X->1, 0->1 all count
as a posedge.

I fell foul of this once, very early in my Verilog apprenticeship.
I was trying to model a clock signal with some jitter in its timing.
So I created a signal that did 0->X followed by X->1 a few ns later.
I was mighty surprised when I found it triggered my flipflops twice
per clock cycle!

Note that posedge should normally be given a single-bit expression to
consider. If you ask for posedge on a vector, it should officially
give you posedge of the least significant bit - but some tools have,
at least at some time in the past, triggered on any rising change
of the whole vector's value. Not a smart thing to try.
--
Jonathan Bromley.

Tue Mar 15, 2011 6:57 am   

On Mon, 14 Mar 2011 02:29:30 -0700 (PDT), Amir <sting.t2_at_gmail.com>
wrote:


Both 'x' to '1' and 'z' to '1' should be detected as posedge in
addition to '0' to 'x' and '0' to 'z'.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Tue Mar 15, 2011 8:19 am   

Muzaffer Kal <kal_at_dspia.com> wrote:

To be an accurate simulation, it should randomly trigger
on changes to/from 'x' or 'z'...

If the input has enough pull-up, though, it will trigger on
an output going to 'z'.

-- glen

Tue Mar 15, 2011 4:26 pm   

On Mar 14, 2:15 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

Jonathan -
You get a bonus point for your wording "Anything in a vaguely upward
direction."

I've never thought about vaguely with digital logic!


John Providenza

Tue Mar 15, 2011 6:45 pm   

That depends on your definition of accurate... Using X's for any
behavioral purpose on clock signals is really pointless, and would not
be helped even with such randomization.

X does not mean "stable, but unknown value" even though as long as the
signal stays X, no more events will be created from it. Instead, X
means "unknown value and stability", and if the clock has a value of X
for 1 ns, there could be from zero to many rising and/or falling edges
in that timespan. Randomly choosing a single transition at the
beginning and/or end of that span is not any closer to reality than
always or never triggering.

Andy

Tue Mar 15, 2011 11:47 pm   

On Tue, 15 Mar 2011 06:19:42 +0000 (UTC), glen herrmannsfeldt wrote:


I don't see what this has to do with Verilog.

No digital simulator can ever possibly claim to do
"accurate simulation". The simulator implements a
programming language, following the defined rules
of that language. Muzaffer Kal (and I, less
thoroughly) outlined those rules. For sure,
they do not represent "accurate simulation" (see
my little anecdote about jittery clocks). But
they're what any Verilog simulator is required
to do, by the language rules. Of course, the
language is designed to provide a useful
approximation to "accurate simulation"; but
if you want accuracy you need Spice :-)

A fine example of this is given by the behaviour
of the Verilog if() procedural statement. The
expression tested by if() can give three possible
outcomes: definitely zero, definitely nonzero, and
unknown (i.e. it has one or more X/Z bits, and
possibly some zero bits). But unfortunately
there's no "maybe" branch on if(). So the
if() statement is defined to execute its "else"
branch if the test condition is unknown. This
often gives rise to behaviour that is not
"accurate simulation" of typical logic hardware.
Note that VHDL has a different set of compromises
for this problem, giving different "inaccuracy".

As far as pullup is concerned, it might be worth
mentioning again how Z works in Verilog. If you
provide a pullup on a net (for example by connecting
a pullup() primitive to it), and then drive the net
with a Z value from some other driver, the net's
value will become 1 and a posedge operator on the
net would have no need to deal with a Z at all.
But if there is no pullup on the net, and you
drive the net with Z, then the net's value really
will be Z.
--
Jonathan Bromley

Wed Mar 16, 2011 1:31 am   

Jonathan Bromley <spam_at_oxfordbromley.plus.com> wrote:


(then I wrote)

I completely agree. If one has a design that triggers
on 'x' during simulation, though, it is likely not to
work with real hardware.


Yes. I was trying to point out differences between
simulation and real hardware.


TTL inputs usually have enough pull-up to go high,
though maybe not as fast as when driven high.
Yes, you could model that with a verilog pullup.

-- glen

Thu Mar 17, 2011 7:24 am   

On Mar 15, 1:57 am, Muzaffer Kal <k...@dspia.com> wrote:

I wouldn't agree with that. I would like to see any transition that
doesn't have a defined logic level at both ends cause the output of a
FF to assume an 'x' or 'u' value. I'm not sure Verilog has a 'u'
value, but I assume it does. I'm more familiar with VHDL.

I don't see any useful application of getting a valid clock edge from
a transition with a "vaguely" defined state at either end.

Rick

Thu Mar 17, 2011 7:39 am   

On Wed, 16 Mar 2011 22:24:42 -0700 (PDT), rickman <gnuarm_at_gmail.com>
wrote:


What I stated was not a personal opinion but a statement of fact as
far as 1364 is concerned.


Various IEEE P1800 (aka SystemVerilog, aka Verilog as we know it
today) subcommittees are in session right now; you might want to take
it up with them but I think it's unlikely that there'll be a change in
this regard.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Thu Mar 17, 2011 8:14 am   

rickman <gnuarm_at_gmail.com> writes:


That's how it's defined in the Verilog specification. posedge is
similar to (name'event and name = '1'), unlike rising_edge(name) which
only detectes '0' to '1'.

There's no 'u' value in Verilog.

//Petter
--
..sig removed by request.

Thu Mar 17, 2011 11:58 am   

[Rickman]

[Muzaffer Kal]

There certainly won't be a 'u' value, ever!

Cliff Cummings proposed a new set of special keywords -
something like "always_x", "always_ff_x" etc, but I'm
not sure of the details - to provide built-in modelling
for this kind of X-management. Many of us felt that it
was putting too much application-specific stuff into
what should be a general-purpose language; after all,
you can already model such things perfectly well with
UDPs, and people who write gate-level cell models
certainly do that. Anyway, for better or worse it
didn't make the cut for things to consider in the
2012 revision of IEEE-1800.

Note that the usual VHDL flipflop modelling style
does nothing at all if there's an X or U on the
clock - it certainly doesn't drive the FF's
output to X. And, once again, it's easy to provide
such modelling explicitly if you can be bothered
to do so.

The usual RTL abstraction, in either VHDL or Verilog,
is intended for the modelling, simulation and
synthesis of functional behaviour at the clock
cycle level. It has many well-known limitations,
of which this is only one. For most of us,
though, the benefits massively outweigh those
limitations, and we have tools (both automated
and mental) for coping with the limitations.
--
Jonathan Bromley

Thu Mar 17, 2011 5:44 pm   

On 3/17/2011 2:58 AM, Jonathan Bromley wrote:



I would say you can adequately model a FF with a well crafted UDP, but
it's amazing how many cell libraries only provide the basic
functionality and hardly any pessimism. I have developed what I consider
the definitive UDP that models a FF with asynchronous set/reset and even
it is not as good as I would like. It's fundamentally limited by the
functionality available in a UDP. I think with a second helper UDP I can
get all the functionality I desire, but I've been busy with other things
so I have not finished this.

For the interested here's the remaining problem.

Given a FF with a defined D input that is opposite the current Q value a
0->X on the clock should produce an X on the output but a subsequent
x->1 should correctly latch the value because at this point in time you
know an edge has occurred. You could actually code this in the UDP as
x->1 latches the D input, but that doesn't work since a 1->x followed by
a x->1 doesn't work correctly (should be undefined). I believe with a
second UDP I can record the previous transition type and then restrict
the x->1 latching to the case where it was proceeded by a 0->x. Even
better is a C model linked into the simulator, but I want to get this
straight with basic Verilog (which is portable) first.

In reality you shouldn't have an X in your clock tree, so this is really
a personal experiment to see how far you can push things.

Cary

Thu Mar 17, 2011 7:09 pm   

On 3/17/2011 10:16 AM, Jonathan Bromley wrote:

Yes, this also needs to be considered. All the complicating factors are
why I think this really should be embedded inside the simulator where
all the extra checking, etc. can be processed efficiently. I'm only
using UDPs to stretch my knowledge of the UDP corner cases. As you well
know, I could easily write a behavioral version of this. FYI I expect
this case to be handled in the helper UDP where a data transition when
the clock is undefined invalidates the previous edge event thus keeping
the undefined value at the X->1 transition.

The one thing I had not been considering is the fact that X could
represent multiple transitions instead of a single transition to an
unknown state. Depending on the circuit either could be the correct
representation. The only time I have seen an X in the clock path is when
someone had two driver in parallel driving the clock signal. Then
because of slight delay differences they got a small window of X at all
edges. For this case interpreting X to be a single edge transition is valid.


Thanks, If I was implementing this with behavioral code I'm sure I'd
have something similar to this somewhere in the code.

Regards,

Cary

Thu Mar 17, 2011 7:16 pm   

hi Cary


Sounds cool. But I'm not sure... I think you
also need to model the effect of changes on
D during (clock===X), because X->1 on the
clock after that D change does not necessarily
mean that there's been an active clock during
the time when D had its new value.

Anyways, I could offer something like this.

event clock_went_bad;
event clock_definitely_happened;
reg last_valid_clock;
reg previous_clock;
always @clock begin
case ({previous_clock, clock})
2'b0x, 2'b0z, 2'b1x, 2'b1z:
-> clock_went_bad;
2'bx1, 2'bz1, 2'b01:
if (last_valid_clock === 1'b0)
-> clock_definitely_happened;
endcase
previous_clock = clock;
if ((~clock) !== 1'bx) last_valid_clock = clock;
end

Now you can use the two events to trigger
activity in your FF model. I'm sure you can
do it even more neatly with UDPs but, as you
well know, I'm not a cell modelling guy!

cheers
--
Jonathan Bromley