Error in building a vanilla quad large boom agfi
141 views
Skip to first unread message
Varun Gandhi
Feb 20, 2021, 9:08:20 AM2/20/21
to chip...@googlegroups.com
Hi,
While trying to build a vanilla quad large boom config. I’ve never seen this error before, where the feasibility check itself failed.
Boom.scala
class QuadLargeBoomConfig extends Config(
new boom.common.WithNLargeBooms(4) ++
new chipyard.config.AbstractConfig)
Error Log:
2021-02-20 04:13:07,816 [flush ] [INFO ] [192.168.1.59] out: ## set errMsg "\nError: 1 or more URAM288 cells in the design are using OREG_B port. This is not supported for this flow. Review previous error messages and update URAM288 to set OREG_B and OREG_ECC_B properties to false."
2021-02-20 04:13:07,816 [flush ] [INFO ] [192.168.1.59] out: ## error $errMsg
2021-02-20 04:13:07,816 [flush ] [INFO ] [192.168.1.59] out: ## error "Error: Site $uramSite is occupied, and connot be prohibited. This design is set to only utilize the lower two (0 and 1) URAM sites of each quad, and this site ($quadLoc) should not be used."
2021-02-20 04:13:07,817 [flush ] [INFO ] [192.168.1.59] out: ## error "Error: Site $uramSite is occupied, and connot be prohibited. This design is set to only utilize the lower three URAM sites (0, 1, and 2) of each quad, and this site ($quadLoc) should not be used."
2021-02-20 04:13:07,820 [flush ] [INFO ] [192.168.1.59] out: ## error $errMsg
2021-02-20 04:13:07,820 [flush ] [INFO ] [192.168.1.59] out: ## error "Error: Variable \'\$uramHeight\' set to unsupported value $uramHeight. Supported values are 2, 3, or 4"
2021-02-20 05:03:02,848 [flush ] [INFO ] [192.168.1.59] out: ERROR: [Place 30-640] Place Check : This design requires more Slice LUTs cells than are available in the target device. This design requires 1310340 of such cell types but only 1181768 compatible sites are available in the target device. Please analyze your synthesis results and constraints to ensure the design is mapped to Xilinx primitives as expected. If so, please consider targeting a larger device. Please set tcl parameter "drc.disableLUTOverUtilError" to 1 to change this error to warning.
2021-02-20 05:03:02,848 [flush ] [INFO ] [192.168.1.59] out: ERROR: [Place 30-640] Place Check : This design requires more LUT as Logic cells than are available in the target device. This design requires 1271278 of such cell types but only 1181768 compatible sites are available in the target device. Please analyze your synthesis results and constraints to ensure the design is mapped to Xilinx primitives as expected. If so, please consider targeting a larger device. Please set tcl parameter "drc.disableLUTOverUtilError" to 1 to change this error to warning.
2021-02-20 05:03:08,213 [flush ] [INFO ] [192.168.1.59] out: ERROR: [Place 30-99] Placer failed with error: 'Implementation Feasibility check failed, Please see the previously displayed individual error or warning messages for more details.
David Biancolin
Feb 20, 2021, 9:34:43 PM2/20/21
to chip...@googlegroups.com
You're going to need to use FireSim's resource optimizations to make that design fit. They will slow down your simulation rate though.
See https://docs.fires.im/en/latest/Golden-Gate/Resource-Optimizations.html.
See https://docs.fires.im/en/latest/Golden-Gate/Resource-Optimizations.html.
--
You received this message because you are subscribed to the Google Groups "Chipyard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/4F59EEE8-25F0-4609-9C28-0DD6372FE313%40g.harvard.edu.
Varun Gandhi
Feb 22, 2021, 11:35:34 AM2/22/21
to chip...@googlegroups.com
Hi David,
I’m trying to build a quad-core large-boom config in the following way:
1. Boom.scala
class QuadLargeBoomConfig extends Config(
new boom.common.WithNLargeBooms(4) ++
new chipyard.config.AbstractConfig)
2. Config_build_recipes.ini
[firesim-boom-large-quadcore-nic-l2-llc4mb-ddr3]
DESIGN=FireSim
TARGET_CONFIG=WithNIC_DDR3FRFCFSLLC4MB_WithDefaultFireSimBridges_WithFireSimConfigTweaks_chipyard.QuadLargeBoomConfig
PLATFORM_CONFIG=MTModels_MCRams_BaseF1Config
instancetype=z1d.2xlarge
deploytriplet=None
However, my build still fails with the following error log:
The checkpoint '/home/centos/firesim-build/platforms/f1/aws-fpga/hdk/cl/developer_designs/cl
_firesim/build/checkpoints/to_aws/21_02_21-190802.SH_CL_routed.dcp' has been generated.
[192.168.0.27] out: write_checkpoint: Time (s): cpu = 00:08:06 ; elapsed = 00:08:48 . Memory (MB): peak = 36636.020 ; gain = 0.000 ; fr ee physical = 37268 ; free virtual = 63772
[192.168.0.27] out: WARNING: [Chipscope 16-359] Could not find a valid clock port for hub dbg_hub. C_CLK_INPUT_FREQ_HZ will get an empt
y value in the LTX file
[192.168.0.27] out: get_timing_paths: Time (s): cpu = 00:02:11 ; elapsed = 00:00:16 . Memory (MB): peak = 36636.020 ; gain = 0.000 ; fr
ee physical = 37292 ; free virtual = 63795
[192.168.0.27] out:
[192.168.0.27] out: FATAL: Design did not meet timing requirements. Terminating.
[192.168.0.27] out: INFO: [Common 17-206] Exiting Vivado at Mon Feb 22 08:11:38 2021...
[192.168.0.27] out:
Warning: run() received nonzero return code 3 while executing './aws_build_dcp_from_cl.sh -foreground'!
FireSim FPGA Build Failed
Your FPGA build failed for triplet: FireSim-WithNIC_DDR3FRFCFSLLC4MB_WithDefaultFireSimBridges_WithFireSimConfigTweaks_chipyard.QuadLar
geBoomConfig-MTModels_MCRams_BaseF1Config.
Best,
Varun
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CAKUMM8PUjdzmcHvU4c%3DNxiQrh4xJ5AV1rxnA%3DUfwT21zn0H9BQ%40mail.gmail.com.
David Biancolin
Feb 23, 2021, 4:25:12 AM2/23/21
to chip...@googlegroups.com
Your design did not meet timing requirements, likely because you didn't meet the setup constraint for the simulator's clock domain. You can look at some of the other build recipes and you'll see that you can prefix the `PLATFORM_CONFIG` with a F<frequency>MHz string to set the FPGA frequency. I'm not totally sure what a good value would be for that design -- 50 MHz possibly? In general, you can look at the log and figure out how much negative slack you have, and then guess from there. In this case I suspect you are too far off the mark for that to work.
Also, for that design you might get away with just using the RAM optimization -- i believe your simulator would run faster than using both. It's worth experimenting with them.
Also, for that design you might get away with just using the RAM optimization -- i believe your simulator would run faster than using both. It's worth experimenting with them.
- David
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/1BC41242-42BC-4548-B987-27653409C47F%40g.harvard.edu.
Reply all
Reply to author
Forward
0 new messages