I'd rather switch than fight!

[KJ]

On May 8, 3:40 am, rickman <gnu...@gmail.com> wrote:

Again, if you get a chance to investigate, I would be interested to hear
how you get on.

I've been using std_ulogic/std_ulogic_vector for a while...no issues
with Quartus or Synplify on the synthesis front.  

I guess the real issue
is that if I am using signed/unsigned, I am using slv, not sulv... end
of story, right?

No, start of story...but it's the story of strong typing that you
object to that started this thread so I'm guessing you won't like the
story, but here it is anyway.

The definition of the types 'signed', 'unsigned', 'std_logic_vector'
and 'std_ulogic_vector' are...

type signed is array (NATURAL range <&gt of std_logic;
type unsigned is array (NATURAL range <&gt of std_logic;
type std_logic_vector is array ( NATURAL RANGE <&gt of std_logic;
type std_ulogic_vector is array ( NATURAL RANGE <> ) of std_ulogic;

As you can see, they all have the same definition...but that doesn't
make them the same from the perspective of the language. They are
different types, none of them are subtypes of anything that is more
general.

If you have a signal or variable of any of the above types, and you
want to assign it to something of any of the other types, you will
need to do a type conversion because they are different *types* not
just different *subtypes*.

Now let's take a look at the definition of std_logic for a moment. It
is...
SUBTYPE std_logic IS resolved std_ulogic;

Since std_logic is defined as a *subtype* of the more general
std_ulogic type then you can freely assign two signals/variables
without the type conversion.

Note though that while std_logic is a subtype of std_ulogic, the
previously mentioned definition of std_ulogic_vector is NOT a subtype
of std_logic_vector. That is why std_logic and std_ulogic can be
freely assigned without type conversions, but std_logic_vector and
std_ulogic_vector can not.

I don't know why the vector versions were defined this way, and maybe
whoever decided this wishes they had done it differently, but in any
case it is the way it is...but before completely throwing in the towel
on the language itself, also recognize that the definitions of those
types are in packages that are outside of the language definition
itself. If you want to create your own types and subtypes without
this limitation, you can do so.

 Would I need to make my own library to use ulogic
based signed/unsigned types?

No.

The main place the mixing of std_logic_vector and std_ulogic_vector
occurs is instantiating some outside widget that uses std_logic_vector
on the interface.  Once I learned that type conversions can be put
into the port map and you didn't need to create std_ulogic 'wrappers',
or use intermediate signals to connect the vectors, it all came
together rather nicely.

Example:

Inst_Some_Widget : entity work.widget
port map(
   Gazinta_slv => std_logic_vector(Gazinta_sulv),
   std_logic_vector(Gazouta_slv) => Gazouta_sulv
);

std_logic and std_ulogic can be freely assigned without any type
conversions

I know I have run into trouble with this in the past.  In fact, I
thought there were some limitations in the standard, not just tool
limitations.  Rather than learn to work around the limitations, I have
always used "wrapper" signals for the conversion.

I've never had any problems with this approach. Tool limitations
though are not only a function of which tool you are using but it also
changes over time. Perhaps if you can find and dust off your example
where you thought this was a limitation of either the tool, the
standard or both you might find that it was something different. In
my case, the fact that you can put a type conversion on the left side
of the port map was my "learn something new every day" moment several
years back...and the end of any need for wrappers for conversions on
entity outputs.

Kevin Jennings

 

[Pete Fraser]

"rickman" <gnuarm@gmail.com> wrote in message
news:34aaac95-f886-481d-a4bb-a6b9c63b336f@r11g2000yqa.googlegroups.com...

When you convert slv to unsigned or unsigned using unsigned(), this is
not really a conversion is it? It is not the same as using
to_integer() to convert signed to integer. 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.
So it would seem this is not a conversion by function. So what is
it?

If you're not doing arithemetic on it, nobody cares, and slv is fine.
If you're doing arithmetic (adding, subtracting, multiplying,
comparing to integer, etc) it tells the synthesizer and / or simulator
whether you consider the N bits to represent an unsigned number
(0 to 2^N -1) or a two's complement signed number (-(2^(N-1))
to 2^(N-1) -1).

Pete

 

[rickman]

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!

When you convert slv to unsigned or unsigned using unsigned(), this is
not really a conversion is it? It is not the same as using
to_integer() to convert signed to integer. 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.
So it would seem this is not a conversion by function. So what is
it?

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.

Rick

 

[KJ]

On May 8, 11:26 pm, rickman <gnu...@gmail.com> wrote:

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]

On May 8, 8:26 pm, rickman <gnu...@gmail.com> wrote:

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]

On May 11, 12:23 pm, Andy Peters <goo...@latke.net> wrote:

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

 

[Robert Miles]

"rickman" <gnuarm@gmail.com> wrote in message
news:f7fe2df7-3398-4f24-8146-71192784abf7@t17g2000vbk.googlegroups.com...

I think I have about had it with VHDL. I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times. I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has. But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement. My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL. Then I can make a fully
informed decision about which I will continue to use. I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

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.

Robert Miles
a Verilog user, retired early due to health reasons
previously a LASAR 6 user and a Logic 5 user

 

[Robert Miles]

"rickman" <gnuarm@gmail.com> wrote in message
news:95699341-d174-4ce0-89de-c169c903d86e@d39g2000yqa.googlegroups.com...
On May 11, 10:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:

"rickman" <gnu...@gmail.com> wrote in message

news:f7fe2df7-3398-4f24-8146-71192784abf7@t17g2000vbk.googlegroups.com...



I think I have about had it with VHDL. I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times. I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has. But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement. My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL. Then I can make a fully
informed decision about which I will continue to use. I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

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

---
Looks like you've had better luck than I did at finding new jobs
without moving to another state to be near the job location. But
then my last job ended back in 2002, so things could easily have
changed since then.

Robert Miles

 

[rickman]

On May 11, 10:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:

"rickman" <gnu...@gmail.com> wrote in message

news:f7fe2df7-3398-4f24-8146-71192784abf7@t17g2000vbk.googlegroups.com...



I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.  My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

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]

On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote:
I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.

On May 12, 12:20 am, rickman <gnu...@gmail.com> wrote:
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]

On May 12, 7:59 am, KJ <kkjenni...@sbcglobal.net> wrote:

On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote:
I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.
On May 12, 12:20 am, rickman <gnu...@gmail.com> wrote:
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.

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]

On Apr 15, 4:48 pm, Patrick Maupin <pmau...@gmail.com> wrote:

On Apr 15, 4:31 pm, Muzaffer Kal <k...@dspia.com> wrote:



On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin

pmau...@gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown <da...@westcontrol.removethisbit.com
wrote:

Another famous contest involved a C and Ada comparison.  It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.

Well, this isn't at all the same then.  The Verilog teams got working
designs, and the VHDL teams didn't.

There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was  an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.

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"

 

[Alan Fitch]

To: comp.lang.vhdl,comp.arch.
In-Reply-To: <i2vft5pq8j21d4olkjbbn8bqnaopdtreu4@4ax.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Ftedna68W9yfgEXWnZ2dnUVZ8n6dnZ2d@brightview.co.uk>
Lines: 57
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-krTvZPYnXrjRCDQ/9mxrUbAO1Nho6pPI1R7zpgLqbTlS3MP5Ii1XVFZZtzT9lNJAqr50OoUdZTIU0Dy!KYqBE3uUf0qmqgBRpCSqdDjlJtDNFIcjaBI9ertX/eUr0t/CXPjZcymhBppWA6Fh6uVkhhzjmpKO!YvjcTHDMTUg8yVSac9W6EaMpQA==
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Path: news.mccarragher.com!news.cambrium.nl!textnews.cambrium.nl!feeder2.cambriumusenet.nl!feed.tweaknews.nl!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
Xref: 127.0.0.1 comp.lang.vhdl:8696 comp.arch.fpga:21879 comp.lang.verilog:12622

On 28/04/2010 11:56, Brian Drummond wrote:

On Tue, 27 Apr 2010 15:56:57 -0700 (PDT), rickman<gnuarm@gmail.com> wrote:

On Apr 27, 6:05 am, Brian Drummond<brian_drumm...@btconnect.com
wrote:

snip

I think you are referring to the ?: conditional operator inherited from C?

I just use VHDL's conditional signal assignments for that purpose. As it's
purely combinational, I have never found the need for an equivalent that I can
use inside a process.

Hi Brian,
just a little note - conditional signal assignment is allowed as a
sequential statement in VHDL 2008

<snip>

If VHDL is to adopt a conditional operator I hope it can do better than that!
Something less surprising, and generalisable to other discrete types or at least
other enums.

And VHDL 2008 provides various matching operators that allow std_logic,
bit and so on to be interpreted as Boolean - see
http://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/

If you're interested in VHDL 2008, I recommend the book "VHDL 2008 -
Just the New Stuff" by Peter Ashenden and Jim Lewis.

Now if only the tools supported ...


regards
Alan

<snip>

--
Alan Fitch
Senior Consultant

Doulos u Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.

---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24