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.

Sign up for GitHub

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

Jump to bottom

Generated Verilog should be more readable #98

Open
whitequark opened this issue Jun 11, 2019 · 5 comments
Open

Generated Verilog should be more readable #98

whitequark opened this issue Jun 11, 2019 · 5 comments
Labels
backend:verilog improvement upstream

Comments

@whitequark
Copy link
Contributor

This is solely blocked on Yosys issue YosysHQ/yosys#726. It's in my queue for some time, but the threshold for merging it is fairly high (multiple days of randomized testing), so I haven't been able to push it to completion yet.
@mithro
Copy link

mithro commented Jun 11, 2019

@whitequark Would having access to a bunch of CPU resources help with the randomized testing?

@whitequark
Copy link
Contributor Author

@mithro It's kind of a pain to set up VlogHammer in the first place. I think I can use the M-Labs machine for testing that once I have a general confidence in the correctness of the changes to that pass.

@whitequark whitequark added this to the 0.1 milestone Jun 28, 2019
whitequark added a commit that referenced this issue Jul 2, 2019
back.rtlil: do not emit $next wires for comb signals.
dd5e513 
According to RTLIL semantics (that was undocumented before today),
the only purpose of `sync always` is to enable inference of latches,
because there is no other way to express them in terms of RTLIL
processes without ending up with a combinatorial loop. But, nMigen
specifically avoids latches, so this is not necessary.

This change results in major improvements in Verilog readability.

See also #98.
@whitequark
Copy link
Contributor Author

whitequark commented Jul 14, 2019 •
edited

Would having access to a bunch of CPU resources help with the randomized testing?

Actually, what kind of resources can you provide? If it's something monstrous like a 64-core machine I'd be interested. VlogHammer is embarrassingly parallel, so it pays off to use a huge number of slower cores.

@mithro
Copy link

mithro commented Jul 15, 2019

I could provide pretty much anything on the list at https://cloud.google.com/compute/docs/machine-types

Anything like the following might work?

  • n1-standard-96
  • n1-highmem-64
  • n1-highcpu-96

@whitequark whitequark removed this from the 0.1 milestone Jul 31, 2019
@whitequark
Copy link
Contributor Author

Fixing YosysHQ/yosys#726 proved to be extraordinarily complex, so bumping this from 0.1 milestone.

Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backend:verilog improvement upstream
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mithro @whitequark