You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of a94be4c, the ZeroSoC design barely fits on the iCE40UP5k FPGA I'm using for testing (on an Icebreaker dev board). We want to add additional modules, and the high utilization is also making it difficult to get good timing results (the critical path is ~8 MHz, which seems very slow to me). Therefore, optimizing resource utilization for the current design to get more headroom seems important.
The current resource utilization, as reported by NextPNR, is as follows (with unused resources omitted):
I summarized a coarse-grained resource utilization by module (as reported by Yosys, using a (* keep_hierarchy *) attribute added to all modules instantiated in the top-level, as well as large submodules in the Ibex core), in this file: stats.txt
Some things that stand out looking at these results:
The ibex_register_file_fpga is intended to infer block RAM, but it doesn't look like that's happening. This module is using a ton of LUTs, so if I can figure out what's going on there that should save a good 30% of LC util and put us in great shape.
GPIO has the highest resource consumption of any peripheral. Right now it's fixed at 32 pins, but I figure it's probably not too difficult to parameterize the amount of I/O it exposes. Cutting down to 16 could maybe get us ~5% savings (I think the Icebreaker only has 24 GPIO pins broken out anyways).
The text was updated successfully, but these errors were encountered:
Actually, looks like Yosys does infer block RAM for the FPGA-optimized register file, but only when it's flattened into the design. My measurement approach didn't really give a correct picture since it involved disabling this flattening.
As of a94be4c, the ZeroSoC design barely fits on the iCE40UP5k FPGA I'm using for testing (on an Icebreaker dev board). We want to add additional modules, and the high utilization is also making it difficult to get good timing results (the critical path is ~8 MHz, which seems very slow to me). Therefore, optimizing resource utilization for the current design to get more headroom seems important.
The current resource utilization, as reported by NextPNR, is as follows (with unused resources omitted):
I summarized a coarse-grained resource utilization by module (as reported by Yosys, using a (* keep_hierarchy *) attribute added to all modules instantiated in the top-level, as well as large submodules in the Ibex core), in this file:
stats.txt
Some things that stand out looking at these results:
Theibex_register_file_fpga
is intended to infer block RAM, but it doesn't look like that's happening. This module is using a ton of LUTs, so if I can figure out what's going on there that should save a good 30% of LC util and put us in great shape.The text was updated successfully, but these errors were encountered: