Array Access and Naming 
Author Message
 Array Access and Naming

Hi,

simple question on a problem i ran into.

say i name a vector My_State and it goes from 3 DownTo 0.

and say i name a signal My_State1.

seems reasonable, right?

now, should the names My_State and My_State1 be distinct?  or does My_State
(first element) conflict with My_State1?  gotta figure out if vhdl
generator or vhdl compiler is guilty and my books don't cover this.  in
Pascal, for instance, the names are distinct.  what's the legal ruling for
vhdl?

yeah, i know, if your arm hurts when you raise it over your head "don't do
that!"  but this is a pain to go in and manually fix, if i have to.

thanks for the help.

--------------------------------------------------------------
rk

"there's nothing like real data to{*filter*}up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------



Sat, 12 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Quote:

> Hi,

> simple question on a problem i ran into.

> say i name a vector My_State and it goes from 3 DownTo 0.

> and say i name a signal My_State1.

> seems reasonable, right?

> now, should the names My_State and My_State1 be distinct?  or does My_State
> (first element) conflict with My_State1?  gotta figure out if vhdl
> generator or vhdl compiler is guilty and my books don't cover this.  in
> pascal, for instance, the names are distinct.  what's the legal ruling for
> vhdl?

From a VHDL point of view there is NO relation between My_State and My_State1,
My_State(1) is not the same as My_state1.

Egbert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE  Enschede
the Netherlands



Sat, 12 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Quote:

>thanks for the reply.  i shall consider the vhdl compiler guilty.  the
>manufacturer stated that they consider My_State(3 DownTo 0) and My_State1 to
>be in conflict when the names get flattenned.

I wouldn't be too hasty about blaming the compiler - this seems to be
common practice. Naylor & Jones's book specifically recommends not
using names that end in a number, for precisely this reason.




Sat, 12 Aug 2000 03:00:00 GMT  
 Array Access and Naming




:
: >thanks for the reply.  i shall consider the vhdl compiler guilty.  the
: >manufacturer stated that they consider My_State(3 DownTo 0) and
My_State1 to
: >be in conflict when the names get flattenned.
:
: I wouldn't be too hasty about blaming the compiler - this seems to be
: common practice. Naylor & Jones's book specifically recommends not
: using names that end in a number, for precisely this reason.
:

hi,

well, i got several e-mails saying that the names should be distinct.
anyone have a copy of the language reference manual (mine's packed away
from the last move, gotta dig it out) and know where this is covered?  then
i know which vendor to complain to and hopefully get this fixed as it's a
pain to go in and modify the code by hand.  now, this naming is done not be
a humanoid but by a machine.  specifically, i'm trying to take statecad
output and run it into the vhdl compiler.  i'm just learning the statecad
and so far didn't see anyway to tell it not to do that.  and it doesn't
have a switch setting form my current vhdl compiler/synthesizer to work
around this "bug" or "feature."  i did run the code fragment through
synplicity (as did another engineer who responded via email) and it didn't
complain.

but rules are rules and any decent programming language should be
unambiguous about this construct.

thanks for the comments!

--------------------------------------------------------------
rk

"there's nothing like real data to{*filter*}up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------



Sat, 12 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Quote:

>Hi,
>say i name a vector My_State and it goes from 3 DownTo 0.

>and say i name a signal My_State1.
>now, should the names My_State and My_State1 be distinct?  or does My_State
>(first element) conflict with My_State1?

In VHDL the names are distinct. Note, however, that many schematic entry tools
treat bus expansion as concatenation of the bus name and index, so you might
run into trouble later.

But that's not VHDL's fault, is it? :)

Greetings,

Hendrik De Vloed -- A4000/40 -- Aminet:hard/hack/lcdaemon.lha -- Barco N.V. FPGA/ASIC design
(these are my private opinions which may oppose those of my employer, my family or other
basic laws of nature) <To reply by E-mail, remove the "_hates_spam" parts from my address>



Mon, 14 Aug 2000 03:00:00 GMT  
 Array Access and Naming

rk:
: >Hi,
: >say i name a vector My_State and it goes from 3 DownTo 0.
: >
: >and say i name a signal My_State1.
: >now, should the names My_State and My_State1 be distinct?  or does
My_State
: >(first element) conflict with My_State1?

hendrik:
: In VHDL the names are distinct. Note, however, that many schematic entry
tools
: treat bus expansion as concatenation of the bus name and index, so you
might
: run into trouble later.
:
: But that's not VHDL's fault, is it? :)

rk:

perhaps it is.  i think we've all learned during schematic entry NOT to
name buses for muxes with input busses BUS1, BUS2, BUS3, etc., with the
output bus being called BUS.  makes a big mess.  and probably why the big
guy invented the '_' character.

but in this particular case, i took the output of a program which generated
VHDL code (and apparently legal code from your response) and fed it into a
VHDL compiler/synthesizer.  no schematics involved.  never touched by
humanoid hands.

now, if as you say, the output of the code generator is legal VHDL code,
then i talk to VHDL compiler/synthesizer people (which is in progress).  if
it's illegal vhdl code being generated, then i call up company #1, whose
program generated the VHDL code.

isn't software wonderful?

--------------------------------------------------------------
rk

"there's nothing like real data to{*filter*}up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------



Mon, 14 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Quote:

> : But that's not VHDL's fault, is it? :)

> rk:

> perhaps it is.  i think we've all learned during schematic entry NOT to
> name buses for muxes with input busses BUS1, BUS2, BUS3, etc., with the
> output bus being called BUS.  makes a big mess.  and probably why the big
> guy invented the '_' character.

> but in this particular case, i took the output of a program which generated
> VHDL code (and apparently legal code from your response) and fed it into a
> VHDL compiler/synthesizer.  no schematics involved.  never touched by
> humanoid hands.

> now, if as you say, the output of the code generator is legal VHDL code,
> then i talk to VHDL compiler/synthesizer people (which is in progress).  if
> it's illegal vhdl code being generated, then i call up company #1, whose
> program generated the VHDL code.

> isn't software wonderful?

If you don't mind me asking who's software was this.  I have to agree
with all the posters they are different, but some very LOW $$$ tools
take shortcuts...so who is it???

TomT...
--
+------------------------ ---------------------- ----------------------+
: t2design                                                             :
: 249 Lois Drive                                                       :
: Louisville, CO 80027                                                 :
+------------------------ ---------------------- ----------------------+

+------------------------ ---------------------- ----------------------+



Mon, 14 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Interesting problem. I was going to preach about the perils of sloppy
programming. But I see that your names are not your own.

I was taught in a software engineering class that identifiers should be clearly
distinct. If one holds to that rule, no names such as foo1 and foo(1) should be
used in the same program. So even if they are legally distinct, they should be
avoided to prevent confusion by the programmer (human). But since your
programmer was a program itself, I guess it is up to the language to govern.
And it sounds very clear that the language indicated that they are distinct.

Rick Collins
re:DSP

Quote:

> ..snip..
> around this "bug" or "feature."  i did run the code fragment through
> synplicity (as did another engineer who responded via email) and it didn't
> complain.

> but rules are rules and any decent programming language should be
> unambiguous about this construct.



Wed, 16 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Rick:
: Interesting problem. I was going to preach about the perils of sloppy
: programming. But I see that your names are not your own.
:
: I was taught in a software engineering class that identifiers should be
clearly
: distinct. If one holds to that rule, no names such as foo1 and foo(1)
should be
: used in the same program. So even if they are legally distinct, they
should be
: avoided to prevent confusion by the programmer (human). But since your
: programmer was a program itself, I guess it is up to the language to
govern.
: And it sounds very clear that the language indicated that they are
distinct.

rk:

i don't see anything that bad about foo1 and foo(1) or other slight
differences in names.  like a recent real humanoid coded design had PPB1
PPB2 PPB3 PPC1 etc., where these were partial products with the letter
representing the level and the number the position across.

now, i would say, that 'foo1' and 'fool' as identifiers would be a crime
against humanity.

just a thought,

--------------------------------------------------------------
rk

"there's nothing like real data to{*filter*}up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------



Thu, 17 Aug 2000 03:00:00 GMT  
 Array Access and Naming

Quote:

> Rick:
> : I was taught in a software engineering class that identifiers should be
> : clearly distinct. If one holds to that rule, no names such as foo1 and :
> foo(1) should be used in the same program. So even if they are legally
> distinct, they    ..snip..
> rk:

> i don't see anything that bad about foo1 and foo(1) or other slight
> differences in names.  like a recent real humanoid coded design had PPB1
> PPB2 PPB3 PPC1 etc., where these were partial products with the letter
> representing the level and the number the position across.

> now, i would say, that 'foo1' and 'fool' as identifiers would be a crime
> against humanity.

> just a thought,

Names such as your example of partial products are used all the time. But the
distinction between foo1 and foo(1) is rather subtle and easy to confuse. In
my personal experience I make this type of error very often (some of us are
worse than others, it would seem). One of these errors I have compensated for
(in C) is the use of = as a comparason operator when == was meant. So I use a
#define EQ = to allow me to use a completely different symbol, EQ, to avoid
this common error. The foo1 vs. foo(1) problem is similar. It is very easy to
enter foo1 when you meant foo(1) and vice versa.

The names PPB1, etc. have a slightly different problem of ease of
understanding their purpose. If the code is well documented this problem is
reduced. But if the use of a variable is not well documented, names such as
this tell little about the function of the variable. The quintissential bad
example is that of many fortran programs which use variable names like A, B
and C. If they are not well commented (and even if they are to a lesser
degree) these names make the code very hard to read for anyone but the
programmer.

A good way to measure how easy your code is to understand is to leave it
alone for a couple of weeks and come back to it. See if you can easily figure
it out without trying to remember what you did. Your code should tell you
everything you need to know to understand it.

Just a few ideas from my college days with Prof. Kahn.

Rick Collins



Mon, 21 Aug 2000 03:00:00 GMT  
 Array Access and Naming



:
: > Rick:
: > : I was taught in a software engineering class that identifiers should
be
: > : clearly distinct. If one holds to that rule, no names such as foo1
and :
: > foo(1) should be used in the same program. So even if they are legally
: > distinct, they    ..snip..
:
: > rk:
: >
: > i don't see anything that bad about foo1 and foo(1) or other slight
: > differences in names.  like a recent real humanoid coded design had
PPB1
: > PPB2 PPB3 PPC1 etc., where these were partial products with the letter
: > representing the level and the number the position across.
: >
: > now, i would say, that 'foo1' and 'fool' as identifiers would be a
crime
: > against humanity.
: >
: > just a thought,
:
: Names such as your example of partial products are used all the time. But
the
: distinction between foo1 and foo(1) is rather subtle and easy to confuse.
In
: my personal experience I make this type of error very often (some of us
are
: worse than others, it would seem). One of these errors I have compensated
for
: (in C) is the use of = as a comparason operator when == was meant. So I
use a
: #define EQ = to allow me to use a completely different symbol, EQ, to
avoid
: this common error. The foo1 vs. foo(1) problem is similar. It is very
easy to
: enter foo1 when you meant foo(1) and vice versa.

actually, if i remember my c, the ability to put assignment conditions in
with relational operations is what is the cause of the problem.  some
languages simply don't allow that.  for example, in pascal, you have the
assignment ':=' and the relation '='; mix them up and the compiler yells at
you.  don't want to start a pascal <--> c war, having enough fun right now.
 but that is an error-prone situation.  my favorite, which i learned the
hardway, back on the days of the decwriter terminals, was using a '1' as an
index instead of 'i' for the for loop.  and with the lousy printer on the
terminal, you can stare at it for a looooong time.  of course, i still use
the 'i' as my for loop variable. never learned ;)

i do agree that foo(1) and foo1 is not that great of an idea and it was a
bit of subtle humor; if you use these names you are a fool.  not much
difference between these variables, even on a crt.  don't know if you were
in on the beginning of the thread but 'style' was machine-generated vhdl
that caused my synthesizer to go belly up.  and i did send off a note to
the company that produced this code, asked them to change the style.  we'll
see what happens.

: The names PPB1, etc. have a slightly different problem of ease of
: understanding their purpose. If the code is well documented this problem
is
: reduced. But if the use of a variable is not well documented, names such
as
: this tell little about the function of the variable. The quintissential
bad
: example is that of many Fortran programs which use variable names like A,
B
: and C. If they are not well commented (and even if they are to a lesser
: degree) these names make the code very hard to read for anyone but the
: programmer.

making an adder tree, it's sort of hard to come up with great names.  i
think, perhaps, your s/w engineering class was a bit overly restrictive.

: A good way to measure how easy your code is to understand is to leave it
: alone for a couple of weeks and come back to it. See if you can easily
figure
: it out without trying to remember what you did. Your code should tell you
: everything you need to know to understand it.

don't know if any variable names would help for this case.  and the 'code'
really isn't that understandable by reading it in any case, as it's a model
for the computations that i want to perform.  perhaps not great code.  but
the first version was in a schematic.  and then they changed the equations
on me, again.  so i did it in vhdl as it's less typing for changes and the
synthesizer gets to do the work.  and, while i lose some control, the first
few go-rounds gave me confidence that i could get the performance out of
the system (high-speed dsp) without doing all of the hand optimizations on
a schematic (labor intensive).

in this particular case, you need the magic piece of paper with the doc
that shows all of the computations making up the tree, the bits shifts,
etc.  then it's *easy* to verify that the code is mathematically correct.
the PPxy tells you where to go to find the note on that arithmetic
operation.  just can't lose that piece of paper or i've had it ;)

: Just a few ideas from my college days with Prof. Kahn.

wasn't he in the star trek movie? ;)

--------------------------------------------------------------
rk

"there's nothing like real data to{*filter*}up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------



Mon, 21 Aug 2000 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. how to access arrays with variable for array names and index

2. access to array if name of array is variable

3. [array names -inorder name]

4. array name ARRAY regexp

5. HOWTO: reference elements of an array if array name is in a variable

6. Access Array Elements by Arrays Reference

7. retaining a accessing file name

8. Accessing file name

9. Access to Script Name Within Awk Script

10. Access a file when I only know its name

11. PPVW1 access to named components

12. How do I programmatically access User name on PalmPilot

 

 
Powered by phpBB® Forum Software