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

build/efinix/common.py: ClkInput: added ClockSignal support #2075

Merged
merged 2 commits into from
Sep 19, 2024

Conversation

trabucayre
Copy link
Collaborator

@trabucayre trabucayre commented Sep 18, 2024

ClkInput specials is currently only uses as PLL's clkin. The current approach is to uses a string for create_clkin. This way is valid because both ClkInput's o name and PLL's clkin must match at iface level and nothing is known in a generated verilog file. But when this specials is used for a ClockDomain this way is no more valid and it's requires to connect .o to the ClockSignal.
The first commit address this limitation by allowing the use of a ClockSignal, converted to a signal when the class contructor is called. In this situation, the constructor adopt the same approach done for PLL's create_clkout method. string is kept as backward compatibility to avoid breaking all existing code.

Second commit address another issue: when a gpio out (ddio f.i.) is used through specials: ClockSignal is resolved and the Signal contains an name_override attribute. But when this primitive is instanciated directly by a module, cd remains a ClockSignal and conversion between signal and name must be done in ifacewriter script. Also the ClockSignal only provides ClockDomain name (not resolved) so a first search for the name is done, but if no results are found: the _clk suffix is added to the name.

@enjoy-digital
Copy link
Owner

Thanks @trabucayre!

@enjoy-digital enjoy-digital merged commit baff4c6 into enjoy-digital:master Sep 19, 2024
1 check passed
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