Examples of issues with std_logic_arith
Sean Durkin
I know the whole numeric_std vs. std_logic_arith issue has been covered
several times before here, but please bear with me for a second :)
Does anyone of you have any concrete examples of problems that came up
because std_logic_arith was used? Code examples that behave differently
in different simulators/synthesis tools maybe? When I look at the
discussions about this issue in the past, it's always "std_logic_arith
should not be used, because it's not a standard and might be implemented
differently in different tools". But I've never seen actual examples or
heard of a problems arising from use of std_logic_arith.
I personally have always used numeric_std, because that's the way I
learned it. But when I talk about this with colleagues, the "use it
because it's a standard"-argument never beats the "I've been using
std_logic_arith forever, never had the slightest problems and don't see
why I should ever change anything"-argument.
So I'd be glad if maybe someone could share some "war stories" or
something. :)
cu,
Sean
--
Replace MONTH with the three-letter-abbreviation for the current
month. Simple, eh?
Jonathan Bromley
>I know the whole numeric_std vs. std_logic_arith issue has been covered
>several times before here, but please bear with me for a second :)
>
>Does anyone of you have any concrete examples of problems that came up
>because std_logic_arith was used? Code examples that behave differently
>in different simulators/synthesis tools maybe?
I don't have any specific examples; I have better things
to do with my time than to hunt bugs in a package that
I never intend to use. But here are the things that
matter to me:
1) *If* there are any errors in either package, then
at least with numeric_std there is formal agreement
about what the right behaviour should be, so the
presence or absence of a bug is unambiguous.
2) std_logic_arith is fairly incomplete, although I'm
sure some tools have filled in the gaps. numeric_std
has a complete repertoire of operators that I can trust.
3) The function names in std_logic_arith are unhelpful.
How am I supposed to remember whether CONV_INTEGER
converts FROM or TO integer? Similar gripe with SXT.
There is almost no cost to changing over; any legitimate
design using std_logic_arith can be ported to numeric_std
merely by allowing your compiler to find the missing
function names, and appropriately patching any calls
to CONV_* and SXT (there shouldn't be very many of those,
in well-written code).
>I personally have always used numeric_std, because that's the way I
>learned it. But when I talk about this with colleagues, the "use it
>because it's a standard"-argument never beats the "I've been using
>std_logic_arith forever, never had the slightest problems and don't see
>why I should ever change anything"-argument.
So, yes, they can coexist if you're willing for YOUR PROJECT
and YOUR PRODUCT to carry the risk of using a non-standard,
potentially unsupported package. Are you OK with that?
How about your project manager? The argument from inertia
is the same one that left some folk coding unproductively in
assembler when smart people were using high-level languages.
>So I'd be glad if maybe someone could share some "war stories" or
>something. :)
Sorry I can't help, but life's too short :-)
--
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...@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.
Mark McDougall
> But I've never seen actual examples or
> heard of a problems arising from use of std_logic_arith.
IIUC, it's the same argument one can use for or against _any_ standard
programming library.
Using any non-ratified standard library, you run the risk of everything
you mentioned. The bottom line - it's less portable. And whilst I can
envisage plenty of future maintainers of your code converting from a
non-standard library to a standard library, I can't imagine many (worth
their salt) converting the other way around (even if they personally
prefer the non-standard library, they should get their bum well and truly
kicked for actually changing already-compliant code).
Having said that, the commercial reality (IMHO) is that your code will be
used in a handful (if not just one) of projects, same vendor, same tools,
and if it works for you now, it'll probably continue to do so long after
your legacy is completely forgotten.
Regards,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Mark McDougall
> (even if they personally
> prefer the non-standard library, they should get their bum well and truly
> kicked for actually changing already-compliant code).
Further on this note...
I come from a software engineering background, and have worked on a whole
host of systems ranging from embedded micro through PC platform up to even
mainframe. One thing I've learned "when in Rome..."
There was a contract I worked on a while back where I was provided with a
copy of the company's "C coding standards". Trouble was, I was adapting
existing code (from Microsoft IIRC) for their purpose, and attempting to
adhere to their standards would've made an absolute mess of the source
code. I advised them that I was happy to follow their standards for any
"external code", but any modifications/additions to the Microsoft code
were going to be consistent with the Microsoft coding style. They agreed
to that much at least.
I admit that traditionally I've been using std_logic_arith myself - only
because I cut my teeth on it before I "knew any better". Lately I've made
a more concerted effort, and am slowly converting my code base to use
numeric_std whenever I need to make modifications to a file.
Martin Thompson
> Hi *,
>
> I know the whole numeric_std vs. std_logic_arith issue has been covered
> several times before here, but please bear with me for a second :)
>
> Does anyone of you have any concrete examples of problems that came up
> because std_logic_arith was used? Code examples that behave differently
> in different simulators/synthesis tools maybe? When I look at the
> discussions about this issue in the past, it's always "std_logic_arith
> should not be used, because it's not a standard and might be implemented
> differently in different tools". But I've never seen actual examples or
> heard of a problems arising from use of std_logic_arith.
IIRC (and it was a long time ago), I spoke to someone who got weird
results from comparisons of different length vectors. Instead of them
being sign or zero extended (depending on type) the shorter vector was
always treated as less than the longer one (eg 0111 < 000001). Or
something like that, I don't recall the details. IIRC the code worked
fine once he changed to numeric_std.
Sorry, that's a bit of a "third-hand" story, but it's where I first
got told "use numeric_std"!
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Tricky
consider this:
architecture sim of play_tb is
constant ZERO_8 : std_logic_vector := x"00";
constant ZERO_9 : std_logic_vector := b"0_0000_0000";
begin
process
begin
echo(boolean'image(ZERO_8 = ZERO_9) & LF);
wait;
end process;
end architecture sim;
if std_logic_unsigned is not included, this returns false (unmatched
array lengths)
if it is included, it returns true.
Using numeric std (and not the synopsys packages) would allow this to
always be false (as it possibly should). Basically the arith/unsigned/
signed packages give meaning to std_logic_vectors, when they really
shouldnt.
Jacko
> Hi *,
>
> I know the whole numeric_std vs. std_logic_arith issue has been covered
> several times before here, but please bear with me for a second :)
The critical point to get is that std_logic_vector is a string type!
so expect it to behave as such sometimes, including having a greater
than 32 bit length.
numeric standard_does a string->number->string with number being
limited to 32 bits. std_logic_artih does not do this conversion, an
all things remain as strings with a limited character subset.
If you go for more than addition and subtraction, then things get less
supported in logic arith. If you understand your logic, then this is
no problem to write your own boole multiplier etc.
With numeric std, full arithmetic is generally supported to 32 bit
resolution with reduction of stuck at 1 or 0 inputs. You can't easily
write a 64 bit cpu in numeric std.
cheers jacko
kennhe...@sympatico.ca
>
> With numeric std, full arithmetic is generally supported to 32 bit
> resolution with reduction of stuck at 1 or 0 inputs. You can't easily
> write a 64 bit cpu in numeric std.
>
> cheers jacko
I just looked at the source for numeric_std and how it implements
addition, subtraction, multiplication, and division. As far as my
quick perusal reveals, everything is coded at the bit level and has no
constraints other than the LENGTH of the unsigned/signed numbers have
to be integers, so it looks like it could support (roughly) numbers up
to 2^31 bits in length. Can you give a more precise description of
where you ran into this issue - I'm curious to know if I mis-read the
code?
- Kenn
Alan Fitch
That's almost completely wrong in every respect.
regards
Alan
--
Alan Fitch
Senior Consultant
Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services
Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan....@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com
------------------------------------------------------------------------
This message may contain personal views which are not the views of
Doulos, unless specifically stated.
Tricky
>
> numeric standard_does a string->number->string with number being
> limited to 32 bits. std_logic_artih does not do this conversion, an
> all things remain as strings with a limited character subset.
>
Tell that to my 36 bit unsigned mutliplier results!
Sean Durkin
just wanted to say thanks to everyone who took the time to respond, I
really appreciate it. Now I have some more convincing arguments :)
Alan Fitch
> Jacko wrote:
>> On 26 Mar, 10:17, Sean Durkin <news_MO...@tuxroot.de> wrote:
>>> Hi *,
>>>
>>> I know the whole numeric_std vs. std_logic_arith issue has been covered
>>> several times before here, but please bear with me for a second :)
>>
>> The critical point to get is that std_logic_vector is a string type!
>> so expect it to behave as such sometimes, including having a greater
>> than 32 bit length.
>>
>> numeric standard_does a string->number->string with number being
>> limited to 32 bits. std_logic_artih does not do this conversion, an
>> all things remain as strings with a limited character subset.
>>
>> If you go for more than addition and subtraction, then things get less
>> supported in logic arith. If you understand your logic, then this is
>> no problem to write your own boole multiplier etc.
>>
>> With numeric std, full arithmetic is generally supported to 32 bit
>> resolution with reduction of stuck at 1 or 0 inputs. You can't easily
>> write a 64 bit cpu in numeric std.
>>
>> cheers jacko
>
> That's almost completely wrong in every respect.
>
> regards
> Alan
>
>
Sorry I was a bit quick there - perhaps I should be more specific
1. std_logic_vector is not "a string type" it is an unconstrained array
of std_logic
2. numeric std uses types signed and unsigned which are also
unconstrained arrays of std_logic
3. numeric std does *not* do a "string -> number -> string" conversion.
All functions and operators (except to_integer, to_signed, to_unsigned)
are written to work on signed and unsigned (which are arbitrary width up
to the range of NATURAL)
The exceptions are the conversions to and from integer which must
produce a result limited to the range of integer - but then so is
conv_integer in std_logic_arith
4. I agree that the coverage of arithmetic operations is not as good in
std_logic_arith as it is in numeric_std.
5. Numeric std *can* easily write a 64 bit cpu,
Mike Treseler
> I personally have always used numeric_std, because that's the way I
> learned it. But when I talk about this with colleagues, the "use it
> because it's a standard"-argument never beats the "I've been using
> std_logic_arith forever, never had the slightest problems and don't see
> why I should ever change anything"-argument.
There probably is no example that will win this argument.
That's the way *they* learned it.
If you prosper, you could buy the company
and lay down the law. Short of that,
it may be best to lead by example.
I code in my own style and then provide
a wrapper interface entity to anyone
allergic to my vector types.
-- Mike Treseler
Jacko
I didn't run into an issue, I've used std_logic_arith always, I have
never needed the higher coverage of division ops, or needed to convert
between integers and std_logic.
I only use + and - and I always make sure that the result size is
assigned to a correctly sized std_logic_vector. I think the limits
come by using type integer to store calculation results, which I never
do. I never use any library feature to perform sign extension, and
prefer a more explicit '&' concat style of coding.
The reason for my preference for std_logic_arith is that I constrains
me to not get too flashy with large sythesis designs. Case in point
'/' can expand to a large amount of logic etc.
signal1 <= unsigned(signal2)+1 -- is about as complex as my use is of
the libraries. as a synchronous counter.
The adder in the ALU of http://nibz.googlecode.com is implemented in
descrete logic to reduce produced area. i.e. the whole CPU fits in
less space than the multiplexed 4 way standard library version of the
ALU processor. Granted it is faster in the 4 way multiplexed library
version, but this is due to non optimal use of fast carry routing.
(technology specific).
I find I can not rely on library code reducing to minimal area.
cheers jacko
Andy
> Fax: +44 (0)1425 471573 http://www.doulos.com
>
> ------------------------------------------------------------------------
>
> This message may contain personal views which are not the views of
>
> - Show quoted text -
I'm not that familiar with std_logic_arith. I've avoided it whenever
possible, and never seen any code that got beyond the basics with it.
What arithmetic operations does SLA/SLS/SLU support that numeric_std
does not?
I am aware that many moons ago, Synopsys did not support
numeric_std.signed/unsigned and div/mod by integral powers of 2 for
synthesis, but they would simulate it.
Andy
Mike Treseler
> I'm not that familiar with std_logic_arith. I've avoided it whenever
> possible, and never seen any code that got beyond the basics with it.
Save here.
The package is often declared, but rarely used.
Commenting the unused USE clause can eliminate some sim warnings.
> What arithmetic operations does SLA/SLS/SLU support that numeric_std
> does not?
None.
That is the old Mentor version by the way.
Synopsys has different names for those operators.
-- Mike Treseler
Mike Treseler
> Save here.
Same