Re: [Help-gnucap] bm_pulse is still buggy

[al davis]

On Saturday 16 February 2008, a r wrote:
> bm_pulse still generates a distorted waveform. On 3/12/2007
> I've posted a corrected version of the tr_eval function that
> does not suffer from this problem. To be honest, it's a bit
> disappointing - I understand you may have a problem testing
> all the stuff by yourself but, please, at least listen to
> users and fix some obvious bugs (especially when you are
> given a working solution).

It's in the queue....

There were two issues ..  one is step control missing 
transitions.  That one should be fixed now.  The other is, I 
think, a misinterpretation of the spec for what it should do.  
The old one correctly implements an incorrect spec.

>
> The following test case exposes the problem (note the
> waveform should have a 50% duty cycle). It would probably be
> a good idea to have an automatic regression test suite.

I have over 400 test cases in an automatic regression suite.  
Apparently, the pulse tests were done based on an incorrect 
spec, so it shows the old behavior as correct.

It will be fixed.  Thanks for pointing it out.

Specifically, the error is in interpretation of the meaning 
of "delay".  Is that correct?  It should be correct when you 
set delay to 0.

> BTW, I noticed there are two modeling functions now: tr_eval
> and tr_review. As far as I can see the former is used for
> generating waveform values and the latter for time events. Is
> this right?

There are more than that, but some are no-ops or inherited.

"tr_eval" evaluates.  That is all.  It is only allowed to make 
calculations and store the results of those calculations.  
Nominally, it is called once per iteration.  Actually, it can 
be called any number of times per iteration, usually 0 or 1.  
Sometimes it is skipped, taking a previous result.  Sometimes 
it will be called more than once in error recovery. 

"tr_review" looks things over after calculations for a time step 
have been made.  Nominally, it is called once per actual time 
step, to review things and decide what to do next. Actually, it 
can be called any number of times per iteration, usually 0 or 
1.  It suggests two time targets based on different criteria, 
that might be used as the next time step, or might not.  One 
possible decision might be to throw away the previous set of 
calculations and try again.