• Top
    • Documentation
    • Books
    • Recursion-and-induction
    • Boolean-reasoning
    • Projects
    • Debugging
    • Std
    • Proof-automation
    • Macro-libraries
    • ACL2
    • Interfacing-tools
    • Hardware-verification
      • Gl
      • Esim
      • Vl2014
      • Sv
      • Vwsim
      • Fgl
      • Vl
        • Syntax
        • Loader
          • Preprocessor
          • Vl-loadconfig
          • Vl-loadstate
          • Lexer
          • Parser
          • Vl-load-merge-descriptions
          • Vl-find-basename/extension
          • Vl-load-file
          • Vl-loadresult
          • Vl-find-file
          • Scope-of-defines
            • Vl-flush-out-descriptions
            • Vl-description
            • Vl-read-file
            • Vl-includeskips-report-gather
            • Vl-load-main
            • Extended-characters
            • Vl-load
            • Vl-load-description
            • Vl-preprocess-debug
            • Vl-descriptions-left-to-load
            • Inject-warnings
            • Vl-read-file-report-gather
            • Vl-write-preprocessor-debug-file
            • Vl-load-descriptions
            • Vl-load-files
            • Translate-off
            • Vl-load-read-file-hook
            • Vl-loadstate-pad
            • Vl-read-file-report
            • Vl-load-summary
            • Vl-collect-modules-from-descriptions
            • Vl-loadstate->warnings
            • Vl-iskips-report
            • Vl-descriptionlist
          • Warnings
          • Getting-started
          • Utilities
          • Printer
          • Kit
          • Mlib
          • Transforms
        • X86isa
        • Svl
        • Rtl
      • Software-verification
      • Testing-utilities
      • Math
    • Loader

    Scope-of-defines

    How VL and other tools handle the scope of `defines.

    What is the scope of a `define?

    Until the end of 2009, we treated `defines as having file-scope, and processed every file using only the initial defines to begin with. But now we are treating `defines as cumulative, allowing them to spill over from one file into the next. This is convenient in that it allows us to see what defines have been encountered, and hence we can programmatically extract the values associated with particular `define symbols.

    This is scary. The order of file loading is not especially predictable when vl-flush-out-descriptions is used, so different things might happen depending on which files happen to get loaded first!

    Well, our behavior appears to be at least similar to what other Verilog tools do. We found that, on both Verilog-XL and NCVerilog,

    • `defines that occur before an `include do seem to carry over into the included file.
    • When we give the tool multiple files, e.g., verilog foo.v bar.v or ncverilog foo.v bar.v, the includes from the earlier files do carry over to the later files. Hence, switching the argument order can affect simulation results.
    • `defines that occur in the main files (those that are given as explicit command line arguments) are indeed carried over into library files
    • `defines from earlier-loaded library files are carried over into later-loaded library files.

    Our behavior is approximately the same. However, it seems very likely that our particular way of loading missing descriptions with vl-flush-out-descriptions will be at least somewhat different from how other tools look for missing descriptions. Roughly, after parsing the main files, we figure out what descriptions are missing and try to load them in alphabetical order. Other tools probably use different orders and may produce very different behaviors.

    BOZO we could probably defend against this by tracking which ifdef tests have ever been considered and what their values are. If we find that two files have ever done an ifdef and gotten different results, we could add a warning that maybe something is amiss with file loading.