On Fri, 30 Apr 2010 14:06:19 -0700 (PDT), rickman <gnuarm@gmail.com> wrote:>On Apr 29, 5:15�pm, Brian Drummond <brian_drumm...@btconnect.com> >wrote:>> >Not for stepping, although I sometimes do that. �It is so I can put up >> >each result in the simulator... >> >> >DCO <= DCO + (Integrated / INTG_GAIN) + (ErrorReg * PROP_GAIN); >> >> >This is overflowing an intermediate result. �How do you debug?>> for example, (ErrorReg * PROP_GAIN) might have its own intermediate signal - >> (in my code it almost certainly would - within the main process - so I can >> control its pipelining but that's another story * ) - I could assert the output >> sign matches the input sign (knowing, or asserting, PROP_GAIN is positive). > >Pipelining is not possible. This is a PLL and adding register delays >changes the nature of the equation. Yes, you can assert things in >simulation, but what do you do in the chip?I understand about pipelining in your case; you're right it wouldn't work (introducing additional poles).But you can still use intermediate (combinatorial) signals. And yes you can run many more cycles on the chip - as well as find unforeseen circumstances - that you can't in sim. In places (which means I am inconsistent about it ) I have adopted "hardware asserts" using sticky bits, of the form process(clk) begin if rising_edge(clk) then shouldnt_happen <= (the expression you would assert); if clear then shouldnt_happen_stky <= '0'; else shouldnt_happen_stky <= shouldnt_happen_stky or shouldnt_happen; end if; end if; end process; I collect all the sticky bits into a health monitor register which I read (and then clear) at leisure. Hardware cost is completely trivial unless you're using a CPLD. If any of them trigger, they show which part of the design to focus on, and make ideal trigger signals for Chipscope.> I had to debug a problem >in the board when the simulation worked perfectly. In fact, I am very >happy with the PLL, it locks in fast and holds the lock tightly. The >problem ended up being a configuration (real time, not compile) >mistake. But it took some real debugging of the PLL to figure that >out.Good work. (nice story of real world snipped...)>> >foo <= ralph + (('1' = Mode) ? A : B); >> >> >compared to >> >> >with Mode select >> > �foo <= ralph + A when '1', >> > � � � � ralph + B when '0', >> > � � � � (others => '-') when others; >> >> I think a closer translation would be >> >> foo <= ralph + A when Mode = '1' else ralph + B; >> >> and I don't get the objection to that. > >Yeah, but in simulation I always use the others to catch "illegal" >states in controls. In your code a value of 'u' in Mode results in >foo <= ralph + B and the circuit continues with no problem.Agreed, but my point was ... the ?: operator does that too! I didn't say it was a better translation, just more accurate.> I want to >propagate crap with crap. Typically operators do that with std_logic >while your simpler logic doesn't.So this is a case where the additional verbosity comes, not from the language missing a useful operator, but from your wish (which I agree with) to do a better job.>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.That's an example of people (myself included) not having pushed the language capabilities far enough in raising quality or productivity. We just use std_logic because the tools (templates, Xilinx examples, etc) just assume it's the default we want to use. But really, outside of 3-state buses, std_ulogic[_vector] should be the default. 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.>> That is what I mean by "break". I suspect we'd have to try writing the BNF for a >> grammar that would handle its use and overloading to settle the question. > >If it is a part of VHDL 2008, isn't it done? I can't imagine they >would have added it to the standard if vendors didn't know how to make >it work yet.?: in the C (Verilog?) form is not in VHDL2008, as far as I know. But there are other (more VHDL-friendly) improvements in the same area.>> >Ok, now you are going off to unsubstantiated claims. �I doubt anyone >> >would agree to go with a feature that required rewriting half the >> >compiler. >> >> Maybe so, my compiler writing days are long ago. But something about adding >> *one* trinary operator sets off alarm bells. > >I guess we can ask the vendors about it. Does anyone have VHDL in >their tools yet? Mine don't seem to include it, but that may be a >switch I need to throw.Some support bits of VHDL2008, but support is still pretty poor. - Brian.
Re: I'd rather switch than fight!
Started by ●April 30, 2010
Reply by ●April 30, 20102010-04-30
On Apr 30, 6:56=A0pm, 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. =A0I would like to make that an error by using > >std_ulogic, but I'm not sure how that works with the other types. =A0I > >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 =3D> std_logic_vector(Gazinta_sulv), std_logic_vector(Gazouta_slv) =3D> Gazouta_sulv ); std_logic and std_ulogic can be freely assigned without any type conversions Kevin Jennings
Reply by ●May 8, 20102010-05-08
On Apr 30, 8:52=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:> On Apr 30, 6:56=A0pm, 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. =A0I would like to make that an error by using > > >std_ulogic, but I'm not sure how that works with the other types. =A0I > > >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 hea=r> > 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. =A0My 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. =A0Once 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( > =A0 =A0Gazinta_slv =3D> std_logic_vector(Gazinta_sulv), > =A0 =A0std_logic_vector(Gazouta_slv) =3D> Gazouta_sulv > ); > > std_logic and std_ulogic can be freely assigned without any type > conversionsI 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
Reply by ●May 8, 20102010-05-08
On May 8, 3:40=A0am, rickman <gnu...@gmail.com> wrote:> > > > Again, if you get a chance to investigate, I would be interested to h=ear> > > 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. =A0 > > 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.> =A0Would 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. =A0Once 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( > > =A0 =A0Gazinta_slv =3D> std_logic_vector(Gazinta_sulv), > > =A0 =A0std_logic_vector(Gazouta_slv) =3D> 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. =A0In fact, I > thought there were some limitations in the standard, not just tool > limitations. =A0Rather 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
Reply by ●May 9, 20102010-05-09
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
Reply by ●May 9, 20102010-05-09
"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
Reply by ●May 9, 20102010-05-09
On May 8, 11:26=A0pm, rickman <gnu...@gmail.com> wrote:> Everything snipped... >You're welcome> That is why I am going to take a good look at Verilog. =A0Then 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> =A0It is not the same as using > to_integer() to convert signed to integer. =A0Perhaps 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. =A0But there are no functions to convert slv and these types.slv_sig <=3D std_logic_vector(uns_sig); un_sig1 <=3D unsigned(slv_sig); What's the trouble?> So it would seem this is not a conversion by function. =A0It 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. =A0Then when I need to figure out something new I > have to go back to basics. =A0It just gets so time consuming. =A0I want t=o> focus on the work, not the method. >Good luck with Verilog KJ
Reply by ●May 10, 20102010-05-10
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
Reply by ●May 11, 20102010-05-11
On May 8, 8:26=A0pm, rickman <gnu...@gmail.com> wrote:> Everything snipped... > > That is why I am going to take a good look at Verilog. =A0I'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
Reply by ●May 11, 20102010-05-11
On May 11, 12:23=A0pm, 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
