Re[2]: 2.1 changes [Done]

Paul,
 
Regarding your points,
 
1. I agree with what you have done.
 
3. This should be done as part of an extension to your project.
 
4. We rejected this change to avoid at this time impacting many, if not
all of your modules. We would really not have time to adequately test
your changes. So do nothing on 4.
 
5. I don't know what the solution would be or impact. For me, I don't care
since I can always do the dos2unix or unix2dos conversion. Kelly C. has
opinions on this issue. If it is a trivial solution or flag, then we
should consider it. Otherwise, I think this should be dropped since there
is no BIRD or formal agreement to proceed.
 
6. The scale issue was raised again at the last meeting and the point is
valid to the extent that the parser not only tests rigorous compliance to
Version 2.1, but also gives in a few cases (monotonicity test) warnings for
reasonableness of data. We currently allow any character or string to
follow any numerical entry, and the first case sensitive letter which would
be interpreted as a unit is explicitly defined. It is difficult to
generalize a warning test without making this a very big project. So, I
would like to see the impact before proceeding since we have not agreed
to what type of test be reasonable.
 
One possible limited test would be just to issue a WARNING message on any
L and C sub-parameters equal or greater than 1m. This will warn someone
who inadvertently entered .5 instead of .5nH or .5pF since some systems
use nH and pF as default units, and would also warn of certain typo's such as
entering .5PF of .5NH or 5mH. There may be about 10 or 15 such subparameters,
and also the coupled package L and C tables.
 
7. Thank you for finding the mistake regarding L_dut, C_dut, R_dut. I think
Derrick should make the correction and repost the standard since this looks
like an omited line.
 
> Will/Derrick/Bob/Ron,
 
> The following is my accessment of what has been documented (2.1 spec) or
> talked about for changes to the golden parser. Please let me know your
> thoughts/comments on what I've mentioned here, plus indicate if I've forgotten
> anything. Once this is decided then work can proceed.
 
 
> >From comparing the ver2_0.ibs file against the ver2_1.ibs file, I find the
> following changes for the parser:
 
> 1) Corrected non-monotonic checking (already done). The actual error message
> used differs from that suggested in the spec, although contains the same
> information (except the "Most simulators ..." text). Instead of "Note:"
> the parser uses "Warning". Also, the parser message doesn't specify the
> model name since the specific curve and line number are provided; this is
> consistent with how we wanted to structure error and warning messages.
 
> 2) Addition of V_fixture_min and V_fixture_max as waveform sub-parameters
> (already done).
 
> 3) Each waveform table must contain at least two entries.
 
 
> Other changes that have been talked about in email, BIRDS or IBIS
meetings are:
 
> 4) Removing the case sensitivity on sub-parameters. I expected the spec
> to mention this, but it did not. Is it still desired?
 
> 5) Handle DOS files on UNIX systems and vice-versa. This is basically the
> issue of the <CR> character being the last character in the record and
> proving itself irratating on the UNIX side.
 
> 6) If scale is not known, then issue a warning. One problem is that 'V' is
> not a known scale but, at least in the spec, is used frequently as a scale.
 
> Notes:
 
> 7) The Sub-Params list in the [Rising Waveform] comments added V_fixture_min
> and V_fixture_max, but DROPPED R_dut, L_dut, and C_dut.
 
 
> I will provide the latest parser and sources to Arpad at the beginning
of this
> next
> week (January 9). Ron and I consider it complete for what was originally bid.
> It
> should only lack the issues mentioned above (#3, #4, #5, and #6),
each of which
> was brought up afterwards. Ron and I understand that you want the
rest of this
> work wrapped up quickly, but I would like to make sure that #4, #5, and #6 are
> definitly things that are desired to be accomplished since none of them are
> mentioned in the new 2.1 spec.
 
> Paul Munsey
Received on Mon Jan 9 10:48:57 1995