Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Rajarshi Roy
    @rjrshr_twitter
    @Akshaygireesh are you using the provided docker container? Then it shouldn't matter if you are using ubuntu or centos, everything is preinstalled and working in the docker https://docs.docker.com/engine/install/ubuntu/
    Once the docker container is launched execute:
    $ cd /OpenROAD-flow/
    $ source setup_env.sh
    $ openroad gcd_nangate45.tcl
    Akshaygireesh
    @Akshaygireesh
    @rjrshr_twitter setup_env,sh not found
    Akshaygireesh
    @Akshaygireesh
    Screenshot from 2020-08-17 12-56-02.png
    Please help resolve this
    quentinw91
    @quentinw91
    Hello, I am using the buffer_ports -inputs command to add buffers to my inputs pins, but then the Resizer resizes them. Is there a "don't touch" command to specify cells we do not want to be resized ?
    Austin Rovinski
    @rovinski
    @/all https://github.com/The-OpenROAD-Project/OpenROAD-flow repository is back online in temporary read-only state. We are still working to restore the history.
    Austin Rovinski
    @rovinski
    @quentinw91 I'm not clear on what you're saying. What is being modified that you don't want it to be? The buffers inserted by buffer_ports?
    Resizer does optimal delay calculations when resizing instances, so it would be resizing the buffers in order to meet timing constraints or fix electrical rules.
    If the issue is that resizer is making the input buffers too large or small, use set_driving_cell in your SDC to give it a better idea of the port input drive. If you really don't want resizer touching the buffers, then you can set the buffer placement status to FIXED and I believe that will prevent resizer from touching it.
    quentinw91
    @quentinw91
    Yes, i have selected a specific buffer cell for the inputs (i.e. BUFX1) but the resizer replaces some of them (i.e. with BUFX2 or BUFX4). But i would like to have the same input capacitance presented at each input pin. So i would like that resizer does not touch the BUFX1, or if it needs to, adds another buffer with higher fanout (BUFX1-->BUFX4--> (rest of logic)... ). I will try the FIXED solution, thanks !
    quentinw91
    @quentinw91
    i used the $inst setPlacementStatus FIRM to have it FIXED, but it did not work. I'll create an issue in github, since it does not seem to be so easy
    quentinw91
    @quentinw91
    i get an error with the OpenROAD-flow-public. yosys seems to be not correctly installed:
    bash-4.2$ source ./setup_env.sh
    OPENROAD: /OpenROAD-flow/tools/OpenROAD
    bash-4.2$ cd flow/
    bash-4.2$ make synth
    [INFO][FLOW] Using platform directory ./platforms/nangate45
    /bin/bash: yosys: command not found
    make: * [versions.txt] Error 127
    (i would create an issue on github with the log file, but it is not possible to open issues)
    quentinw91
    @quentinw91
    i created the issue on openroad repo instead
    Austin Rovinski
    @rovinski
    I responded on the issue, but until OpenROAD-flow is not read-only, it's probably best to just post any flow-specific issue here. Issues that aren't related to OpenROAD directly may just get closed by less friendly developers.
    quentinw91
    @quentinw91
    yeah, i just did not want to flood the chat with my 26K lines log file :p
    David Pan
    @CPA872
    Hello all, I've new to openroad-flow. I have it installed using docker. But after doing "docker run openroad" and "source setup_env.sh", bash still prompts "openroad: command not found". (Ubuntu 20.04) Does any have this issue or can provide any help? Thanks in advance!
    $ source setup_env.sh
    OPENROAD: /home/cx872/OpenROAD-flow/tools/OpenROAD
    ^Above is the output after sourcing.
    Akshaygireesh
    @Akshaygireesh
    try running it via docker
    2 replies
    Austin Rovinski
    @rovinski
    @CPA872 Are you running the script inside or outside of a docker container? It must be run inside. From the README:
    3. Start an interactive shell in a docker container using your user credentials
    docker run -it -u $(id -u ${USER}):$(id -g ${USER}) openroad/flow bash
    laurentc2
    @laurentc2
    With TritonRoute I got many "Error: instAnalysis unsupported pinFig".
    It is very tough to find the origin of the errors, probably my cellLib lef file.
    It would be nice to get more info for the debug : which cell? which pin? which pin property ?
    Maybe my technology tlef file is badly defined : it is the most difficult file to setup. More info would be welcome, especially for the VIARULE.
    Thank you!
    Austin Rovinski
    @rovinski
    Hi @laurentc2, I recognize you from the KLayout forums! Good to see you trying out OpenROAD :)
    TritonRoute is known to have very bad error messages. Unfortunately they are written to help the developer and not so much the end user. We are aiming to dramatically improve user messages across all of OpenROAD starting sometime within the next few months.
    For Error: instAnalysis unsupported pinFig, seems to come from this section of code
    TritonRoute only supports RECT-based pins in LEF MACROs. A vast majority of PDKs we've encountered use RECT pins. The only one I've seen do otherwise is Nangate45, which uses POLYGON pins. For this reason, we've recreated the Nangate45 LEF to use RECT pins instead (available here).
    If your cell library uses POLYGON pins, you would have to use a tool to re-extract them as RECT pins. Unfortunately this might take some work :(
    laurentc2
    @laurentc2
    Thank you for that great help : it was my problem !
    laurentc2
    @laurentc2
    Yes, I often use KLayout a very great tools !
    By the way, all examples of the openroad Flow use random placement of the pins ... it not the case in the true life. Please, could you add an example with the pins placed at a given position in X or Y. It will be very helpful and be more real.
    Thank you again!
    Austin Rovinski
    @rovinski

    @laurentc2 There is a mode of ioPlacer which uses non-random assignment - it uses an algorithm to place I/O pins such that wire length is minimized. We don't have it active right now because there was an issue where it might place pins too close together and cause routing violations. It depends on a placed design, so to run it, one has to run random IO assignment --> global placement --> non-random IO assignment.

    It is not quite what you are asking, but it is better than random. There is probably a way to do place pins using OpenDB commands, but yes, we should make the interface easier to use. I will forward this to the team.

    laurentc2
    @laurentc2
    Thank you Austin! I hope to set at least the side of each pin : left, right top or bottom. This will really fit the real life!
    laurentc2
    @laurentc2
    Using the random_io placement, I made some progress in the flow.
    But now I get an error that I don't understand with TritonRoute :
    start pin access
    Error: no ap for X554B/A
    laurentc2
    @laurentc2

    I found out that that some pins were defined in a layers not connected, so it solved my last issue.
    But now, I face a new problem : TritonRoute is crashing in the middle of its processing with the message :
    post process guides ...
    GCELLGRID X -1 DO 48 STEP 14400 ;
    GCELLGRID Y -1 DO 87 STEP 14400 ;
    terminate called after throwing an instance of 'std::out_of_range'
    what(): vector::_M_range_check: __n (which is 10) >= this->size() (which is 10)
    0:03.00elapsed 250%CPU 19148memKB

    Hope you can help me, I cannot find in the TritonRoute code the line that is crashing ...
    Thank you, BRgds,
    Laurent

    Austin Rovinski
    @rovinski
    @laurentc2 Error: no ap for AAA/BBB means that TritonRoute was unable to find an access point (ap) for cell instance AAA on pin BBB. This can mean several things, such as 1) TritonRoute cannot find the pin definition in the LEF, 2) the cell is designed such that TritonRoute is unable to make a clean connection to the pin, 3) The location where the instance was placed makes it inaccessible by TritonRoute.
    Austin Rovinski
    @rovinski
    @laurentc2 terminate called after throwing an instance of 'std::out_of_range' is definitely a bug. Is it possible to provide a test case? If the problem is reproducible in an open kit like nangate45 or sky130 then it makes it really easy for us to debug. You can open a GitHub issue on the TritonRoute repository and attach the test case if possible. If you use OpenROAD-flow, you can run make tritonRoute_issue which will create a tar.gz file in the format we use for internal debugging.
    laurentc2
    @laurentc2

    I still cannot solve the first issue as I always have the same error with TritonRoute :
    Error: no valid pattern for unique instance X1700, refBlock is IV2
    pin ordering (with ap):
    A (281.48, 138.385) (281.48, 138.415) (281.72, 138.385) (281.72, 138.415)
    Z (281.96, 137.535) (281.96, 137.575) (281.96, 137.975) (281.96, 138.015) (281.96, 139.185) (281.96, 139.225)

    For the bug, I could bypass it by creating an extra dummy routing layer and it solved it!
    I think it comes from one of the code line with : .at(layerNum)
    BRgds,
    Laurent

    Austin Rovinski
    @rovinski
    @laurentc2 I believe Error: no valid pattern for unique instance X1700 means that TritonRoute cannot create a pin access pattern that creates a clean connection to the instance. This occurs with cells that have too high of a pin density, or the pins are too small. This can occur frequently with cells that have less than X1 drive strength. Sometimes it can also occur with X1 strength cells. I recommend adding the cell to the DONT_USE list in the config file so that Yosys does not try to synthesize to that type of cell, and so that Resizer does not try to resize for that cell.
    laurentc2
    @laurentc2
    Thank you Austin for your help.
    However, I solved in a different way. My basis netlist is a gate netlist, so I don't use the Yosis synthesis part of the flow. And finally, I succeed to solve my issue by setting :
    MANUFACTURINGGRID 0.005 ;
    while the technology requires :
    MANUFACTURINGGRID 0.01 ;
    I will have to put my routing back on grid under KLayout, but I can manage it.
    BRgds,
    laurentc2
    @laurentc2
    How to force the cells track, not the metals track ?
    Laurent
    quentinw91
    @quentinw91

    Hi, i am getting this weird error at the end of the flow, while doing final report:

    ==========================================================================
    report_clock_skew
    --------------------------------------------------------------------------
    Error: Internal error in /OpenROAD/src/OpenSTA/search/Crpr.cc:78 missing prev paths.

    Any idea what might cause this ? (i do not see any other error in the log file that could explain this)

    Austin Rovinski
    @rovinski
    @laurentc2 I would be careful with changing the manufacturing grid, that seems like an easy way to get misalignment in the routing tracks.

    How to force the cells track, not the metals track ?
    Laurent

    @laurentc2 I'm not sure what you're asking, can you elaborate?

    2 replies
    Austin Rovinski
    @rovinski
    @quentinw91 Internal error is basically an assertion failure, i.e. a bug. If you can provide a detailed test case to OpenSTA, I would do so.
    Cheng Tan
    @tancheng
    @rovinski Hi Austin, I am new to OpenRoad. When I tried to place a new design, it showed the ERROR "RePlAce divergence detected. Please decrease init_density_penalty value (REPL-3)". I saw you replied to @gkamendje_gitlab that we need to make the DENSITY higher than the CORE_UTILIZATION, and I did do that (you can see util(%)=24.613287 and TargetDensity=0.2500). Do you have any idea about this error? The screenshot is as follows.
    Notice 0: Finished DEF file: ./results/nangate45/comp/2_floorplan.def
    [INFO] DBU = 2000
    [INFO] SiteSize = (380, 2800)
    [INFO] CoreAreaLxLy = (20140, 22400)
    [INFO] CoreAreaUxUy = (140220, 140000)
    [INFO] NumInstances = 491
    [INFO] NumPlaceInstances = 407
    [INFO] NumFixedInstances = 84
    [INFO] NumDummyInstances = 0
    [INFO] NumNets = 615
    [INFO] NumPins = 1653
    [INFO] DieAreaLxLy = (0, 0)
    [INFO] DieAreaUxUy = (160340, 160000)
    [INFO] CoreAreaLxLy = (20140, 22400)
    [INFO] CoreAreaUxUy = (140220, 140000)
    [INFO] CoreArea = 14121408000
    [INFO] NonPlaceInstsArea = 89376000
    [INFO] PlaceInstsArea = 3453744000
    [INFO] Util(%) = 24.613287
    [INFO] StdInstsArea = 3453744000
    [INFO] MacroInstsArea = 0
    [InitialPlace]  Iter: 1 CG Error: 8.22656e-08 HPWL: 43844280
    [InitialPlace]  Iter: 2 CG Error: 1.18405e-06 HPWL: 25511121
    [InitialPlace]  Iter: 3 CG Error: 1.09402e-07 HPWL: 20147647
    [InitialPlace]  Iter: 4 CG Error: 9.91762e-08 HPWL: 19970488
    [InitialPlace]  Iter: 5 CG Error: 1.15753e-07 HPWL: 19917056
    [INFO] FillerInit: NumGCells = 413
    [INFO] FillerInit: NumGNets = 615
    [INFO] FillerInit: NumGPins = 1653
    [INFO] TargetDensity = 0.250000
    [INFO] AveragePlaceInstArea = 8485857
    [INFO] IdealBinArea = 33943428
    [INFO] IdealBinCnt = 416
    [INFO] TotalBinArea = 14121408000
    [INFO] BinCnt = (16, 16)
    [INFO] BinSize = (7505, 7350)
    [INFO] NumBins = 256
    [NesterovSolve] Iter: 1 overflow: 0.480216 HPWL: 23894010
    [ERROR] RePlAce divergence detected. 
            Please decrease init_density_penalty value (REPL-3)
    Error: RePlAce terminated with errors.
    Austin Rovinski
    @rovinski
    @tancheng 24.6% is still very close to 25%. Try setting place density to 30% and see if it helps.
    Cheng Tan
    @tancheng
    @rovinski Thanks Austin, I sweep from 1% to 100%. It does not work. when it is set more than 24.6%, it shows "please decrease", when it is set equal or less than 24.6%, it shows "please put higher target density"...
    Austin Rovinski
    @rovinski
    @tancheng Hmmm... Sometimes RePlAce can have problems with a design if it is very small. I see your design is <500 instances. Try adding export GLOBAL_PLACEMENT_ARGS = -skip_initial_place to your design config file.
    laurentc2
    @laurentc2
    I have tried to use : write_path_spice to generate a spice netlist for LVS.
    But I really cannot figure out what argument to pass to : -path_args
    I have even looked at the OpenSTA code and could find what is path_args.
    An example with write_path_spice would be welcome.
    Austin Rovinski
    @rovinski
    @laurentc2 Maybe I'm mistaken but I don't think OpenSTA is meant to output spice for LVS... it's more for netlist simulation.
    Our workflow is to take the final verilog netlist using write_verilog and convert it to spice / CDL. Yosys can do this.
    Also if you're curious, OpenSTA has PDF documentation in OpenSTA/doc/OpenSTA.pdf
    laurentc2
    @laurentc2
    @rovinski I see your flow. By the way, FreePDK45 already has the KLayout LVS script. It is currently manual, but it can easily be scripted.
    Austin Rovinski
    @rovinski
    Yes, we plan to make this part of the flow in the next update. We need to make the flow repository non read-only first.
    laurentc2
    @laurentc2
    @rovinski I just generated the spice netlist through that flow based on Yosys, and I see 2 drawbacks :
    • the library is never provided with the blackbox_library.v file, but with a CDL spice netlist, so the blackbox_library.v file has to be generated
    • the bus is generated as bus.0 bus.1 bus.2 ... while we need bus[0], bus[1], bus[2]... for the LVS
      The spice netlist generated from OpenSTA for the NGSPICE simulations is from a CDL spice netlist of a libray. So modifying it for the spice netlist for the LVS would be easier for a new library.
      It was just my hint ...
    quentinw91
    @quentinw91
    Hi, i build openroad_flow_public, everything looks to be ok, but i cannot start openroad:
    openroad: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory
    I tried with --latest option to build_openroad.sh, same thing
    Austin Rovinski
    @rovinski
    @quentinw91 openroad-flow-public is not compatible with the latest version of OpenROAD.
    For this specific issue you can add RUN yum install -y qt5-qtbase-devel into openroad-flow-public/Dockerfile
    2 replies