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

Just for the record, when you're referring to "Assertion" with the "*assert*"
statement, you should be referring to the PSL "*assume*" statement.
* The *assert *directive assert instructs the verification tool to verify
that a property holds.
* The *assume *directive instructs the verification tool to constrain the
verification
(e.g., the behavior of the input signals) so that a property holds. The *assume
*is used in formal verification to guide the tool about the assumptions of
the design.
I don't believe that PSL or SVA is used in synthesis. However, the *unique
* maybe be used by synthesis tools (we need to check on that, but I believe
they this construct is supported.
From the SV LRM, teh syntax is:
conditional_statement ::= // from A.6.6
[ unique_priority ]* if* ( cond_predicate ) statement_or_null
{ *else if* ( cond_predicate ) statement_or_null }
[ *else* statement_or_null ]

unique_priority ::= unique | unique0 | priority
cond_predicate ::= expression_or_cond_pattern { &&&
expression_or_cond_pattern }
expression_or_cond_pattern ::= expression | cond_pattern
cond_pattern ::= expression matches pattern
Ben Cohen
On Sat, Feb 26, 2011 at 11:12 AM, Peter Flake <flake@elda.demon.co.uk>wrote:

> SystemVerilog has the “unique if” and “unique case” constructs to indicate
> mutual exclusion. These are simpler than using assertions, though not as
> general.
>
>
>
> Regards,
>
>
>
> Peter
>
>
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Jonas Nilsson
> *Sent:* 24 February 2011 09:42
>
> *To:* vhdl-200x@eda.org
> *Subject:* RE: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list
>
>
>
> 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] *On
> Behalf Of *Jones, Andy D
> *Sent:* Tuesday, February 22, 2011 7:09 PM
> *To:* '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] *On
> Behalf Of *hans@ht-lab
> *Sent:* Tuesday, February 22, 2011 11:10 AM
> *To:* 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
>
> www.ht-lab.com
>
>
>
> *From:* Jones, Andy D <andy.d.jones@lmco.com>
>
> *Sent:* Tuesday, February 22, 2011 4:14 PM
>
> *To:* mailto:vhdl-200x@eda.org <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] *On
> Behalf Of *Daniel Kho
> *Sent:* Tuesday, February 22, 2011 7:30 AM
> *To:* 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
> 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* <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.