How portable is this code?

[Tricky]

consider the following functions:

function get_i return integer is
begin
return 10;
end function get_i;

function get_i return boolean is
begin
return true;
end function get_i;

they both have the same name but different return types. are these
going to be safe in something like this statement across most, if not
all simulators?

echo(integer'image(get_i) & " " & boolean'image(get_i) & LF);

Am I creating a potentially confusing (for the simulator/synthesisor)
situation?

 

[Mike Treseler]

Tricky wrote:

Am I creating a potentially confusing (for the simulator/synthesisor)
situation?

As long as the return types are different,
the function IDs can be the same.

-- Mike Treseler

 

[Martin Thompson]

Tricky <Trickyhead@gmail.com> writes:

consider the following functions:

function get_i return integer is
begin
return 10;
end function get_i;

function get_i return boolean is
begin
return true;
end function get_i;

I make lots of use of this in my simulations. For example, I have
functions to decode data streams which can return several different types,
depending on how much the data I'm interested in having returned to
me.

I've never tried it in synthesis though - it ought to work,
but... well, let's say I'm a bit more pessimistic in my expectations
of synth tools (although not as much as some are

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Brian Drummond]

On Mon, 17 Nov 2008 10:57:32 +0000, Martin Thompson
<martin.j.thompson@trw.com> wrote:

Tricky <Trickyhead@gmail.com> writes:

consider the following functions:

function get_i return integer is
begin
return 10;
end function get_i;

function get_i return boolean is
begin
return true;
end function get_i;

It's absolutely fine.

I make lots of use of this in my simulations. For example, I have
functions to decode data streams which can return several different types,
depending on how much the data I'm interested in having returned to
me.

I've never tried it in synthesis though - it ought to work,
but... well, let's say I'm a bit more pessimistic in my expectations
of synth tools (although not as much as some are

I would not hesitate to use it in synth code. If it failed I would
report it to the vendor and mention it here if I felt it was
appropriate. Though I can't claim to have exhaustively tested this
approach I can say that where I've used it, so far, there have been no
sign of problems with functionality.

The only downside I've seen is that in Xilinx ISE, a really big function
evaluated at elaboration time, to populate a lookup table, (using nested
functions to generate floating point quantities, extract 48 bits of
mantissa, convert to unsigned, trim, adjust resolution and add rounding
terms etc) can take a very long time in elaboration. Like an hour for a
thousand element LUT. (Only half an hour in ISE 7.1 but it slowed down
with newer versions).

I can see something n^2 going on (once I added an assert per LUT entry)
as it clicks through the first terms quite fast and gets slower and
slower... doubling the LUT size quadruples the runtime. Perhaps it's
building linked lists of stack frames in TCL and never garbage
collecting. Quite sad really.

The same thing runs invisibly fast (<<1s) in either ISIM or Modelsim so
there's no excuse for this.

- Brian