I'd rather switch than fight!

[KJ]

Everything snipped...

You're welcome

That is why I am going to take a good look at Verilog.  

Then go take a look

I've been
using VHDL for some 12 years and I still don't feel like I completely
understand even basic things like how signed/unsigned relate to
std_ulogic and how closely related types... well, relate!

It was in what the snipped part that you pitched out so ungloriously
at the start...maybe you shouldn't be so hasty

When you convert slv to unsigned or unsigned using unsigned(), this is
not really a conversion is it?

Yes, it converts a std_logic_vector to an unsigned type...if it makes
you feel better think of it as applying a particular numeric
interpretation to a collection of bits so that you can add them,
subtract them

 It is not the same as using
to_integer() to convert signed to integer.  

Perhaps you should explain why you think that 'to_integer' is somehow
different than converting between std_logic_vectors and (un)signed?
Hint: They're fundamentally not...they are both converting between
things of different types.

In the std_numeric library
they include conversion functions between integer and signed/
unsigned.  But there are no functions to convert slv and these types.

slv_sig <= std_logic_vector(uns_sig);
un_sig1 <= unsigned(slv_sig);

What's the trouble?

So it would seem this is not a conversion by function.  

It would seem you missed how to convert between the types...not that
they are not type conversion functions.

So what is
it?

A type conversion

At one time I thought I understood all this, but it is so far removed
from getting work done that I typically adopt standard practices and
forget the details.  Then when I need to figure out something new I
have to go back to basics.  It just gets so time consuming.  I want to
focus on the work, not the method.

Good luck with Verilog

KJ

 

[Andy]

I thought there was a change in the latest version of vhdl that
redefined std_logic_vector as a resolved subtype of
std_ulogic_vector? That would make SLV and SULV as interchangeable as
SL and SUL.

Anyway, VHDL allows for "built-in" conversions (explicitly invoked)
between "closely related" aggregate types. "CR" means that both types
are aggregates of the same element type. These built-in conversions
are invoked by simply using the name of the target type, so to convert
SLV to unsigned, you just need "unsigned(my_slv)".

BTW, I always create a subtype slv as follows:

subtype slv is std_logic_vector;

Now, "slv" is its own (sub)type name which can be used for
declarations, and even a built-in conversion invocation:

my_slv <= slv(my_unsigned);

You could probably do the same thing with an alias, but I figured out
the subtype trick first.

Andy

 

[Andy Peters]

Everything snipped...

That is why I am going to take a good look at Verilog.  I've been
using VHDL for some 12 years and I still don't feel like I completely
understand even basic things like how signed/unsigned relate to
std_ulogic and how closely related types... well, relate!

Well, since Verilog knows nothing about types, there are no
conversions.

But you do a lot of DSP, and proper numeric representation is
obviously important. You'll go absolutely batshit crazy trying to sort
out numeric operations in Verilog. (And don't buy into that line about
how "C and Verilog are highly similar.")

FWIW, I tend to always use VHDL's unsigned() and signed() (as needed)
types in preference to std_logic_vectors when the arrays of bits
represent actual numbers. I also use unsigned() and signed() types on
port lists.

For things like counters, I use ranged naturals, unless of course the
count can be negative.

-a

 

[Patrick Maupin]

But you do a lot of DSP, and proper numeric representation is
obviously important. You'll go absolutely batshit crazy trying to sort
out numeric operations in Verilog. (And don't buy into that line about
how "C and Verilog are highly similar.")

Verilog and DSP is not very difficult. And C is quite similar in some
ways, although it does have nice features like structures that are not
available in (non-System) Verilog. But, if you're happy coding with
C, you can easily code most of your testbench in C with verilog.

Regards,
Pat

 

[rickman]

The last time I searched the general-purpose jobs newsgroup for jobs
available for either, there were about twice as many jobs available for
VHDL as for Verilog.  Looks to me like a good reason to learn both,
and then stay current enough on both to be able to use either, as the
job prefers.

Yes, I guess jobs is important to many, but I work for myself and my
main customer uses Verilog. He hasn't had a problem with me using
VHDL, but every time I express any exasperation with some aspect of
VHDL I am reminded of how Verilog doesn't have that problem. I know
of a few instances of when strong typing found bugs for me before they
turned into lab bug searches... which is one of the main reasons for
using such features. The earlier in the process bugs are found, the
easier they are found and the smaller the impact. Still, there is a
cost and the question is whether the cost is justified...

Rick

 

[KJ]

I know
of a few instances of when strong typing found bugs for me before they
turned into lab bug searches... which is one of the main reasons for
using such features.  The earlier in the process bugs are found, the
easier they are found and the smaller the impact.  

It seems you've already (re)discovered actual examples where type
checking can be useful

Still, there is a
cost and the question is whether the cost is justified...

Depends strongly on the cost of a bug.

KJ

 

[rickman]

It seems you've already (re)discovered actual examples where type
checking can be useful


Depends strongly on the cost of a bug.

Yep! Today we found the hardest bug to date on this project. It was
a configuration error... software setting up the hardware. No amount
of type checking would have helped to find that one. That is my
point. VHDL may help prevent some bugs, but there is a lot more to
minimizing bugs than what can be forced on you by tools. Effective
design is a holistic practice that has to take into account the unique
aspects of each design optimizing the process to match the risk
areas. I actually knew that the interface of my board to the rest of
the system was the high risk part of the design, both in terms of the
system itself and in terms of communicating the details. I failed to
give this risk factor enough attention. I tried taking a shortcut of
putting too much effort into the test bench and not doing bench
testing (not the same as test bench testing) before turning the design
over to the customer for integration.

It should be smooth sailing from here on. So at least I'll have more
time to post here and later look into the advantages of Verilog.

Rick

 

[radarman]

But it's mostly academic and FPGA people who think that VHDL might
have any future at all.  See, for example:

http://www.eetimes.com/news/design/columns/industry_gadfly/showArticl...

Regards,
Pat

Rumors of VHDL's impending death have been around for a while, usually
propagated by companies specializing in Verilog tools looking to sell
products. This article (from 2003) is little different. Seven years
later, and I see that Synopsys is still offering both VHDL and Verilog
compilers with their tools.

I've seen this claim for nearly the entire time I've been working in
the field, and yet I still see VHDL going along quite fine. If
anything, the language has been more stable than Verilog, though I
will give credit for maintaining backwards compatibility. I just don't
see System Verilog being crowned the winner. Perhaps it's just my
industry, but I don't see System Verilog much at all. (plenty of
Verilog, though)

Shoot, if anything; I see tools like Matlab and C-to-RTL tools
eventually taking mind-share away from both VHDL and Verilog. One of
my previous employers did all of their complex algorithmic work in
Matlab, only using VHDL to stitch the final code into a wrapper, or to
connect external RAM. While the performance wasn't as great as a
purely coded implementation, the design time was reduced dramatically.
If that's the extent of your language use, it really matters little
which RTL language you use.

Lastly, while I often see snarky opinions from ASIC guys about FPGA's
high cost per unit, it only takes one bad ASIC spin to pay for a whole
lot of Virtex or Stratix parts. The first time you get your new ASIC
back, and you find a bug, will be when you start to appreciate the
ability reprogram an FPGA in-system, or even remotely. I've even seen
ASIC guys have to stick an FPGA on the board to avoid respinning an
ASIC. Even if the ASIC vendors abandon VHDL entirely, I'm not going to
be all that worried for work.

With gate counts and core frequencies increasing all the time, all the
while $/gate is plummeting, the performance/size advantage is getting
thinner too. I've seen a lot of designs that might have once been done
in ASICs being shipped with FPGA's - not all of them low performance
of high cost, either. I'm not saying ASICs are going anywhere, as
there are definitely applications where the raw speed gain, or low
recurring cost, is vital - but for a lot of designs, FPGA's are a
realistic option.

In short, there is still plenty of room for VHDL, Verilog, Matlab,
etc. I think it's a bit premature to pick a "winner"