Hi Sri, Sri Chandra wrote: >> I didn't realise we were going to allow the analog_function_port_list >> similar to what is in digital. Of course I would prefer not to as it >> means a parser change :) >> If we are trying to mimic digital functions, I wonder if we should >> remove the restriction on not allowing recursive analog function >> calls, so you can support things like a factorial function? >> I have read through 10.4 and I think I have most of it covered. >> The main thing I tried to add for analog UDF's is how output and >> inout parameters are supported as I tend to find these confusing. >> Especially inout parameters. This depends very much on how one >> defines "inout", is it pass by reference, copy in - copy out? Anyway >> I have documented it as copy in - copy out, and when we do the UDF >> section we can discuss further if needed. > One extra think, after looking at section 10.4 of 1364-2005, I like > the level of detail that the standard goes into. However, the LRM 2.2 > does not go to that level of detail. To what level of detail are you > going to to define the analog function and analog function calls? > > > The confusion comes especially when you use repeated arguments ie. > udf_fn(a,a,...) where the arguments are inout its a bit confusing what > the values should be. In that sense i think it is a good idea to > clearly define what the intent is, and i think explicitly stating > copy-in/copy-out is probably a good thing. Wonder what C does? Guess > it depends on compiler and order of evaluation of the arguments of a > function (left-to-right vs right-to-left)? > Well C it is a bit clearer as you have to pass by pointer, so you know that you are directly modifying the original variable. > >>> >>>> 5. Am I allowed to have constant_analog_function_call? I notice >>>> that the syntax only allows for constant_function_call. Should we >>>> add a constant_analog_function_call rule and include it in >>>> constant_primary? >>> OK, I think your question points to a bigger issue that has not be >>> discussed previously. >>> >>> In LRM 2.2 the function_declaration can only be called from >>> 'expression' syntax, while analog_function_declaration can only be >>> called from analog_expression syntax. No overlap wrt. domain. Now >>> in the 1364-2005, constant version of function declarations (see >>> section 10.4.5 for the constraints) can be declared and called >>> within the constant_expression syntax. This means a constant digital >>> function declarations can be called from with the analog behavior >>> where ever a constant expression syntax is used. Should this be >>> allowed? >> >> Well my answer is no, we shouldn't allow this, but I think my answer >> is influenced by implementation. >> >>> >>> Even if the answer to the above question is yes, I believe there is >>> little value in supporting constant versions of analog function >>> declarations for use in constant expression. My reasoning for this >>> is that similar constraints (as in section 10.4.5 of the 2005 LRM) >>> will need to be applied to the analog function declarations. In >>> doing so, the constant analog function declarations will become very >>> much like a constant digital function declarations. So it would be >>> easier to use the existing constant function call mechanism instead >>> of creating constant analog function declaration which basically >>> does the same thing. I'll be very interested to know what other >>> committee members think about this issue. > > I agree that whereever possible if we can use the same syntax as the > digital (ie. no need to differentiate and create an analog version of > the syntax) i would just go ahead and use the existing ones. > > Is this query also related to initializing a parameter with constant > UDF calls? Sorry if i didnt understand the usage correctly. > > For example: > parameter real Q = ...; > parameter P = myUDF(Q); ?? > Yes, I am referring to constant UDF's solely for parameter initialisation. Among other reasons, I wanted a constant analog UDFso I could initialise a parameter that is declared inside an analog named block. Cheers... Dave > > > cheers, > Sri > -- ===================================== -- David Miller -- Design Technology (Austin) -- Freescale Semiconductor -- Ph : 512 996-7377 Fax: x7755 =====================================Received on Wed Sep 6 03:24:03 2006
This archive was generated by hypermail 2.1.8 : Wed Sep 06 2006 - 03:24:05 PDT