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