Skip to content

Conversation

dlmiles
Copy link
Contributor

@dlmiles dlmiles commented Sep 19, 2025

Totally untested at PR time will update on status, after this has been tested.

Doing:

`ifdef SIM
   $info("Hello World");
`endif

`ifndef OPENLANE_SYNTHESIS
   $info("Hello World");
`endif

With config.json setup VERILOG_DEFINES = [ "OPENLANE_SYNTHESIS" ]

Causes the TT check_ports() to fail. The flow itself works fine.

The ASIC flow has config.json that a user can provide but Yosys can
also need globals options, particularly with Verilog pre-processor
defines so the Verilog source can be shared between ASIC and FPGA
allowing for example ASIC/FPGA target specific cells to be
added/removed from design.
@urish
Copy link
Member

urish commented Sep 19, 2025

Thanks! I'm not sure we'll actually keep check ports the way it is - it will probably make more sense to implement it as a LibreLane step, or so.

--create-user-config uses Yosys to extract ports, but did not inherit
config.json VERILOG_DEFINES when it does this step.  So the source
view that is presented is completely different to that of the ASIC
flow.  Which would have otherwise worked successfully.

This means if Verilog expressions not compatible or necessary for
main flow were correctly ifdef/endif the flow would still fail due
to the TT --create-user-config step bailing.

It maybe necessary for users to manually add SYNTHESIS to their
VERILOG_DEFINES list so that is added for this custom TT step.
No attempt is made to mimic implicitly added defines, as that will
always play catchup.  It would be completely compatible with all
systems to have the user just be explicit about it if that is
needed for their project.

This commit provides the option to achieve a good configuration
without needing to customize verilog source code (by manually
doing the task of ifdef/endif and committing what is left).
@dlmiles dlmiles force-pushed the ttsky25a-check-port-defines-fix branch from 0c85eaa to 7959507 Compare September 19, 2025 17:56
@dlmiles
Copy link
Contributor Author

dlmiles commented Sep 19, 2025

Yes that would be a better solution, so it has the same project settings and source view as the actual flow.

I'm just about to see if I can add a custom flow+yosys plugin to implement/ignore the $info/$warning by providing a no-operation callout etc... but also to remove/ignore by default the assert() which appears transformed to $check cell for formal but when running flow for synthesis it should be ignored as a non-synthesis expression.

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.

2 participants