Re: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

Using assert is the proper way to do this. However, VHDL should support an additional logical predicate - implies.

ASSERT X implies Y;

Implies can be implemented as "not X or Y", but having the keyword is clearer. Most Satisfiability Modulo Theory solvers, which are often used to optimize code, understand the implies statement directly. Some more examples:

ASSERT X > 3 implies Y = 0;
ASSERT X = 1 implies (Y /= Z and Y > 3);

It's also useful anywhere an AND or OR could be used. Note that X implies Y and Y implies X is not the same as X = Y. Implies is a predicate where as equality is a binary function from items in some domain onto bool values predicates may operate over. That said, it doesn't seem overly onerous to language implementers to conflate equality and equivalence for these purposes.

On Feb 24, 2011, at 4:43 AM, "Jonas Nilsson" <Jonas.Nilsson@synopsys.com<mailto:Jonas.Nilsson@synopsys.com>> wrote:

I agree that introducing “don’t cares” into synthesis is an excellent use of
assertions. If some input combinations are impossible, and we can inform the
synthesis tool that they are, it will have more freedom to implement the logic.

Assume for instance a behavioral description of a dual –port memory, where
you know that the read and write addresses are never the same. The statement
“ASSERT Raddr /= Waddr;” is a very elegant way to inform the synthesis tool of
this fact, without resorting to tool proprietary attributes with obscure semantics.

I don’t understand why standardized functions are necessary though. You can
use any function or logic expression in the assert clause, and the tool would be
able to do the right thing. You can easily define your own “mutex” function for
various types and values.

So I think this capability is already in the language, and doesn’t have to be introduced
as a new language element. The semantics should perhaps be described the RTL
synthesis standard to reduce ambiguity. For instance: should the tool be allowed
to do such simplifications only for asserts with SEVERITY FAILURE, or also for
SEVERITY ERROR?

The RTL synthesis standard could also contain a set of standardized functions
such as your “std_mutex”, but they don’t belong in the language itself, IMHO.

Regards,
Jonas

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jones, Andy D
Sent: Tuesday, February 22, 2011 7:09 PM
To: 'vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>'
Subject: RE: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

Hans,

“Change” can mean a lot of things.

If I compare an integer to several target values in a long if-then else tree, the synthesis tool knows that the integer cannot have more than one value at a time, and each value is mutually exclusive. Therefore the synthesis tool can optimize the priority encoding inferred by the if-then-else tree.

I’m suggesting a way to inform the synthesis tool that it can infer the same from a set of inputs that I specify as mutually exclusive, and make the same optimization. These inputs would in practice be constrained as mutually exclusive in an external interface specification which is not accessible to the HDL tool. In effect, by using the assertion (with severity failure), I have nullified the HDL description for the case where the inputs might not actually be mutually exclusive. Therefore the synthesis tool is free to do whatever it wants in that case, because the description did not describe the behavior to be implemented. The optimal implementation would usually be to strip out the priority encoding inferred by the if-then-else tree.

There are manual ways to describe priority-less decoding (e.g. by explicitly coding the and-or logic), but such methods are more subject to coding errors, and are less readable/reviewable than simply using an if-then-else tree.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of hans@ht-lab
Sent: Tuesday, February 22, 2011 11:10 AM
To: <mailto:vhdl-200x@eda.org> vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: Re: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

Hi Andy,

If I understand you correctly, what you are suggesting is to change what the synthesis tool infers from your RTL by an assert statement?

Regards,
Hans
<http://www.ht-lab.com>www.ht-lab.com<http://www.ht-lab.com>

From: Jones, Andy D<mailto:andy.d.jones@lmco.com>
Sent: Tuesday, February 22, 2011 4:14 PM
To: <mailto:vhdl-200x@eda.org> mailto:vhdl-200x@eda.org
Subject: RE: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list
Some synthesis tools will already report failed assertions. What is needed for synthesis is to allow assertions that call standardized functions to inform the synthesis tool about the inputs such that additional optimizations could be made (e.g. WRT mutual exclusivity, it is safe to remove priority logic from the input decoding.)

For example:

Assert std_mutex(inputs, 1or0hot);

This would tell the synthesis tool that the inputs array’s contents are mutually exclusive with one or zero hot.

What is missing is a standard function that can be agreed upon to indicate one/zero hot, one hot, etc. so that all synthesis tools could look for the same function used in an assertion.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Tuesday, February 22, 2011 7:30 AM
To: <mailto:vhdl-200x@eda.org> vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Cc: hans@ht-lab
Subject: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

Hi Hans,

Just a few more (these aren't solely my suggestions; others have contributed to the discussion as well):
1: make some currently non-synthesizable code become synthesizable. Examples are "after", "assert", "report", etc. Need to >study which of these are feasible to implement.

Some of them like assert are already supported by most synthesis tools. As far as I know they only generate a warning rather than stopping the synthesis process. I believe that synthesis vendors are already trying to support as many language constructs as possible as this is a major product differentiator.

Yes, I'm aware of this. Most synthesis tools just give warnings on valid VHDL syntax but those that they don't know how to generate logic with. So I agree that constructs like "after" and "assert" (and a whole bunch of others) to not stop the synthesis process, but they all do get ignored by it and no logic is being generated. I was thinking that we give the designer an option whether or not he wants to generate logic for these? Perhaps an attribute (like "keep")?

One reason for this is that more and more people would like to have their simulation testbenches synthesized to become either BIST or tester circuits.

2: easier way to design configurable testbenches, e.g. support shorthand entity instantiation (to be embedded into >configurations) instead of component instantiation.

Please explain.

For example, you have these files:
Top-level design: block0.vhdl
library ieee,work;
use ieee.<packages>.all;
use work.subblock0;

entity block0 is port(...);
end entity block0;

architecture structural of block0 is
begin
   instance0: entity work.subblock0 port map(...);
end structural;

Sub-level design: subblock0.vhdl, subblock0_arch.vhdl
The entity of subblock0 is specified in subblock0.vhdl.
The architecture of subblock0 is specified in subblock0_arch.vhdl.

cfg_block0.vhdl
library work;
use work.subblock0;

configuration cfg_block0 of block0 is
    for structural
        for sub0_arch0: subblock0
            use entity work.subblock0(arch0);
        end for;
    end for;
end configuration cfg_block0;


Currently both my synthesis and simulation tools reported errors for this design. Apparently the entity instantiation in the top-level design is not supported for use with configurations (though it is valid when configurations are not used):
instance0: entity work.subblock0 port map(...);

To make this work, I had to explicitly convert the entity instantiation into a component instantiation (which was THE way to do things a long time ago when direct entity instantiation wasn't yet supported). Having to do this again with configurations is like we're stuck with something of the past...
architecture structural of block0 is
   component subblock0 is port(...); end component subblock0;
begin
   instance0: subblock0 port map(...);
end structural;

Anyway, the main reason I request this is because I think everybody agrees we need to spend more time simplifying design verification - that means making it easier to write testbenches and run simulations. Configurations is an elegant way to automate verification of testcases, and there are quite a number of people out there who use this method to generate testbenches. Other methods (without using configurations) are possible too, and I believe there are other things we can do to improve those areas.

Well, to compete against other design verification languages like SystemVerilog, e, Vera, I believe we should start with finding ways to make it easier to write testbenches the pure VHDL way. VHDL itself is already an excellent language for design verification, though things can be made easier to use.
I for one do not use PSL or VHPI or stuff like that, because that means having to learn another language and a whole new paradigm.
3. Timing constraints supported by language.

This was mentioned before and I didn't understand it then, do you have an example?

I know that synthesis tools supports all sorts of attributes to set pin numbers, IOB's, fsm coding styles etc but I find it questionable coding style as it makes your code highly un-portable.

We were discussing about how to make the synthesiser/P&R timing-aware. We currently already have the SDC file format to input timing constraints, so there was a suggestion of supporting timing constraints directly by VHDL (either by embedding SDC, or have our own syntax, or both).


Regards,
Hans
<http://www.ht-lab.com>www.ht-lab.com<http://www.ht-lab.com>

..
Regards,
Daniel

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.