I'd rather switch than fight!
in [FPGA]
|
From: Brian Drummond on 29 Apr 2010 17:15 On Thu, 29 Apr 2010 05:42:47 -0700 (PDT), rickman <gnuarm(a)gmail.com> wrote: >On Apr 29, 7:12�am, Brian Drummond <brian_drumm...(a)btconnect.com> >wrote: >> On Wed, 28 Apr 2010 16:55:13 -0700 (PDT), rickman <gnu...(a)gmail.com> wrote: >> >That is one long reply... >> >> I'm unclear why you say a separate concurrent statement facilitates debugging; >> are you stepping through code in the simulator? (I haven't done that in over ten >> years) > >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? Sometimes, not very well... But for this situation I would assert properties of the expression, or better, of each intermediate term. So 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). (* I've had summer interns exploring register retiming tools; they didn't beat my hand-timed results. Which may say something about the tools, or not) Then either I get a pinpoint report of the problem, or the testbench is inadequate... >> A better solution all round would be to replace it with an if-expression (in >> which "if", "then", "else" are explicit, (don't rely on the reader knowing C) >> and a case-expression for the (n>2) enumeration and integer subrange cases. >> >> But that seems to have fallen out of favour since Algol-W. > >I'm not sure what you are referring to. An if is a sequential control >flow structure. Maybe in some languages, but it doesn't have to be. I used to be able to write code of the form ---- a := if <expr1> then <expr2> [ else <expr3>]; ---- (the assignment being skipped if expr1 was false and there was no else clause) and similarly, case expressions with semantics like case statements. And I am delighted to hear it's on the way back in a mainstream language and one of the main influences on VHDL. >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. I doubt there's a synthesis tool alive that would duplicate the adder! But if there were, I would mux A or B onto an intermediate signal . >I don't get the "break" part. I think that is a subjective opinion. >> >I don't get why you think the conditional operator would be a wart. >> >It is just an operator. �It is a trinary operator rather than uniary >> >or binary, >> For a start, what would the syntax for overloading it look like? > >Why would it be any different from what we currently use??? What does >it look like? What we currently use and overload are unary and binary operators. In neither of these do you have to split the operator symbol in half and insert an argument in the middle. There is no syntax for expressing that, in VHDL. 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. I confess I haven't looked to see how C++ overloads ?: That might be quite illuminating... >> And definitely not worth rewriting half the parser for one operator on one >> specific enumerated type. > >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. - Brian
From: Brian Drummond on 29 Apr 2010 17:42 On Wed, 28 Apr 2010 12:33:21 +0100, Alan Fitch <alan.fitch(a)spamtrap.com> wrote: >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/ Heh... It says (and I hope quoting this comes under the heading of fair use) ---------------------------------------------------------------------------------------------- How many times have you wanted to write something like this: if A and B then where A and B are STD_LOGIC? ... You have to write this instead: if A = '1' and B = '1' then VHDL-2008 introduces a new operator, ??....So you can now write this: if ?? A and B then ---------------------------------------------------------------------------------------------- I confess, on the odd occasion, to writing if A and B then anyway. Is it cheating to (ab)use overload resolution by return type, overloading "and" for std_logic args to return a boolean? >If you're interested in VHDL 2008, I recommend the book "VHDL 2008 - >Just the New Stuff" by Peter Ashenden and Jim Lewis. I'll definitely follow this up... - Brian
From: Andy on 30 Apr 2010 13:38 I have used two home-grown functions for years for this: is1() and is0(). Both handle metavalues, etc. if is1(A and B) then No silly syntax or language "improvements" required. Andy
From: KJ on 30 Apr 2010 20:38 On Apr 29, 5:42 pm, Brian Drummond <brian_drumm...(a)btconnect.com> wrote: > On Wed, 28 Apr 2010 12:33:21 +0100, Alan Fitch <alan.fi...(a)spamtrap.com> wrote: > How many times have you wanted to write something like this: > if A and B then > where A and B are STD_LOGIC? ... You have to write this instead: > if A = '1' and B = '1' then > You don't HAVE to write it that way...it can also be written (just as clearly in my opinion, but a few more taps on the keyboard then VHDL-2008) if (A and B) = '1' then KJ
From: KJ on 30 Apr 2010 20:52
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. 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 |