Hi Mac, Michael McNamara wrote: >On the face of it, from good software engineering principles, it makes >a lot of sense to me to separate the files containing configs from >files containing module definitions, for the very reason that in this >way configs can speak clearly about which module definitions should be >included and which should not be included. I also like to have the >surgeon be a different entity than the patient for this very reason. > >If the file that contains the config also contains module or primitive >definitions, it would be possible to construct a config which would >exclude the module(s) whose specification share the file containing >the config. This would be weird. > I can't agree here. I think the syntax is quite sufficient to implement a separation of concerns without the ncessity of creating a separate file type for the purpose. Too, VHDL has happily allowed configurations and entity/architectures/packages to coexist in the same file for some time. This has not seemed clumsy or weird in this more structured world and I don't think it seems clumsy or weird in Verilog. In fact, if things go the way you're supporting, this may be one of those few instances where Verilog winds up more regidly structured than VHDL. Its a subjective thing at any rate, I guess. >Further the fact that we have the BNF in three major sections, A1.1 >describing the Library BNF, A 1.2 describing the Config BNF, and A1.3 >that describes the module/primitive text, with the BNFs in A1.1 and >A1.2 completely specified in their sections, and only the BNF in A1.3 >refers to productions contained in other BNF sections (which are >defined in [A1.4 .. ] ), and further that an explicit rule does exist >that library maps (BNF A1.1) must be in their own file, leads pretty >good support via tranitive closure and the rule of least surprise to >the expectation that Config BNFs should also be in their own files. > Clearly, the current state of the BNF is quite problematic. It will need to be repaired and augmented with additional text once its decided what the correct view is. I'm confused by you arguing this view, though. Didn't you participate in this specification activity and agree with Cliff's mail in its substance if not the details? Don't you actually have a better idea as to what was being specified than to have to resort to this kind of forensics? >But finally, I return to the question as to why it would be a Good >Idea to include module definitions in the same file as the config. Is >there a compelling reason? What use model is uniquely enabled by this? > What use model is "uniquely enabled" by including modules in the same file as UDPs? The question isn't that important. In that we have a syntax that specifies a "design element, similar to a module, which exists in the Verilog namespace", it seems natural that they would exist in the same file type. Doing otherwise is what needs justification (and, as I said, I am sympathetic to the preserving keywords argument but observe that the keywords are already reserved). -randy. >One reason that might come to mind, is that it might be nice to wrap >up the entire design in a single file for shipment (tokens.v), >including the config; but configs would be completely useless in this >mode, as they can only talk about libraries, which fundamentally >require parts of the design to be in different different files which >likely reside in different directories. Since all of the design is in >a single file, it hence is in a single directory, and the set of legal >config file syntax gets to be rather boring. > >A second thought is I guess one could have three possible top level >module possibilities (A.v, B.v & C.v), and for efficiency sake, >include each definition of the top level module with its particular >config. But then this makes it difficult to run, say top level module >from file B.v with some deep part of its hierarchy in gate mode rather >than rtl mode, as the file defining the top level module (B.v) has a >config in it already with which we would likely be conflicting. > >-mac > > >-- On Apr 23 2005 at 22:53, Randy Misustin sent a message: > > To: sharp@cadence.com, gordonv@model.com, btf@boyd.com, etf@boyd.com, sv-bc@eda.org, sv-ec@eda.org > > Subject: "Re: [sv-ec] Re: [sv-bc] potential command line option" > > Steven, > > > > Gee, thanks for the grammar lesson. > > > > My real point was that there was insufficient care and formality given > > to the BNF in the 2001 spec to be able to authoritatively conclude > > either interpretation. But then again, my major concern isn't whether > > the 2001 spec does or doesn't allow a config to appear in Verilog > > source. My major concern is that the config keywords remain in the > > keyword list for the upcoming 1364 specification. Whether the reason for > > doing so is that configs are intended to be in Verilog source today, > > whether it's to reserve that capability for the future, or whether its > > for the frankly insightful reason you mentioned below (minus the > > extended identifier silliness) isn't nearly as important to me (OK, I do > > prefer the 1st but I'm pragmatic). > > > > Other messages in this thread have suggested that configs were, in fact, > > intended to be part of Verilog source files. I guess you're arguing that > > this was botched and, rather than fix it for the next version of the > > spec, you'd like to drop it. Is this your position? > > > > -randy. > > > > Steven Sharp wrote: > > > > >Randy, > > > > > >A lot of the issues here are necessarily matters of opinion and > > >judgement, and what the current LRM says is only one of the factors > > >to be considered. However, it helps to establish any facts that > > >we can. > > > > > >You wrote: > > > > > > > > >>I've tried to go back and divine from where you derive your strong > > >>assertion "syntax boxes and BNF clearly specify that they cannot appear > > >>in Verilog source files". The best I could come up with is that > > >>source_text in A.1.3 and library_text in A.1.1 don't grammatically > > >>derive each other. Your view must therefor be that source_text cannot > > >>share a file with library_text, correct? I didn't find this restriction > > >>anywhere. > > >> > > >> > > > > > >This restriction does not have to be spelled out separately, any more > > >than the rest of the meaning of the BNF notation does. It follows from > > >the accepted definitions of formal language theory and the BNF notation. > > >Note that there is no separate restriction saying that this email is > > >not valid Verilog source either; that follows in the same way. > > > > > >A formal language is defined by a formal grammar and a start symbol. > > >It consists of the set of all strings that can be derived from the > > >start symbol using the grammar. The BNF in the LRM fails to specify > > >the start symbol for Verilog source, though we can deduce from > > >information outside the BNF that it is source_text. You could argue > > >that some other start symbol should be used (thus defining a different > > >language), and there is nothing in the BNF to contradict it. However, > > >there is no start symbol that can be chosen that derives a string > > >containing both a config and a module. Therefore we can state with > > >certainty that no language defined by the BNF allows it. > > > > > >If someone wanted to define such a language, they could do so by > > >modifying the BNF to specifically allow it. This BNF does not. > > > > > >You might instead be suggesting that when the syntax of a programming > > >language is specified by a formal language, only a sub-string of the > > >source input needs to be a valid string in the formal language. This > > >is not the accepted convention, and it is easy to see why not. The > > >formalism would lose its power to fully specify legal input. For > > >example, any input would have to be accepted as Verilog source, since > > >it contains a legal string as a sub-string (specifically, the empty > > >string). > > > > > > > > > > > >>The keywords > > >>are already part of the 2001 specification. Whether you view > > >>configurations as allowable within a source file or not doesn't create > > >>the problem. The problem already exists. The keywords are part of the > > >>existing 1364-2001 standard. > > >> > > >> > > > > > >While I can come up with some arguments otherwise, I would have to > > >agree with you that a strict interpretation of the LRM text supports > > >this. All of the keywords in Annex B are reserved in both Verilog > > >source files and library map files. > > > > > > > > > > > >>In fact, the inclusion of the configuration keywords in a > > >>common list of keywords in Appendix B would seem to support the > > >>conclusion that both grammars can share a common parse. > > >> > > >> > > > > > >If we move from strict interpretation to speculation, there are many > > >possible conclusions. Annex B may simply contain a combined list of > > >keywords from the two different source languages defined in the BNF, > > >and may not intend to say that all are reserved everywhere. > > > > > >There is also a reason why you might want to reserve the library map > > >file keywords in Verilog source files, even though they can never be > > >used as keywords in a Verilog source file. If they are not reserved, > > >then they are valid identifiers that can be used for a module name. > > >However, that module name could not be referenced in a config, since > > >it is a keyword there. Fortunately, it could be referenced by using > > >the escaped version of the name (since in Verilog, the escaped version > > >of an identifier is considered to match the non-escaped version, unlike > > >VHDL). Once this is recognized, the reason for reserving the keywords > > >is bypassed. > > > > > > > > > > > >>I'm quite sympathetic to your motivations > > >>of wanting to limit keyword explosion, but this is a bit like trying to > > >>close the barn door after the horses have already left, no? > > >> > > >> > > > > > >With a strict interpretation of the current LRM, I would describe the > > >situation as "the barn door is open, but the horses have not left yet, > > >so we can safely close it". > > > > > >Reserving a keyword can create a backward compatibility problem. > > >Unreserving an unused keyword cannot. > > > > > >Every program that compiled with the keyword reserved will also compile > > >with it unreserved. The only problem is that it allows programs that > > >will be illegal if you reserve it in the future. But since the keywords > > >were not reserved before the 2001 standard, there are already plenty of > > >such programs. And having them reserved in the 2001 standard isn't really > > >helping if most tools aren't enforcing it. > > > > > >So while the interpretation that configs are not allowed in Verilog > > >source files does not automatically allow "config" as an identifier in > > >1364-2001, it means that allowing it as an identifier in 1364-2005 would > > >be backward compatible with 1364-2001. > > > > > >Steven Sharp > > >sharp@cadence.com > > > > > > > > > > > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > > <html> > > <head> > > <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> > > <title></title> > > </head> > > <body text="#000000" bgcolor="#ffffff"> > > Steven,<br> > > <br> > > Gee, thanks for the grammar lesson.<br> > > <br> > > My real point was that there was insufficient care and formality given > > to the BNF in the 2001 spec to be able to authoritatively conclude > > either interpretation. But then again, my major concern isn't whether > > the 2001 spec does or doesn't allow a config to appear in Verilog > > source. My major concern is that the config keywords remain in the > > keyword list for the upcoming 1364 specification. Whether the reason > > for doing so is that configs are intended to be in Verilog source > > today, whether it's to reserve that capability for the future, or > > whether its for the frankly insightful reason you mentioned below > > (minus the extended identifier silliness) isn't nearly as important to > > me (OK, I do prefer the 1st but I'm pragmatic).<br> > > <br> > > Other messages in this thread have suggested that configs were, in > > fact, intended to be part of Verilog source files. I guess you're > > arguing that this was botched and, rather than fix it for the next > > version of the spec, you'd like to drop it. Is this your position?<br> > > <br> > > -randy.<br> > > <br> > > Steven Sharp wrote:<br> > > <blockquote type="cite" > > cite="mid200504232307.j3NN7nI16343@quicksand.Cadence.COM"> > > <pre wrap="">Randy, > > > > A lot of the issues here are necessarily matters of opinion and > > judgement, and what the current LRM says is only one of the factors > > to be considered. However, it helps to establish any facts that > > we can. > > > > You wrote: > > </pre> > > <blockquote type="cite"> > > <pre wrap="">I've tried to go back and divine from where you derive your strong > > assertion "syntax boxes and BNF clearly specify that they cannot appear > > in Verilog source files". The best I could come up with is that > > source_text in A.1.3 and library_text in A.1.1 don't grammatically > > derive each other. Your view must therefor be that source_text cannot > > share a file with library_text, correct? I didn't find this restriction > > anywhere. > > </pre> > > </blockquote> > > <pre wrap=""><!----> > > This restriction does not have to be spelled out separately, any more > > than the rest of the meaning of the BNF notation does. It follows from > > the accepted definitions of formal language theory and the BNF notation. > > Note that there is no separate restriction saying that this email is > > not valid Verilog source either; that follows in the same way. > > > > A formal language is defined by a formal grammar and a start symbol. > > It consists of the set of all strings that can be derived from the > > start symbol using the grammar. The BNF in the LRM fails to specify > > the start symbol for Verilog source, though we can deduce from > > information outside the BNF that it is source_text. You could argue > > that some other start symbol should be used (thus defining a different > > language), and there is nothing in the BNF to contradict it. However, > > there is no start symbol that can be chosen that derives a string > > containing both a config and a module. Therefore we can state with > > certainty that no language defined by the BNF allows it. > > > > If someone wanted to define such a language, they could do so by > > modifying the BNF to specifically allow it. This BNF does not. > > > > You might instead be suggesting that when the syntax of a programming > > language is specified by a formal language, only a sub-string of the > > source input needs to be a valid string in the formal language. This > > is not the accepted convention, and it is easy to see why not. The > > formalism would lose its power to fully specify legal input. For > > example, any input would have to be accepted as Verilog source, since > > it contains a legal string as a sub-string (specifically, the empty > > string). > > > > </pre> > > <blockquote type="cite"> > > <pre wrap="">The keywords > > are already part of the 2001 specification. Whether you view > > configurations as allowable within a source file or not doesn't create > > the problem. The problem already exists. The keywords are part of the > > existing 1364-2001 standard. > > </pre> > > </blockquote> > > <pre wrap=""><!----> > > While I can come up with some arguments otherwise, I would have to > > agree with you that a strict interpretation of the LRM text supports > > this. All of the keywords in Annex B are reserved in both Verilog > > source files and library map files. > > > > </pre> > > <blockquote type="cite"> > > <pre wrap="">In fact, the inclusion of the configuration keywords in a > > common list of keywords in Appendix B would seem to support the > > conclusion that both grammars can share a common parse. > > </pre> > > </blockquote> > > <pre wrap=""><!----> > > If we move from strict interpretation to speculation, there are many > > possible conclusions. Annex B may simply contain a combined list of > > keywords from the two different source languages defined in the BNF, > > and may not intend to say that all are reserved everywhere. > > > > There is also a reason why you might want to reserve the library map > > file keywords in Verilog source files, even though they can never be > > used as keywords in a Verilog source file. If they are not reserved, > > then they are valid identifiers that can be used for a module name. > > However, that module name could not be referenced in a config, since > > it is a keyword there. Fortunately, it could be referenced by using > > the escaped version of the name (since in Verilog, the escaped version > > of an identifier is considered to match the non-escaped version, unlike > > VHDL). Once this is recognized, the reason for reserving the keywords > > is bypassed. > > > > </pre> > > <blockquote type="cite"> > > <pre wrap="">I'm quite sympathetic to your motivations > > of wanting to limit keyword explosion, but this is a bit like trying to > > close the barn door after the horses have already left, no? > > </pre> > > </blockquote> > > <pre wrap=""><!----> > > With a strict interpretation of the current LRM, I would describe the > > situation as "the barn door is open, but the horses have not left yet, > > so we can safely close it". > > > > Reserving a keyword can create a backward compatibility problem. > > Unreserving an unused keyword cannot. > > > > Every program that compiled with the keyword reserved will also compile > > with it unreserved. The only problem is that it allows programs that > > will be illegal if you reserve it in the future. But since the keywords > > were not reserved before the 2001 standard, there are already plenty of > > such programs. And having them reserved in the 2001 standard isn't really > > helping if most tools aren't enforcing it. > > > > So while the interpretation that configs are not allowed in Verilog > > source files does not automatically allow "config" as an identifier in > > 1364-2001, it means that allowing it as an identifier in 1364-2005 would > > be backward compatible with 1364-2001. > > > > Steven Sharp > > <a class="moz-txt-link-abbreviated" href="mailto:sharp@cadence.com">sharp@cadence.com</a> > > > > </pre> > > </blockquote> > > </body> > > </html> > >Received on Sun Apr 24 11:44:26 2005
This archive was generated by hypermail 2.1.8 : Sun Apr 24 2005 - 11:45:25 PDT