«

So, is this what they mean by "Design For Test"? ;^)

Seriously, there is nothing like embedding self-checking code in the
design itself, to provide guidance for future reviewers/maintainers
about the functionality required of the design.

I've long advocated a system where we could embed assertion
statements, perhaps with standardized functions that verify things
like mutual exclusivity of inputs, etc., such that a synthesis tool
could use the information to optimize the implementation. In
simulation, the assertion would verify that the inputs were indeed
mutually exclusive, thus checking the external interface to that
module.

For instance, if I had a function that could take an unconstrained
array of boolean and return false if more than one element were true,
I could write an assertion that called it:

Assert std_mutex(read_enable & write_enable));

Then if I had code that looked like:

if read_enable then
....
elsif write_enable then
....
end if;

then the synthesis tool could recognize that the priority implied by
the if-elsif statement was not needed and could be optimized out of
the implementaion.

We'd get better verification, with better synthesis in the bargain.

Andy

Andy wrote:

> For instance, if I had a function that could take an unconstrained
> array of boolean and return false if more than one element were true,
> I could write an assertion that called it:
>
> Assert std_mutex(read_enable & write_enable));
>
> Then if I had code that looked like:
>
> if read_enable then
> ...
> elsif write_enable then
> ...
> end if;
>
> then the synthesis tool could recognize that the priority implied by
> the if-elsif statement was not needed and could be optimized out of
> the implementaion.
>
> We'd get better verification, with better synthesis in the bargain.


I could collect statistics in a self-checking simulation,
but I don't follow how I could prove the proposition
except for a constant array.

-- Mike Treseler

On Jan 29, 3:11*pm, Andy <jonesa...@comcast.net> wrote:
>
> I've long advocated a system where we could embed assertion
> statements, perhaps with standardized functions that verify things
> like mutual exclusivity of inputs, etc., such that a synthesis tool
> could use the information to optimize the implementation.

And if the assertion statements logically contradict the logic in some
fashion, which path should the synthesis tool follow?

- If the synthesis tool followed the path of the written code, it
would be doing what it does today...which is to ignore all but
statically verifiable assertions for the purposes of generating logic
and simply report those assertion failures and stop (at best...some
tools don't do that).

- If it followed the path of the assertions, then what makes the line
of assertion code more likely to be correct than the code for the
logic? I don't think I'm alone in that every line of code I write is
a potential to initially be wrong and need fixing. This is true
whether the line of code is logic for the design or an assertion to
check that design.

Kevin Jennings

On Jan 29, 2:07*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> This is also a quick way to add some visibility
> for debugging a variable deep in the design.
>

That's why I keep tellin' ya...use some concurrent assignments and
signals for a change and cut back on those variables

Kevin Jennings

KJ wrote:
> On Jan 29, 2:07 pm, Mike Treseler <mtrese...@gmail.com> wrote:
>> This is also a quick way to add some visibility
>> for debugging a variable deep in the design.
>>
>
> That's why I keep tellin' ya...use some concurrent assignments and
> signals for a change and cut back on those variables

Touché.
I should have said, "register"

-- Mike Treseler
(still likes that "printf" debugging)

Kevin and Andy are correct, of course, but there is a much simpler way
to write a testbench. I don't know anything about your design but
let's assume, for the sake of argument, that:

1 - PRESET_N is an active-low reset
2 - PWM is the output waveform
3 - PWM is split into 8 slots
4 - DUTY_CYC is the count of 0 slots
5 - (8-DUTY_CYCLE) is the count of high slots

In this case, the Maia code below tests your design. It applies all 3
combinations of DUTY_CYCLE to your DUT, and then checks the low and
high periods. It runs for 72 cycles and reports any failures in your
code.

disclaimer #1: I work for Maia EDA. You can currently get a free
compiler at www.maia-eda.net; it creates a testbench, and you'll need
a simulator to run the testbench.

disclaimer #2: The current version produces only Verilog output.
You'll need a dual-language simulator if your DUT is in VHDL (the
compiler driver automates all of this).

-Evan

// -------------------------------------
// Maia testbench code:
DUT {
module FSM_CorePWM(
input PCLK, PRESET_N, PSEL, PENABLE, PWRITE,
input [2:0] DUTY_CYC,
output PWM, INT,
output [7:0] PRDATA);
[PRESET_N, PCLK, DUTY_CYC] -> [PWM];
create_clock PCLK;
}

main() {
int3 dcycle;
int i,j;

for all dcycle { // all 8 values: 0->7
[0, .C, .X] -> [0]; // reset
for(i=0; i<dcycle; i++)
[1, .C, dcycle] -> [0];
for(j=0; j<8-dcycle; j++)
[1, .C, dcycle] -> [1];
}
}

Does it really make a difference whether the assertion (or any other
kind of verification code) is located in the design module or in the
testbench? Is it any less likely to be correct because you put it in a
place where synthesis could take advantage of it? And if it is
incorrect, but synthesis could not take advantage of it, does not the
same assertion still have to be fixed?

Perhaps we simply give the synthesis tool the ability to do the
following:

By writing "assert one_hot(inputs);"

We are saying that any f(inputs) is "don't care" iff one_hot(inputs)
is false?

Conditions could also be put on/around the assertion or its expression
to limit the scope to e.g. rising edges of the clock, when not in
reset, etc., either by including those conditions in the assertion
expression, or by the location and therefore conditional execution of
the assertion statement itself.

I see your point WRT design behavior in off-nominal cases, but that is
just as big an issue everytime we enable synthesis optimizations for
one-hot state machines, etc.

Andy

On Feb 1, 12:56*pm, Andy <jonesa...@comcast.net> wrote:
> Does it really make a difference whether the assertion (or any other
> kind of verification code) is located in the design module or in the
> testbench?

See my post from Jan 28 in this thread for an advantage that one may
gain by putting the verification in the design rather than the
testbench.

> Is it any less likely to be correct because you put it in a
> place where synthesis could take advantage of it?

Nope, nor did I suggest that it would.

> And if it is
> incorrect, but synthesis could not take advantage of it, does not the
> same assertion still have to be fixed?

Only if the incorrect assertion can be found, can it be fixed.

A simulation that runs to completion without failing an assert, no
matter how well thought out, does not imply that all of those
assertions are actually correct and match the logic under every
condition. To prove that they do match, one would have to use a
formal logic checker of some sort, not a simulator.

But none of that has to do with the point that I was making. My point
was along the lines of which path should be followed by a synthesis
tool if it used non-static assertions to guide how it formed the logic
and there was a logical difference between what was asserted and what
the written code actually said.

Kevin Jennings

On Feb 1, 10:53*pm, KJ <kkjenni...@sbcglobal.net> wrote:
> But none of that has to do with the point that I was making. *My point
> was along the lines of which path should be followed by a synthesis
> tool if it used non-static assertions to guide how it formed the logic
> and there was a logical difference between what was asserted and what
> the written code actually said.

Sorry, I misinterpreted your point.

But since you clarified it...

I think the (synthesis-aware) assertions would have to be implemented
like a subsequent conditional assignment of "don't care", and that way
their interference with the otherwise coded logic is controlled and
(somewhat) predictable.

Not all assertions are explicitly coded; some are built-in.

For example, if I have a decoder as follows:

variable address : natural range 0 to 15;
variable decode : std_logic_vector(7 downto 0);
....
decode := (others => '0');
decode(address) := '1';

What should the synthesis tool do if address is outside of
decode'range?

1. Should (or can) decode remain (others => '0')?

2. Should (or can) decode be (address mod 8 => '1', others => '0')?

3. Should (or can) decode be (others => '-')?

My opinion is that any of these options (and probably others) is
perfectly acceptable, but the #3 is a more accurate option, which
would be typically optimized to #2.

Is this example any different than manually adding an assertion that
address is between 0 and 7 inclusive? And would not the #3 option be
the same as a subsequent conditional assignment to (others => '-')?

By using the assertion, you are not telling the synthesis tool that
the implementation has to do something else, you are merely giving it
permission to do something else, especially if it is more efficient.

The same thing happens when an integer counter under/over-flows in
synthesis. The implementation will simply roll over, probably because
that is the most efficient thing to do.

Andy

Andy wrote:

> Not all assertions are explicitly coded; some are built-in.
> For example, if I have a decoder as follows:
> variable address : natural range 0 to 15;
> variable decode : std_logic_vector(7 downto 0);
> ...
> decode := (others => '0');
> decode(address) := '1';
>
> What should the synthesis tool do if address is outside of
> decode'range?

I guess I like the vhdl rules as is.

I will assume this 'decode' is a vector:
decode := (others => '0');

And this 'decode' is an f(vector) returns std_ulogic:
decode(address) := '1';

If the decode vector is constrained,
I would expect a synthesis error.
If the decode vector is not constrained,
I am not following my design rules.


-- Mike Treseler