In my design while i was checking out the numbers I found that fanout/design repair is using dlyb_1 as for ordinary buffer is the what's suppose to happen ?
These are being added by the repair_design command in the flow
Deepak
In my design while i was checking out the numbers I found that fanout/design repair is using dlyb_1 as for ordinary buffer is the what's suppose to happen ?
These are being added by the repair_design command in the flow
Unfortunately, OpenROAD does not currently differentiate between data and hold buffers during buffer selection: https://github.com/The-OpenROAD-Project/OpenROAD/issues/10622
While you can disable all delay buffers, this would also mean that they could not be used for hold repair.
6:29 a.m.
@RebelMike did a workaround for his design where he replaced all setup-repair dlyb with normal buffers iirc.
Description It would sometimes be useful to replace the cell for a given instance, e.g. to change buffer type or resize a cell to improve timing. This could be an ECO step similar to InsertECOBuffe...
TinyQV including analog peripherals for TT GF 0.3. Contribute to MichaelBell/ttgf0p3-tinyQV development by creating an account on GitHub.
1
Leo Moser (mole99)
Unfortunately, OpenROAD does not currently differentiate between data and hold buffers during buffer selection: https://github.com/The-OpenROAD-Project/OpenROAD/issues/10622
While you can disable all delay buffers, this would also mean that they could not be used for hold repair.
ohh ok I tried to disable the delay cells this but the hold timing got bad so
I will check the work around
Btw would it effect the tapeout if the dlyb buffers are used instead of normal buffer ?
Deepak
ohh ok I tried to disable the delay cells this but the hold timing got bad so
I will check the work around
Btw would it effect the tapeout if the dlyb buffers are used instead of normal buffer ?
Anyone here have full SOC designs and having issues with very long synthesis times? Our same design for fpga on vivado takes 15-30 minutes to synth, but on yosys we’re seeing 12+ hours despite enabling multi threading and other usual suspects. Is this a known issue?
I opened a PR with yosys to merge some optimizations and it was rejected because it was “AI assisted” and I must admit the attitude was very disappointing despite providing follow ups, asking questions, etc.
Yes we do leverage the keep_hierarchy. I’m aware of the LLM rules but frankly it felt like an aversion not a guardrail. But I’m not keen to focus this discussion on that, I’m trying to understand if our synth times are abnormal and if we need to investigate a problem
J-Lo
Yes we do leverage the keep_hierarchy. I’m aware of the LLM rules but frankly it felt like an aversion not a guardrail. But I’m not keen to focus this discussion on that, I’m trying to understand if our synth times are abnormal and if we need to investigate a problem
This is a summary from my team, and because I’m seeing openroad yes it might be PNR
synthesis/signoff runs were spending huge time in OpenROAD.RepairDesignPostGPL. The dominant cause was a massive high-fanout reset net: i_chip_core.rst_n had about 38,354 terminals, and OpenROAD was serially building buffer trees for it. LibreLane parallelism knobs do not help this step much.
J-Lo
This is a summary from my team, and because I’m seeing openroad yes it might be PNR
synthesis/signoff runs were spending huge time in OpenROAD.RepairDesignPostGPL. The dominant cause was a massive high-fanout reset net: i_chip_core.rst_n had about 38,354 terminals, and OpenROAD was serially building buffer trees for it. LibreLane parallelism knobs do not help this step much.
Place and route runtimes are highly dependent on routing areas. Placing macros too close together or too close to the edges can result in unroutable designs.
bailey
Place and route runtimes are highly dependent on routing areas. Placing macros too close together or too close to the edges can result in unroutable designs.
Thanks we do have an SRAM macro in there and I wonder if that’s what’s causing some of our issues. I will note it is routable and we get a GDS, it just takes an obscenely long time to create
J-Lo
Thanks we do have an SRAM macro in there and I wonder if that’s what’s causing some of our issues. I will note it is routable and we get a GDS, it just takes an obscenely long time to create
Waiting for a file transfer of the final report but in summary I think you’re on to something, probably to do with the SRAM macro:
Dense SRAM macro grid. The current report has 39 SRAM macros consuming 4.48365 mm²; total core payload is 8.23514 / 12.90200 mm², about 64% including macros. In macros_3v3.yaml, SRAM columns at x=1040 and x=1380 are only about 38.7 µm apart after subtracting the 301.3 µm SRAM width.
1
6:12 p.m.
I’m not sure how solvable this problem is with such a short time until tape out. I think it’s just a challenge posed by the small chip area and requirement to have an SRAM
Hello I was just doing final check up on the design and show that rst_n_pad is neither pu or pd is that normal or i can pull it down ? is there a reason for it being so ?
10:38 a.m.
As i have pulled up my cs_n pin for my input spi in the design so if there is some issue with that i should change that
Could a kind soul tell me if I am misunderstanding this ?
The IO pins have an input capacitance (driven from outside the pad) of:
bidir : 3.635930 (pf)
input: 3.247814 (pf)
And since the max_capacitance STA check does a blanket check of all max capacitance above a 0.2pf threshold they get incorrectly flagged even though this is perfectly handled ?
Hello everyone, we got our design routed with synopsys, we will place that gds into the padframe.
We have one question, the exported gds has the std cells as lef (only metals not any comp, active, etc)
is this correct ? or should we see on klayout the std cells with all the parts, comp, active etc
RRichmondR
Hello everyone, we got our design routed with synopsys, we will place that gds into the padframe.
We have one question, the exported gds has the std cells as lef (only metals not any comp, active, etc)
is this correct ? or should we see on klayout the std cells with all the parts, comp, active etc
Ok, just making sure.
It should be easy to get Klayout to fill in the blanks btw.; I just don't know for lack of experience.
I'd suggest trying it's LEF import wizard and making sure all the relevant .GDS with the used cells are provided/listed for the wizard to pull from when materializing the LEF.
so.... well.... yeah.
Figure if the column multiplexer circuity can also be sufficciently squished, it'd be desirable to tape out at least a smol single block of it to hopefully have the denser (though possibly slightly slower, I think) variant silicon-proven before the Run3 deadline.
In OpenROAD, is there a good way to enforce hierarchical placement within a bounding box?
I'm using plenty of macros, but directing soft placement would be helpful to fix routing congestion.
6:04 a.m.
AI mentions commands like "create_region" "add_to_region" and "report_region", but I haven't found any documentation for these.
Is it an AI hallucination?
I would suggest to check out the LibreLane step configuration variables: https://librelane.readthedocs.io/en/stable/reference/step_config_vars.html
You can place hard and soft obstructions using FP_OBSTRUCTIONS and PL_SOFT_OBSTRUCTIONS.
And you can also limit the routing amd PDN generation using ROUTING_OBSTRUCTIONS and PDN_OBSTRUCTIONS.
For FPGAs, you can often softly hint or enforce cell placement of an instance and all of its children within rectangular or polygonal boundary constraints.
You can usually control whether foreign cells are excluded from place/routing through these blocks.
Xilinx terminology is "pblock", Altera "logic lock"
Normally every time you re-implement the design, each region is replaced/routed; but you can also lock the placement and routing as well, effectively more like a macro here. Would be good if these tools implemented softer hierarchical placement. I bet commercial ASIC tools have a direct equivalent.
Ouf, well you could go count the transistors per cells+macro by looking at the floorplans and then multiply that per each of the cells+macos you have. But that sounds tedious.
5:51 p.m.
Maybe the antenna check could inspire a better way of doing this
Anyways, I don't have any good solutions for you.(edited)
The spice for the cells is probably an easier way to count
5:56 p.m.
You/AI could probably write a script to count the number of fets in each cell subcircuit in the spice file for the standard cell library you are using, and then mutliply it by the cell counts.
1
RebelMike
The spice for the cells is probably an easier way to count
Although you might need a similar trick to get the final counts of each cell - yosys logs what it sythnthesized, but then lots of buffers will be added, I'm not sure if there's a final log anywhere or if you'll need to count that from the netlist
Deepak
How does one find the total number of transistors that are used in design?
CVC-RV will report the total number of devices and number of each device type in the equivalent flattened netlist, but it uses an extracted version that has parallel devices combined. I can help you with the setup if you want.
tnt
But what do you count as a transistor ? Does a 2 finger nmos count as 1 or 2 ?
aah not sure, i just curious about checking how many fet are even there in my design
bailey
CVC-RV will report the total number of devices and number of each device type in the equivalent flattened netlist, but it uses an extracted version that has parallel devices combined. I can help you with the setup if you want.
1
1
1
1
1
Anyways, I don't have any good solutions for you. 
2
1
2
1