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

assert site_pin ('I') not in ['HARD1', 'HARD0'] #27

Closed
jgoeders opened this issue Sep 25, 2020 · 7 comments
Closed

assert site_pin ('I') not in ['HARD1', 'HARD0'] #27

jgoeders opened this issue Sep 25, 2020 · 7 comments

Comments

@jgoeders
Copy link
Contributor

I'm trying to run fasm2bels for the attached design. fasm.zip. The bitstream was generated by Vivado 2019.2, and then the fasm created by bit2fasm.py.

PART_FAMILY = "artix7"
PART = "xc7a200tsbg484-1"

It looks like the code is following a route, and then gets to a section of code with this label:

    # There are no active pips upstream from this node, check if this is a
    # site pin connected to a HARD0 or HARD1 pin.  These are connected to the
    # global ZERO_NET or ONE_NET.

and then hits this assertion

assert site_pin in ['HARD1', 'HARD0'], (sink_node_pkey, tile,
AssertionError: (7997249, 'LIOB33_X0Y143', 'IOB_IBUF0', 'I')

https://github.com/SymbiFlow/symbiflow-xc-fasm2bels/blob/master/fasm2bels/make_routes.py#L562

It seems like it unexpectedly hitting an input pad? Any insight on what would in the design would cause this?

Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/__main__.py", line 4, in <module>
    main()
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/fasm2bels.py", line 452, in main
    top.make_routes(allow_orphan_sinks=args.allow_orphan_sinks)
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/models/verilog_modeling.py", line 2267, in make_routes
    for sink_wire, src_wire in make_routes(
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/make_routes.py", line 701, in make_routes
    expand_sink(
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/make_routes.py", line 589, in expand_sink
    expand_sink(
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/make_routes.py", line 589, in expand_sink
    expand_sink(
  File "/home/jgoeders/bfasst/third_party/fasm2bels/fasm2bels/make_routes.py", line 562, in expand_sink
    assert site_pin in ['HARD1', 'HARD0'], (sink_node_pkey, tile,
AssertionError: (7997249, 'LIOB33_X0Y143', 'IOB_IBUF0', 'I')
@litghost
Copy link
Contributor

Can you attach a DCP?

@jgoeders
Copy link
Contributor Author

design.zip

@litghost
Copy link
Contributor

That wire looks pretty boring, unclear what is going on. I'll take a look next week.

@litghost
Copy link
Contributor

I've found the issue. The problem has to do with the PUDC pin on 7-series parts. The relevant problematic code is here: https://github.com/SymbiFlow/symbiflow-xc-fasm2bels/blob/3b72e6f5beb09d85d2ba2957282ef2cf13933b0c/fasm2bels/models/iob_models.py#L322-L328

The proper solution here is to emit the PUDC, and during cleanup remove it if nothing actually connects to it. In your design, the PUDC pin is connected, so the code to simply skip it is broken.

@jgoeders
Copy link
Contributor Author

jgoeders commented Oct 6, 2020 •
edited

OK, from what I can tell this PUDC pin is still an IOB33, but it just also functions as the PUDC pin during configuration. I'm not sure that matters for fasm2bels.

Currently I've just commented these lines out, and the code continues to treat it as any other IOB. Seems to be working fine, although it would be nice to verify somehow that this isn't causing problems elsewhere. Not familiar enough with the code base to understand the implication of commenting this out.

@litghost
Copy link
Contributor

litghost commented Oct 6, 2020

OK, from what I can tell this PUDC pin is still an IOB33, but it just also functions as the PUDC pin during configuration. I'm not sure that matters for fasm2bels.

Like you say, the PUDC does things during configuration. I believe the Vivado bitstream generator is emitting a PULLUP (or PULLDOWN) on the PUDC if the pin is unused. When a design doesn't use the PUDC pin is run through fasm2bels, we don't want to emit a IBUF if that IBUF isn't actually part of the design. When a design does use the PUDC pin, then the IBUF (or other) should be emitted.

@jgoeders
Copy link
Contributor Author

jgoeders commented Apr 2, 2023

Fixed in #63

@jgoeders jgoeders closed this as completed Apr 2, 2023
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 @jgoeders