A
Amir
Guest
Hi,
does "posedge" samples the transition from "x" to "1" or only from "0"
to "1" ?
Thanks
-Amir
does "posedge" samples the transition from "x" to "1" or only from "0"
to "1" ?
Thanks
-Amir
J
Jonathan Bromley
Guest
On Mon, 14 Mar 2011 02:29:30 -0700 (PDT), Amir wrote:
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.
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.
M
Muzaffer Kal
Guest
On Mon, 14 Mar 2011 02:29:30 -0700 (PDT), Amir <sting.t2@gmail.com>
wrote:
addition to '0' to 'x' and '0' to 'z'.
--
Muzaffer Kal
DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.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
G
glen herrmannsfeldt
Guest
Muzaffer Kal <kal@dspia.com> wrote:
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
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
J
johnp
Guest
On Mar 14, 2:15 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
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
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
A
Andy
Guest
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
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
J
Jonathan Bromley
Guest
On Tue, 15 Mar 2011 06:19:42 +0000 (UTC), glen herrmannsfeldt wrote:
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
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
G
glen herrmannsfeldt
Guest
Jonathan Bromley <spam@oxfordbromley.plus.com> wrote:
on 'x' during simulation, though, it is likely not to
work with real hardware.
simulation and real hardware.
though maybe not as fast as when driven high.
Yes, you could model that with a verilog pullup.
-- glen
(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 betweenMuzaffer 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
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
R
rickman
Guest
On Mar 15, 1:57 am, Muzaffer Kal <k...@dspia.com> wrote:
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
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
M
Muzaffer Kal
Guest
On Wed, 16 Mar 2011 22:24:42 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:
far as 1364 is concerned.
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
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
P
Petter Gustad
Guest
rickman <gnuarm@gmail.com> writes:
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.
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.
J
Jonathan Bromley
Guest
[Rickman]
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
[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
C
Cary R.
Guest
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
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
C
Cary R.
Guest
On 3/17/2011 10:16 AM, Jonathan Bromley wrote:
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.
have something similar to this somewhere in the code.
Regards,
Cary
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
J
Jonathan Bromley
Guest
hi Cary
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
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
R
rickman
Guest
On Mar 17, 2:39 am, Muzaffer Kal <k...@dspia.com> wrote:
your point.
can't treat a transition involving a state that has no defined logical
value (in the boolean sense) to produce a valid clock edge. I have no
idea what it would seem to be useful to have a simulation behave in a
way that is so different from the real world and at the same time be
so non-useful.
Rick
When you say "should be" that sounds like an opinion to me. But I get
your point.
It wouldn't be their first mistake! It is just obvious to me that you
can't treat a transition involving a state that has no defined logical
value (in the boolean sense) to produce a valid clock edge. I have no
idea what it would seem to be useful to have a simulation behave in a
way that is so different from the real world and at the same time be
so non-useful.
Rick
R
rickman
Guest
On Mar 17, 5:58 am, Jonathan Bromley <jonathan.brom...@verilab.com>
wrote:
thing is outside of the domain of logic really. When has your logic
ever been in the 'x' state? Mine never has. To suggest that
transition between a non-boolean state and valid level not be treated
as a rising edge is hardly "application specific".
properly represent all logic as I know it, we should allow the default
behavior to be inconsistent with the real world and then let the user
figure out how to get around that.
undefined state and a 1 as a rising clock edge and ignoring the
transition altogether.
of them.
Rick
wrote:
"application specific"??? Verilog is for logic, no? The whole x
thing is outside of the domain of logic really. When has your logic
ever been in the 'x' state? Mine never has. To suggest that
transition between a non-boolean state and valid level not be treated
as a rising edge is hardly "application specific".
Yes, that is just what I want to do. Rather than the language
properly represent all logic as I know it, we should allow the default
behavior to be inconsistent with the real world and then let the user
figure out how to get around that.
There is a far cry from treating a transition between a boolean
undefined state and a 1 as a rising clock edge and ignoring the
transition altogether.
Sure there can always be issues that are hard to fix. This isn't one
of them.
Rick
R
rickman
Guest
On Mar 17, 12:44 pm, "Cary R." <no-s...@host.spam> wrote:
behavior and I don't know that it matches the real world in any useful
way. The fact that there should have been a clock edge somewhere
within the intermediate X region of a 0 to 1 transition is not
usefully modeled by making the output transition concurrent with the
final transition to 1. Within the X region may have been many
transitions and these may not meet specs for proper clocking of the
device and may even cause the FF to go metastable. So why treat the x
to 1 transition as a valid clock?
Rick
I don't know that there is much value in providing this sort of
behavior and I don't know that it matches the real world in any useful
way. The fact that there should have been a clock edge somewhere
within the intermediate X region of a 0 to 1 transition is not
usefully modeled by making the output transition concurrent with the
final transition to 1. Within the X region may have been many
transitions and these may not meet specs for proper clocking of the
device and may even cause the FF to go metastable. So why treat the x
to 1 transition as a valid clock?
Rick
J
Jonathan Bromley
Guest
[me]
like this, giving an active clock for X->1:
if clock'event and clock = '1' then ...
It's just modelling, using the bare language's features.
Choose your model to suit your needs and convenience
(and, less happily, to suit the templates mandated by
synthesis tools).
A simulation language's X value, in any of its various
flavours, is a trick to make Boolean algebra work even
when you have certain unknowable conditions. It doesn't,
and can't, directly mean anything in real circuits -
it merely means that we don't know enough about a bit's
simulated value to be sure it's 1 or 0. As soon as you
have these meta-values, you get all kinds of fallout in
any programming language: what should happen when you
test if(x)? what does a 0->x transition mean, when
your functional behaviour only makes sense for 0->1
transitions? For every one of these questions, any
language must necessarily make a decision to mandate
the language's behaviour. Since people can combine
language constructs in all manner of interesting ways,
there is no one right answer and some work must be
left to the user. That way, the user gets to choose
how much trouble they should go to in attempting to
model reality.
Of course, we have conventional patterns of code that
work well enough that we're happy with them most of
the time. The standard RTL flipflop templates fall
into that category; they're not part of the language
itself. As Cary and I pointed out in different ways,
you *can* (both in VHDL and Verilog) build quite
accurate FF models that trash their Q value when
bad things happen on clocks, resets and so on.
Well-written library cell models should do exactly
that, to provide the best possible checking that all
is well at gate level. But when we're doing RTL
simulation, we care primarily about 0/1 functional
behaviour and we (or, at least, I) should be happy
to accept that all bets are off if we let an X
creep on to our simulated clock signal. A simple
assertion on the clock's value will soon alert us
if that requirement is violated, at far lower cost
than futzing around with complicated X modelling
at each flop (whether built-in or hand-written).
would prefer a language that's much more tightly
coupled to the specifics of real flops and other
components.
--
Jonathan Bromley
[Rickman]
No, there isn't. Some people still write their VHDL flops
like this, giving an active clock for X->1:
if clock'event and clock = '1' then ...
It's just modelling, using the bare language's features.
Choose your model to suit your needs and convenience
(and, less happily, to suit the templates mandated by
synthesis tools).
A simulation language's X value, in any of its various
flavours, is a trick to make Boolean algebra work even
when you have certain unknowable conditions. It doesn't,
and can't, directly mean anything in real circuits -
it merely means that we don't know enough about a bit's
simulated value to be sure it's 1 or 0. As soon as you
have these meta-values, you get all kinds of fallout in
any programming language: what should happen when you
test if(x)? what does a 0->x transition mean, when
your functional behaviour only makes sense for 0->1
transitions? For every one of these questions, any
language must necessarily make a decision to mandate
the language's behaviour. Since people can combine
language constructs in all manner of interesting ways,
there is no one right answer and some work must be
left to the user. That way, the user gets to choose
how much trouble they should go to in attempting to
model reality.
Of course, we have conventional patterns of code that
work well enough that we're happy with them most of
the time. The standard RTL flipflop templates fall
into that category; they're not part of the language
itself. As Cary and I pointed out in different ways,
you *can* (both in VHDL and Verilog) build quite
accurate FF models that trash their Q value when
bad things happen on clocks, resets and so on.
Well-written library cell models should do exactly
that, to provide the best possible checking that all
is well at gate level. But when we're doing RTL
simulation, we care primarily about 0/1 functional
behaviour and we (or, at least, I) should be happy
to accept that all bets are off if we let an X
creep on to our simulated clock signal. A simple
assertion on the clock's value will soon alert us
if that requirement is violated, at far lower cost
than futzing around with complicated X modelling
at each flop (whether built-in or hand-written).
I disagree, but I'm fully aware that many people
would prefer a language that's much more tightly
coupled to the specifics of real flops and other
components.
--
Jonathan Bromley
J
Jan Decaluwe
Guest
On 03/18/2011 02:38 PM, Jonathan Bromley wrote:
admittedly a long time ago), that wasn't really the
case. For example, gate level simulation wasn't aware
that 'not X' is actually the boolean opposite of 'X'.
Synthesis on the other hand understands this very
well. So the result was perfectly valid ciruits
that "couldn't get out of reset" because of incorrectly
pessimistic gate level simulation.
Therefore, I am rather unconvinced of the value of
this 'X' concept, even at the gate level.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
Last time I checked out gate level simulation (which is
admittedly a long time ago), that wasn't really the
case. For example, gate level simulation wasn't aware
that 'not X' is actually the boolean opposite of 'X'.
Synthesis on the other hand understands this very
well. So the result was perfectly valid ciruits
that "couldn't get out of reset" because of incorrectly
pessimistic gate level simulation.
Therefore, I am rather unconvinced of the value of
this 'X' concept, even at the gate level.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com