The-OpenROAD-Project-Attic/FastRoute

Segfault when running FRlefdef on a small LRU(lest recently used) Verilog module

oharboe opened this issue · 11 comments

This was using: https://github.com/The-OpenROAD-Project/alpha-release/releases/tag/v2019-07-30_05-17

To reproduce use the attached files:

# FRlefdef --no-gui --script LRU.rsyn 
[deleted]
Running generic reader...
Parsing LEF files...
[deleted]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
Parsing LEF files... Done (runtime: 0.01051 seconds memory: +3 MB)
Parsing DEF files...
Segmentation fault (core dumped)

segfault.zip

Hi, @oharboe.

Can you check and test the branch 'fix_issue#2', commit fdee44a?

Thanks.

@eder-matheus What are the steps to test this?

@oharboe Just build this branch and run your Rsyn script

Using these files https://github.com/The-OpenROAD-Project/FastRoute4-lefdef/files/3456263/segfault.zip, it still fails:

# FastRoute4-lefdef/FRlefdef  --no-gui --script LRU.rsyn

                             _____                  
                            |  __ \                 
                            | |__) |___ _   _ _ __  
                            |  _  // __| | | | '_ \ 
                            | | \ \\__ \ |_| | | | |
                            |_|  \_\___/\__, |_| |_|
                                        __/ /       
                                       |___/        


-------------------------
3rd Party License Notices
-------------------------
1) FLUTE is a software developed by Dr. Chris C. N. Chu at Iowa State University (http://class.ee.iastate.edu/cnchu/)

Running generic reader...
Parsing LEF files...
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
Parsing LEF files... Done (runtime: 0.011106 seconds memory: +4 MB)
Parsing DEF files...
WARNING: PIN gnd doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN vdd doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN clock doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_accessed[1] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_accessed[0] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_enable doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_leastRecentlyUsed[1] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_leastRecentlyUsed[0] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_pageEnable_0 doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_pageEnable_1 doesn't have direction. Setting UNKNOWN_DIRECTION
Omitting further warnings for pin with unknown direction
Parsing DEF files... Done (runtime: 0.041917 seconds memory: +3 MB)
Populating the design...
terminate called after throwing an instance of 'Rsyn::NetAlreadyExistsException'
  what():  Net 'vdd' already exists.
Aborted (core dumped)

Hi, @oharboe.

We do not have support for nets and special nets with the same name.
We also opened your LEF/DEF with Innovus, and it return some warnings and error messages.
Please, check the attached file.

Thanks.
invs.log

Hi, @oharboe.

We do not have support for nets and special nets with the same name.
We also opened your LEF/DEF with Innovus, and it return some warnings and error messages.
Please, check the attached file.

Thanks! the LEF/DEF files are from qflow gscl45nm tech and LRU.v.

@RTimothyEdwards The segfault in FRlefdef is fixed. What do you make of the remaining issues identified above?

Thanks.
invs.log

There are stub nets (with non-default width) in SPECIALNETS which was a limitation of the version of DEF I started with. I now know of some other ways to add these bits of geometry into the NETS section compatible with DEF 5.7 or 5.8, and I will get around to doing that sometime.

However, this one is different. . . it is where a power supply is also a net. If you have routed your power supply, then it is in the SPECIALNETS section. But if you also have, say, only one flop type of DFFSR in your standard cell set, then some of the S and R pins are tied to the power rails. They have to be routed, so they are NETS. . . I guess in theory they could be put under SPECIALNETS. But there is nothing in the DEF spec that says that a net cannot appear in both NETS and SPECIALNETS. Nets may appear multiple times in either section, and there can be multiple NETS and SPECIALNETS sections.

As far as the Innovus warnings/errors: I do not know what is a "generated pitch" is, but. . . you are presenting an already-routed DEF file to the router?

There is an apparent disagreement of scale somewhere. I will see what I can do to figure out where it comes from. One thing that pops out at me is the off-grid errors, which look like they are all due to negative numbers being rounded the wrong way (-759 instead of -780).

Qflow/magic do not use the TRACKS statement. From the Innovus messages I just learned something about how TRACKS are parsed by commercial tools, I guess. On the other hand, this would have no impact on, say, GDS output. If I ever have such a mix and match environment in qflow that I would be passing a placed layout from graywolf to FastRoute4 for routing, then I'll make sure that the TRACKS is understood by FastRoute4. I couldn't care less what Innovus thinks of it.

---Tim

@RTimothyEdwards I wanted to take FRlefdef for a spin, so I took the output from "qflow place" and gave it to FRlefdef.

I now see that LRU_unroute.def exists, so I tried that too. Attached is the updated files, including LRU.v, that uses LRU_unroute.def: lru-unrouted.zip

Much the same result:

# FastRoute4-lefdef/FRlefdef  --no-gui --script LRU.rsyn
[deleted]
Running generic reader...
Parsing LEF files...
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
WARNING: Unsupported INOUT direction in data pin. vdd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER]
Parsing LEF files... Done (runtime: 0.01005 seconds memory: +2 MB)
Parsing DEF files...
WARNING: PIN gnd doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN vdd doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN clock doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_accessed[1] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_accessed[0] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_enable doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_leastRecentlyUsed[1] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_leastRecentlyUsed[0] doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_pageEnable_0 doesn't have direction. Setting UNKNOWN_DIRECTION
WARNING: PIN io_pageEnable_1 doesn't have direction. Setting UNKNOWN_DIRECTION
Omitting further warnings for pin with unknown direction
Parsing DEF files... Done (runtime: 0.033217 seconds memory: +3 MB)
Populating the design...
terminate called after throwing an instance of 'Rsyn::NetAlreadyExistsException'
  what():  Net 'vdd' already exists.
Aborted (core dumped)

Hi, @oharboe. Please, check commit 9e9620d. Your testcases with multiple net definitions should not have problem anymore

@eder-matheus There needs to be an automated test, probably something like a boost unit-test, for this that's run automatically. Retesting edge cases manually is pointless: after a dozen changes in the same area of the code, this will break again. I count dozens of if() statements in this change, it really needs a unit-test.

Hi, @oharboe.
We are closing this issue since load LEF/DEF files are under the responsibility of OpenDB.

Thanks.