Jonathan David wrote: >I wouldn't know about the "un-neccessary" hack.. >but I'd be interested to see how to get the same >functionality with wires .. >BTW a signal flow discipline is the the Continuous >time domain, while wreal is in the discrete time >domain.. which is VERY useful when trying to write >fast math models without impacting the analog solver.. >60x faster in at least one case I developed. > > "continuous" is usually piecewise-linear (pwl), so it's actually discrete when differentiated wrt time, also the requirement for it being pwl comes from the solver rather than the language itself, so if the solver can handle infinite dV/dt (or the description doesn't need a solver - which is the wreal usage) you could use signal-flow discipline wires instead of wreal. >wreal can be set in an always block.. >a signal flow discipline can only be set in an analog >block.. > > An unnecessary restriction, you should be able to drive analog signals directly from digital processes, it's there because the solvers don't handle it well if analog signals are driven with non-pwl signals and sorting out if it is necessary to use a solver can be awkward. If an analog signal has no contributions from analog process it can be treated much the same as wreal, and if it also has no analog processes receiving it then it should be able to support discrete (non-pwl) waveforms without any problems (since it doesn't need to go into the solver). This would generally be nicer to have than wreal because you can type-check connections and plug & play works better. >It may be a hack.. but I'll only give it up when we >get a better discrete time analog signal.. ie from >SystemVerilog or SystemC .. > > > I think if we had a modified assignment with slew-rate(s) that you could use in digital processes you would get everything you need, and you could avoid the solver problems too e.g.: always @(...) V(supply) # max_dvdt <+ func(...); // modify Vdd Handling a pwl signal in a digital simulator isn't difficult, but if you want you could just ignore the dv/dt limit(s) and just pass through the voltage for behavior identical to wreal. Kev. >jonathan > >--- Kevin Cameron <kevin@sonicsinc.com> wrote: > > > >>Helwig Graham-A11558 wrote: >> >> >> >>>Hello Kev, >>> >>> >>> >>> >>> >>>>I doubt "input p2; logic p2; wreal p2;" is allowed >>>> >>>> >>or >> >> >>>>feasible since it's hard to seperate the usage as >>>> >>>> >>real or >> >> >>>>logic syntactically, and there are no resolution >>>> >>>> >>rules for >> >> >>>>wreal and logic. >>>> >>>> >>>> >>>> >>>I treat wreal as just another discrete net type >>> >>> >>(i.e. wire). The only difference I see is that wreal >>nets have a few more restriction that the other net >>types. Declaring a discrete discipline with a wreal >>net type can be very useful in a design, >>particularly when 2 wreal nets need to be >>incompatible with each other. >> >> >>> >>> >>> >>> >>IMO wreal was an unecessary hack introduced by >>Cadence to be compatible >>with stuff they had already implemented and shipped. >>You can achieve the >>same functionality with wires and signal-flow >>disciplines. If we ever >>get the SV syntax/semantics for binding an arbitrary >>(user defined) type >>to a wire sorted out I expect wreal to be >>deprecated. >> >> >> >>>I think the discipline resolution and connect >>> >>> >>module should not be limited to discrete and >>continuous, instead it should expand to handled an 2 >>incompatible nets regardless of domain. >> >> >>> >>> >>> >>> >>Of course, it would be nice to be able to have (say) >>an >>electrical/optical connection have an opto-coupler >>module auto-inserted, >>but that kind of "connect module" is something that >>represents real >>hardware (a transducer) rather than a simulation >>artifact, so it would >>be a significant language extension. As yet no-one >>has proposed any >>schemes for providing resolution functions for user >>defined types in SV >>so I suspect it will be some time before we get as >>far as a general >>cross-domain/cross-type connection scheme. >> >>BTW, the last presentation I saw on the future of SV >>indicated that >>there might not be a single (System)Verilog LRM, but >>rather the SV and >>Verilog LRMs would continue as seperate entities, so >>targeting Verilog >>200X for AMS might be problematic if your goal is >>actually merging with SV. >> >>Kev. >> >> >> >>>Regards >>>Graham >>> >>> >>> >> >> > > > >Received on Tue Nov 29 18:30:00 2005
This archive was generated by hypermail 2.1.8 : Tue Nov 29 2005 - 18:30:21 PST