regarding "posedge"

Sat Mar 19, 2011 7:47 pm   

rickman <gnuarm_at_gmail.com> wrote:

(snip, I wrote)

I might agree, but the problem is that state machines that start
up just fine in real life won't start up properly if X propagates
in all cases.


Well, violate the input spec is different. If I have logic that
is either 0 or 1, but I don't know which one, then subtract will
give zero. If it is somewhere in between, then that is different.

(snip)

Again, the problem is state machines that initialize with real
data, but not with X. So, even though I agree with you mostly,
it would be nice to write systems that can verify the design,
and yet start up in any initial state.


Except for FF's, (and some state machines), I mostly write
structural verilog. So, yes, it does seem that FF's are not
part of the language, at least not from structural verilog.


-- glen

Sat Mar 19, 2011 8:21 pm   

On 03/19/2011 05:24 PM, rickman wrote:

Sure, we can't all be HDL language design geniuses.

Still, there is something that puzzles me. An HDL
like AHDL seems to be exactly the closer-to-hardware
HDL that you want. Of course, I believe that it is moving
into the ranks of forgotten HDLs for the same reason.
But still, one would expect that you would mention it
as an example to follow. At least this would get
the discussion real instead of vague and open-ended.

So if you ever did historical research about HDLs
(= googling for "HDL"), or even better, if you have
experience with an HDL like AHDL, you did a very good
job at hiding it.

Otherwise: those who don't know history are bound
to repeat it. Mistakes included.

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

Sun Mar 20, 2011 8:10 am   

On Mar 19, 1:47 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

Yes, but if you consider what 'X' means, it includes your case, but
does not only mean that. It means that the state is not known and can
be changing in an unknown way. So in reality, your simulation is not
the same as reality, because the states are not specified well
enough.

I remember finding this back when I started working with HDLs and a
tech support person who knew something about HDLs (this was back when
you could actually speak with someone knowledgeable on a hot line)
told me that this was a well known issue. I guess it has not been a
big enough problem to do anything about it. In the case of a FF with
feedback never getting out of a meta value is the same as the
subtraction case. But in the FF case the solution would be to test
with the input in each state. For the subtraction case you would need
to test with all possible combinations which would be an unrealistic
task. This would require telling the simulator that the two inputs
are not known, but stable, valid and equal. That doesn't sound too
realistic either.



I'm not sure how that relates to FSMs that start up with unknown
inputs. If you don't know the value of a clock enable, how can you
know when or if it will capture the input signal? With FSMs it is
particularly difficult because they will eventually arrive at a known
state, but the process of getting there will not necessarily the same
in all cases. So how could that be accommodated?



Structural coding in VHDL is a real PITA because of the verbosity.
I'm a little unclear on what you say you do. I would instantiate FFs
and use RTL for the logic. Why would you instantiate the logic and
infer the FFs? FFs can be instantiated, no? I'm more familiar with
VHDL, but I don't use instantiation for low level objects.

Rick

Sun Mar 20, 2011 9:04 am   

rickman <gnuarm_at_gmail.com> wrote:

(snip, I wrote)


OK, say you have a state machine that uses clock enable as
part of its feedback, and also is well designed such that it
works no matter the initial state. If it starts in X, then
it won't work.

Simplest I can think of is a FF with clock enable the XNOR
of its output and its output delayed by one clock cycle.
If it clock enable is low, the output won't change, the XNOR
will go high, and so the clock enable.

I haven't thought about why one would want to do that, but
it doesn't seem so strange.

-- glen

Sun Mar 20, 2011 1:35 pm   

On Sun, 20 Mar 2011 07:04:59 +0000 (UTC), glen herrmannsfeldt wrote:


The problem is that X is only an abstraction, and
it doesn't (and doesn't claim to) model all the
real possibilities.

In Verilog, the hardware meaning of X is pretty much
"it's either a 0 or a 1 but, for some reason, I can't
decide which it is". This idea gives some obvious
inconsistencies, as we've seen. Suppose, for example,
I have an XOR gate whose inputs are both X. In effect,
that means we have four possible values for the XOR's
inputs: 00, 01, 10, 11 - either input can be 0 or 1.
So we don't know the output and we must write the
truth table as X^X=X.

But suppose, for a moment, that both inputs are wired
to the same signal. Now we have only two possible
inputs: 00, 11. The output is reliably 0. How can
we capture this? Obviously we can't describe it in
the truth table of XOR, because that can't know about
correlations between its two inputs.

This is precisely why I believe it is futile to try
to make the language imitate hardware reality to the
extent that Rick seems to want. It will always be
possible to find cases where the modelling doesn't
match reality (is too pessimistic or too optimistic)
because X values carry no information about their
relationship to other X values. What we have right
now may not be the perfect compromise, but it's well
defined and we know how to live with it. (Did I
mention assertions?)

Symbolic simulation, and formal analysis, are able
to deal with these questions because they understand
the functionality of the whole circuit, not just a
set of uncorrelated truth tables. Conventional
functional simulation can't be that smart.

Another way to handle it, which has been used on
real projects, is to interfere with the simulation
at time zero so that all register-like signals are
initialized to a random 0 or 1 value instead of X
(it's tricky, but not impossible, to do this using
the Verilog VPI). By running many such simulations
with different random seeds you can learn a lot about
the real start-up and "X" behaviour. There has been
a serious proposal to add such a facility to the
Verilog standard, and I think there's one commercial
simulator that already supports it, but it's not
happening in the current standards effort. There
are some papers on this in the public domain that
I'll try to hunt down and link to.

cheers
--
Jonathan Bromley

Sun Mar 20, 2011 2:47 pm   

On 03/20/2011 07:10 AM, rickman wrote:


That may explain why you were a little hasty in dismissing
my suggestion to use Verilog instantation as a cheap way to
implement a closer-to-hardware HDL. Your VHDL past is the problem.

I suggest to reconsider. First, let me point out that any
closer-to-hardware HDL will necessarily involve the use of
more "low level objects" in some form.

More importantly, as is commonly known and as I believe you
experienced yourself, Verilog is a neat and concise HDL as
opposed to super-verbose VHDL. Certainly for structural
coding. Therefore, you will probably find Verilog instantiations
a joy to work with.

And of course, this applies to any functionality, not just FFs.
For example, you could use it for the module power-of-2 counters
that, as I recall, you couldn't get to synthesize properly.

I suppose you now see how this proposal addresses the issues
of your concern.

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

Sun Mar 20, 2011 6:42 pm   

On Mar 20, 3:04 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

But if you assume the starting state is unknown, how do you prove that
the FSM will work? You can't. You have to consider all possible
starting states and test them all or something similar. By specifying
an 'X' state, you have not provided enough information for a
simulation to know this will work. Just saying that the machine will
work no matter the starting state is not enough to resolve an 'X'.

Tell me what transition sequence you would expect to see as the FSM is
clocked with 'X' on the inputs?

Rick

Sun Mar 20, 2011 6:55 pm   

On Mar 20, 8:35 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

The issue is not that 'X' can't model all possibilities, but that 'X'
is saying that you lack information about the state. To model the
real world in more detail you need more information than 'X'
reprensents.



I don't agree with this really. It says you don't know the state, not
that it is at a valid and constant, but unknown value. It does not
represent having any information about the state of the signal. So
you can't make many of the assumptions you indicate below.



So far, so good.



I don't agree that knowing the same signal is on the two inputs of an
XOR gate is enough information to know the output. In a real world
circuit this can easily generate glitches on every state change of the
input. So you don't know the output and the output of 'x' is valid.



I think you are overstating what I have asked for. I am not saying
you have to model logic perfectly. My original thought was that FFs
are not modeled well by assuming a transition from 'x' to '1' is a
rising clock edge. I still think this is a very poor model. Either
ignore invalid edges or generate an invalid output from the FF. The
former makes perfect sense to me while the latter would likely be hard
to do given the current languages.



Yes, randomization of start up states can help with the simulation,
but it doesn't seem to be the right way to deal with the issue of FSM
startup. It only takes one missed case to spoil a design. I'm not
clear though on why a part of a design that needs to start up
correctly would not use an initialization through reset of similar.
When would this randomization be needed?

Rick

Sun Mar 20, 2011 8:52 pm   

On Sun, 20 Mar 2011 09:55:57 -0700 (PDT), rickman wrote:


Yes, I think that's pretty much what I said. You need to
know about relationships that hold between different signals,
not just the values on individual signals.


You're welcome to disagree all you like, but that's how it
works for all the Verilog built-in operators. I agree that
posedge is somewhat anomalous, and if() is inevitably
unsatisfactory, but the basic behaviour is as I stated.
Check out the behaviour of the ?: conditional operator
when the selector is X, if you want further confirmation:
wire [3:0] Y = 1'bX ? 4'b1010 : 4'b0110;
gives Y=4'bXX10.


I didn't say "constant", and certainly didn't intend to
imply it. "Valid", though, I did mean. If you want
X to mean "some voltage on the wire that makes it
uncertain whether I have 0 or 1" then you must go to
analog modelling of some kind.


I'm not sure what you mean by that. I posited some
example situations, and didn't aim to "make assumptions".


That's a different issue, easily modelled by adding timing
(a specify block, in Verilog-speak) to your XOR model. The
Verilog calculation "y = a ^ a" will ALWAYS yield zero
if 'a' is either 0 or 1; you won't see a glitch when 'a'
makes a transition. Of course you may get a glitch in the
real hardware; it you really want to see that in simulation,
you'll need to add timing to your model. That's irrelevant
to my point that the (stable) value of a^a is zero
regardless of the (stable) value of 'a', but ordinary
functional simulation can't produce that correct result
when a=X. Similarly, if you do provide the necessary
timing model so that flipping the XOR's inputs from 00
to 11 gives a visible output glitch, you won't - and
could not, by any stretch of the imagination - get
such a glitch when the inputs "transition" from XX
to XX, because there's no transition. The X value
allows propagation of unknown-ness through the design
in some cases, but doesn't allow you to represent
all the possibilities that you might care about.


I don't disagree that the definition of posedge is odd, and
probably somewhat inappropriate, but that's the way it is
and we need to live with it. Did I mention assertions?

Note that a suitable SystemVerilog assertion could
allow you to trash the Q value of a conventional
synthesisable FF model if there's an X on the clock,
without compromising the ability to synthesise the
code, if you think that's the right thing to do.


I hope that no-one should equate "randomized" with "scattergun"
for functional verification. I can easily collect coverage
on those randomly generated initial states to check that
any specific critical case has been covered exhaustively,
while tolerating just a selection of starting values
for less critical things such as the counter in a
divide-by-N block.

If I'm really worried about such a thing, I can deploy
a formal assertion checker (or manual analysis) to prove
that all possible start states work properly. Pencil
and paper still has its place.


Some of the systems I'm working on right now have
an audio timebase, typically 44kHz but could be even
as low as 8kHz. That's generated by dividing down
the system clock, probably 50MHz. No-one cares
about the absolute phase of this timebase relative
to reset. I can't necessarily reset the counter
at power-up (the chip may have multiple power
domains, some of which come out of power-down at
times when there's no reset happening). The
counter powers-up at X; oops, no simulation.
If I force it to zero at power-up, I'm testing
only one of thousands of possibilities. Why
not randomize its state at power-up? If I allow
that random startup value to vary across the
hundreds of simulations I do for other reasons,
I'll get pretty good confidence that all is well.
--
Jonathan Bromley

Sun Mar 20, 2011 9:50 pm   

rickman <gnuarm_at_gmail.com> wrote:
(snip)


(snip)

Well, that would be true if there was a different delay between
the paths. As verilog does model delay (though rarely used) it
would seem fair for it to include the delay.

(snip)

I like the randomization idea, but, yes that wouldn't be the
final anser for SM startup. I have used big constants
(such as 12345) when it made sense.

There have been suggestions to supply random bits for floating
point post-normalization, to simulate the uncertainty in the result.

-- glen

Mon Mar 21, 2011 9:39 am   

On 03/18/2011 04:18 PM, rickman wrote:


This is just a bunch of clichés, as misleading and boring
as clichés can be.

Many HDLs have been proposed. Most were in the "close to hardware"
camp. They are mostly forgotten. The market clearly prefers
the "outsiders" that look more like "programming languages".

Of course, the market may be (temporarily) wrong, but to back that
up you better come up with very strong arguments and fresh ideas.

Programming is of course about languages, compilers and methodolgies.
However, a point frequently missed by hardware designers is that
there is a wide variety of sub-discplines and application domains,
with very different characteristics and constraints. The best
programmers know their application domain very well, they master
the coding patterns that work well for their purpose, and they
understand what they can expect from their compilers.

A good HDL designer should of course do exactly the same. He
should understand hardware design very well. But he should also
understand what kind of coding patterns are efficiently
handled by his compiler (synthesis tool). Focussing on
"describing hardware" is counter-productive, because it tends
to make designers blind for useful coding patterns.

Interpreting HDL design as a specific software discpline has
a tremendous advantage: you benefit from all advances in tools
and methodologies from the overall software world. The best
talent that gives us real breakthroughs is there - that is
just a matter of numbers.

We hardware designers are much less special than we often
like to think. By realizing that, we can reduce our development
costs and increase our productivity.

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

Tue Mar 22, 2011 10:44 am   

On 03/19/2011 02:32 AM, Muzaffer Kal wrote:

No need to be humble here - that is exacly right and well put.

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

Tue Mar 22, 2011 10:59 am   

On 03/19/2011 03:33 PM, rickman wrote:

Then finally come up with something concrete how that should
look like. Some technical starting point, no matter how small,
that we could analyze and criticize in a meaningful way.

Even though I have argued, with arguments open to anyone's
criticism, that the concept goes into the wrong direction,
I have made 2 concrete suggestions: Verilog instantiations
and AHDL. A good start would be to tell us what is wrong
or right with those approaches for your purposes.

Just stop misrepresenting synthesis and the cheap talk.

--
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