Basic question #2

[m]

Researching the use of "ext".

I found this in the list archives:

-- zero extend STD_LOGIC_VECTOR (ARG) to SIZE,
-- SIZE < 0 is same as SIZE = 0
-- returns STD_LOGIC_VECTOR(SIZE-1 downto 0)
function EXT(ARG: STD_LOGIC_VECTOR; SIZE: INTEGER) return
STD_LOGIC_VECTOR;

Not clear on which direction the extension happens. Does it add zeros
on the left or right of ARG?


BTW, picked-up a copy of "The designer's guide to VHDL" as
recommended. It sort of covers "others" (my prior question) in the
more general sense, however it doesn't seem to let you know that you
can use it by itself (i.e.: other => '0') .

"ext" is not covered anywhere. At least I can't find it in the
index. There's a reference to "Zero extension" but nothing in those
pages about "ext".

It does look like a very good book though and I don't mind having
added it to my library. However, the fact that these highly
recommended books don't seem to cover basic operations is of some
concern. Any other books I should be looking at? The Internet is
good, but a good set of reference books is also essential.


Thanks,

-Martin

 

[m]

Thanks for your comments. I am translating some VHDL to Verilog (and
learning VHDL as a side-effect). I have no control over what the
original author decided to use. "ext" is peppered throughout this
code. I understand now why the books might cover it. I also know to
stay away from "std_logic_arith" when I eventually write my own VHDL
code.

Thanks,

-Martin

 

[Brian Drummond]

On Sun, 28 Sep 2008 20:07:39 -0400, "KJ" <kkjennings@sbcglobal.net>
wrote:

"m" <martin.usenet@gmail.com> wrote in message
news:605b3515-30e0-429e-9026-661af118f029@k36g2000pri.googlegroups.com...
Researching the use of "ext".

I found this in the list archives:

-- zero extend STD_LOGIC_VECTOR (ARG) to SIZE,
-- SIZE < 0 is same as SIZE = 0
-- returns STD_LOGIC_VECTOR(SIZE-1 downto 0)
function EXT(ARG: STD_LOGIC_VECTOR; SIZE: INTEGER) return
STD_LOGIC_VECTOR;


The 'ext' function is a part of the std_logic_arith package. This package
was created by Synopsys and is not a standard. The package you should be
using is numeric_std which is an IEEE standard. The function you would use
there is called 'resize'.

Even some design tools slip std_logic_arith in by default.

It is sometimes worth commenting out the "use" clause for the
std_logic_[arith|signed|unsigned] libraries and compiling just to see
what happens.

About half the time the errant lib has been included by default but is
unused. Or there are one or two uses which are easily replaced by
numeric_std.

It may not be important, but to me it's a relatively quick way of
reducing the search space for potential problems later.

If "ext" is the only (or main) use of std_logic_arith, bear in mind
there's no rule that stops you writing your own "ext" function using
numeric_std.resize to do the work...

The few remaining files ... I'm not as religious about getting things
clean as I used to be. If the component has a good testbench I'll go
ahead and do it; otherwise the worst that happens is I uncomment the use
clause and make a comment in the project notes.

Files that include both numeric_std and one or more of
std_logic_[arith|signed|unsigned] are another matter...

BTW, picked-up a copy of "The designer's guide to VHDL" as
recommended. It sort of covers "others" (my prior question) in the
more general sense, however it doesn't seem to let you know that you
can use it by itself (i.e.: other => '0') .


Not by itself because 'others' refers to anything that has not been already
explicitly handled. But it can't no that unless it knows how big the target
of the assignment is. I'm not sure if that's what you meant by 'use it by
itself' or not, just guessing.

To reinforce KJ's point,

A <= (others=> '0');
is not exactly using the others clause by itself; the assignment
statement is built into the language and it can infer the SIZE of the
array to be filled by "others" from the destination.

-- In contrast,
if A = (others=> '0') then -- do something
end if;
-- won't work.

This is because '=' is an operator (just a function) that has two
operands and can be overridden; its definition is not hard-wired into
the language. (Read the source for the "std_logic_1164" package to see a
definition of '=')

So there is no guarantee that the two operands need the same size;
that's down to the function declaration. Therefore, (others=> '0')
really stands alone here, and compilation will fail because there is no
way to define the size of the right hand operand.

-- Here you could say
if A = (A'range => '0') then -- do something
end if;
-- and the 'range attribute supplies the missing information.

Get used to using the 'range attribute (and its cousins, 'high, 'low
etc) and you'll probably never write an off-by-1 loop again.

-- e.g. (inside a process)
for i in A'range loop
A(i) <= '0';
end loop;

It's the most complex way yet of performing your initial assignment!
But consider: the loop adjusts itself to any changes in the size of A.

- Brian

 

[M. Norton]

On Sep 29, 3:47 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

Files that include both numeric_std and one or more of
std_logic_[arith|signed|unsigned] are another matter...

Out of curiosity, is there potential danger with declaring both?

I ask this because I've been doing some code review for another
project. Basically giving a "grade" for the code written, saying it
appears to do what it's supposed to do, following company coding style
guidelines, good practice, etc.

Anyhow, I ran across one engineer declaring both std_logic_unsigned/
arith and numeric_std. I flagged it as "unusual" and talked with
another engineer about it. Apparantly the code builds and simulates
alright, and was considered "legacy" so I believe we're just going to
leave it. Still, it bugs me and if there's some concrete issue I can
say "this is bad because X may happen" I can probably get that
changed.

From what I remember, neither package was necessary for the code so I
imagine that's why there were no conflicts. That's all I can really
forsee as a problem, some of the overloaded operators are going to
overlap.

Best regards,
Mark Norton

 

[Brian Drummond]

On Mon, 29 Sep 2008 10:52:59 -0700 (PDT), "M. Norton"
<remillard@gmail.com> wrote:

On Sep 29, 3:47 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:
Files that include both numeric_std and one or more of
std_logic_[arith|signed|unsigned] are another matter...

Out of curiosity, is there potential danger with declaring both?

I don't think so in terms of the code itself; though I never convinced
myself it was completely safe. I'd be interested in other opinions.

I'd say there's definite potential danger if anyone comes along to
maintain the code or re-use it later...

Anyhow, I ran across one engineer declaring both std_logic_unsigned/
arith and numeric_std. I flagged it as "unusual" and talked with
another engineer about it.

Unfortunately it doesn't seem to be at all unusual.

From what I remember, neither package was necessary for the code so I
imagine that's why there were no conflicts.

That's my experience; if you comment them out and it still compiles,
they were unnecessary, and that's a common explanation for no conflicts.

That's all I can really
forsee as a problem, some of the overloaded operators are going to
overlap.

At least if two operators with the same signature are visible, the
compiler pretends it can't see either of them. So it won't ever make an
arbitrary choice between two operators (e.g. one which sign-extends and
one which doesn't); one choice in simulation and another in synthesis
would be problematic!

Deleting both use clauses indicates that this module does not use
numeric properties of std_logic_vectors. Which may be useful information
to a maintainer. Including numeric_std suggests it probably does; but
such actual use will be indicated by signed or unsigned types; which is
pretty unambiguous. As far as I can see, including std_logic_arith gives
no information whatsoever about the intent of the module.

However, while cleaning a module up may take seconds, in some
environments re-qualifying it afterwards can be time consuming and
expensive. So I wouldn't criticise anyone for leaving legacy code as-is.

- Brian

 

[thutt]

m <martin.usenet@gmail.com> writes:

Researching the use of "ext".

I found this in the list archives:

-- zero extend STD_LOGIC_VECTOR (ARG) to SIZE,
-- SIZE < 0 is same as SIZE = 0
-- returns STD_LOGIC_VECTOR(SIZE-1 downto 0)
function EXT(ARG: STD_LOGIC_VECTOR; SIZE: INTEGER) return
STD_LOGIC_VECTOR;

Not clear on which direction the extension happens. Does it add zeros
on the left or right of ARG?


BTW, picked-up a copy of "The designer's guide to VHDL" as
recommended. It sort of covers "others" (my prior question) in the
more general sense, however it doesn't seem to let you know that you
can use it by itself (i.e.: other => '0') .

"ext" is not covered anywhere. At least I can't find it in the
index. There's a reference to "Zero extension" but nothing in those
pages about "ext".

It does look like a very good book though and I don't mind having
added it to my library. However, the fact that these highly
recommended books don't seem to cover basic operations is of some
concern. Any other books I should be looking at? The Internet is
good, but a good set of reference books is also essential.

I personally find that the available information on VHDL is not nearly
as complete as software programming langauges. I have the Ashenden
book, and I can agree with your complaints.

thutt
--
Hoegaarden!

 

[m]

-- e.g. (inside a process)
for i in A'range loop
    A(i) <= '0';
end loop;

Interesting.

I have to say...coming from ten years of Verilog I am tearing my hair
out trying to figure out why anyone would want to use VHDL. Acually,
no, I know of at least one reason: If you are getting paid by the
hour to code you want VHDL. You'll definitely have more billable
hours. The other side of that coin is that if I am paying someone to
code I want Verilog, as VHDL will cost me more money.

I don't want this to turn into a Verilog vs. VHDL thread. Just take
my comment as a VHDL newbie's statement of frustration and let it go.
In other words, please ignore the last paragraph.


Thanks,

-Martin

 

[M. Norton]

On Sep 29, 10:22 pm, m <martin.use...@gmail.com> wrote:

Interesting.

I have to say...coming from ten years of Verilog I am tearing my hair
out trying to figure out why anyone would want to use VHDL.  Acually,
no, I know of at least one reason:  If you are getting paid by the
hour to code you want VHDL.  You'll definitely have more billable
hours.  The other side of that coin is that if I am paying someone to
code I want Verilog, as VHDL will cost me more money.

I don't want this to turn into a Verilog vs. VHDL thread.  Just take
my comment as a VHDL newbie's statement of frustration and let it go.
In other words, please ignore the last paragraph.

It's kind of funny that *today* I had the exact same sensation, but
while reading a Verilog book. I've used Verilog in the past, and
there are some things I like and some things I don't like. I bought
the Salnitkar (sp?) book on Verilog HDL and have been reading up
proper on the language and I keep thinking "VHDL is so
straightforward, and there are all these odd things in Verilog, why
would anyone want to use it?"

I don't charge any more for VHDL than I would Verilog for what it's
worth. It's all HDL.

I'm just amused.

Best regards,
Mark Norton

 

[M. Norton]

On Sep 29, 5:02 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

However, while cleaning a module up may take seconds, in some
environments re-qualifying it afterwards can be time consuming and
expensive. So I wouldn't criticise anyone for leaving legacy code as-is.

Bingo. That's precisely the situation. I checked with folks and it
simulates and synthesizes the way the design needs so I'm loathe to
touch it at the moment. However, if I get half a chance to rewrite
some of the coding styles, I'm going to mandate numeric_std only (or
at the very least pick one, or the other, and never the twain shall
meet.)

Thanks for the information, I appreciate it.

Best regards,
Mark Norton

 

[m]

It's kind of funny that *today* I had the exact same sensation, but
while reading a Verilog book.

Yeah, I guess it can be that way.

I write a lot of C and C++, so maybe Verilog feels more familiar.
Your brain doesn't have to "context switch" to think of saying things
in a radically different way. I used to do lots of work in Forth. I
abandoned it because of the same reason. For me it is far easier to
try to keep it as similar as possible. Very often I'll switch to
writing embedded code in C while the FPGA tools are compiling. Coming
back to Verilog isn't a problem.

I can see the power and flexibility of VHDL. I've known this for a
long time. Now I am forced to work with it, so my opinion could
change inside of 3.4 weeks.

-Martin

 

[Brian Drummond]

On Mon, 29 Sep 2008 22:50:20 -0700 (PDT), "M. Norton"
<remillard@gmail.com> wrote:

On Sep 29, 5:02 pm, Brian Drummond <brian_drumm...@btconnect.com
wrote:
However, while cleaning a module up may take seconds, in some
environments re-qualifying it afterwards can be time consuming and
expensive. So I wouldn't criticise anyone for leaving legacy code as-is.

Bingo. That's precisely the situation. I checked with folks and it
simulates and synthesizes the way the design needs so I'm loathe to
touch it at the moment.

As long as your job description allows you to pass the buck backwards
because "I didn't touch it, guv, it was like that when I got it" if
something crops up later...

- Brian

 

[Brian Drummond]

On Mon, 29 Sep 2008 22:22:41 -0700 (PDT), m <martin.usenet@gmail.com>
wrote:

-- e.g. (inside a process)
for i in A'range loop
    A(i) <= '0';
end loop;

Interesting.

No: trivial. If that's all you are doing in the loop, it's a bloody
stupid way to do it. But given a more realistic loop, the fact that the
bounds just work saves a lot of grief.

I have to say...coming from ten years of Verilog I am tearing my hair
out trying to figure out why anyone would want to use VHDL. Acually,
no, I know of at least one reason: If you are getting paid by the
hour to code you want VHDL. You'll definitely have more billable
hours.

If coding was the whole of the job, you'd have a good point there.
But it isn't, by a long way (at least, not my job).

I don't want this to turn into a Verilog vs. VHDL thread. Just take
my comment as a VHDL newbie's statement of frustration and let it go.
In other words, please ignore the last paragraph.

It's OK. It's nothing like my frustration in C or C++, where the
underlying principle seems to be, there is no underlying principle,
there only looks like one, except where it has exceptions.

- Brian

 

[Andy]

On Sep 29, 11:07 pm, thutt <thutt...@comcast.net> wrote:

I personally find that the available information on VHDL is not nearly
as complete as software programming langauges.  I have the Ashenden
book, and I can agree with your complaints.

thutt
--
Hoegaarden!

You could say the same about any HDL. One reason: there are not nearly
as many practitioners or written lines of code of HDL as there are of
software programming languages.

Andy

 

[Andy]

On Sep 30, 1:00 am, m <martin.use...@gmail.com> wrote:

I write a lot of C and C++, so maybe Verilog feels more familiar.
Your brain doesn't have to "context switch" to think of saying things
in a radically different way.  I used to do lots of work in Forth.  I
abandoned it because of the same reason.  For me it is far easier to
try to keep it as similar as possible.  Very often I'll switch to
writing embedded code in C while the FPGA tools are compiling.  Coming
back to Verilog isn't a problem.

One of the reasons I like variables in VHDL so much is that they
behave like SW, but also get implemented in HW with that same SW
behavior.

Andy

 

[M. Norton]

On Sep 29, 11:00 pm, m <martin.use...@gmail.com> wrote:

It's kind of funny that *today* I had the exact same sensation, but
while reading a Verilog book.

Yeah, I guess it can be that way.

I write a lot of C and C++, so maybe Verilog feels more familiar.
Your brain doesn't have to "context switch" to think of saying things
in a radically different way.  I used to do lots of work in Forth.  I
abandoned it because of the same reason.  For me it is far easier to
try to keep it as similar as possible.  Very often I'll switch to
writing embedded code in C while the FPGA tools are compiling.  Coming
back to Verilog isn't a problem.

I can see the power and flexibility of VHDL.  I've known this for a
long time.  Now I am forced to work with it, so my opinion could
change inside of 3.4 weeks.

It is definitely one of those sensations based on what you are more
used to. The last serious C I wrote was probably 10 years ago, so I
never quite grok the similarities between Verilog and C. I have a
board design background and learned VHDL first, so Verilog seems
quirky to me (e.g. the whole concept of wires and regs... technically
I know why it's done that way, but it feels like an unnecessary
distinction... in VHDL EVERYTHING is a net and register is behavior
defined by the code, very straightforward).

Definitely take some time to get to know the language, but you will
still probably always have a preference for your first HDL ;-). The
important thing to remember is... that's perfectly okay.

For what it's worth, if you are familiar enough with Emacs, the VHDL
language mode is very helpful in managing some of the tasks that seem
repetitive (cutting and pasting an entity as a component, pasting it
as a instantiation, etc.) That might help ease some of that -- I know
for me that's the most tedious aspect. You can do it with vi as well,
just not quite as automated. You have to be quick and handy with on
the fly keyboard macros. I really really wish someone skilled in both
elisp and vim-script would come up with a translation of VHDL mode.

Good luck!

Best regards,
Mark Norton

P.S.: I also like Forth ;-)