Problem with AMD vendor libraries

[DrPiWork]

I try to analyze a design using the AMD UNISIM library.

I get errors like Entity 'IBUFG' not found for component 'IBUFG' in library 'UNISIM'.
I agree that these errors are legitimate.
But in this case, we should have a mean to tell pyVHDLModel to ignore the error. Right ?

[Paebbels]

Uff. So we need to allow for black boxes.

I could imaging the following:

• Design has a AllowBlackBox setting.
• Library has a AllowBlackBox setting.

If a symbol is resolved and the component is from library Unisim, black boxes are acceptable, while the remaining design creates error.

I'm also investigating how to handle warnings in Python. I have a vision for a concept similar to exceptions, but they can be resumed.

[DrPiWork]

The Library has a AllowBlackBox setting. is my preferred choice. This allows to keep verification on other parts of the design.

I'm also investigating how to handle warnings in Python. I have a vision for a concept similar to exceptions, but they can be resumed.

When an exception is caught, it can be re-raised like this :

    try: 
        int('N/A') 
    except ValueError: 
        print("Didn't work") 
        raise

or like this to catch all exceptions :

try: 
 ... 
except Exception as e: 
    # Process exception information in some way 
    ... 
    # Propagate the exception 
    raise

e is optional and can be used for advanced usage.

But maybe I misunderstood the they can be resumed statement.

[Paebbels]

But maybe I misunderstood the they can be resumed statement.

Actually, yes ;)

---

Right now, any programming language I know, will abort the execution of the current subprogram (function, method, ...) when an exception is raised. Then the exception traverses its way upwards in the call stack until it reaches either a try-catch/try-except block or it reaches the entry point of the program. In case the exception is caught somewhere on its way upwards, it can be handled. Usually, the exception gets assigned to a variable like e or ex. Then its message, content etc. can be used e.g. by gathering it in a list/queue. The list can be printed by the application e.g. in a error report after executing the libraries algorithm.

Of cause, we can throw:

• another exception (exception transformation)
• another exception attached with the current exception (exception chaining), or
• same exception (re-throw / re-raise)

upwards, but it's only upwards the in the call stack.

I would like to go down to the exception source and continue execution. Imagine, not to throw an exception, but throw a warning and after someone caught that warning (saved in a list or printed it or just ignored it), we could resume the execution deep down in the code after the raise statement.

---

What other alternatives exist:

1. A library could print warnings directly -> very bad design
   • no control by the application when and where the library prints and how it's formatted or translated
2. Use a global data structure, e.g. a list of warnings -> no parallel execution / multi-threading
   • writing warnings causes interleaved outputs from multiple threads
3. Using Python's logger
   • Loggers create a hierarchy per code hierarchy, but not per thread/call hierarchy
4. Handing over a variable for collecting warning to every call -> lot's of work
   • every method needs to accept such a parameter and pass it downwards

---

Ok, let's construct another idea:
It should behave like an exception (bubbling upwards) and like a coroutine which can be continued by the caller after using yield in the callee. The problem of yield and coroutines is, it cannot be done across multiple layers of nested function calls.

[DrPiWork]

I see what you mean.

Maybe PubPub can help achieve what you want to do.
With a well thought topics hierarchy, you can do interesting things.

To try it : pip install pypubsub.

[Paebbels]

The Library has a AllowBlackBox setting. is my preferred choice.

Sorry, I was not specific enough. Multiple layers in the logical hierarchy of language constructs can be marked as AllowBlackbox.

1. The Design, then it's allowed every where.
2. A Library like unisim, so blackboxes are limited to that library.
3. A Package like unisim.VComponents, so blackboxes are limited to components listed in that package.
4. An entity, an architecture (in case of locally defined components)

The value can be True, False and None. In case of None at a package level, it looks for a value at the library level, if this is also inconclusive, it looks at the design level.

By rewriting all "..." & x"..." expressions in unisim.VComponents plus adding the discussed feature, I was able to run the analysis algorithm. It writes these warnings for a small test design instantiating a BUFG and IBUFDS:

# Found a blackbox for 'clockinputbuffer: IBUFDS'.
# Found a blackbox for 'clockbuffer: BUFG'.

The used Python code looks like this:

design = Design()
design.LoadDefaultLibraries(IEEEFlavor.Synopsys)

unisimLibrary = design.GetLibrary("Unisim")
unisimLibrary.AllowBlackbox = True
document = Document(self._root / "dom/examples/unisim_VCOMP.vhd")
design.AddDocument(document, unisimLibrary)

topLibrary = design.GetLibrary("top")
document = Document(self._filename)
design.AddDocument(document, topLibrary)

design.Analyze()

Tomorrow, I can clean up the code and push it.