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

Hi Andy,
Yes, this is one good way to make assertions more usable in synthesis. I
agree to discuss further on such a function. Perhaps the synthesis attribute
fsm_encoding can be used here?

I notice my current tool vendor doesn't support this attribute, rather it
prefers to use its own vendor-specific attribute (which makes it not really
'93-compliant). If we can find more uses for these kinds of synthesis
attributes, probably tool vendors will adopt them.

Regards,
Daniel

On Wed, Feb 23, 2011 at 12:14 AM, Jones, Andy D <andy.d.jones@lmco.com>wrote:

> 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, and is
believed to be clean.