-
Notifications
You must be signed in to change notification settings - Fork 58
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
Finding out what resources an nMigen module uses in the output design #289
Comments
This is unfortunate behaviour, but when it happens it generally means you have a pretty major logic bug. The best way to catch these is through simulation and a healthy dose of paranoia.
My personal approach here is to use
Here,
I'll admit Yosys does produce a lot of noise here, but there are useful things inside of it: the
Your Yosys could be a little old; Yosys added an |
@ZirconiumX's suggestion of the Their suggestion of using simulation (or property testing) to catch logic bugs is also good.
The FF numbers are final because nextpnr doesn't duplicate FFs currently (and most toolchains don't do it by default). The LUT and carry numbers aren't quite final because of legalization, but they are very close and I would say you don't need to look at nextpnr report. In general unfortunately the issues you highlight are valid but they are not something nMigen can fix as it is at the mercy of the synthesis tool. For example, Lattice Diamond prints why it removed some cell or net each time it does so. |
Thank you both for your responses!
I was using the 0.9 release, so I just tried building and installing the newest version. That is SO much better, thank you!
Oh yes! I used that BRAM pass output to figure out why my 256-byte RAM wasn't really a RAM, haha. But sometimes the "efficiency" is too low and it uses DFFs anyway, and I'm not sure why... maybe you know?
Yeah, I've mostly just gone in with guns blazing and tested with my ears (it's a little synthesizer). I'm still very new to hardware design and haven't learned the best practices for development yet. :D
That's pretty much EXACTLY what I was looking for! Thanks! I can already see some places where I need to look more closely at what's going on.
Right, I figure this is mostly out of nMigen's hands. But I'm glad I was able to ask here and get some good answers. :) I'll close this now since it was just a question. Thanks again! |
BRAMs are a limited resource; if Yosys converted every pair of registers with a mux into a BRAM, you'd quickly exhaust them all. Worse, currently it does not even know how many are available in any given FPGA. Also, using a BRAM may make your design slower in some cases because it constraints the router. "Efficiency" is an attempt to capture all these concerns with a single number. It's not perfect, but it helps.
You don't have to use |
Makes sense. The log mentions "waste" (unused bits?) and seems to judge my memories too wasteful to bother with the BRAMs. But I have two 8-element arrays of 24-bit numbers, which is 384 bits, and that's a lot of flip-flops on an HX1K... Are there ways to "encourage" it to use BRAMs even when it doesn't think they're the best idea? I have a ton of timing slack right now so I don't even mind if there's some performance hit.
I was just playing around with that! I did platform.build(top, do_program = args.program or args.interactive, synth_opts = '-abc9 -noflatten') And though yosys was happy, nextpnr died with an assertion failure (!).
|
You will need bang-up-to-date nextpnr to use |
Wish granted: YosysHQ/yosys#1603 |
Fair enough! I can use the
Very nice. How exactly would I use that though? |
On iCE40, use |
Sorry but, how about in nMigen? |
Oh oops sorry. That's um, actually not possible right now... primarily because Yosys did not have this feature before. Could you open an issue for attaching attributes to memories? |
Sure thing. |
This is a question!
I've been learning FPGA design on an iCEStick with nMigen. I haven't had more than "toy-level" experience with Verilog or with the yosys-nextpnr toolchain. The problem I keep running into is sort of multi-faceted:
I've been reading the
.rpt
file, but that's huge, and a lot of it doesn't make much sense without thoroughly understanding the toolchain that produced it.I also open the design in the nextpnr-ice40 GUI and then poke around in the cells/nets lists to see what signals they map back to. This is pretty awkward and indirect, and a lot of the cells/nets are autogenerated with names that only refer to the pass that generated them (e.g.
simplemap_dff
,alumacc
, etc), and not the original code that they map to.I think it's doing some serious global optimization, so I don't expect to be able to get a perfect report of "elaboratable X is using Y LCs" or something, but it would at least be nice to be able to get an estimate. Is this something that the toolchain provides? Is this even possible to do?
Thanks for any help you can give. Keep up the great work on this library.
The text was updated successfully, but these errors were encountered: