Prev: www.world2015.org welfare trust
Next: State Machine Initialization in Synplify Pro
From: Jonathan Bromley on 21 Jan 2010 10:17
On Thu, 21 Jan 2010 05:54:10 -0800 (PST), rickman wrote:

[Mike Treseler]
>> I use integer/natural ranges for small numbers
>> and signed/unsigned for large.
>
>Can you explain the idea behind that? Why integers for small numbers
>and not large?

Can't speak for Mike, but my reasoning might be: integers are
convenient because they allow mixing of signed and unsigned
quantities, and all the sign extension and range checking
gets sorted out for me automatically; but VHDL integers
(inexcusably, for any time later than about 1990) don't
support anything wider than 31 bits. Yes, 31, that's not
a typo for 32; you can't reliably get 32-bit signed
behaviour from VHDL integers, and you can't get 32-bit
unsigned behaviour at all. Madness, and one of my top
beefs with VHDL.

Beyond 31 bits, the signed and unsigned types work well
and don't put any insuperable obstacles in my way; but
mixing signed and unsigned is tedious, and it's also
irritating that you can't copy an integer number or
expression directly into a signed or unsigned vector,
because VHDL doesn't allow overloading of the
assignment operator.

My personal choice tends to be driven by whatever looks
neatest in the specific application I have to hand;
any cracks can easily be papered-over by creating some
appropriate VHDL functions.


>As optimized as they [data types in library ieee] may be, a
> signal that does not require resolution
>will take longer than one that does. Detecting multiple drivers is
>done at compile time while the resolution is done at simulation time.
>I guess if there are no multiple drivers the difference may not be
>apparent though.

Right, a simulator can (and should!) optimise away the resolution
function when only one driver exists on a signal. I suspect the
need to support multi-valued logic is a bigger cost of CPU power
than the resolution function, in many cases. No U/X/Z to worry
about in an integer!

>> Detecting multiple drivers at compile time is very useful
>> for new users using many processes,
>> but these errors can also be found at elaboration time.

And also by synthesis tools. When writing HDL code that
aims to be synthesisable, it's a smart move to synthesise
it early in the debug process - just as soon as you've
got the syntax goofs out of it. Synthesis tools do a lot
of pretty smart static analysis and, obviously, can check
for synthesis design rules that are of no concern to simulators.
Some simulators have a "synthesis rule check" option on their
compilers, but I've never found those to be useful; they miss
far too much.

>Yeah, I can't say I have many issues with multiple drivers. I'm
>pretty sure the tools I've been using give adequate warnings when I do
>make a mistake and reuse a signal name.

Sure, but you can easily end up with syntactically legal - and
perfectly meaningful - code that drives a signal from more than
one process, and waste a lot of debug time as a result. In
fairness, that tends to be more of a beginner's problem; the
old hands around here probably get that sort of thing right
first time, more often than not.
--
Jonathan Bromley
 | 
Pages: 1
Prev: www.world2015.org welfare trust
Next: State Machine Initialization in Synplify Pro