Skip to content

Conversation

seldridge
Copy link
Member

@seldridge seldridge commented Jul 8, 2025

This is two logical commits:

  1. Remove BlackBoxResourceFileNameAnno since this has not been load beagin
    after it was removed from Chisel [1]. This annotation was used to control
    the name of a file which was produced that listed all blackboxes in the
    design. Instead, use the default name always.

  2. Completely remove the generation of the vestigial
    firrtl_black_box_resource_files.f. This file is intended to be unused by
    downstream flows.

@seldridge seldridge requested a review from darthscsi as a code owner July 8, 2025 17:12
Copy link
Contributor

@fabianschuiki fabianschuiki left a comment

Choose a reason for hiding this comment

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

Awesome! CIRCT 1 : Bit-Rot 0.

seldridge added 2 commits July 8, 2025 14:33
Remove `BlackBoxResourceFileNameAnno` since this has not been load beagin
after it was removed from Chisel [[1]].  This annotation was used to
control the name of a file which was produced that listed all blackboxes
in the design.  Instead, use the default name always.

Note: I plan to remove this file entirely in a follow-on as this appears
to be completely unused.

[1]: chipsalliance/chisel@70f5c70

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Remove the generation of `firrtl_black_box_resource_files.f`.  This file
was originally controllable by the `BlackBoxResourceFileNameAnno`, but
that has since been removed.  This file is, additionally, no longer load
bearing and can be completely dropped.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
@seldridge seldridge force-pushed the dev/seldridge/firrtl-remove-BlackBoxResourceFileNameAnno branch from ade0d90 to c7e10d7 Compare July 8, 2025 18:46
@seldridge seldridge merged commit c7e10d7 into main Jul 8, 2025
3 checks passed
@seldridge seldridge deleted the dev/seldridge/firrtl-remove-BlackBoxResourceFileNameAnno branch July 8, 2025 18:46
@tymcauley
Copy link
Contributor

@seldridge after removing firrtl_black_box_resource_files.f, what is the intended way to get the list of black-box files produced by firtool?

@seldridge
Copy link
Member Author

seldridge commented Jul 8, 2025

@tymcauley: Do you need to know the names of any of the generated blackboxes given that these will always show up in one of the output build directories?

I.e., BlackBoxPathAnno is a way of telling CIRCT to copy some file into another file relative to the output directory. BlackBoxInlineAnno is a way of having verbatim text written to a file relative to the output directory. Given this, the build system should be able to do a file glob of the know build areas to get all blackboxes generated in this way.

Note: I'm spitballing this here as I dropped this without much concern for existing users. 😬 Are you using this currently and how are you using it?

@tymcauley
Copy link
Contributor

Ya, I just need to know the names of those generated blackbox files. Right now, they're showing up in my output directory along with all of the other generated SystemVerilog files. I'm using a build system similar to what Chipyard does: https://github.com/ucb-bar/chipyard/blob/973f8732d4ffeb8cc231edf109e84eef114e3d6e/common.mk#L188

Is there a way to place all of the blackbox files defined in Chisel into a subdirectory of the firtool output area?

@seldridge
Copy link
Member Author

Is there a way to place all of the blackbox files defined in Chisel into a subdirectory of the firtool output area?

firrtl.transforms.BlackBoxTargetDirAnno sets this. (You could alternatively do something in Chisel to setup the blackbox directory for all the annotations, though that may be really annoying.) Using this, you should be able to duplicate the behavior with a file glob or ls.

Note: I am entirely fine with reverting this if we need to! However, if dropping this shakes out a simpler solution with fewer ways of doing things that would be good. 😉

@tymcauley
Copy link
Contributor

Okay, that annotation looks like it should do the trick, thanks! For the path provided in that annotation, can it be a relative path, and I'm assuming it would be relative to wherever firtool is executed from?

@seldridge
Copy link
Member Author

Yes, it can be relative. It should be relative to the -o path, not necessarily the path where firtool is executed from.

@seldridge
Copy link
Member Author

This breaks upstream Chisel as it relies on this file to find blackboxes through logic here: https://github.com/chipsalliance/chisel/blob/177579fe6159217b607d898ee5180445627a4427/src/main/scala/chisel3/simulator/package.scala#L236

I will plan to update svsim so that this will continue to work. svsim really shouldn't be relying on these undocumented filelists.

@tymcauley
Copy link
Contributor

I also ran into #8672 while trying to experiment with firrtl.transforms.BlackBoxTargetDirAnno.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants