Verilog import fails in macro substitution about bsc HOT 2 OPEN

Oh wow. Yeah, this is a combination of a number of quirks, that come together to cause trouble. Sorry for that.

It may be best to just write a script external to BSV which generates the BSV imports for all the modules. You could also see if the BH syntax allows expressing it better than BSV. But if you do want to try expressing this entirely in BSV, one workaround that I found is this:

`define BIND_FIFOF(uniqueid, vmodule, bitwidth) \
`line(BIND_FIFOF,uniqueid,1,1) \
        import "BVI" vmodule = \
...

`BIND_FIFOF(1, FIFO1, 8)
`BIND_FIFOF(2, FIFO1_16, 16)

I tried to make the unique ID implicit, by making it a macro definition that gets updated each time you call BIND_FIFOF, but ran into difficulties putting a define inside a define (and I'm not sure if that's just a limitation of the SVpp syntax or of BSC's implementation). But being able to control the position with a uniqueid argument does allow you to give distinguishing position information to each macro call, which could be helpful if you did get an error message pointing to the inside of the macro.

BSV's import-BVI syntax is really a wrapper around the very limited import that BSC supports in its internal representation. If you import a Verilog module into BSV with name mkMod and interface Ifc, what is generated in BSC's internal representation is: (1) a mkMod_raw which imports the Verilog into a raw interface Ifc_raw and (2) a wrapper module mkMod which instantiates mkMod_raw and converts its interface into Ifc. I used the names _raw for illustration, but it looks like BSC is using the position information to create the unique names. And that breaks when using macros that cause multiple imports to have the same position.

In BH, the import of raw Verilog is an expression. BH users currently have to manually write the wrapper around an import. But this does provide extra flexibility, because the import is an expression, which can appear inside code, like functions. So you might be able to do this in BH using an ordinary function in place of the macro call. There are some features that BSV provides that BH's import does not (yet), around multiple clocks I think, but it looks like you're not doing anything advanced, so BH syntax might be sufficient. (Note that the wrapper does also include some additional internal code for recording the types of ports and user names, etc, which would need to be manually replicated if written in BH.)

The BH import syntax even lets you construct the string for the Verilog module name, which BSV doesn't. So for example, this would be how to import multiple RegUN modules:

interface VReg n =
    write :: Bit n -> PrimAction
    read :: Bit n

mkVImport :: Module (VReg n)
mkVImport =
  let modname = "RegUN_" +++ integerToString (valueOf n)
  in
    module verilog modname "CLK" {
        read = "Q_OUT"{reg};
        write = "D_IN"{reg} "EN";
    } [ read <> read,
        read < write,
        write << write ]

mkImport :: (IsModule m c, Bits a sa) => m (Reg a)
mkImport = liftModule $
    module
      _r :: VReg sa
      {-# hide #-}
      _r <- mkVImport
      let name = Valid (primGetModuleName _r)
      let t = typeOf (_ :: a)
      primSavePortType name "D_IN" t
      primSavePortType name "Q_OUT" t
      interface
        _read = unpack _r.read
        _write x = fromPrimAction (_r.write (pack x))


mkRegUN8 :: Module (Reg (Bit 8))
mkRegUN8 = mkImport

mkRegUN16 :: Module (Reg (Bit 16))
mkRegUN16 = mkImport

In your case, the imported interface would seem to already be in raw form, so maybe BSC doesn't need to create Ifc_raw. I guess we could enhance BSC to detect this situation and not create a raw interface when not needed. But actually, I think that Action is not in raw form, so there would still need to be a wrapper that converts between PrimAction and Action. It may be possible that BSC's internal representation could be extended to include all the wrapper stuff inside the import construct, so that new definitions aren't needed. But I'm not sure if that's really possible -- at some point the construct will need to be expanded into the wrapper code. But maybe if the expansion is done after type-checking, then it can avoid having to create new names.

There is already an open issue #386 asking to enhance the preprocessor to keep a stack of the multiple positions that result from macro calls. If that was supported, then the Ifc_raw name could possibly be made more unique by using the multiple positions.

There may also be other ways to create unique names. But I think the line number was used because it helps the user connect the identifer back to their source code, if they saw it in a message from the compiler.

from bsc.

Thank you for the elaborate reply! For now I will stick with the macro workaround. Once I get more into BH I may switch to the BH variant. I really like that you can construct the Verilog module name as string and pass it to the import.

from bsc.