Configs & Modules in separate files - was: potential command line option

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Sun Apr 24 2005 - 10:15:05 PDT

  • Next message: Clifford E. Cummings: "Config-keyword work-around - was: potential command line option"

    Hi, All -

    New subject line to separate out the issues.

    At 01:34 AM 4/24/2005, 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, ...

    I absolutely agree and I teach it this way in Advanced Verilog training
    classes.

    >... 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.

    I agree that configs should be in separate files and thinking back on why I
    wrote the BNF the way I did is because I did not want to infer that modules
    could be nested in configs and configs could not be nested in modules. I
    still wanted both configs and modules to be read in the same Verilog input
    stream. Mea culpa!

    The best evidence I can offer to show that config, endconfig and library
    were intended to be read in the Verilog input stream is the Draft-4 Annex B
    of the Verilog-2001 Standard that I sent with my email dated 4/21/2005. In
    that annex, we clearly showed that config, endconfig and library were
    intended to be Verilog keywords while all other config and library-related
    keywords were separated into their own keyword lists. Per vendor requests,
    we combined the keywords in Draft-5.

    Any vendor following the draft standards for Verilog-2001 could very easily
    conclude from Draft-4 that configs and library's should be read in the
    Verilog input stream, especially since combining the keywords in Draft-5
    did not add any text anywhere prohibiting configs from being in the same
    files as a module. I believe ModelSim, as described by Randy, has correctly
    implemented the intended functionality.

    >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?

    I see no great compelling reason to include configs and modules in the same
    file (small exception described below). I do however see some very
    compelling reasons to include configs and modules in the same Verilog input
    stream. Having them in the same input stream gives me a powerful way to
    eliminate the need for -y -v +libext+.v+ and many of my -f file-list
    command line switches without the need to add new command line switches to
    accomplish the same goal. Passing a config file to my tool tells my tool
    which files I want to assign to which modules or which instances of modules
    for this configuration of my simulation. That is the intent and value.

    Verilog also allows you to start a Verilog module in one file, continue the
    module in a second file, and finish the module in a third file, and then
    you must compile the files in the correct order, but it will work (EOF is
    just considered to be white space). I tell my students that, "if I EVER
    catch you doing this, I will take back your course completion
    certificate!!" (use a stern parental tone while uttering these words!)

    For 99% of real designs, engineers will separate configs from modules
    without even being told to do so.

    I also separate 99% of all Verilog testbenches from my Verilog design
    files, but there is the occasional testing of a concept where I throw both
    testbench and design into the same file, just so I can quick compile and
    test. I imagine I might do the same thing with configs to quick-compile and
    quick-test a concept. Throwing config, testbench and design into the same
    file is also a convenient way to pass an idea to a colleague for
    experimentation or to pass a bug to a vendor for testing.

    Hope this helps.

    Regards - Cliff

    ----------------------------------------------------
    Cliff Cummings - Sunburst Design, Inc.
    14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
    Phone: 503-641-8446 / FAX: 503-641-8486
    cliffc@sunburst-design.com / www.sunburst-design.com
    Expert Verilog, SystemVerilog, Synthesis and Verification Training

    This archive was generated by hypermail 2.1.4 : Sun Apr 24 2005 - 09:56:07 PDT and
    sponsored by Boyd Technology, Inc.