For Verilog configurations, the library mapping file rules state: 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. (32.3.3 combined draft, 13.2.3 1364-2005) How far does the consideration of the "source file" extend? For example, assume that one has a mapfile that directs a.v to lib_a, b.v to lib_b, etc. Clearly (to me), if you have: <compile command> a.v b.v the intent is for the contents of a.v to go to lib_a and b.v into lib_b. But what if you have some "ab.v" that says: `include "a.v" `include "b.v" and then do: <compile command> ab.v Would the file names of the *include* still direct where the contents of a.v and b.v should be targeted? Or is "ab.v" the only name that should be considered? Additionally, what if you have the contents of c.v being: module c; and the contents of d.v being endmodule Where does module "c" reside if one compiles as: <compile command> c.v d.v The "split module" case would also apply to modules defined via a `include of both c.v and d.v. I think that we should tighten up on the rules here a bit. If people have definite suggestions, I'd like to get those on the table. What I would suggest is something along the following lines: 1) for the purposes of a lib.map file, the contents of `include files are considered to be part of the including file 2) in determining the target library for a cell, the file in which the cell name occurs shall be used. If this sounds reasonable to everyone, I can add a Mantis item and proposal. If anyone has a different set of rules, please post them and we can figure out which way we want to go. Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jul 11 07:44:22 2007
This archive was generated by hypermail 2.1.8 : Wed Jul 11 2007 - 07:44:32 PDT