RE: [vhdl-200x] A Challenge

Hello list,

Le 2015-04-28 08:38, Radosław Nawrot a écrit :
> Hi Jim, Hi All
> 
> I don't know if this appeal concerns features that are not in wiki 
> proposals
> or not on the voting list. I assume that If It's not on voting list - 
> it was
> not considered to work on it.
> 
> IMHO very important feature would be DPI for VHDL:
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/DpiProposal
> 
> Even in basic variation of proposal  (only DPI_C) i would be usefull 
> and
> gives user many new opportunities (simple and fast access to golden 
> model,
> Xtors, own library or different tool),

I only discover DPI now, and it looks interesting.
I use a lot of VHPI with GHDL to get around the limitations
of the software and language so any progress in the interoperability
of extensions, and any enhancement of interfaces (outside of the
plain simulator) is a Good Thing (tm).

                      -o-oO0Oo-o-

I have not been able to contribute these last months but
the subjects that motivate my subscription are three aspects
of the same bundle (the very definition of numbers in VHDL) :

1) higher bit count integer numbers (64 bits or more
if/when the user needs it),
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers

2) modular and/or saturated arithmetic (I still have to respond
to several messages about this and some misunderstandings)
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ModularTypes

3) boolean/logic operators on integers (my pet concern).
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/IntegerOperators

All three appear to be linked so Jim's requirement of an easy
and unobstrusive addition is not met.

However, if a "quick and easy" spec is all Jim needs,
the logic/boolean operators addition is the easiest
and most likely to ease certain simulations or simplify code.

The IntegerOperators proposal raises several issues and
they could be addressed with an interim package.
The package will help fine tune the operators, provide
backwards compatibility (old simulators can use the new code)
and will not break old code (the new operators can be used
only if included by the new package, so it won't interfere
if they were defined already by another package).

The package would contain "dumb" definitions such as

function "and" (a,b : in integer) return integer is
   begin
     return to_integer(to_signed(a, 32) and to_signed(b, 32));
   end;

(32 should be adjusted so it fits the platform, it could be
a package-specific variable or constant...)

My initial idea was to enable the new operators with
a command line switch but the package approach is more
flexible and allows older tools to benefit from them.
Tool writers can then detect if the package is included
in a given scope, and provide an "optimised version" (enabling
the operator directly in the compiler/parser).

This obviously leaves certain issues open but they will
be solved naturally with the modular and arbitrary
integers. At least, it helps build some momentum toward
their definition.

The issues I see are related to the size of the integers.
The example uses 32 bits, but the platform may have more
and the user may want less. The implementations can also
check the integer's 'RANGE attribute to mask with the
appropriate value. Please be forgiving as I know I'm pulling
this out of nothing but I'm only resuming my contribution.


Sorry, I won't be available (again) for the next meeting :-/

> Best Regards,
> Radek
yg

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.