https://open-source-silicon.dev logo
Join Slack
Powered by
This may be a dumb question, but I'm having troubl...
# openlane
t
This may be a dumb question, but I'm having trouble hardening a design and after some experimenting I found that the problem was a multiplication, namely "assign r = a*b" Is this not permitted by the openlane tools? I don't know if this is enough information to answer the question. If it isn't, what should I provide? Thanks in advance.
j
I am supposing this line is in your own Verilog file. That is converted by Yosys into an equivalent Verilog which is a netlist of cells from a given library, in the case the standard cells implemented in the Skywater 130nm standard cell library. Yosys can decompose an addition into simpler cells available in Sky130 and in theory can do the same for multiplication. In practice you might have to replace that with a module that explicitly implements multiplication: mymult m(r,a,b);
t
That is indeed the case. The module I'm trying to harden is exactly one that implements multiplication. What you're saying is that I should harden the top module which uses this one instead of both separately right?
j
I just tested and Yosys can certainly transform this design into what Xilinx FPGAs need, for example. But it does use a DSP48 block, which sky130 doesn't have
Yosys also generated it for the ICE40 using 159 LUT4 blocks (for 8 bit inputs and 16 bit output). I'll try to see what happens for sky130
t
Thank you for your time. In case this approach doesn't work, are there other ways to implement a multiplication block?
j
Here is an example of a hand crafted design. It is only 4 bit input, so extending it to 16 bits would mean four times as many lines: http://barrywatson.se/dd/dd_multiplier_simple.html
I haven't yet seen how to get Yosys to use sky130 cells, but the generic "synth" command generates:=== multa === Number of wires: 342 Number of wire bits: 371 Number of public wires: 4 Number of public wire bits: 33 Number of memories: 0 Number of memory bits: 0 Number of processes: 0 Number of cells: 354 $_ANDNOT_ 97 $_AND_ 55 $_NAND_ 25 $_NOR_ 12 $_NOT_ 7 $_ORNOT_ 10 $_OR_ 37 $_XNOR_ 25 $_XOR_ 86
So the problem is not in Yosys itself
h
It could be that there is a timing issue. Such a wide multiplication creates a fairly deep logic cone when there is no pre-made multiplier cell available (which isn't in the SKY130 libs). The way to go is likely to build a pipelined multiplier which spends a few cycles to get the result.
a
Yosys can synthesize this. I have design with multiplication thatwas passed through openlane
My guess: Timing issues probably. Could you provide more information, like logs in which step it fails. In your design its entirety combinational. Its unlikely that you will be able to have reasonable timings. Dont harden just combinational circuits
t
[INFO]: Incremented step index to 17.
[INFO]: Running Fill Insertion...
[INFO]: Changing layout from /home/openpdk/caravel/fct-iot-node-project/openlane/multa/runs/multa/tmp/routing/15-diodes.def to /home/openpdk/caravel/fct-iot-node-project/openlane/multa/runs/multa/tmp/routing/18-fill.def
[INFO]: Incremented step index to 18.
[INFO]: Running Global Routing...
[ERROR]: during executing openroad script /openlane/scripts/openroad/groute.tcl
[ERROR]: Exit code: 1
[ERROR]: Last 10 lines:
child process exited abnormally
[INFO]: Creating reproducible...
[INFO]: Saving runtime environment...
[INFO]: Reproducible packaged: Please tarball and upload multa/runs/multa/openroad_issue_reproducible if you're going to submit an issue.
[INFO]: Calculating Runtime From the Start...
[INFO]: Generating Final Summary Report...
[INFO]: Design Name: multa
Run Directory: /home/openpdk/caravel/fct-iot-node-project/openlane/multa/runs/multa
Source not found.
----------------------------------------
LVS Summary:
Source: /home/openpdk/caravel/fct-iot-node-project/openlane/multa/runs/multa/logs/finishing/multa.lvs.lef.log
Source not found.
----------------------------------------
Antenna Summary:
No antenna report found.
[INFO]: check full report here: /home/openpdk/caravel/fct-iot-node-project/openlane/multa/runs/multa/reports/final_summary_report.csv
[INFO]: Saving runtime environment...
[ERROR]: Flow failed.
It fails here, which to my knowledge is due to full RAM. I did, however, add 70Gb of swap memory (+ base 10Gb) and it always fills up. Hope this helps
[INFO GRT-0101] Running extra iterations to remove overflow.
[INFO GRT-0103] Extra Run for hard benchmark.
It stays here until it eventually runs out of memory and crashes.
Upon trying to run the design again I'm getting extra warnings I didn't get before 
[WARNING GRT-0150] Net _0393_ has errors during updateRouteType1.
[WARNING GRT-0169] Net _0393_: Invalid index for position (403650, 403650). Net degree: 7.
[WARNING GRT-0150] Net _0393_ has errors during updateRouteType1.
This is now where it stays until memory fills.
a
1. Do you have enough HDD space? 2. No looks like you error is not running out of memory. Its exiting with error
If it was killed by OOM it would error 130
whats your density and util, do you have macros? What die area are you using?
t
1. Yes I have enough space. 2. I don't know about the error, but it exits at the same time as the swap memory fills up. Below is my config file:
Copy code
set ::env(PDK) "sky130A"
set ::env(STD_CELL_LIBRARY) "sky130_fd_sc_hd"
set script_dir [file dirname [file normalize [info script]]]
set ::env(DESIGN_NAME) multa
Copy code
set ::env(VERILOG_FILES) "\
	$::env(CARAVEL_ROOT)/verilog/rtl/defines.v \
	$script_dir/../../verilog/rtl/biquad/multa.v"
set ::env(DESIGN_IS_CORE) 0
Copy code
set ::env(CLOCK_PORT) "clk"
set ::env(CLOCK_PERIOD) "20"
Copy code
set ::env(FP_SIZING) absolute
set ::env(DIE_AREA) "0 0 900 600"
set ::env(FP_PIN_ORDER_CFG) $script_dir/pin_order.cfg
Copy code
set ::env(PL_BASIC_PLACEMENT) 1
set ::env(PL_TARGET_DENSITY) 0.4
Copy code
# Maximum layer used for routing is metal 4.
# This is because this macro will be inserted in a top level (user_project_wrapper) 
# where the PDN is planned on metal 5. So, to avoid having shorts between routes
# in this macro and the top level metal 5 stripes, we have to restrict routes to metal4.  
# 
# set ::env(GLB_RT_MAXLAYER) 5
set ::env(RT_MAX_LAYER) {met4}
Copy code
# You can draw more power domains if you need to 
set ::env(VDD_NETS) [list {vccd1}]
set ::env(GND_NETS) [list {vssd1}]
Copy code
set ::env(DIODE_INSERTION_STRATEGY) 4 
# If you're going to use multiple power domains, then disable cvc run.
set ::env(RUN_CVC) 1
Update: As said here, it was probably timing issues. I changed the module into a 4-stage pipeline with smaller multiplications and reduced the number of bits and after some parameter optimization finally managed to harden the design. Thank you all that helped for your time.
👍 1
a
You have basic placement enabled. Thats the reason why it fails
2. If you use absolute die area values, make sure you have enough area for that utilization or use relative die area + fp core util. Otherwise you will get problems down the line. Like exactly the one you see here
👍 1
t
You're right, basic placement was ultimately the culprit there. I tried the first design again with relative die area as well and it works now. I'm left with one last question though. You said previously that I shouldn't harden just combinatory circuits, but since the design passed the timing tests does this mean that it is fine? Or could there still be other problems?
a
You still might have issues on top level, because there is no lib with timings generated. Just avoid combinational only macros.
You also might be fine. If both bottom and top levels pass timings
Example: you generate a multiplier. Because of top-bottom architecture you will need to use lower frequency to make the bottom layer pass. Then you have to use on top level that lower frequency to make sure the flow succeeds. In registered variants the overhead is low.
Open in Slack
PreviousNext
Powered by