veripool / verilog-mode

Verilog-Mode for Emacs with Indentation, Hightlighting and AUTOs. Master repository for pushing to GNU, verilog.com and veripool.org.
http://veripool.org/verilog-mode
GNU General Public License v3.0
253 stars 90 forks source link

Question: Preferred method for dealing with vendor-library primitives #1472

Closed veripoolbot closed 5 years ago

veripoolbot commented 5 years ago

Author Name: Berk Akinci Original Redmine Message: 3027 from https://www.veripool.org


Hi, Do you have a recommended way of dealing mixing Verilog AUTOs with 'black box' vendor library primitives?

Something overly-simplified like:

module edge_clock
  ( output clk_edge,
     input  clk_pll,
     input  reset_l
  );

  /*AUTOREG*/

  ECLKSYNCA eclksynca_inst
     ( // Outputs
       .ECLKO(clk_edge),
        // Inputs
       .ECLKI(clk_pll),
       .STOP(!reset_l)
       );

endmodule

AUTOs insists on declaring a reg for clk_edge. If I use AUTOINST in the module instantiation, I'll have to start making dummy declarations for the primitives. I acknowledge AUTOREG isn't necessary since I use Verilog 2001 ports. I've gotten to the habit of using it to alert me of forgotten connections.

veripoolbot commented 5 years ago

Original Redmine Comment Author Name: Wilson Snyder (@wsnyder) Original Date: 2019-08-03T12:05:22Z


Been thinking about this for a while and I don't have a straightforward solution. Best I thought of was an /AUTOINSTOFF/ which would trigger the routine that looks for // Output comments, however that didn't work because verilog-mode must still read the submodule to determine types of the outputs. Sorry.

veripoolbot commented 5 years ago

Original Redmine Comment Author Name: Berk Akinci Original Date: 2019-08-08T13:42:16Z


Hi Wilson,

Thanks for thinking about it.

I've also thought about it some. In case it helps, I'll let others know the conclusion I came.

I welcome suggestions and comments; I'd rather hear them now then clean up a mess later.

I decided to bite the bullet and copy the vendor primitive library stubs to a place accessible in the project. I haven't done it just yet, but it's essentially the same thing I've had to do for other (non-primitive) vendor IP. In the case of vendor primitive library, I found the stub file with quick log inspection. It's one file with all primitives, name @devicename.v@, but it should be trivial to use your vsplitmodule to expand that into a directory full of primitives. This file is highly unlikely to change, so keeping in sync shouldn't be a problem.

My vendor-IP solution goes something like this...

In the project, there is:

./Vendor_IP/some_ip/

some_ip comes with @some_ip_stub.v@ provided by the vendor.

I create a directory:

./Vendor_IP/__stubs/

I create a symlink to fix the module-name file-name mismatch.

ln -sf ./Vendor_IP/some_ip/some_ip_stub.v ./Vendor_IP/__stubs/some_ip.v

(The version control system (Git in my case) handles the symlink just fine.)

I include the @./Vendor_IP/__stubs@ directory in my @modulepathflags.vc@. Verilog-AUTOs finds the stub and all works as I expect.