FYI. from Mark Hartoog. -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] Sent: Wednesday, April 20, 2005 2:10 PM To: sv-ec-approval@eda.org Subject: BOUNCE sv-ec@eda.org: Non-member submission from ["Mark Hartoog" <Mark.Hartoog@synopsys.com>] From: "Mark Hartoog" <Mark.Hartoog@synopsys.com> To: "'Adam Krolnik'" <krolnik@lsil.com>, "'Randy Misustin'" <ram@model.com> Cc: "'Steven Sharp'" <sharp@cadence.com>, <gordonv@model.com>, <btf@boyd.com>, <etf@boyd.com>, <sv-bc@server.eda.org>, <sv-ec@server.eda.org> Subject: RE: [sv-ec] Re: [sv-bc] potential command line option Date: Wed, 20 Apr 2005 14:10:05 -0700 You say that you were expecting the config and verilog syntax to be separate, but were you expecting configurations to be allowed only in library mapping files? If you were expecting them only in library mapping files, how do you get a config into a logical library. As I describe in more detail in the attached email, the LRM says/implies: 1) configs only appear in library mapping files. 2) configs can be cells in logical libraries. 3) the library map file is NOT a source file 4) the library mapping in a libmap file applies to source files only. This leaves no mechanism for specifying how a configuration gets into a logical library. It is clear to me that configs are part of the design, and therefore should be in a "source file". The libmap file does not really look like a source file to me. It looks more like a tool/library setup file. I think it is a bad idea to mix tool setup information with design information in the same file. Many people interested in using configs in Verilog are coming from a vhdl background, where configs are part of the language and could appear in the same file as other vhdl. They may find it strange that Verilog has a separate configuration language that is only allowed in separate files, and I am sure they will find it strange if it is only allowed in libmap files. I believe the current proposal creates a separate class of source files for configurations, as well as allowing them in libmap files, and then recommends some command line options to specify to tools that the next file is a config source file rather than a verilog source file. Having to specify that extra option all the time looks inconvient to me. It means I cannot do something like <tool-name> *.v <other_options> You cannot even do <tool-name> *.v *.cfg <other_options> because you would need a command line option in front of every config file. I don't really like that. > Behalf Of Adam Krolnik > Hi Randy; > > A little history about configurations. > > The BTF originally did not combine the configuration file > syntax with the verilog file syntax. That was done during > editing of the final specification. We were expecting that > the configuration file syntax and keywords was separate from > the verilog language syntax and keyword set. > > Thanks. > > -- > Adam Krolnik > ZSP Verification Mgr. > LSI Logic Corp. > Plano TX. 75074 > Co-author "Assertion-Based Design" > ------=_NextPart_000_000D_01C545B2.A738A610 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Mark Hartoog" <markh@synopsys.com> To: <Shalom.Bresticker@freescale.com>, "'Steven Sharp'" <sharp@cadence.com> Cc: <btf@boyd.com>, <etf@boyd.com> Subject: RE: [sv-bc] potential command line option Date: Wed, 20 Apr 2005 10:17:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C545B2.A738A610" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVFV/2nfPtGfpMqRAOytdYLmDt8FgAcQbPw In-reply-to: <Pine.GSO.4.10.10504200613590.10859-100000@eagle> This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C545B2.A738A610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the section on Hierarchical configurations the 1364-2001/1364-2005 LRMs say you can specify the following mapping: instance top.a1.foo use lib1.foo:config; // bind to the config foo in library lib1 This clearly implies that a config can be an "cell" in a library. The BNF only allows configs in library mapping files. How would you get the configs into a libraries? Would you name the library mapping file in the wild card patterns so that its contents would be mapped into the library also? In the section on libraries (13.2.1 in 1364-2001) it says "When parsing a source description file (or files), the parser shall first read the library mapping information from a pre-defined file prior to reading any source files." This implies that library mapping files are NOT source files. In the section on "Mapping source files to libraries" (13.2.3 in 1364-2001) it says "For each cell definition encountered during parsing/compiling, the name of the source file being parsed is compared to the file path specifications of the library declarations in all of the library map files being used. The cell is mapped into the library whose file path specification matches the source file name." This implies that library mapping only applies to source files, and library map files are NOT source files. I don't see any way to get a configuration into a library if configurations are not allowed in some kind of source file. I think the 1364-2001 LRM is inconsistent about where configuration may appear. Either it was an error in the BNF that configurations can not appear in source files, or it was an error that configurations can be cells that are in libraries. I think we should allow configurations in libraries, so I think we should say it was an error in the BNF. I don't like the idea of creating two classes of source files, normal verilog and config, but I suppose I can live with that, if we have too. > -----Original Message----- > From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On > Behalf Of Shalom.Bresticker@freescale.com > Sent: Tuesday, April 19, 2005 8:18 PM > To: Steven Sharp > Cc: btf@boyd.com; etf@boyd.com > Subject: Re: [sv-bc] potential command line option > > Just to be fair, I should point out that IEEE rules state > that where the standard is ambiguous, an interpretation needs > to allow the most liberal interpretation. This is because the > content of a standard is determined by what is written there, > not by what was intended to be written there, and here there > was not even an intent at that time. > > Shalom > > > > It is not clear that this would be a change to what is specified in > > 1364-2001. The text doesn't state where configs can > appear, and the > > syntax boxes and BNF clearly specify that they cannot appear in > > Verilog source files. This proposal could be viewed as an official > > interpretation with a corresponding clarification in the > LRM. There > > has been no prior request for interpretation that would > conflict with > > this. Supporting both 1364-2001 and 1364-2005 would not > require different behavior. > > -- > Shalom.Bresticker @freescale.com Tel: > +972 9 9522268 > Freescale Semiconductor Israel, Ltd. Fax: > +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL Cell: > +972 50 5441478 > > [ ]Freescale Internal Use Only [ ]Freescale Confidential > Proprietary > ------=_NextPart_000_0009_01C545B2.A738A610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7036.0"> <TITLE>RE: [sv-bc] potential command line option</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>In the section on Hierarchical configurations the = 1364-2001/1364-2005</FONT> <BR><FONT SIZE=3D2>LRMs say you can specify the following = mapping:</FONT> </P> <P><FONT SIZE=3D2>instance top.a1.foo use lib1.foo:config;</FONT> <BR><FONT SIZE=3D2>// bind to the config foo in library lib1</FONT> </P> <P><FONT SIZE=3D2>This clearly implies that a config can be an = "cell" in a library.</FONT> </P> <P><FONT SIZE=3D2>The BNF only allows configs in library mapping files. = How would</FONT> <BR><FONT SIZE=3D2>you get the configs into a libraries? Would you name = the library mapping</FONT> <BR><FONT SIZE=3D2>file in the wild card patterns so that its contents = would be mapped </FONT> <BR><FONT SIZE=3D2>into the library also? </FONT> </P> <P><FONT SIZE=3D2>In the section on libraries (13.2.1 in 1364-2001) it = says "When parsing </FONT> <BR><FONT SIZE=3D2>a source description file (or files), the parser = shall first read the </FONT> <BR><FONT SIZE=3D2>library mapping information from a pre-defined file = prior to reading </FONT> <BR><FONT SIZE=3D2>any source files." This implies that library = mapping files are NOT</FONT> <BR><FONT SIZE=3D2>source files.</FONT> </P> <P><FONT SIZE=3D2>In the section on "Mapping source files to = libraries" (13.2.3 in </FONT> <BR><FONT SIZE=3D2>1364-2001) it says "For each cell definition = encountered during </FONT> <BR><FONT SIZE=3D2>parsing/compiling, the name of the source file being = parsed is</FONT> <BR><FONT SIZE=3D2>compared to the file path specifications of the = library declarations </FONT> <BR><FONT SIZE=3D2>in all of the library map files being used. The cell = is mapped into </FONT> <BR><FONT SIZE=3D2>the library whose file path specification matches the = source file name."</FONT> </P> <P><FONT SIZE=3D2>This implies that library mapping only applies to = source files, and</FONT> <BR><FONT SIZE=3D2>library map files are NOT source files. I don't see = any way to get</FONT> <BR><FONT SIZE=3D2>a configuration into a library if configurations are = not allowed </FONT> <BR><FONT SIZE=3D2>in some kind of source file. </FONT> </P> <P><FONT SIZE=3D2>I think the 1364-2001 LRM is inconsistent about where = configuration may</FONT> <BR><FONT SIZE=3D2>appear. Either it was an error in the BNF that = configurations can not </FONT> <BR><FONT SIZE=3D2>appear in source files, or it was an error that = configurations can be</FONT> <BR><FONT SIZE=3D2>cells that are in libraries.</FONT> </P> <P><FONT SIZE=3D2>I think we should allow configurations in libraries, = so I think we should</FONT> <BR><FONT SIZE=3D2>say it was an error in the BNF. I don't like the idea = of creating two </FONT> <BR><FONT SIZE=3D2>classes of source files, normal verilog and config, = but I suppose I can</FONT> <BR><FONT SIZE=3D2>live with that, if we have too.</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: owner-btf@boyd.com [<A = HREF=3D"mailto:owner-btf@boyd.com">mailto:owner-btf@boyd.com</A>] On = </FONT> <BR><FONT SIZE=3D2>> Behalf Of Shalom.Bresticker@freescale.com</FONT> <BR><FONT SIZE=3D2>> Sent: Tuesday, April 19, 2005 8:18 PM</FONT> <BR><FONT SIZE=3D2>> To: Steven Sharp</FONT> <BR><FONT SIZE=3D2>> Cc: btf@boyd.com; etf@boyd.com</FONT> <BR><FONT SIZE=3D2>> Subject: Re: [sv-bc] potential command line = option</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Just to be fair, I should point out that IEEE = rules state </FONT> <BR><FONT SIZE=3D2>> that where the standard is ambiguous, an = interpretation needs </FONT> <BR><FONT SIZE=3D2>> to allow the most liberal interpretation. This = is because the </FONT> <BR><FONT SIZE=3D2>> content of a standard is determined by what is = written there, </FONT> <BR><FONT SIZE=3D2>> not by what was intended to be written there, = and here there </FONT> <BR><FONT SIZE=3D2>> was not even an intent at that time.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Shalom</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> > It is not clear that this would be a change = to what is specified in </FONT> <BR><FONT SIZE=3D2>> > 1364-2001. The text doesn't state = where configs can </FONT> <BR><FONT SIZE=3D2>> appear, and the </FONT> <BR><FONT SIZE=3D2>> > syntax boxes and BNF clearly specify that = they cannot appear in </FONT> <BR><FONT SIZE=3D2>> > Verilog source files. This proposal = could be viewed as an official </FONT> <BR><FONT SIZE=3D2>> > interpretation with a corresponding = clarification in the </FONT> <BR><FONT SIZE=3D2>> LRM. There </FONT> <BR><FONT SIZE=3D2>> > has been no prior request for = interpretation that would </FONT> <BR><FONT SIZE=3D2>> conflict with </FONT> <BR><FONT SIZE=3D2>> > this. Supporting both 1364-2001 and = 1364-2005 would not </FONT> <BR><FONT SIZE=3D2>> require different behavior.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> -- </FONT> <BR><FONT SIZE=3D2>> Shalom.Bresticker = @freescale.com &nbs p= ; Tel: = </FONT> <BR><FONT SIZE=3D2>> +972 9 9522268</FONT> <BR><FONT SIZE=3D2>> Freescale Semiconductor Israel, = Ltd. &n b= sp; Fax: </FONT> <BR><FONT SIZE=3D2>> +972 9 9522890</FONT> <BR><FONT SIZE=3D2>> POB 2208, Herzlia 46120, = ISRAEL &= nbsp; Cell: </FONT> <BR><FONT SIZE=3D2>> +972 50 5441478</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> [ ]Freescale Internal Use = Only [ ]Freescale Confidential </FONT> <BR><FONT SIZE=3D2>> Proprietary</FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------=_NextPart_000_0009_01C545B2.A738A610-- ------=_NextPart_000_000D_01C545B2.A738A610--Received on Wed Apr 20 22:48:19 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 20 2005 - 22:50:06 PDT