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

 

[KJ]

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'.

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

Plus you could have yet other questions if you apply some mental numeric
interpretation to the number (i.e. x"FF" being '255'...or should it be '-1'?
What happens with the sign bit?

If you use numeric_std's 'resize' function instead you will have to
explicitly tell it whether it should be treated as an unsigned number or a
signed number. If it is signed, and the number is negative then the sign
bit will get padded on to the left, if the number is positive, or if you
said to treat the vector as an unsigned number then 0 will be padded on to
the left. At first the extra typing will seem annoying, but it actually is
worth the little bit of extra effort.

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.

"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".

Maybe it doesn't cover std_logic_arith...which is just as well, numeric_std
is the preferred way, std_logic_arith has some issues if you use it.

KJ

 

[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

 

[M. Norton]

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

 

[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]

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]

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

 

[Andy]

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

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]

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]

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 ;-)