Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > undeclared identifier error message but all libraries are declaredand added (precision)

Reply
Thread Tools

undeclared identifier error message but all libraries are declaredand added (precision)

 
 
Jan Decaluwe
Guest
Posts: n/a
 
      01-03-2007
Jim Lewis wrote:

> For testbenches, where one needs to add to the address as part
> of the algorithm, what do you do? Note that address is only a
> collection of bits and, hence, is std_logic_vector.


I think this demonstrates the basic problem: we hardware designers
tend to think bottom-up, instead of top-down.

From a high-level perspective, what could be more integer-like
than an address (even without adding something to it)? Why would
I have to look at it as a collection of bits, especially in
a test bench, but also in RTL?

Still, most of us insist in dealing with integer representations
(unsigned, signed, overloaded std_logic_vectors) instead of the
abstract type itself. Problem is, people are very bad at that, even
hardware designers. So we get into trouble with it all the time.

For example, in a language like VHDL, the combination of
representational types with strong typing leads to an
explosion of type conversion and overloaded functions.
VHDL designers tend to think that this is a normal and
even useful (?) consequence of strong typing. But that's not
the case. Rather, it shows that we're not using the
"right" types - or that those are not available.

Regards,

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      01-05-2007

"Jan Decaluwe" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Jim Lewis wrote:
>
>> For testbenches, where one needs to add to the address as part
>> of the algorithm, what do you do? Note that address is only a
>> collection of bits and, hence, is std_logic_vector.

>
> I think this demonstrates the basic problem: we hardware designers
> tend to think bottom-up, instead of top-down.
>
> From a high-level perspective, what could be more integer-like
> than an address (even without adding something to it)? Why would
> I have to look at it as a collection of bits, especially in
> a test bench, but also in RTL?
>
> Still, most of us insist in dealing with integer representations
> (unsigned, signed, overloaded std_logic_vectors) instead of the
> abstract type itself. Problem is, people are very bad at that, even
> hardware designers. So we get into trouble with it all the time.
>
> For example, in a language like VHDL, the combination of
> representational types with strong typing leads to an
> explosion of type conversion and overloaded functions.
> VHDL designers tend to think that this is a normal and
> even useful (?) consequence of strong typing. But that's not
> the case. Rather, it shows that we're not using the
> "right" types - or that those are not available.
>


Although not using the 'right' types does lead to type conversion functions
there are still other areas where the type conversions will come up that
don't have anything to do with bottom-up or top-down approaches.

- Generally things need to be coded to a specification and that
specification specifies bit locations for fields in ports that interface to
software. If the hardware design were done in SystemC and the software in
C++ then one could dispense with the software interface portion of the
specification document and instead reference it to a C header file which
links to both the software and the hardware design so that changes to the
header will be incorporated in the next build of both. Lacking such a
monolithic approach you pretty much have to have conversion functions
somewhere to put port fields into the proper bit positions.

- System issues. What does it mean to update a particular byte of a
natural? That can only take on meaning after one performs the conversion to
bits and vectors. Not having a way to update a particular subunit of some
software port forces one to instead define all operations to be on things of
a particular data width. So of course you pick the size most convenient for
the design at hand and choose 8, 16, 32 based on the processor that you're
using in this system and move on.....and then find that code not really
reusable when you'd like to reuse that code in a design that has a processor
with a different native data size.

- Lack of something equivalent to a C++ template. When creating reusable
IP, generally the 'std_logic' type and derived types are used as the
interface because there is no way to make the function portable to arbitrary
types which creates the need for type conversion functions to get you to and
from the std_logic types.

As a simple example take the classic single clock fifo. Once you've written
the code for such a fifo to handle let's say type 'std_ulogic_vector' you
can't directly reuse that design to create a fifo to handle type 'natural'
(or any other type for that matter). Instead you have to physically copy
the design and dutifully go through and change the 'std_ulogic_vector' to
'natural' where it refers to fifo data items throughout the code. That copy
operation though has just created a new independent code stream.
Fixes/changes to the 'std_ulogic' version do not get incorporated in the
'natural' version unless you do so manually. The only approach in VHDL to
maintain the single code stream for the fifo functionality then is to create
conversion functions that translate from the newly desird type (in this case
'natural') to/from the type handled by the fifo design (in this case
std_ulogic_vector). Thus the conversion functions provide an aid to
actually being able to reuse IP.....but the only reason for needing those
functions is because VHDL does not have a way to parameterize the actual
type of a signal as you can with a C++ template.

Another approach would be to use some form of meta-language where the
'pristine' design code for the functionality with parameterizable data type
is coded and some tool is then used to spit out VHDL (or any other language)
as output. But the only reason for the meta-language is because of the lack
of features in the original language....it's much like a translator that
reads in System C code and spits out VHDL/Verilog for synthesis. Some
companies use this approach simply as a method to be able to supply code in
a particular language to meet customer requirements that may state use of a
preferred language.

Kevin Jennings



 
Reply With Quote
 
 
 
 
Jonathan Bromley
Guest
Posts: n/a
 
      01-05-2007
On Fri, 05 Jan 2007 12:05:58 GMT, "KJ"
<(E-Mail Removed)> wrote:

>- Lack of something equivalent to a C++ template. [...]
>
>As a simple example take the classic single clock fifo. Once you've written
>the code for such a fifo to handle let's say type 'std_ulogic_vector' you
>can't directly reuse that design to create a fifo to handle type 'natural'
>(or any other type for that matter).


SystemVerilog has addressed this with its type parameters.
As well as being useful for making templated classes, it allows any
design that only moves and stores data to be parameterized for type.

I know I have to say this quietly when Jim Lewis is listening ,
but that is one of the really good contributions that
SystemVerilog has made to the world of RTL design.
--
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.MYCOMPANY.com

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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Undeclared Identifier... but why? Kensai C++ 6 12-18-2009 09:17 PM
identifier not found error, undeclared identifier aarthi28@gmail.com C++ 2 02-26-2007 02:11 AM
Position of variable declaration is causing "undeclared identifier" error. craigbeanhead C Programming 6 07-27-2003 02:25 AM
Position of variable declaration is causing "undeclared identifier" error. craigbeanhead C Programming 1 07-24-2003 10:19 PM
Re: undeclared identifier? Ron Natalie C++ 0 07-21-2003 08:38 PM



Advertisments