-
Notifications
You must be signed in to change notification settings - Fork 154
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
Clash generates invalid verilog names #2845
Comments
christiaanb
added a commit
that referenced
this issue
Nov 18, 2024
The global vars are usually backed by a clock generator that are not work-free. In addition, when these global vars are recursively defined, they can mess up the post-normalization flattening stage which then violates certain invariants of the netlist generation stage. This then causes the netlist generation stage to generate bad Verilog names. Fixes #2845
2 tasks
christiaanb
added a commit
that referenced
this issue
Nov 18, 2024
The global vars are usually backed by a clock generator that are not work-free. In addition, when these global vars are recursively defined, they can mess up the post-normalization flattening stage which then violates certain invariants of the netlist generation stage. This then causes the netlist generation stage to generate bad Verilog names. Fixes #2845
DigitalBrains1
pushed a commit
that referenced
this issue
Dec 1, 2024
The global vars are usually backed by a clock generator that are not work-free. In addition, when these global vars are recursively defined, they can mess up the post-normalization flattening stage which then violates certain invariants of the netlist generation stage. This then causes the netlist generation stage to generate bad Verilog names. Fixes #2845
DigitalBrains1
pushed a commit
that referenced
this issue
Dec 7, 2024
The global vars are usually backed by a clock generator that are not work-free. In addition, when these global vars are recursively defined, they can mess up the post-normalization flattening stage which then violates certain invariants of the netlist generation stage. This then causes the netlist generation stage to generate bad Verilog names. Fixes #2845 (The PR on master was malformed somehow, with the correct contents but missing the commit message above and an incorrect Git structure. This backport to 1.8 is reconstructed by hand.)
DigitalBrains1
added a commit
that referenced
this issue
Dec 7, 2024
The global vars are usually backed by a clock generator that are not work-free. In addition, when these global vars are recursively defined, they can mess up the post-normalization flattening stage which then violates certain invariants of the netlist generation stage. This then causes the netlist generation stage to generate bad Verilog names. Fixes #2845 (The PR on master was malformed somehow, with the correct contents but missing the commit message above and an incorrect Git structure. This backport to 1.8 is reconstructed by hand.) Co-authored-by: Christiaan Baaij <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracking the invalid name generation in a separate issue
The first variant is without
NOINLINE cntr
:This generates the following Verilog:
Duplicate.hs Verilog
Al least the following things are duplicated:
along with 2 instead of 1 clock primitive, and 2 register blocks for
cntr
instead of 1.[edit]
I noticed I could get rid of the second clock and still have the duplication. The one with the second clock might still be interesting because of other weirdness, such as the
done
signal in HDL beingnot <$> done
in Haskell?This is output generated by the following code:
Originally posted by @DigitalBrains1 in #2570 (comment)
The text was updated successfully, but these errors were encountered: