Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Examples in LRM and/or LCS



Hi Pablo,

Multiplying an N bits (unsigned) vector by a P bits vector creates a (N+P) bits result.
and certainly not 2 N bits !
Apparently, this was not known by the person who wrote "*" (unsigned,natural).
This function should return a 32 + N bits result. (Natural'length + N)
It's a bug. It's nasty because the warning is very difficult to relate to the
problem source etc.
Note : I don't have a good opinion about numeric_std in general, there
are many other bad things in it. The fact it has been that bad for so long
doesn't make it any better.

And how about this one :

Library IEEE;
 use IEEE.std_logic_1164.all;
 use IEEE.numeric_std.all;

entity resizebug is end;
architecture test of resizebug is
begin
  process
    subtype uByte_t is unsigned (7 downto 0);
    variable u8 : uByte_t;
  begin
    wait for 10 ns;
    u8 := resize (unsigned'(x"8000"),8);
    -- we naively believe it is safer using resize than cutting a slice !
    report ("resize(x""8000"",8) = (drumroll....) "&integer'image(to_integer(u8)) & " without a warning !" );
    wait;
  end process;
end architecture test;

In the list of things that would help make VHDL better and be easier/safer
to use IMHO is fixing the many poor existing implementations when it is
possible to do so without disrupting existing code.
This is another example of this. Even if I don't have the code, I'm sure
it's trivial to fix (generate the proper warning).
The package body not being public doesn't help.
Not issuing a warning for a dedicated function that takes a slice and loses
information doesn't look brilliant to me.
It's yet another caveat I have to teach :-(
In Verilog, you almost never get any warning, so you learn the hard way
to be cautious and perform some linting... In VHDL, you have to deal with
so many false negatives (hence the current discussion about warnings
control) that you tend to forget that false positives do exist.

Bert

On 13/03/2020 13:49, Pablo Blecua wrote:
Hi all,

The Instance part of the message is a courtesy of your simulator vendor (the one with the M I guess).

Mine doesn’t say anything at all, so finding where it happens is a real burden:

ASSERT/WARNING (time 861093750 PS) from function @ieee.NUMERIC_STD:TO_SIGNED

NUMERIC_STD.TO_SIGNED: vector truncated


I was going to make the suggestion that the warning should provide (ideally) the instance and process where it is called (and even better if they add the line number). As a bare minimum I would want the instance name. Other ways it can be a nightmare for debugging. Imagine if you have several files all using numeric_std? Yes, I know that one could elaborate/simulate them one by one... not very efficient. Then I saw that in Ryan's provided log the instance name was indicated and assumed that it was so for all simulators (I also have been working with M lately, so when I double-checked I also got the instance name for run-time warnings).


report "Numeric_std says : 128 * 1000 = " & integer'image(to_integer(unsigned'(x"80")*1000));

In my opinion this particular case should not give a warning, but an error (I may be the one that Jim mentioned :p). That would allow the user to see that the operation is not being performed correctly, according to the selected rules/implementation (if the selected rules/implementation is the best possible one is a different topic), and correct the code to perform as expected. I know that this "may break older designs" but I see it more as "it will show errors in older designs that apparently have never triggered" This may allow to patch code that otherwise may, in the future, fail.
Looking at it a second time I am not sure if there may be designs out there with this "bug", since any multiplication of an unsigned 8-bit with 1000 (or any natural greater than 255) would give an erroneous value (except if the 8-bit is set to 0) since it is really doing value_16bit = value_8bit * (1000 MOD 2^8). Unless of course the part of the code with the multiplication has not been tested?
Please note that I advocate promoting SOME warnings to errors not all of them.

Regards,

   Pablo


On Fri, Mar 13, 2020 at 9:59 AM Jakko Verhallen <jakko.verhallen@xxxxxxxxxxx> wrote:

Hi Ryan,

 

It does print messages but it can be confusing.

The message says that the to_unsigned call in /test0 is failing.

And if you look in that hierarchy, you see a to_unsigned, so you might think the error is there.

But that is not the one which is failing, it is the one implied by the “*” operator, deeper down the package.

 

The Instance part of the message is a courtesy of your simulator vendor (the one with the M I guess).

Mine doesn’t say anything at all, so finding where it happens is a real burden:

ASSERT/WARNING (time 861093750 PS) from function @ieee.NUMERIC_STD:TO_SIGNED

NUMERIC_STD.TO_SIGNED: vector truncated

 

 

Regards,

 

Jakko

 

From: vhdl-200x@xxxxxxxxxxxxxxxxx <vhdl-200x@xxxxxxxxxxxxxxxxx> On Behalf Of Ryan Hinton
Sent: Friday, March 13, 2020 12:00 AM
To: vhdl-200x@xxxxxxxx
Subject: RE: Examples in LRM and/or LCS

 

<snip CUZEAU example>

 

OK, I wanted to make sure.  A MWE follows.  As expected, I get the following warning at startup.

 

# Loading std.standard

# Loading std.textio(body)

# Loading ieee.std_logic_1164(body)

# Loading ieee.numeric_std(body)

# Loading work.test0(test)#1

# ** Warning: NUMERIC_STD.TO_UNSIGNED: vector truncated

#    Time: 0 ns  Iteration: 0  Instance: /test0

 

Design:

 

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.numeric_std.all;

entity test0 is

end entity test0;

architecture test of test0 is

begin

  process

  begin

    report "Numeric_std says : 128 * 1000 = "

            & integer'image(to_integer(unsigned'(x"80")*1000));

    wait;

  end process;

end architecture test;

 

Let it not said that NUMERIC_STD is sparing in its warnings. :-)

 

- Ryan

 

From: vhdl-200x@xxxxxxxxxxxxxxxxx <vhdl-200x@xxxxxxxxxxxxxxxxx> On Behalf Of Jim Lewis
Sent: Thursday, March 12, 2020 3:45 PM
To: vhdl-200x@xxxxxxxx
Subject: [EXT] s::[i] Re: s::[i] Re: [Extern] RE: VHDL-20XX - Make a list ....

 

Hi Bert,
To publicize and popularize SV, I think it was Accellera that
funded SV LRM for free.    I doubt there will be funding for
free VHDL LRM.

OTOH, we can create examples and if we do the text in the proposals
well, maybe we can have an open source a "New Stuff" book.
Authors only make enough to buy one round of beer for a small group
friends.

WRT your example, there are proposals to provide better control
of these and at least one that thought wimpy warnings should be
errors, however, your example is an even more special case as the _expression_
you show is probably evaluated during analysis (compile), and hence,
is unlikely to produce an error during run time.  

Bert_Example: process
  subtype uByte_t is unsigned (7 downto 0);
begin
  report ("Numeric_std says : 128 * 1000 = "& integer'image(to_integer(uByte_t'(x"80")*1000))); wait;
end process;
-- ** Note: Numeric_std says : 128 * 1000 = 29696

One of the more interesting bugs I chased was when the tool was
evaluating a _expression_ during elaboration and crashed the simulator.
No break points to set the simulator crashed before it started.
Good thing I am good at guessing.

Cheers,
Jim

On 3/12/2020 11:48 AM, Bertrand CUZEAU wrote:

Hi Jim,

I think there are (many) PROs and I agree (some) CONs for including
detailed and practical examples in an LRM. I just re-opened the paper
version of 1076-2000 (I never considered it was a good use of my money)
and I see some examples, and not enough for my taste (like in 7.4 static
expressions -a common chore imo-).
I didn't try to acquire the pdf version and I almost never opened it.
But I do have the 1800-2017.pdf on all my PCs desktops !
Not only because it's free now (I also did purchase it when it was not free -d'oh),
but because it includes a lot of examples that help understand the rationale
and the working of the language features. When I teach SV, I encourage delegates
in opening the (1315 pages pdf) LRM during the labs when they have doubts
on a particular construct.

IMHO, a perfect LRM should both be a complete and unambiguous reference
for the tools designers (with  formal syntax and semantics definitions, hard
to read to most humans), and a Reference Guide for the users (with practical
examples and caveats).
(And it should be free, but that's another story).

I had recently a heated argument with a SV simulator vendor about
zero-length sequences : they did not agree about x ##1 a[*0:1] ##1 y
being either x ##1 y (or x ##1 a ##1 y), as we teach.
They claimed it should be x ##2 y (or ...).
Fortunately, the LRM has a lengthy explanation about the handling
of zero-length sequences, but also practically the same example with
a decomposition demonstrating why we were right and they were wrong.
This helps both the common user and the tool vendors (RTFM).

I am not a scientist nor a semantic expert, but just a modest user of the
languages and tools as instruments to create reliable, readable, creative
and optimized designs and IPs. I think people in my case should not be afraid
of opening an LRM while working. Having to rely on what you learn at school
or in third party books never worked ! I wrote my first Verilog course 25 years
ago, quickly followed by a VHDL course and a Digital Design course.
I never thought I would still have to teach all of them 25 years later.
Not everybody can afford attending high quality ILTs.

I think an ideal LRM should also be a reliable and reasonably friendly place
to learn a language. And open-source.

I'm less sure about whether this idea would be implementable (probably not) :
the LRM might include or point to code segments that could be used as
regression tests for tools and not only practical examples.

My VHDL favorite :-) is :

process
  subtype uByte_t is unsigned (7 downto 0);
begin
  report ("Numeric_std says : 128 * 1000 = "& integer'image(to_integer(uByte_t'(x"80")*1000))); wait;
end process;
-- ** Note: Numeric_std says : 128 * 1000 = 29696
(and no warning at all)

Bert

On 12/03/2020 17:26, jim wrote:

I am not sure I want them in the LRM / LCS as if we are nat careful that can be hard to maintain.

 

We need to make sure a small core group can update the standard without too much trouble.

 

If course make the process better and then maybe I will be all in.

 

On the last revision there were numerous notes that restated implications of requirements on protected types from other sections.  While well intentioned and I am sure they benefited someone they were painful to update.   We need to avoid adding this sort of no value item to the document.  

 

The LRM is not a user guide and is not meant to replace a book.

 

OTOH, rather than putting the examples into the standard, we could put them into an open source book.   Maybe we could evolve the accepted proposals into the book text?

 

 

 

-- 
Bertrand Cuzeau 

To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1

 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis                                  Jim@xxxxxxxxxxxxxx
VHDL Training Expert                       http://www.SynthWorks.com
IEEE VHDL Working Group Chair                      
OSVVM, Chief Architect and Cofounder
1-503-590-4787
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1


  

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.

 


To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1


To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1


To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1


-- 
Bertrand Cuzeau - Technical Manager 
  mailto:cuzeau@xxxxxxxxxxx 
  ALSE : The FPGA Experts
  http://www.alse-fr.com
  8, passage Barrault - 75013 - PARIS France
  Tel : 33. 1 84 16 3232
=D-  =D-  =D-  =D-  =D-  =D-  =D-

To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1