Mode enum

[Jingyi99]

Issue: #400
I was not entirely sure where to put the mode enum class so I put it in hammer_tool.py. I can move it if there is a better place.
I will modify the string comparisons and open another PR if this enum class looks good.

[edwardcwang]

Thanks for your contribution! I left a comment below about this enum.

[edwardcwang]

As far as I'm aware, the modes we use are:

    Auto = 1
    Empty = 2
    Manual = 3
    Generated = 4

append, prepend are part of another part of Hammer and not part of this mode enum.

Also, if we are going to create this enum, I think it may be good to also use them in some of the settings.

[jwright6323]

We should change power straps to generated from generate if we're going to use generate. I personally like generate better, but generated does keep all of the modes as adjectives, which also makes sense.

[edwardcwang]

Yeah, maybe we can do that as a separate issue then?

[jwright6323]

We can just tack it on to #397 .

[Jingyi99]

Hi Edward, thanks for your comment! I checked defaults.yml and it seems that pin place mode uses generated, and power straps mode uses generate. Just to make sure, they are the same and we'll stick with generate, right?
Also, I'm not sure what it means to use the enum in the settings, could you explain a bit more?

[jwright6323]

Hi Jingyi- let's use generated instead of generate. We'll change the power straps mode to generate.

[edwardcwang]

Yeah, so John's comment above is alluding to that problem. I think the desired action is to use generated and just ignore the power straps mode for now.

As for use, if you look in the code, right now it uses strings - the intention is to use this enum instead

hammer/src/hammer-vlsi/hammer_vlsi/hammer_tool.py

Line 896 in 8bcbc40

if bumps_mode == "empty":

[Jingyi99]

It seems like I broke something...

[edwardcwang]

For type hinting comments, let's keep them proper

[edwardcwang]

ditto

[edwardcwang]

ditto

[jwright6323]

We may want to create a static helper method called ModeType.from_setting that takes the HammerTool object and the setting string as args and returns a ModeType. e.g.

class ModeType:
  @staticmethod
  def from_setting(tool: HammerTool, setting: str) -> ModeType:
    return ModeType.from_str(str(tool.get_setting(setting)))

which would then allow the following change (no need for type hint, either):

Suggested change

	gds_map_mode = ModeType.from_str(str(self.get_setting("par.inputs.gds_map_mode"))) # type: ModeType
	gds_map_mode = ModeType.from_setting(self, "par.inputs.gds_map_mode")

[edwardcwang]

Not to nitpick too much - at that point I would prefer almost gds_map_mode = self.get_mode_setting("par.inputs.gds_map_mode") to avoid a dependency from ModeType -> HammerTool

[jwright6323]

I also like that, perhaps more.

[Jingyi99]

Sorry for introducing bugs. The errors in the unit tests are

File "/buildbot/run_unittests/build/src/hammer-vlsi/hammer_vlsi/hammer_tool.py", line 1135, in HammerTool
  def get_mode_setting(self, setting: str) -> ModeType:
NameError: name 'ModeType' is not defined

Is it potentially because I was not importing properly?
Also, are there any units tests that I can run locally?
Thanks!

[jwright6323]

Hi Jingyi- you can run the unittests in src/test/unittests.sh: https://github.com/ucb-bar/hammer/blob/master/src/test/unittests.sh
You cal also run the typechecker by running the mypy_with_exclusions.sh script