I'd rather switch than fight!
in [FPGA]
|
From: Brian Drummond on 27 Apr 2010 06:05 On Mon, 26 Apr 2010 18:26:25 -0700 (PDT), Patrick Maupin <pmaupin(a)gmail.com> wrote: >On Apr 26, 7:15�pm, Andy <jonesa...(a)comcast.net> wrote: >> Cliff's paper is about avoiding race conditions. However, in vhdl >> "blocking assignements" (to unshared variables) are limited to local >> process/subprogram scope anyway, so you never have problems with race >> conditions with them. That is why it is safe and even beneficial to >> use blocking assignments (to unshared variables) in VHDL clocked >> processes. > >Yes, the two process model probably isn't nearly as useful in VHDL. > >As others have been quick to point out, you don't need a combinatorial >process in verilog either, but then you have to be careful about >blocking vs. non-blocking, not using variables which have blocking >assignments to them from other processes, etc. The two process model >is simply an organizing principle that provides a separation of >concerns and simplifies the rules a bit, making it easier to reason >about the code. Extremely simple code doesn't gain anything from >using this model, but a lot of real-world code does. I have to wonder if *that* is the reason the two-process model refuses to die in VHDL textbooks, tutorials, and example designs worldwide. Perhaps too many educators focus on comparing the languages, showing how the same thing is done *the same way* in both languages. I would prefer to see each language shown off at its best. Then VHDL could be illustrated with the (much less verbose) single process model, functions and procedures to raise the abstraction level and simplify the main process, and proper use of the type system to help rather than frustrate the user. (e.g. recently here, there was an example where someone frustrated himself by using a type with integer semantics when he really wanted a type with modular semantics, so he had to code all the wrap-arounds by hand. Easy pitfall for someone used to C which doesn't have any types with integer semantics.) Likewise best practice in Verilog could be illustrated. (I have no idea what that is; hearsay suggests it would include avoiding races, avoiding problems with signed arithmetic, implicit declarations and so on. But Verilog must have real strengths too) - Brian
From: rickman on 27 Apr 2010 18:56 On Apr 27, 6:05 am, Brian Drummond <brian_drumm...(a)btconnect.com> wrote: > On Mon, 26 Apr 2010 18:26:25 -0700 (PDT), Patrick Maupin > > > > <pmau...(a)gmail.com> wrote: > >On Apr 26, 7:15 pm, Andy <jonesa...(a)comcast.net> wrote: > >> Cliff's paper is about avoiding race conditions. However, in vhdl > >> "blocking assignements" (to unshared variables) are limited to local > >> process/subprogram scope anyway, so you never have problems with race > >> conditions with them. That is why it is safe and even beneficial to > >> use blocking assignments (to unshared variables) in VHDL clocked > >> processes. > > >Yes, the two process model probably isn't nearly as useful in VHDL. > > >As others have been quick to point out, you don't need a combinatorial > >process in verilog either, but then you have to be careful about > >blocking vs. non-blocking, not using variables which have blocking > >assignments to them from other processes, etc. The two process model > >is simply an organizing principle that provides a separation of > >concerns and simplifies the rules a bit, making it easier to reason > >about the code. Extremely simple code doesn't gain anything from > >using this model, but a lot of real-world code does. > > I have to wonder if *that* is the reason the two-process model refuses > to die in VHDL textbooks, tutorials, and example designs worldwide. > > Perhaps too many educators focus on comparing the languages, showing how > the same thing is done *the same way* in both languages. > > I would prefer to see each language shown off at its best. > > Then VHDL could be illustrated with the (much less verbose) single > process model, functions and procedures to raise the abstraction level > and simplify the main process, and proper use of the type system to help > rather than frustrate the user. > > (e.g. recently here, there was an example where someone frustrated > himself by using a type with integer semantics when he really wanted a > type with modular semantics, so he had to code all the wrap-arounds by > hand. Easy pitfall for someone used to C which doesn't have any types > with integer semantics.) > > Likewise best practice in Verilog could be illustrated. > (I have no idea what that is; hearsay suggests it would include avoiding > races, avoiding problems with signed arithmetic, implicit declarations > and so on. But Verilog must have real strengths too) > > - Brian I don't agree that the two process model is inherently less desirable. Or maybe I should say that I don't think describing combinatorial logic outside of clocked processes is inherently less desirable. I seldom put a lot of combinatorial logic in processes, clocked or unclocked, mainly because the structures in processes and combinatorial logic are rather weighty (a synonym for verbose I guess). But it always depends on the logic. Lacking the conditional expression, VHDL concurrent logic can be a PITB to write complex expressions in a clear manner. This means sometimes I put combinatorial in unclocked processes because it is more clear. Simple logic goes in with the clocked process, but when possible, I put combinatorial logic in concurrent statements. A foolish consistency is the hobgoblin of little minds, but there are times when consistency is a good thing in engineering, other times not. I guess I'm consistently inconsistent. Rick
From: Brian Drummond on 28 Apr 2010 06:56 On Tue, 27 Apr 2010 15:56:57 -0700 (PDT), rickman <gnuarm(a)gmail.com> wrote: >On Apr 27, 6:05�am, Brian Drummond <brian_drumm...(a)btconnect.com> >wrote: >I don't agree that the two process model is inherently less >desirable. Or maybe I should say that I don't think describing >combinatorial logic outside of clocked processes is inherently less >desirable. Where there are combinatorial outputs to be described, I agree, I'll describe them outside the main process. But I can't remember the last time I had one so complex it needed a process of its own. > I seldom put a lot of combinatorial logic in processes, >clocked or unclocked, mainly because the structures in processes and >combinatorial logic are rather weighty (a synonym for verbose I >guess). But it always depends on the logic. Lacking the conditional >expression, VHDL concurrent logic can be a PITB to write complex >expressions in a clear manner. This means sometimes I put >combinatorial in unclocked processes because it is more clear. Simple >logic goes in with the clocked process, but when possible, I put >combinatorial logic in concurrent statements. 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. I eventually figured out what I heartily detest about that (?:) - it's the ONE construct across all the languages I've encountered that expects the list of choices in descending order. (And does so implicitly as opposed to explicitly, with a "downto" or "step -1" or "when true else..." or some visible indication that it's doing something quaint) 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. If you are going to allow --------------------------------- Signal Flag : Boolean := True; Signal Int_val : Integer; Int_val <= Flag?1:0; --------------------------------- then you must surely allow similar expressions with other enumerations, for instance: --------------------------------- Type NTSC_Color is (red, green, blue); Signal Channel_Color : NTSC_Color; Signal Channel_Gain : real; Channel_Gain <= Channel_Color ? 0.11 : 0.55 : 0.34; -- nice and compact, but descending order to remain compatible with Boolean --------------------------------- Now I believe that ascending order, like every other positional list in the language (port lists, argument lists, etc), would be less surprising: Channel_Gain <= Channel_Color ? 0.34 : 0.55 : 0.11; There would of course be an associative form of the expression Channel_Gain <= Channel_Color ? red =>0.34 : green =>0.55 : blue=>0.11; to make the bugs harder to bury. In this context, is anyone still happy with the C-compatible version? However... in today's VHDL, if I ever needed ?: I would resort to a trivial function, and replace Int_val <= Flag?1:0; with Int_val <= cond(Flag,1,0); or even Int_val <= cond( test=>Flag, T=>1, F=>0 ); YMMV but for the sake of keeping the language relatively free of warts, I don't mind typing six extra characters. It's precisely that wart-free-ness that lets you extend it (e.g. by adding functions) in simple ways that actually work, instead of frustrating you. And it's precisely the remaining warts that limit the ability to extend it further. For example, the closed set of operators (a wart shared with most not-quite-object-oriented languages like C++) stops you naming the above function "?:" and writing Int_val <= "?:"( Flag,1, 0 ); to look that little bit more like Verilog or C. Or a better example: if you allowed types as generics, as Ada does, you could write the "?:" function once and use it to return different types. (Newer versions of C++ have this, as the template). >A foolish consistency is the hobgoblin of little minds, but there are >times when consistency is a good thing in engineering, other times >not. I guess I'm consistently inconsistent. Oh I'm inconsistent too, just not consistently so. I like "consistently inconsistent" - I suspect it would make the best description of the underlying design principles of C. (I don't know Verilog at all well, so won't extend the same courtesy to it!) - Brian
From: Alan Fitch on 28 Apr 2010 07:33 On 28/04/2010 11:56, Brian Drummond wrote: > On Tue, 27 Apr 2010 15:56:57 -0700 (PDT), rickman<gnuarm(a)gmail.com> wrote: > >> On Apr 27, 6:05 am, Brian Drummond<brian_drumm...(a)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 � 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(a)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.
From: Andy on 28 Apr 2010 10:02
On Apr 28, 5:56 am, Brian Drummond <brian_drumm...(a)btconnect.com> wrote: > then you must surely allow similar expressions with other enumerations, > for instance: > --------------------------------- > Type NTSC_Color is (red, green, blue); > Signal Channel_Color : NTSC_Color; > Signal Channel_Gain : real; > > Channel_Gain <= Channel_Color ? 0.11 : 0.55 : 0.34; > -- nice and compact, but descending order to remain compatible with Boolean > --------------------------------- > > Now I believe that ascending order, like every other positional list in the > language (port lists, argument lists, etc), would be less surprising: > > Channel_Gain <= Channel_Color ? 0.34 : 0.55 : 0.11; The problem with this approach is that the action depends not only on the enumerated values defined in the type, but also on their order of definition. Especially when the type is often defined in a package, not immediately visible to the user/reviewer, I would much prefer a more explicit (yes, verbose!) coding of what action is desired. Using an array indexed by the enumerated type, or using the aforementioned function, we can do this already, without the conditional operator (I'm probably in the minority, but this was not a wise addition to the language in 2008). By adding such ambiguous shortcut features to the language, we are only deterring the use of a universally accepted solution to code complexity: subprograms (functions and/or procedures). Consistently inconsistent here too... BTW, WRT combinatorial outputs of clocked processes, many synthesis tools now support the following: process (clk, rst) is variable myvar : ... begin if rst then myvar := ... elsif rising_edge(clk) then myvar := myfunc(inputs); end if; combout <= outfunc(myvar); end process; Combout is then the combinatorial output of outfunc() applied to the output of the register inferred by the access to myvar. This gives us the ability to describe combinatorial output logic without the simulation penalty, latches, and signal overhead associated with a separate combinatorial process, implied or explicit. Andy |