Re: Re[2]: Use of femto scaling in IBIS models

To all:

Version 1.1 of IBIS allowed only these scale factors:

   M, k, m, u, n, and p

Version 2.0 added to the list:

   T, G, and f.

Every other letter and case is permitted. So ibis_chk
for Version 1.1 and ibischk2 for Version 2.1 will not
give any error for any character (lower or upper case)
appended to any number. Thus we can add V or v, A or a,
S or s, etc.

Therefore Version 1.1 files with these factors should
either be designated Version 2.1 (even if they contain
only the Version 1.1 subset) or else a Version 1.1
compliant set of multipliers (e.g. 0.1p, 1e-10, etc.
for 100f.) This will avoid the situation that different
simulators will give different results for the same
data that is itself not technically what was intended.

Best Regards,
Bob Ross
Interconnectix

> Date: Wed, 27 Nov 96 09:03:00 PST
> From: Will Hobbs <Will_Hobbs@ccm.jf.intel.com>
> Message-ID: <Wed, 27 Nov 96 09:05:41 PST_6@ccm.jf.intel.com>
> To: owner-ibis@vhdl.org, ibis@vhdl.org
> Subject: Re[2]: Use of femto scaling in IBIS models
> Status: R

> Text item:

> Arpad, et al,

> I know that early on we talked of the parser as the "executable spec," but since
> we have gone through formal balloting, etc., of IBIS as an ANSI EIA
> specification, the written spec is the spec. Period. The parser should be as
> faithful to that spec as possible. If "f" has to be added to the spec, then so
> be it. That should be a 3.0 issue, and a Bird generated and voted on.

> Will

> Mike,

> Thanks for the information. This issue is clearly an oversight on my part.
> When I wrote our tool that automates the process of generating IBIS models, I
> didn't check what the valid prefixes are in IBIS, so I coded my program to use
> all known prefixes available in the engineering world. Since then, I have a
> newer revision of the tool which uses engineering notation in the
> tables (only).

> Due to time limitations, I cannot commit to fix all the earlier models.
> One way
> of getting around the fA problem is to edit the file to be version
> 2.1, since it
> is legal in that spec.

> However, I question whether this is a spec or parser issue. I parsed the 1.1
> IBIS file in question with both parsers just now, and neither one of them gave
> me an error. If this is illegal in 1.1, both parsers should have given me an
> error. This is why these prefixes slipped in to start out with...

> At one time we were debating whether in cases like this, when the
> parser didn't
> agree with the spec, which one should take precedence. If I remember
> correctly
> we voted for the parser. In this light, the Intel models are not illegal.
> (Someone correct me if I am wrong).

> So the question is, should we fix the parser, or change the spec to allow for
> all prefixes. In my opinion it doesn't make sense to have to say
> 0.01 pA for 10
> fA and so on. Even though these kind of numbers are usually noise and outside
> the usually measurable range, I would still allow them for the sake of
> consistency and completeness. You never know, someone might even need them in
> some cases... (especially with capacitances).

> Arpad
> ===============================================================================
> =

> Ibisians,

> I have recently found a problem in the parser which affects both
> versions of the parser when parsing version 1.x IBIS models which
> contain values scaled using the femto(f) prefix.

> As far as I know this only affects Intel models as everyone else
> uses unscaled number in engineering/scientific format.

> According to the IBIS 1.1 spec, the prefix f is not
> a legal prefix, pico is the smallest allowed. As the Intel model is
> set as version 1.1 it is not a valid IBIS model.
> Also the IBIS2.1 parser does not pick it up as it uses the IBIS v1.1
> parser checker.

> Illegal scale characters in the IBIS file are set to ' ' i.e. scale=1.0
> without any error message.

> I fiexed it by adding the character f to the known_scales array
> i.e Mkmunp -> Mkmunpf
> If the IBIS version in the file is set to 2.1 it will work OK
> as f is recognised.

> This should only affect simulated models, as measured models are
> somewhat difficult to measure to that degree of accuracy.
> I did once see currents of magnitude e+41 in an Intel model which I
> presumed was simulated otherwise most of California would have been
> blacked out!

> Here is a supplementary question. Why is not having the same file
> name as that in the file classified as an error rather than a warning?
> Even if the file has the right name and you access it through a full
> path name you get the error.

> Regards

> Mike

> --
> ********PLEASE NOTE NEW ADDRESS AND FAX NUMBER *****************
> | Mike Ventham - Vice-President Engineering, |
> | Quantic Laboratories Inc Headquarters |
> | Croft House, Chilcompton, 191 Lombard Ave, Winnipeg, |
> | Somerset, UK, BA3 4JA Manitoba, Canada R3B 0X1 |
> | Tel: 44 (0)1761 232191 Tel: (204) 942 4000 |
> | Fax: 44(0)1761 233549 Fax: (204) 957 1158 |
> | Email: ventham@quantic.mb.ca |

> Text item: External Message Header

> The following mail header is for administrative use
> and may be ignored unless there are problems.

> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=us-ascii
> Subject: Use of femto scaling in IBIS models
> To: ibis@vhdl.org
> MIME-Version: 1.0
> X-Mailer: Mozilla 3.0Gold (WinNT; I)
> Organization: Quantic Laboratories Inc
> Reply-To: ventham@quantic.mb.ca
> From: Mike Ventham <ventham@quantic.mb.ca>
> Date: Fri, 22 Nov 1996 16:10:15 +0000
> Message-ID: <3295D067.5EDE@quantic.mb.ca>
> Received: from henty by maelstrom.dial.pipex.net (8.8.2/)
> id QAA07402; Fri, 22 Nov 1996 16:13:36 GMT
> Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET
> PIPEX simple 1.28)
> id QAA21850; Fri, 22 Nov 1996 16:13:04 GMT
> Received: from typhoon.dial.pipex.net by maelstrom.dial.pipex.net (8.8.2/)
> id QAA07928; Fri, 22 Nov 1996 16:14:32 GMT
> Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET
> PIPEX simple 1.28)
> id QAA22072; Fri, 22 Nov 1996 16:17:56 GMT
> Received: from typhoon.dial.pipex.net (typhoon.dial.pipex.net [158.43.128.46])
> b
> y vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15019 for <ibis@vhdl.org>;
> Fri, 2
> 2 Nov 1996 12:14:49 -0800 (PST)
> Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.
> c
> om (8.8.3/8.7.3) with ESMTP id MAA01881; Fri, 22 Nov 1996 12:09:19 -0800 (PST)
> Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4])
> by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id MAA00672; Fri, 22
> Nov 1996 12:
> 06:45 -0800 (PST)
> Return-Path: owner-ibis@vhdl.vhdl.org

> Text item: External Message Header

> The following mail header is for administrative use
> and may be ignored unless there are problems.

> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

> Subject: Re: Use of femto scaling in IBIS models
> To: ibis@vhdl.org
> Message-ID: <Tue, 26 Nov 96 19:30:41 PST_14@ccm.fm.intel.com>
> From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
> Date: Tue, 26 Nov 96 12:29:00 PST
> Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 26 Nov 96 19:31:02 PST
> Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id TAA26
> 779 for ibis@vhdl.org; Tue, 26 Nov 1996 19:31:02 -0800 (PST)
> Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 2
> 7 Nov 1996 03:33:13 GMT
> Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vh
> dl.vhdl.org (8.7.3/8.7.3) with ESMTP id TAA14709 for <ibis@vhdl.org>; Tue, 26 No
> v 1996 19:44:17 -0800 (PST)
> Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com (
> 8.8.3/8.7.3) with ESMTP id TAA14747; Tue, 26 Nov 1996 19:35:47 -0800 (PST)
> Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
> ntel.com (8.8.2/8.7.3) with ESMTP id TAA04657; Tue, 26 Nov 1996 19:35:47 -0800 (
> PST)
> Return-Path: owner-ibis@vhdl.vhdl.org
Received on Wed Nov 27 11:28:42 1996