Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next
KJ
Guest
Sat May 01, 2010 2:30 am
On Apr 30, 6:56 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
Quote:
On Fri, 30 Apr 2010 14:06:19 -0700 (PDT), rickman <gnu...@gmail.com
In fact, it is only a warning when you have two drivers of an
std_logic signal. I would like to make that an error by using
std_ulogic, but I'm not sure how that works with the other types. I
need to investigate that sometime.
snip
I suspect there may be some tools issues in the less-well-trodden path
of std_ulogic. And I have a nagging suspicion that numeric_std is
compatible with std_logic and may be harder to use with its unresolved
cousin. (But I hope not)
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. The only downside is
some extra type conversions to convert between the vectors where you
have to for some reason have std_logic_vector. The upside of course
is that the compiler immediately flags when you have multiple drivers
on a net, you don't have to sim/debug to find that out.
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
Kevin Jennings
Brian Drummond
Guest
Sat May 01, 2010 11:35 am
On Fri, 30 Apr 2010 17:52:10 -0700 (PDT), KJ <kkjennings_at_sbcglobal.net>
wrote:
Quote:
On Apr 30, 6:56 pm, Brian Drummond <brian_drumm...@btconnect.com
wrote:
snip
I suspect there may be some tools issues in the less-well-trodden path
of std_ulogic. And I have a nagging suspicion that numeric_std is
compatible with std_logic and may be harder to use with its unresolved
cousin. (But I hope not)
I've been using std_ulogic/std_ulogic_vector for a while...no issues
with Quartus or Synplify on the synthesis front.
Good to know. Seen any extra cruft getting to/from numeric_std?
Quote:
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
);
Port map conversions (not this one) are one area where I have seen (and
reported) problems with Xilinx ISIM. Not show-stoppers, I just have to
put the conversions elsewhere and wait patiently for Xilinx to fix it.
But it's my experience that tools issues are a big cause of "drag" in
learning to improve my use of VHDL.
- Brian
KJ
Guest
Sat May 01, 2010 4:44 pm
On May 1, 6:35 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
Quote:
On Fri, 30 Apr 2010 17:52:10 -0700 (PDT), KJ <kkjenni...@sbcglobal.net
I've been using std_ulogic/std_ulogic_vector for a while...no issues
with Quartus or Synplify on the synthesis front.
Good to know. Seen any extra cruft getting to/from numeric_std?
No.
KJ
Paul Uiterlinden
Guest
Tue May 04, 2010 10:22 am
Alan Fitch wrote:
Quote:
On 28/04/2010 11:56, Brian Drummond wrote:
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.
Indeed: highly recommended.
Quote:
Now if only the tools supported ...
Again: indeed. I asked Mentor Graphics when to expect full support for VHDL
2008 in ModelSim/QuestaSim. This was their answer:
Quote:
There isn't a set date/revision for full support for VHDL 2008
at this point. Some of the reasons are due ambiguity in the
spec and and the resulting work between customers and the
standards committee, and the priority/usefulness/convenience of
the still to-do features. I see some are not scheduled until
6.7 towards the end of the year and no doubt some will come
later than that.
Seems it is going to take a while....
I sent in my wish list, highest priority first:
Quote:
- generic types
- generic lists in packages
- generic lists in subprograms
- generic subprograms
- local packages
- context declarations
- unconstrained element types
- signal expressions in port maps
- all signals in sensitivity list
- std_logic_1164: std_logic_vector is a subtype of std_ulogic_vector
- if and case generate
- condition operator ("??")
- matching relational operators ("?=", "?/=", "?<", ...)
- matching case statements ("case?")
The matching operators are low in the list, as I'm mainly interested in
improvements in the area of behavioral VHDL for verification
(testbenches/testcases/BFMs).
--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
rickman
Guest
Sat May 08, 2010 10:40 am
On Apr 30, 8:52 pm, KJ <kkjenni...@sbcglobal.net> wrote:
Quote:
On Apr 30, 6:56 pm, Brian Drummond <brian_drumm...@btconnect.com
wrote:
On Fri, 30 Apr 2010 14:06:19 -0700 (PDT), rickman <gnu...@gmail.com
In fact, it is only a warning when you have two drivers of an
std_logic signal. I would like to make that an error by using
std_ulogic, but I'm not sure how that works with the other types. I
need to investigate that sometime.
snip
I suspect there may be some tools issues in the less-well-trodden path
of std_ulogic. And I have a nagging suspicion that numeric_std is
compatible with std_logic and may be harder to use with its unresolved
cousin. (But I hope not)
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.
My concern is compatibility with numeric_std types. I almost never
use std_logic_vector, if for no other reason, the name is soooooo long
to type. I much prefer signed/unsigned types. I guess the real issue
is that if I am using signed/unsigned, I am using slv, not sulv... end
of story, right? Would I need to make my own library to use ulogic
based signed/unsigned types?
Quote:
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.
Rick
KJ
Guest
Sat May 08, 2010 6:01 pm
On May 8, 3:40 am, rickman <gnu...@gmail.com> wrote:
Quote:
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 <>) of std_logic;
type unsigned is array (NATURAL range <>) of std_logic;
type std_logic_vector is array ( NATURAL RANGE <>) 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.
Quote:
Would I need to make my own library to use ulogic
based signed/unsigned types?
No.
Quote:
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
Guest
Sun May 09, 2010 4:56 am
"rickman" <gnuarm_at_gmail.com> wrote in message
news:34aaac95-f886-481d-a4bb-a6b9c63b336f_at_r11g2000yqa.googlegroups.com...
Quote:
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
Guest
Sun May 09, 2010 6:26 am
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
Guest
Mon May 10, 2010 1:09 am
On May 8, 11:26 pm, rickman <gnu...@gmail.com> wrote:
Quote:
Everything snipped...
You're welcome
Quote:
That is why I am going to take a good look at Verilog.
Then go take a look
Quote:
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
Quote:
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
Quote:
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.
Quote:
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?
Quote:
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.
Quote:
So what is
it?
A type conversion
Quote:
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
Guest
Mon May 10, 2010 7:46 pm
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
Guest
Tue May 11, 2010 8:23 pm
On May 8, 8:26 pm, rickman <gnu...@gmail.com> wrote:
Quote:
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
Guest
Wed May 12, 2010 12:07 am
On May 11, 12:23 pm, Andy Peters <goo...@latke.net> wrote:
Quote:
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
Guest
Wed May 12, 2010 3:45 am
"rickman" <gnuarm_at_gmail.com> wrote in message
news:f7fe2df7-3398-4f24-8146-71192784abf7_at_t17g2000vbk.googlegroups.com...
Quote:
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
Guest
Wed May 12, 2010 5:38 am
"rickman" <gnuarm_at_gmail.com> wrote in message
news:95699341-d174-4ce0-89de-c169c903d86e_at_d39g2000yqa.googlegroups.com...
On May 11, 10:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:
Quote:
"rickman" <gnu...@gmail.com> wrote in message
news:f7fe2df7-3398-4f24-8146-71192784abf7_at_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
Guest
Wed May 12, 2010 7:20 am
On May 11, 10:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:
Quote:
"rickman" <gnu...@gmail.com> wrote in message
news:f7fe2df7-3398-4f24-8146-71192784abf7_at_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
Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next
