-
Notifications
You must be signed in to change notification settings - Fork 155
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
base: master
Are you sure you want to change the base?
Conversation
If `Clash.Magic.setName` was used, use that name for the instance. Otherwise, use a fixed default name. Fixes #2654
Interesting! Didn't know this was a thing. Should we add a netlist output regression test? |
There was a problem hiding this 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
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.
What exactly would it test; that it doesn't regress to issue #2654? So, in essence that the netlist output should not contain 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:
So I guess it could work like that? |
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)