Clock Edge notation

[JAF]

On Mon, 20 Aug 2007 12:26:35 -0700, Larry Pattis <NeverHere@spam.invalid>
wrote:

Please help me add verses to this little ditty for our paranoid
schizophrenic friend:

Take him, and your doggerel, and shove them both.
--
JAF anarchatntlworldfullstopcom
http://petitions.pm.gov.uk/faithschools/sign

 

[Tony Weber]

Larry Pattis wrote:

Please help me add verses to this little ditty for our paranoid
schizophrenic friend:


I've got those persecution blues,
The man keeps spyin' on me.
I can post to the internet, and complain, you see,
Because itšs all comin' down, and my radio is listenin' to me.

Whoa, I've got those persecution blues,
I can't keep all them eyes off of me.
They bug my computer, they bug my TV,
They bug my toilet, now that's really buggin' me.

Say, I've got those persecution blues,
And it's really got me seein' red.
I post all my nonsense, and I forget to take my meds,
They're chasin' after me, and you know what, it's all in my head.

So I've got those persecution blues,
It's their silence that has me convinced,
That they're about to bust in,
And have all my grey matter rinsed.

Just because they are really out to get you doesn't mean that you aren't
paranoid.

TW

 

[William Elliot]

On Mon, 20 Aug 2007, Larry Pattis wrote:

Please help me add verses to this little ditty for our paranoid
schizophrenic friend:

I've got those persecution blues,
The man keeps spyin' on me.
I can post to the internet, and complain, you see,
Because itšs all comin' down, and my radio is listenin' to me.

Whoa, I've got those persecution blues,
I can't keep all them eyes off of me.
They bug my computer, they bug my TV,
They bug my toilet, now that's really buggin' me.

Say, I've got those persecution blues,
And it's really got me seein' red.
I post all my nonsense, and I forget to take my meds,
They're chasin' after me, and you know what, it's all in my head.

So I've got those persecution blues,
It's their silence that has me convinced,
That they're about to bust in,
And have all my grey matter rinsed.

Wash, wash, wash your brains

Gently down the drain.
Wearily, wearily, wearily, wearily.
Who's there now to blame?

 

[Jonathan Bromley]

(Restricting this to comp.arch.vhdl only)

On Tue, 28 Aug 2007 11:30:44 -0700,
Weng Tianxiang <wtxwtx@gmail.com> wrote:

1. How 'elsif' and 'orif' work together?

See the following example:

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

'if', 'elsif' and 'else' play a role like brackets, putting together a
group of signals that are grouped with 'orif' between them to specify
mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
E5) and signals in each group are mutually exclusive. Other grammar
meanings remain unchanged: It also means that if one of (E0, E1, E2)
is true, then 'if' statement is finished, otherwise try to test (E3,
E4, E5), like an usual 'if' statement.

The keyword 'orif' only adds the meaning that all signals in the group
are mutually exclusive, no more meaning is added.

OK, so to try to put this a little more precisely:

'orif' has exactly the same execution semantics as 'elsif',
EXCEPT THAT
any group of branch tests, starting with if or elsif and
continuing through any number of orif with no intervening
elsif, are evaluated together and if more than one of those
tests evaluates to TRUE then it shall be an error.

Note that this mandates the evaluation of ALL tests in the
set before any decision is made, whereas regular VHDL
executes them one by one, only moving on to the next if
the current test is false.

Question: In the following example Tn are Boolean expressions,
and Sn are statement blocks.

if T1 S1
orif T2 S2
orif T3 S3 --- T1, T2, T3 are mutually exclusive
elsif T4 S4
orif T5 S5 --- T4, T5 are mutually exclusive
else S6

If (T1 OR T2 OR T3) is true, do we then also check T4/T5 for
mutual exclusivity? Both answers (yes, no) have potential
disadvantages.

There are some VERY tricky problems with language definition
if any of the Tn tests calls an impure function that may influence
the results of another Tn test - SystemVerilog has already had
trouble with that one.

I still don't understand how you intend to deal with the
practically-common "exactly one" requirement. A final else
doesn't do what I want, because it simply provides an execution
path when all the Tn are false; it does not provide me with a
check that exactly one of the Tn is true.

What I want is to transfer to a VHDL compiler the information that
there is mutually exclusive information about them and use them in
best interest of timing.

As I've already said, this is a worthy objective. Jim Lewis has
suggested it could be done with assertions. I suspect, though,
that a specialized language construct might be a more satisfactory
solution; the use of assertions means that a synthesis tool must
tie together two distinct language constructs, with a wide variety
of possible coding styles and the risk of very wide separation of
the two constructs (conditional and assertion). SystemVerilog
synthesis tools are gaining real practical benefit from the
"unique" and "priority" keywords today, but I know of no
synthesis tool that exploits explicit assertions to
improve its optimization.

3. I am not fimiliar with Verilog, but from Marcus posting, I know
there is a definitive advantage of my method over Verilog's:
You have never to specify "at-least-one" and "at-most-one" tests.

This is not a convincing point. SystemVerilog simply has two
new keywords that can be used as a prefix to 'if' or 'case'.
That is surely no worse than the need to remember a new
'orif' keyword. It's a difference of detail only, and at
present your approach is weaker because it has no way to
specify exactly-one or at-least-one among a set of tests.
(As Marcus and I have both said already, SystemVerilog
has probably got this slightly wrong - but it *does*
offer all the possibilities, which your 'orif' does not).

Keep provoking the community with good ideas - you're doing
a great job - but this one needs more work, I'm afraid.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

On Aug 30, 12:43 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

On Aug 30, 10:08 am, Weng Tianxiang <wtx...@gmail.com> wrote:



On Aug 30, 7:46 am, Jim Lewis <j...@synthworks.com> wrote:

Weng,
I have to change my keyword 'orif' definition to make it perfect (it
may need more fine tuning with other's help, no matter what is, I am
not a good protocol writer, but I am learning), but the basic idea has
been the same as before and consistent without any change since March
2002 I published a paper with Jim as the paper's reviewer.

So you and I have had some time to discuss and ponder this.

Personally I am worn out and don't have further energy to
afford this issue as I consider it a solved problem.

One of the things that shifted my mind away from "ORIF"
is that there are mutual exclusion problems that it
cannot solve. One you had brought up in a previous
discussion (some time ago) where you had mixed conditions
with some signals mutually exclusive and some not.
I think this is a common case.
Can you post one of the examples you shared with me previously
and explain how this would be handled by "ORIF"?

I have to point out the following code has error:
...
Here is Jim's equation that is wrong !

Please use quoting properly as I can't tell your
referenced text from your new thoughts. As a result,
I cannot follow your line of thought at all, so I can't
comment on all of it - it looks like you included too
much text.

I will make an educated guess that this is the example
on which you wanted to comment:

Also note that if you are using std_logic or bit types, with the
Accellera VHDL-2006 revision you can write:
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <> > > > (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;

Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
Data0 or Data3, not Data0.

Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif, so yes there is no
priority between E0 and E3 here and Data0 or Data3 is the
correct answer.

Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <> > > (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end process ;

What compelling real hardware problems does "ORIF" solve
that either are not solved by other methods or are
cumbersome using other methods?

Cheers,
Jim- Hide quoted text -

- Show quoted text -

Hi Jim,
Simply say, there are several ways to specify that a group of signals
is mutually exclusive.

In other words, there are several ways to do the same things. Now the
question is which is best one to be chosen as part of standard of
VHDL.

The differences between your way and mine are as follows:
1a. Your way advantage
Your function name zero_one_hot() can be more compatible with same old
function zero_one_hot(). But you admit there are still problems over
there and you promise it is not a big problem.

1b. You way disadvantage:
it must be done off-line with 2N+1 extra lines to do the same things:
N signal declaration lines;
N assign statements to new signals
1 assertion call statement.

2a. My way advantages are
a. It provides on-line programming capability.
b. It provides a unified language branch statement structure by mixing
'elsif' and 'orif'.

2b. Keyword 'orif' would conflict other old signal name orif users
might have had used.
I am not sure Colin has proved that it can be avoid or not. In this
respect I would like other experts' help to determine it or resolve
it.

From the following code segment provided by Marcus,

Verilog uses new keyword 'unique' to provide on-line programming
capability to specify mutually exclusiveness.

| module unique_if;
| bit clk, reset;
|
| logic E0, E1, E2, E3, E4, E5;
| logic [0:5] E;
|
| logic [7:0] OutBus;
| logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
|
|
| initial begin
| clk <= 0;
| reset <= 1;
| #20ns;
| reset <= 0;
| end
|
| always clk = #5ns ~clk;
|
| always @(posedge clk, posedge reset) begin
| if(reset)
| OutBus <= 0;
| else begin
| void'(randomize(E) with {
| E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
occurence of 10
| });
|
| {E0, E1, E2, E3, E4, E5} = E;
|
| unique if(E0) OutBus <= Data[0];
| else if(E1) OutBus <= Data[1];
| else if(E2) OutBus <= Data[2];
| else if(E3) OutBus <= Data[3];
| else if(E4) OutBus <= Data[4];
| else if(E5) OutBus <= Data[5];
| end
| end
|
| endmodule : unique_if

I don't know if Verilog provides the same function zero_one_hot().

As far as 'orif' is concernd, I would like to ask why 'orif' name
conflict problem is so serious?

In my experiences, I have met more consistency problems between two
VHDL versions about unsigned, std_logic_vec, ... and very confused and
I don't know how to listen to which experts's ideas.

For example, for 200x VHDL version, a new keyword 'orif' will be
added, then you must check if your old design has the words, and
if ...
Is it not enough? Or is it troubled enough to make confusion as large
as unsigned, std_logic_vec, ...?

I will re-post my encoding with 'orif' posted two years ago as Jim
asked.

Weng- Hide quoted text -

- Show quoted text -

Hi Jim:
1. Your previous coding has error.
"Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif,"
Please check my first posting over there and it mixes the use of
'orif' and 'elsif' starting from the first posting and it never uses
keyword 'orif' only.

And your coding example is directly copied from your first post on
this thread without any change.

You wrote two assertion statements to show your assertion statement
ability, but coding is wrong. You never wrote a assertion that
includes 6 signals from E0 to E5, but your coding was based on it. It
is a little error not affecting out discussions.

2. Jim asked:
Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <> (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end process ;

Here is the answer:

A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E0 = '1') then
OutBus <= Data2;
orif(E0 = '1') then
OutBus <= Data3;
orif(E0 = '1') then
OutBus <= Data4;
orif(E0 = '1') then
OutBus <= Data5;
else
OutBus <= Zero_64;
end if;
end if;
end process;

"ORIF' can not only do the above as an beginner would like to do, but
also do the following equations you showed before more efficiently:

-- assert zero_one_hot (E0, E1, E2) ; -- Jim wrote
-- assert zero_one_hot (E3, E4, E5) ;
assert zero_one_hot (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line
to make code correct

-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <> (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;

I don't know which VHDL version permits the operation: (E0 and Data0),
even though It is not a problem here

-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
else
OutBus <= OutBus;
end if;
end if;
end process;

The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'

It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.

The above two example show that with mixed 'elsif' and 'orif' language
branch statement structure, HDL will provide more powerful and concise
way to deal with mutually...

read more ť

Colin,

My comment regarding indentation, though poorly stated on my part, was
intended to support the traditional use of indentation, which is to
visually indicate subordinate execution/analysis of statements. Since
orif is not executed subordinately to elsif any more than additional
elsif's are, it should not be indented beyond elsif.

In my informal proposal to Jim, I suggested that zero_one_hot() (or
some standard function with that purpose) be defined in a VHDL-
standard package as a VHDL function (i.e. in addition to, or
independent of, a similar PSL function) so that it could be used with
the VHDL ASSERT statement. Thus, if it were defined in a standard
package, then the function name could be prefixed with the package
name to make it unique from any other identifier.

Andy

 

[Torsten Landschoff]

[Narrowed to c.l.vhdl only]

Hi Weng,

On 31 Aug., 05:32, Weng Tianxiang <wtx...@gmail.com> wrote:

Your zero_one_hot() tells simulator to check if all bits meet the zero
or one active conditions. If it meets, return '1', otherwise return
'0'.

Render me confused. If I assert a condition in VHDL, I would expect
the synthesizer to use that information to optimize the circuit (at
least if it has severity error, which is the default). When such an
assertion is declared, it can be assumed that the following code
relies on it anyway. Adding one more instance of "undefined behaviour"
should not matter.

However, I wonder if current synthesizers do some kind of validation
if the assertion can be violated ;-)

Greetings, Torsten

 

[Michael Jřrgensen]

"Andy" <jonesandy@comcast.net> wrote in message
news:1188427440.253466.111560@r34g2000hsd.googlegroups.com...

<BEGIN QUOTE>
Any synthesis tool that cannot figure out the code below (rewritten
from your example, but in standard vhdl with elsif) indicates mutually
exclusive conditions should be immediately uninstalled and returned to
the vendor for a full refund!

if(two_bits = "00") then
...
elsif(two_bits = "01") then
...
elsif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;
<END QUOTE>


I think perhaps the above example is a bit too simple. In my designs I have
an external CPU accessing various tables inside the FPGA. The address
decoding leads to a number of mutually exclusive conditions, but the
synthesis tool does not recognize them as such.

The following example shows what I mean (see code at end of post).
Basically, it is just 4-input 4-output LUT, but when synthesizing I end up
with a long chain of MUX'es.

I would like the output signal in the code below to be synthesized as a
single 8-to-1 multiplexer (i.e. in parallel), and not as seven 2-to-1
multiplexers chained together in series.

Others have suggested using enumerated types, but I can't see how that
helps. This will just lead to a chain of if-statements in the address
decoding, instead of in the output multiplexing.

So either I'm missing something fundamental in VHDL (quite likely, since I'm
still new in this field), or the language has a limitation that is causing
problems for me.

-Michael.


<BEGIN CODE EXAMPLE>

library ieee;
use ieee.std_logic_1164.all;

package p_test_decode is
subtype t_data is std_logic_vector(3 downto 0);
subtype t_addr is std_logic_vector(3 downto 0);
end p_test_decode;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.p_test_decode.all;

entity test_decode is
port (
Addr_IN : in t_addr;
D_OUT : out t_data
);
end entity test_decode;

architecture rtl of test_decode is
signal reg_hit : std_logic_vector(7 downto 0);
type t_decode is array(7 downto 0) of t_addr;
constant addr : t_decode := ("0001", "0010", "0110", "0101", "1001",
"1000", "1010", "1101"); -- Just a random selection of bit patterns
type t_val is array(7 downto 0) of t_data;
constant val : t_val := ("1010", "1011", "1100", "0100", "1001", "0011",
"0001", "0000"); -- Just another random selection of bit patterns
begin
hit: for i in 0 to 7 generate
reg_hit(i) <= '1' when Addr_in = addr(i) else '0';
end generate;

-- reg_hit is essentially a one-hot representation of the result of the
address decoding.

-- I want D_OUT to be an 8-to-1 multiplexer; not seven 2-to-1
multiplexers.

D_OUT <= val(0) when reg_hit(0) = '1' else
val(1) when reg_hit(1) = '1' else
val(2) when reg_hit(2) = '1' else
val(3) when reg_hit(3) = '1' else
val(4) when reg_hit(4) = '1' else
val(5) when reg_hit(5) = '1' else
val(6) when reg_hit(6) = '1' else
val(7) when reg_hit(7) = '1' else
(others => 'X');

end architecture rtl;

<END CODE EXAMPLE>

 

[KJ]

"Michael Jřrgensen" <ingen@ukendt.dk> wrote in message
news:46d8498b$0$903$edfadb0f@dread12.news.tele.dk...

"Andy" <jonesandy@comcast.net> wrote in message
news:1188427440.253466.111560@r34g2000hsd.googlegroups.com...

BEGIN QUOTE
Any synthesis tool that cannot figure out the code below (rewritten
from your example, but in standard vhdl with elsif) indicates mutually
exclusive conditions should be immediately uninstalled and returned to
the vendor for a full refund!

if(two_bits = "00") then
...
elsif(two_bits = "01") then
...
elsif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;
END QUOTE


I think perhaps the above example is a bit too simple. In my designs I
have an external CPU accessing various tables inside the FPGA. The address
decoding leads to a number of mutually exclusive conditions, but the
synthesis tool does not recognize them as such.

The following example shows what I mean (see code at end of post).
Basically, it is just 4-input 4-output LUT, but when synthesizing I end up
with a long chain of MUX'es.

When I synthesized it with Quartus I got 4 LUTs for the total usage, one to
compute each of the four bits of D_OUT. The input to each of the four LUTs
are the four address inputs Addr_IN(3:0). The intermediate signal
'reg_hit(3:0)' was optomized out, the logic path for all four outputs
consisted of a single LUT delay. There was no cascading of LUTs or
anything. Bottom line is that the synthesized result is exactly what I
would have expected.

Since you synthesized it and ended up with "a long chain of MUX'es" perhaps
you should take Andy's suggestion regarding such a synthesis tool which is
that it "should be immediately uninstalled and returned to the vendor for a
full refund!".

I would like the output signal in the code below to be synthesized as a
single 8-to-1 multiplexer (i.e. in parallel), and not as seven 2-to-1
multiplexers chained together in series.
I'm not sure how the 8->1 mux fits into the example you posted, but perhaps

you should ponder a bit on how to implement an 8->1 mux given logic
primitives that take 4 to 6 inputs only (i.e. various FPGAs). CPLDs have
much wider inputs to the logic array, but FPGAs with their LUTs don't so
maybe what you're seeing when you talk about long chains of muxes is simply
because the FPGA LUT with it's 4-6 inputs simply cannot implement an 8->1
mux in a single level of logic. Again though, the 8->1 mux you're speaking
of must be something other than for the code you posted.

Others have suggested using enumerated types, but I can't see how that
helps. This will just lead to a chain of if-statements in the address
decoding, instead of in the output multiplexing.
Enumerated types wouldn't help in the synthesis in this particular example,

but what it can help with is readability. D_OUT(0), D_OUT(1), etc. is
probably less descriptive then D_OUT(Ram), D_OUT(Flash), etc. The mutual
exclusivity of the bits of the signal 'reg_hit' in your example was
correctly handled as it should be by Quartus.

So either I'm missing something fundamental in VHDL (quite likely, since
I'm still new in this field), or the language has a limitation that is
causing problems for me.

I don't think it's a language limitation that is causing whatever problems

you're seeing. Given the synthesis results that you got (the long chain of
mux) suggests that the problems are caused by your synthesis tool.

KJ

 

[comp.arch.fpga]

On 2 Sep., 02:14, Weng Tianxiang <wtx...@gmail.com> wrote:

As far as "don't care" situation is concerned, VHDL compile ignores
it
at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem.

Finally you get my point. There is no need to change the language, you
only
need to change the compiler to support the existing language features:
- interpretation of assertions to deduce reachability don't cares.
- honoring output observability don't cares coded as '-' during
optimization

Again: The existing language features can do a lot more than mutual
exclusiveness.
You only need compilers that use them. Adding a keyword for a special
case to the
language will only delay adoption of the general case.

Kolja Sulimma

 

[Weng Tianxiang]

On Sep 2, 3:23 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:

On 2 Sep., 02:14, Weng Tianxiang <wtx...@gmail.com> wrote:
As far as "don't care" situation is concerned, VHDL compile ignores
it

at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem.

Finally you get my point. There is no need to change the language, you
only
need to change the compiler to support the existing language features:
- interpretation of assertions to deduce reachability don't cares.
- honoring output observability don't cares coded as '-' during
optimization

Again: The existing language features can do a lot more than mutual
exclusiveness.
You only need compilers that use them. Adding a keyword for a special
case to the
language will only delay adoption of the general case.

Kolja Sulimma

Hi Kolja,
"at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem. "

In above sentence, what I had refered to is the case of 'dont' care'
you mentioned in your example, not the 'orif' case.

Verilog introduction of 'unique' and other related functions has
showed that mutually exclusiveness in HDL needed to be added and
improved.

Weng

 

[mk]

Hi,
I updated the GTKWave for Win32 port I am maintaining. It's at 3.1.0
which supports reload now.

http://www.dspia.com/gtkwave.html

 

[Michael Jřrgensen]

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:cdhCi.4628$JD.606@newssvr21.news.prodigy.net...

[snip]

I don't think it's a language limitation that is causing whatever problems
you're seeing. Given the synthesis results that you got (the long chain
of mux) suggests that the problems are caused by your synthesis tool.

KJ

Thanks for your comments.

I entered this thread because I thought I recognized a problem I was having
myself, i.e. that the synthesis tool (I'm using Quartus) did not properly
utilize mutually explusiveness. Well, I was mistaken. Let me explain.

The small example in my previous post was created to describe my problem.
However, I was making the mistake of looking in the RTL viewer. Using my
example, there is indeed a chain of MUX's clearly seen in the RTL view.
However, I then checked the equation file, and that consists essentially of
four parallel ALUTs, just as you described.

That surprised me: I thought the RTL viewer was essentially a graphical
representation of the equation file, but that is clearly not the case. It
only represents something that is logically equivalent. I'm glad to have
found that out.

I tried a more complicated example where the output was to be multiplexed
from four different RAMS. Again, the selection was done in a single ALUT for
each output bit.

So it seems that Quartus is actually doing a very good job at optimizing the
design, contrary to my initial claim.

My conclusion is therefore that the problem I aluded too is non-existent.

Going back to the OP, this leads me to ask, what is actually the problem
that Weng is trying to solve?

-Michael.

 

[Jonathan Bromley]

Going back to the OP, this leads me to ask, what is actually the problem
that Weng is trying to solve?

The issue is well-known, and has numerous prior-art solutions
(I'll come back to them): There are many, many designs in which
the designer has private knowledge of the set of values that may
legally appear on a group of signals. If the designer cannot
express that knowledge to the synthesis tool, he will get
inferior logic optimization. If the designer cannot express
that knowledge to the simulator, he runs the risk of failing
to detect certain errors that put illegal values on to the
signals.

Here's a very simple example, for which no new solution is
needed. Suppose I wish to make an electronic die that
displays (using seven LEDs) the usual pattern of one to
six spots. My display has four "segments" made from
seven lamps:

A B
C D C 1->D, 2->A, 3->AD, 4->AB, 5->ABD, 6->ABC
B A

Now I run a binary counter over the values 1,2,3,4,5,6
to generate the values. I need a decoder:

signal count: unsigned(2 downto 0);
signal lamps: std_logic_vector(0 to 3); --- 0=A,1=B, 2=C, 3=D
...
case count is -----lamps ABCD
when "001" => lamps <= "0001";
when ....
when "110" => lamps <= "1110";
when others=> lamps <= "----";
end case;

This is a simple and effective style that allows the synth tool
full scope for optimization, and in simulation makes it very clear
to you if you mistakenly put a bad value on "count". You could
even add a simulation-only error diagnostic (assertion) in the
"others" branch. I have been able to write code that captures
my hidden design knowledge both for simulation and for synthesis.
If, in the real hardware, the count should go to 0 or 7 then I
will get some goofy pattern on the LEDs; but I don't care,
because my simulations convinced me that this will never happen.

In more complicated situations, and particularly in situations
where different signals need to be tested to choose different
branches of a conditional, it can be very difficult indeed to
capture this kind of design knowledge in the code.

Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.

Synthesis pragmas or directives, notably the full_case
and parallel_case pragmas supported by all serious Verilog
synthesis tools, provide a convenient way to flag to a
synthesis tool that certain conditions will always hold
(full_case specifies that at least one branch of a
conditional will be taken and therefore the tool does
not need to consider any other possibilities; parallel_case
specifies that no more than one branch of a conditional
will be taken, so the tool can assume mutual exclusivity).
Unfortunately, simulators completely ignore such directives
and therefore we not only risk missing important error
conditions, but also we may get mismatches between simulation
and synthesis behaviour. Most VHDL designers would rightly
choke on their coffee at such a thought.

Consequently, many people have sought some way to express
such kinds of design intent within the language itself.
Assertions are the obvious candidate, but are probably
too open-ended to be tractable for synthesis: for example,
an assertion in one part of a design might enforce
mutual exclusivity on a conditional in quite another
part of the design and it is unreasonable to expect
synthesis tools to be able to handle that sort of thing.
SystemVerilog has taken the approach of adding some new
language keywords ("unique" and "priority") that can
be used to modify the conditional statements "case"
and "if"; simulators recognise these keywords as a
special assertion, and synthesis tools recognise them
as licence to perform certain optimizations. Everyone
is happy. We get better logic, and no sim/synth mismatch.

There is absolutely no point in trying to apply anything
like full_case and parallel_case to VHDL case statements,
since they are inherently full and parallel by the language
definition. However, there *may* be some mileage in
chasing that goal for the "if" statement. That's what
Weng's "orif" keyword aims to do. I, and many others,
think it's an idea that has merit but is too flawed and
limited to be worthy of inclusion in the language.

It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL. There is,
however, much to be said for providing a language-based
mechanism to solve these important and common problems.
Some posters to this thread have argued that enumeration
types do all they need; I totally disagree, because
enumerations specify mutual exclusivity only in cases
where the mutual exclusivity can trivially be shown
to hold statically.

The practical reality, today, is that all the common
examples of this problem (notably, many variations on
the one-hot-coded theme) have perfectly viable solutions
in standard VHDL. Consequently, language support is not
high on the list of priorities for the people that matter.
I lack the will and the stamina to try to change that
situation, so I'll now shut up even though I think I
may have some better ideas
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:4sund3tnppl93cbt1lm13qeg96lfoovu1u@4ax.com...

Going back to the OP, this leads me to ask, what is actually the problem
that Weng is trying to solve?

The issue is well-known, and has numerous prior-art solutions
(I'll come back to them): There are many, many designs in which
the designer has private knowledge of the set of values that may
legally appear on a group of signals. If the designer cannot
express that knowledge to the synthesis tool, he will get
inferior logic optimization. If the designer cannot express
that knowledge to the simulator, he runs the risk of failing
to detect certain errors that put illegal values on to the
signals.

Here's a very simple example, for which no new solution is
needed.

<snip>
You did kind of the bait and switch on this one without really addressing
the question posed....what is the problem that Weng is trying to solve?

In more complicated situations, and particularly in situations
where different signals need to be tested to choose different
branches of a conditional, it can be very difficult indeed to
capture this kind of design knowledge in the code.

Ummm.....like what? Certainly not Weng's outbus example. That one is best

coded by writing it in a sum of products form, but Weng dismisses that as
being the equivalent of assembler whereas the 'orif' is a high level
construct which is completely wrong. Other cases that have been brought up
can be handled by properly reformulating the problem using enumerated types.

From what I can tell, the only problem that 'orif' solves is how to
structure something into an 'if' statement instead of using other clearly
understandable statements that are already part of the language. Much like
the person who owns a hammer sees every problem as a nail, Weng sees the
'if' statement as his hammer but finds it somewhat deficient in that he
needs a modified one (one with an 'orif') to tackle a problem that has no
nail.

Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.

If you already have the complete logic description (which is encoded in all
of the 'non-assert' statements) the synthesis tool will not really have much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information. Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)? The
synthesis tool generated logic will have no way to flag this and, I'm
guessing, is free to implement this case however it wants to independent of
the logic description....I think I'll pass on such a tool, the supposedly
'impossible' happens, 'specially as code gets reused in new applications.

<snip>

It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL.

Many times with uncontorted code as well....like the sum of products
solution to the outbus example.

There is,
however, much to be said for providing a language-based
mechanism to solve these important and common problems.
Some posters to this thread have argued that enumeration
types do all they need; I totally disagree, because
enumerations specify mutual exclusivity only in cases
where the mutual exclusivity can trivially be shown
to hold statically.

So we agree that the enumeration type solves the one class of mutual
exclusiveness. But I'm still waiting for the example of this 'common'
problem for which 'orif' is the solution.

KJ

 

[Jonathan Bromley]

On Mon, 3 Sep 2007 13:37:29 -0400, "KJ" wrote:

Here's a very simple example, for which no new solution is
needed.
snip
You did kind of the bait and switch on this one without really addressing
the question posed....what is the problem that Weng is trying to solve?

I thought/hoped that I had been fairly clear about that:
A situation in which knowledge of the dynamic, runtime
behaviour of a design is required in order to optimize
it effectively in hardware. The classic example (which,
it must be said, can easily be handled in other ways) is
the conversion of a one-hot coded bus to a binary
representation. Problems such as CPU instruction decoders
often lead to other, less straightforward examples.

it can be very difficult indeed to
capture this kind of design knowledge in the code.

Ummm.....like what? Certainly not Weng's outbus example. That one is best
coded by writing it in a sum of products form, but Weng dismisses that as
being the equivalent of assembler whereas the 'orif' is a high level
construct which is completely wrong. Other cases that have been brought up
can be handled by properly reformulating the problem using enumerated types.

I agree. It is often rather hard to capture the problem in the
form of an easily digestible example. Consequently,
advocates for such things commonly fall back on simple
examples; this stratagem is fatally flawed, because folk
like you can easily see how the simple problem can be
solved in a more elegant way.

From what I can tell, the only problem that 'orif' solves is how to
structure something into an 'if' statement instead of using other clearly
understandable statements that are already part of the language. Much like
the person who owns a hammer sees every problem as a nail, Weng sees the
'if' statement as his hammer but finds it somewhat deficient in that he
needs a modified one (one with an 'orif') to tackle a problem that has no
nail.

I have already pointed out that I regard Weng's "orif" formulation
as both flawed and inadequate. That doesn't mean that the problem
he's trying to tackle is irrelevant.

Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.

If you already have the complete logic description (which is encoded in all
of the 'non-assert' statements) the synthesis tool will not really have much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information.

Sorry, this is nonsense. Synthesis tools generally cannot see
outside the boundary of the module they're currently compiling.
Suppose you have two quite independent modules, communicating
over a flat 32-bit data bus. Suppose, what's more, that there
is a "fetch" signal emitted by one module and received by the
other; and when this "fetch" signal is asserted, the source
module reliably produces an instruction code that is one-hot
coded. How can the destination (receiving) module's VHDL
code possibly capture that knowledge? - knowledge that is
very valuable for optimising the instruction decode logic.

In any case, the idea of an "unverifiable" assertion is surely
absurd. The whole point of assertions is that they continually
monitor the data whose properties they check; long after the
assertion's author has forgotten why he put it there, the
assertion continues to contribute to the verification effort.

Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)?

Then your verification effort correctly shows that you have made
unjustified assumptions that you must review. That's the whole
point: by capturing *in a single language construct* both an
assumption that you're making about runtime behaviour, and a
permission to the synthesis tool to share that assumption,
you have a safe way to capture knowledge of a system's
expected behaviour that cannot be described any other way.

It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL.

Many times with uncontorted code as well....like the sum of products
solution to the outbus example.

Indeed so. Often there is a simple solution that
merely needs to be revealed and added to the folklore.

So we agree that the enumeration type solves the one class of mutual
exclusiveness. But I'm still waiting for the example of this 'common'
problem for which 'orif' is the solution.

OK, I promise I'll try to find some more compelling examples.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:6eqod399r1bee93gljsurka4dvrc9qnt83@4ax.com...

On Mon, 3 Sep 2007 13:37:29 -0400, "KJ" wrote:

Here's a very simple example, for which no new solution is
needed.
snip
You did kind of the bait and switch on this one without really addressing
the question posed....what is the problem that Weng is trying to solve?

<snip>

I agree. It is often rather hard to capture the problem in the
form of an easily digestible example. Consequently,
advocates for such things commonly fall back on simple
examples; this stratagem is fatally flawed, because folk
like you can easily see how the simple problem can be
solved in a more elegant way.
And we end up in the situation where one person is claiming superiority of a

new solution to an unstated problem or making unfounded claims. This thread
has droned on for a bit and Michael asked a very straightforward question
about just what problem is being solved in the OP?

From what I can tell, the only problem that 'orif' solves is how to
structure something into an 'if' statement instead of using other clearly
understandable statements that are already part of the language. Much
like
the person who owns a hammer sees every problem as a nail, Weng sees the
'if' statement as his hammer but finds it somewhat deficient in that he
needs a modified one (one with an 'orif') to tackle a problem that has no
nail.

I have already pointed out that I regard Weng's "orif" formulation
as both flawed and inadequate. That doesn't mean that the problem
he's trying to tackle is irrelevant.

Or that it hasn't been tackled already.

Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.

If you already have the complete logic description (which is encoded in
all
of the 'non-assert' statements) the synthesis tool will not really have
much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information.

Sorry, this is nonsense. Synthesis tools generally cannot see
outside the boundary of the module they're currently compiling.

Which optomization boundary are you talking about? The entity? I see cross
entity optomizations all the time. A trivial example that most here can
probably relate to is when you don't connect an entity input correctly or
don't connect the outputs to anything and you run it through and find the
whole entity has been optomized out. How do you explain that behaviour if
the entity represents any sort of actual optomization boundary.

Suppose you have two quite independent modules, communicating
over a flat 32-bit data bus. Suppose, what's more, that there
is a "fetch" signal emitted by one module and received by the
other; and when this "fetch" signal is asserted, the source
module reliably produces an instruction code that is one-hot
coded. How can the destination (receiving) module's VHDL
code possibly capture that knowledge? - knowledge that is
very valuable for optimising the instruction decode logic.

Here's two (assuming that we're living all within one FPGA/Asic design)
1. If the data bus is a point to point connection, then don't use a flat 32
bit bus, but use an enumerated type to pass the data between the modules.
2. If modules must use std_logic_vector busses to communicate (like if you
use Wishbone or Avalon, etc. as your preferred way to stitch together
modules) then an enumerated type coupled with a 'To_Std_Logic_Vector' and a
'From_Std_Logic_Vector' function.

I haven't run into any lack of optomization across the entity boundaries
when I've done either of the above and it makes for very concise and easily
maintainable code. Not only that but the mutual exclusivity (if that's a
word is directly coded it's not an assumption that may or may not be
guaranteed, new things can easily be added/subtracted from the list, blah,
blah, blah....in other words enumerated types are the solution to this one.

Optomizations (or lack thereof) could be a tool dependent issue though but I
haven't run across it to be a problem with Quartus or Synplify.

If the two modules are in different physical parts and the bus is a device
I/O then I think it would be totally inappropriate to have any code that
assumes that the PCBA and the solder connections and such would feel bound
by the idea of any sort of mutual exclusion which is why my two examples are
within the constraints of being inside one physical device.

In any case, the idea of an "unverifiable" assertion is surely
absurd. The whole point of assertions is that they continually
monitor the data whose properties they check; long after the
assertion's author has forgotten why he put it there, the
assertion continues to contribute to the verification effort.
In simulation yes. If the synthesized logic is somehow 'different' because

of the inclusion or not of the assert statement in the source code then how
does the physical part behave when the asserted condition fails? That was
my basic point. I would expect it to behave as defined by the the logic
description completely.

Having synthesis check assertions that are statically determined things is
appropriate. Dynamically though? Not convinced that it could or even
should attempt this.

Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)?

Then your verification effort correctly shows that you have made
unjustified assumptions that you must review. That's the whole
point: by capturing *in a single language construct* both an
assumption that you're making about runtime behaviour, and a
permission to the synthesis tool to share that assumption,
you have a safe way to capture knowledge of a system's
expected behaviour that cannot be described any other way.

The logic function though is described though by the logic that is written
not by the assert. Maybe we're not understanding what the other is saying
on this particular point though..

It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL.

Many times with uncontorted code as well....like the sum of products
solution to the outbus example.

Indeed so. Often there is a simple solution that
merely needs to be revealed and added to the folklore.

Definitely agree...that's one good thing about newsgroups. Not every day do
you get a useful nugget, but often enough you do.

So we agree that the enumeration type solves the one class of mutual
exclusiveness. But I'm still waiting for the example of this 'common'
problem for which 'orif' is the solution.

OK, I promise I'll try to find some more compelling examples.

Look forward to it....but I'm guessing that there may be better things to
do.

KJ

 

[Marcus Harnisch]

Hi KJ

"KJ" <kkjennings@sbcglobal.net> writes:

2. If modules must use std_logic_vector busses to communicate (like if you
use Wishbone or Avalon, etc. as your preferred way to stitch together
modules) then an enumerated type coupled with a 'To_Std_Logic_Vector' and a
'From_Std_Logic_Vector' function.

That way you will shift the issue (given that there be any) to a
different stage. What about the supposed if/else construct in
'From_Std_Logic_Vector'? Again, how's synthesis to know that the input
parameter is *always* -- say -- one-hot? You could of course use an
enumerated type to work around that...

In simulation yes. If the synthesized logic is somehow 'different' because
of the inclusion or not of the assert statement in the source code then how
does the physical part behave when the asserted condition fails? That was
my basic point. I would expect it to behave as defined by the the logic
description completely.

Having synthesis check assertions that are statically determined things is
appropriate. Dynamically though? Not convinced that it could or even
should attempt this.

What about formal verification?

The logic function though is described though by the logic that is written
not by the assert. Maybe we're not understanding what the other is saying
on this particular point though..

That's why an assertion is not appropriate for that particular
purpose. A language feature that is very similar to an assertion but
not quite the same.

What about attributes? I think these are totally underused in VHDL. I
guess the fact that their point of declaration is normally not very
close to the place where they'd be used later on, doesn't really make
them very popular. Emacs' vhdl-mode could solve that (if it doesn't
already) by displaying attribute values for the current language
construct.

Regards,
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

 

[KJ]

On Sep 4, 8:52 am, Marcus Harnisch <marcus.harni...@gmx.net> wrote:

Hi KJ

"KJ" <kkjenni...@sbcglobal.net> writes:
2. If modules must use std_logic_vector busses to communicate (like if you
use Wishbone or Avalon, etc. as your preferred way to stitch together
modules) then an enumerated type coupled with a 'To_Std_Logic_Vector' and a
'From_Std_Logic_Vector' function.

That way you will shift the issue (given that there be any) to a
different stage. What about the supposed if/else construct in
'From_Std_Logic_Vector'? Again, how's synthesis to know that the input
parameter is *always* -- say -- one-hot? You could of course use an
enumerated type to work around that...

The to/from std_logic_vector functions would convert the enumerated
type to/from std_logic_vectors simply for communicating over the
presumed 32 bit data bus. There would be no need for any if
statements in either of these functions. The encoding and decoding
functions can be lots of things but they could simply be a one hot
coding of the enumeration list or a binary coding or whatever.
Synthesis unrolls the functions and the net result of converting an
enumerated type to a std_logic_vector and then back to an enumerated
type on the other end is zero logic cells (as it should be since the
one function is the inverse of the other)....and yes it really does do
this with real tools, not just an academic 'well it should do this'.

KJ

 

[Andy]

If you already have the complete logic description (which is encoded in all
of the 'non-assert' statements) the synthesis tool will not really have much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information. Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)? The
synthesis tool generated logic will have no way to flag this and, I'm
guessing, is free to implement this case however it wants to independent of
the logic description....I think I'll pass on such a tool, the supposedly
'impossible' happens, 'specially as code gets reused in new applications.

If you've ever used integer types for synthesis, then you've already
used "built-in" assertions, and seen the synthesis tools' ability to
infer information from them, and optimize the logic to take advantage
of input combinations that cannot exist in the simulation:

signal my_int : integer range 0 to 255;

This is an integer, which if it's value ever exceeds the range of 0 to
255, inclusive, will cause a simulation halt, with an unrecoverable
error.

The synthesis tool recognizes this, and decides it does not need all
32 signed bits to represent all possible values of my_int, it only
needs 8 unsigned bits. What happens to the circuit if some value is
attempted to be stored that is greater than 255 (or less than 0)? It
does not matter, because the simulator will not describe it either.
So, for a counter, the most efficient implementation would be for it
to roll over, even though that would not happen in the simulation code
(nothing would happen, it would be an error). In effect, an assignment
that cannot happen in the simulator is treated as a don't care in the
circuitry.

So indeed there is precedence for synthesis tools using information
that is in the form of built-in assertions to allow optimization of
logic.

If you doubt this, consider the following code:

process (clk, reset) is
variable count : integer range 0 to 255;
begin
if reset = '1' then
count := 0;
elsif rising_edge(clk) then
if count - 1 < 0 then
count := 255;
else
count := count - 1;
end if;
end if;
end process;

Since count is an integer, it cannot take on a value of less than
zero, otherwise a simulation error would occur. However, the integer
expression (count - 1) can have a value less than zero (so long as the
result is not stored back in count), and therefore is a legitimate
comparison. This same code would not work for numeric_std.unsigned,
since a the subtraction operator with an unsigned and a natural always
returns unsigned. The synthesis tool is aware of all this, and
correctly optimizes the two subtractions into one (shares them), and
extracts the carry (borrow) bit for the comparison. The fitter may
perform additional optimizations or transformations, based on the
technology being targeted.

Andy

 

[KJ]

On Sep 4, 10:13 am, Andy <jonesa...@comcast.net> wrote:

If you already have the complete logic description (which is encoded in all
of the 'non-assert' statements) the synthesis tool will not really have much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information. Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)? The
synthesis tool generated logic will have no way to flag this and, I'm
guessing, is free to implement this case however it wants to independent of
the logic description....I think I'll pass on such a tool, the supposedly
'impossible' happens, 'specially as code gets reused in new applications.

If you've ever used integer types for synthesis, then you've already
used "built-in" assertions, and seen the synthesis tools' ability to
infer information from them, and optimize the logic to take advantage
of input combinations that cannot exist in the simulation:

signal my_int : integer range 0 to 255;

This is an integer, which if it's value ever exceeds the range of 0 to
255, inclusive, will cause a simulation halt, with an unrecoverable
error.

The synthesis tool recognizes this, and decides it does not need all
32 signed bits to represent all possible values of my_int, it only
needs 8 unsigned bits.

Not at all. Synthesis tools key off the range definition that is
typed in as being from 0 to 255 to calculate that an 8 bit
representation is needed. Assertions have nothing to do with it.

So indeed there is precedence for synthesis tools using information
that is in the form of built-in assertions to allow optimization of
logic.

And how can you say with any certainty that this is not just

precedence for using the defined range of an integer and has
absolutely nothing to do with assertions?

KJ