cornell-brg / pymtl

Python-based hardware modeling framework
BSD 3-Clause "New" or "Revised" License
237 stars 82 forks source link

explicit_modulename doesn't work for a very simple verilog import #153

Open jsn1993 opened 8 years ago

jsn1993 commented 8 years ago

I'm trying to specify explicit_modulename in a verilog pymtl wrapper, and I found a problem that has something to do with our verilog import. The way we do verilog import in pymtl is that we append a piece of code at the beginning of the verilog wrapper. In the following example, when I specify explicit_modulename = "Adder", there will be error.

// this part is added by pymtl
//+++++++++++++++++++++
module Adder
(
...
);

  // Imported Verilog source from:
  // <path>/<to>/Adder.v

  Adder#(
  )  verilog_module
  (
...
  );
endmodule
//---------------------
// the below part is the verilog file
module Adder(
...

You can simply see the problem: the explicit_modulename is used as the verilog wrapper module name, and it is the same as the actual module name.

I remember when Prof. Batten added this feature to pymtl, the situation was that students are getting inconsistent hash values for a pmx combination.

class ProcMemXcel ( Model ):
  def __init__( s, modulename, ProcModel, MemModel, XcelModel ):
    s.explicit_modulename = modulename

In the above situation, the explicit_modulename is probably different from the verilog (if there is) module name of proc, mem, and xcel, so it works.

cbatten commented 8 years ago

Is there a use case when you need to use explicit_modulename in this context? In other words, PyMTL does the right thing if we just don't use explicit_modulename here, correct? explicit_modulename is really meant for Verilog export as opposed to Verilog import, right?

jsn1993 commented 8 years ago

When I pushed the verilog through the flow, I was just thinking that the hash suffix looks messy in Makefrag.

cbatten commented 8 years ago

Ah -- I see. You could always use explicit_modulename = AdderWrapper?