Functions

[Matt North]

Hi,

Is it good code practice to use functions in code that will be synthesised
to a chip, rather than using them in testbenches etc?
I have a function which holds a for loop, the loop identifier increments
through an array
performing a conversion on each byte of the array.
When this is simulated in modelsim it seems to convert all the data in the
array instantly,
how does this relate to the conversion it must be doing in the hardware!.

Thanks,
Matt

 

[Jonathan Bromley]

"Matt North" <m.r.w.north@NO_SPAMrl.ac.uk> wrote in message
news:bpcv8s$p08@newton.cc.rl.ac.uk...

Is it good code practice to use functions in code that will be synthesised
to a chip, rather than using them in testbenches etc?

I think it's a great idea.

I have a function which holds a for loop, the loop identifier
increments through an array performing a conversion on each
byte of the array.
When this is simulated in modelsim it seems to convert all
the data in the array instantly,

I should hope so - you're not allowed to have any "wait"
statements in a function; they must execute in zero time.

how does this relate to the conversion it must be doing
in the hardware!.

It simply means that all conversions are done in parallel,
using separate instances of the logic implied by your
conversion function.

If the conversion function is a simple conversion from
vector to integer or similar, then the synthesised
conversion function is only wires and all is well.
But if it's a "clever" function, such as "count how
many bits are set in the word", then each byte in
your array will have a significant amount of logic
associated with it.

There's no escape; if you execute a function multiple
times, there must necessarily be multiple instances
of whatever hardware it implies. You can't use one
piece of hardware to do multiple things *at the
same moment*. If you want to cycle the bytes in
your array through one piece of hardware, one
byte per clock cycle, you will need to create a
state machine and some data steering logic.

HTH
--
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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

 

[Mike Treseler]

Matt North wrote:

Is it good code practice to use functions in code that will be synthesised
to a chip, rather than using them in testbenches etc?

A function is an optional way to
compress and parameterize an expression.

Functions can be used to create values for synth or sim.
Advantages can include code clarity and less typing.

Usage is a style question.

Is

foobar := foobar + 1;

better than

inc(foobar);

?

-- Mike Treseler

 

[Kai Harrekilde-Petersen]

Mike Treseler <mike.treseler@flukenetworks.com> writes:

Matt North wrote:

Is it good code practice to use functions in code that will be synthesised
to a chip, rather than using them in testbenches etc?

A function is an optional way to
compress and parameterize an expression.

Functions can be used to create values for synth or sim.
Advantages can include code clarity and less typing.

Usage is a style question.

Is

foobar := foobar + 1;

better than

inc(foobar);

For trivial functionality - such as the increment above - using
function should really be avoided, IMHO[*]. For more complex functions,
e.g. a leaky-bucket or CRC32 update, functions are great.

[*]Of course, you could use the inc() function to hide the
implementation of said incrementer, and later pick an implementation
that suits the purpose (binary, gray, or one-hot?). In that case,
using a function is clearly defendable.

So, as a general statement, I would say that it is a good practive to
use functions in code that will be synthesized.

Regards,


/Kai