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

VIO and ILA: explicitly check setName #2662

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

DigitalBrains1
Copy link
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
Member

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

Copy link
Member

@martijnbastiaan martijnbastiaan left a comment

Choose a reason for hiding this comment

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

But in general LGTM!

@@ -148,15 +148,18 @@ areEqual :: Eq a => [a] -> Maybe a
areEqual = \case { [x:_] -> Just x; _ -> Nothing } . group

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

DigitalBrains1 commented Feb 8, 2024

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
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
3 participants