I'd rather switch than fight!
in [FPGA]
|
From: Brian Drummond on 1 May 2010 06:35 On Fri, 30 Apr 2010 17:52:10 -0700 (PDT), KJ <kkjennings(a)sbcglobal.net> wrote: >On Apr 30, 6:56�pm, Brian Drummond <brian_drumm...(a)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? >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
From: KJ on 1 May 2010 09:44 On May 1, 6:35 am, Brian Drummond <brian_drumm...(a)btconnect.com> wrote: > On Fri, 30 Apr 2010 17:52:10 -0700 (PDT), KJ <kkjenni...(a)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
From: Paul Uiterlinden on 4 May 2010 05:22 Alan Fitch wrote: > 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. > 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: > 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: > - 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.
From: rickman on 8 May 2010 03:40 On Apr 30, 8:52 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Apr 30, 6:56 pm, Brian Drummond <brian_drumm...(a)btconnect.com> > wrote: > > > On Fri, 30 Apr 2010 14:06:19 -0700 (PDT), rickman <gnu...(a)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? > 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
From: KJ on 8 May 2010 11:01
On May 8, 3:40 am, rickman <gnu...(a)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 <>) 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. > 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 |