Skip to content

Segmentation fault in ODIN+Yosys flow for a very simple design #2007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
aman26kbm opened this issue Apr 12, 2022 · 1 comment
Closed

Segmentation fault in ODIN+Yosys flow for a very simple design #2007

aman26kbm opened this issue Apr 12, 2022 · 1 comment
Assignees

Comments

@aman26kbm
Copy link
Contributor

aman26kbm commented Apr 12, 2022

Expected Behaviour

No segmentation fault should happen.

Current Behaviour

I'm seeing a SIGSEGV happening when I run the yosys+odin flow on a very simple design, in a specific case.

I have attached the design. Here's the failing case:

Failure case:
Design file: Attached
Flow: ODIN+yosys
Arch file: arch/COFFE_22nm/k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml

But I tried this file with some other architectures and flows, and they all passed:

Pass:
Design file: Attached
Flow: ODIN only
Arch file: arch/COFFE_22nm/k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml

Pass:
Design file: Attached
Flow: ODIN+yosys
Arch file: arch/timing/k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml

Pass:
Design file: Attached
Flow: ODIN only
Arch file: arch/timing/k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml

I am suspecting the issue is with this statement:
assign tmp_product = a_reg0 * b_reg0;
tmp_product is 65 bits, a_reg0 is 32 bits and b_reg0 is 34 bits.
Typically, you'd have tmp_product be 66 bits in such a case.
So, I modified the design and changed signal widths from 65 to 66 in the file.

With that, it passes with all the 4 cases:

  1. ODIN only flow, arch file = arch/COFFE_22nm/k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml
  2. ODIN+yosys flow, arch file = arch/COFFE_22nm/k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml
  3. ODIN only flow, arch file = arch/timing/k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml
  4. ODIN+yosys flow, arch file = arch/timing/k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml

Possible Solution

Steps to Reproduce

Design file:
temp2.zip

Arch files are mentioned in the description above.

Command
../../scripts/run_vtr_flow.py --const_gen_inference comb --timing_report_detail aggregated --route_chan_width 300 -elaborator yosys -fflegalize

Context

Moving this issue from email discussion to github for easier tracking.

Your Environment

  • VTR revision used: master
  • Operating System and version: Ubuntu 18.04
  • Compiler version:
@aman26kbm
Copy link
Contributor Author

Hey @sdamghan , I am seeing another issue which seems to be related to this multiplier issue.

I'm running yosys+odin flow. I am attaching a design file. I'm running using the same architecture: arch/COFFE_22nm/k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml

The error I get is from ABC:
/export/aman/vtr_aman2/vtr-verilog-to-routing/abc/src/base/abc/abcFanio.c:92: Abc_ObjAddFanin: Assertion `!Abc_ObjIsNet(pObj) || !Abc_ObjFaninNum(pObj)' failed

Adding some print statements around this error, it seems to point to some of the multiplier code in the blif file (I couldn't exactly tell because the net name wasn't matching in the BLIF file, which was weird).

A comment next to that assertion in ABC says that there is a net with multiple fanins, but I am suspecting there is a net with 0 fanins, but I'm not sure. Looks like yosys+odin is generating an incorrect netlist.

Another point to note that this design passes when I use the flagship VTR architecture (arch/timing/k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml).

Please take a look.

conv.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants