Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Fasm2bels fails due to orphan sink #1149

Closed
acomodi opened this issue Nov 12, 2019 · 8 comments
Closed

Fasm2bels fails due to orphan sink #1149

acomodi opened this issue Nov 12, 2019 · 8 comments

Comments

@acomodi
Copy link
Contributor

acomodi commented Nov 12, 2019

While dealing with #1102, to debug the reasons of not having the OSERDES work on HW, I stumbled on an orphan_sink issue in fasm2bels. The error is the following:

// LIOI3_X0Y25 IOI_OLOGIC0_CLK 5816393
// LIOI3_X0Y25 IOI_OCLK_0 5816355
// LIOI3_X0Y25 IOI_LEAF_GCLK5 5816230
// HCLK_IOI3_X1Y26 HCLK_IOI_CK_IGCLK0 1918182
// HCLK_IOI3_X1Y26/HCLK_IOI_CK_IGCLK0 is connected to net via wire_pkey 1918166
// sink node 1322627 connected to source 1627198
// LIOI3_X0Y25/IOI_LEAF_GCLK5 is connected to net via wire_pkey 1918182
// sink node 1322683 connected to source 1627198
// LIOI3_X0Y25/IOI_OCLK_0 is connected to net via wire_pkey 5816230
// sink node 2020629 connected to source 1627198
// LIOI3_X0Y25/IOI_OLOGIC0_CLK is connected to net via wire_pkey 5816355
// sink node 2020667 connected to source 1627198
// LIOI3_X0Y25 IOI_OLOGIC0_CLKDIV 5816395
Traceback (most recent call last):
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/build/env/conda/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/build/env/conda/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/xc7/fasm2bels/__main__.py", line 4, in <module>
    main()
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/xc7/fasm2bels/fasm2bels.py", line 296, in main
    top.make_routes(allow_orphan_sinks=args.allow_orphan_sinks)
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/xc7/fasm2bels/verilog_modeling.py", line 1381, in make_routes
    net_map=self.net_map,
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 700, in make_routes
    allow_orphan_sinks=allow_orphan_sinks
  File "/home/alessandro/projects/symbiflow/tmp/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 610, in expand_sink
    assert False, (sink_node_pkey, tile_name, wire_name, sink_wire_pkey)
AssertionError: (2020669, 'LIOI3_X0Y25', 'IOI_OLOGIC0_CLKDIV', 5816395)

By examining both the fasm file and the routing graph I have double-checked that the route is actually there.
expand_node should be able to find a route to the first sink which is connected to a source, as it happens for the LIOI3_X0Y25 IOI_OLOGIC0_CLK for which the tool can find the connections to the HCLK_IOI_CK_IGCLK0 that already has a connection.
Instead, the tool seems to be unable to find very similar routes for the OLOGIC0_CLKDIV pip.

The problem may be that expand_node cannot find an active upstream connected pip to OLOGIC0_CLKDIV, and this seems to be a possible bug in make_routes as in the top.fasm file the connection is there (to IOI_LEAF_GCLK1):

...
LIOI3_X0Y25.ILOGIC_Y1.ZINV_D
LIOI3_X0Y25.IOI_OCLK_0.IOI_LEAF_GCLK5
LIOI3_X0Y25.IOI_OLOGIC0_CLKDIV.IOI_LEAF_GCLK1
...
@acomodi acomodi changed the title Fasm2bels fails due to orphan_sink Fasm2bels fails due to orphan sink Nov 12, 2019
@acomodi
Copy link
Contributor Author

acomodi commented Nov 12, 2019

@litghost FYI

@acomodi
Copy link
Contributor Author

acomodi commented Nov 12, 2019 •
edited

To reproduce the error is enough to run the vivado_load_dcp target of one of the oserdes tests of #1102

@litghost
Copy link
Contributor

litghost commented Nov 12, 2019 •
edited

Any chance there is a swapping of Y0 and Y1? That might be causing the problem.

@acomodi
Copy link
Contributor Author

acomodi commented Nov 12, 2019

I Have to check it, but I doubt it as I think also the OLOGIC0_CLK would fail as well

@litghost
Copy link
Contributor

OLOGIC0_CLK is a ppip, so it would not have failed. OLOGIC0_CLKDIV does have routing choices, so it is not a ppip.

@acomodi
Copy link
Contributor Author

acomodi commented Nov 13, 2019 •
edited

So, the Y locations should be correct. I am debugging fasm2bels and a strange thing happens during the computation of the maybe_active_pips:

...
SINK WIRE:  IOI_LEAF_GCLK1
SOURCE WIRE:  IOI_OCLK_0
SINK WIRE:  IOI_LEAF_GCLK5
NOT TAKEN SOURCE WIRE:  IOI_OLOGIC0_CLKDIV
...

IOI_OLOGIC0_CLKDIV seems not to be present in the wire_in_tile table.

@acomodi
Copy link
Contributor Author

acomodi commented Nov 14, 2019

I have discovered the issue. It is related with the usage of non-canonical physical tiles, for which the IOI_OLOGIC0_CLKDIV source wire could not be found as the tile_type_pkey did not match any entry in the db.

I have a fix for that in a68cc81

@acomodi
Copy link
Contributor Author

acomodi commented Nov 18, 2019

Solved in #1102. Closing

@acomodi acomodi closed this as completed Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@litghost @acomodi