Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
veripoolbot opened this issue Jul 21, 2019 · 2 comments
Closed
Labels

Comments

@veripoolbot
Copy link
Collaborator


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
Copy link
Collaborator Author


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
Copy link
Collaborator Author


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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant