Skip to content

VIO and ILA: explicitly check setName#2662

Open
DigitalBrains1 wants to merge 1 commit into
masterfrom
explicit-name
Open

VIO and ILA: explicitly check setName#2662
DigitalBrains1 wants to merge 1 commit into
masterfrom
explicit-name

Conversation

@DigitalBrains1

Copy link
Copy Markdown
Member

If Clash.Magic.setName was used, use that name for the instance. Otherwise, use a fixed default name.

Fixes #2654

Still TODO:

  • Write a changelog entry (see changelog/README.md)
  • Check copyright notices are up to date in edited files

If `Clash.Magic.setName` was used, use that name for the instance.
Otherwise, use a fixed default name.

Fixes #2654
@martijnbastiaan

Copy link
Copy Markdown
Member

Interesting! Didn't know this was a thing. Should we add a netlist output regression test?

@martijnbastiaan martijnbastiaan left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But in general LGTM!

ilaBBF :: HasCallStack => BlackBoxFunction
ilaBBF _isD _primName args _resTys = Lens.view tcCache >>= go
ilaBBF _isD _primName args _resTys = do
instName <- fromMaybe "ila_inst" <$> Lens.view setName

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
instName <- fromMaybe "ila_inst" <$> Lens.view setName
instName <- fromMaybe "ila_inst" <$> traverse affixName (Lens.view setName)

The above really is just a suggestion. Normally we add suffixes and prefixes to setName. I know this is not what we want for ILAs, but now the ILA is the odd one out with regards to setName.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I agree, this was a simple oversight. This is not the place to strip affixes; if we want to do that, we should do it elsewhere.

@DigitalBrains1

DigitalBrains1 commented Feb 8, 2024

Copy link
Copy Markdown
Member Author

Should we add a netlist output regression test?

What exactly would it test; that it doesn't regress to issue #2654? So, in essence that the netlist output should not contain __VOID_TDECL_NOOP__ anywhere?

My tired brain won't come up with an analysis how useful this is, so I'm just going to go with your opinion. If you want it, I'll write it.

@christiaanb

Copy link
Copy Markdown
Member

Should we add a netlist output regression test?

What exactly would it test; that it doesn't regress to issue #2654? So, in essence that the netlist output should not contain __VOID_TDECL_NOOP__ anywhere?

My tired brain won't come up with an analysis how useful this is, so I'm just going to go with your opinion. If you want it, I'll write it.

We already have HDL tests that check whether something is not in the generated HDL:

assertNotIn needle haystack

So I guess it could work like that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

__VOID_TDECL_NOOP__ is not correctly matched

4 participants