AMI Parameter Configurator window one line only

[capn-freako]

Issue Description

Note: This issue is in support of PyBERT Issue 175

There tend to be two primary ways in which the hierarchical structure of an AMI parameter set gets encoded in the actual *.ami file:

Nested Parameters

In this (preferred) case, the *.ami file is actually structured hierarchically:

(example_rx

    (Description "Example Rx model w/ hierarchically defined AMI parameters.")

    (Reserved_Parameters
    ...
    )

    (Model_Specific
        (ctle
            (mode
                (Usage In )
                (Type Integer )
                (List 0 1 )
                (List_Tip "Off" "Manual" )
                (Description "CTLE operating mode." )
            )
            (freq
                (Usage In )
                (Type Float )
                (Range 5000000000.0 1000000000.0 5000000000.0 )
                (Description "CTLE peaking frequency (Hz)." )
            )
            (mag
                (Usage In )
                (Type Float )
                (Range 0.0 0.0 12.0 )
                (Description "CTLE peaking magnitude (dB)." )
            )
            ...
        )
        ...
    )
)

Encoded Parameter Names

Alternatively, some model makers choose to encode the hierarchical structure of the AMI parameter set, using special parameter naming conventions:

(example_rx

    (Description "Example Rx model w/ hierarchically encoded AMI parameter names.")

    (Reserved_Parameters
    ...
    )

    (Model_Specific
         (ctle_mode
             (Usage In )
             (Type Integer )
             (List 0 1 )
             (List_Tip "Off" "Manual" )
             (Description "CTLE operating mode." )
         )
         (ctle_freq
             (Usage In )
             (Type Float )
             (Range 5000000000.0 1000000000.0 5000000000.0 )
             (Description "CTLE peaking frequency (Hz)." )
         )
         (ctle_mag
             (Usage In )
             (Type Float )
             (Range 0.0 0.0 12.0 )
             (Description "CTLE peaking magnitude (dB)." )
         )
        ...
    )
)

The first method (hierarchical *.ami file w/ nested parameter groups) is preferred because it makes the hierarchical structure of the AMI parameter set explicit and does not depend on any particular parameter name encoding scheme, which must then be translated into a parser.

Indeed, properly hierarchically written *.ami files pose no problem for PyBERT/PyIBIS-AMI, which simply reflects their hierarchy in the GUI model configuration dialog it creates, resulting in a well balanced and spatially pleasing layout.

However, *.ami files written using the encoded parameter name scheme pose a problem, as their flat nature often results in model confiugration dialogs that are either too wide or too tall for the screen, causing the user to have to annoyingly pan left/right, or up/down, in order to finish configuring the model.

The goal of this issue is to better accommodate those incorrectly written, flat *.ami files, by somehow intelligently decoding the parameter naming scheme into the original parameter hierarchy.

[capn-freako]

Current Status

The code is currently broken, due to this line.
HFlow needs to be reverted to HGroup.
However, making just that change will not solve the problem of configuration dialogs ending up too wide or too tall.

Action Items

• Create a new test case, to capture this during testing.
  • Is this possible? I don't think we have any GUI support during test runs.
    ==> Won't do; don't have the necessary GUI support while testing.
• Revert HFlow to HGroup, as per above.
• Figure out how to accommodate parameter configuration dialogs that would be either too short&wide, or too tall&narrow, by default.
  • That is, devise some parsing scheme for composite AMI parameter names, which can correctly recover the hierarchy of the AMI parameter set, so that the model configuration dialog may be laid out appropriately.
    ==> Believe fixed. Am now parsing parameter names of the form: <group>_<param>, such that all with a common <group> element end up in the same VGroup. This is yielding a pleasing spatial layout for all models I've tried.

[capn-freako]

Hi @jdpatt ,

Do you remember if this line was only added for GUI aesthetics, or if there was some deeper functional purpose to it?

Thanks,
-db

[jdpatt]

Looking at git blame for that line, it looks like you introduced it when working on some ADI support. b26985d

[capn-freako]

Hi @jdpatt ,

Wrt/ my first action item above, do you see anyway to accomplish this, given that our testing offers no GUI support?

Thanks,
-db

[capn-freako]

Hi @jdpatt ,

I just pushed a fix.
When you have time, could you run this branch on some random IBIS-AMI models and just make sure that the model configuration dialog actually looks "reasonable" in all cases?

Thanks,
-db

[jdpatt]

I wonder if a VGroup and setting the view to resizable and scrollable is more flexible. You can't see all at once but for smaller screens that will help the overflow more. Swapping back to a HGroup will fix the regression but something like the stratix10 rx model still makes a very wide or tall regardless of HGroup or VGroup.

PyAMI/src/pyibisami/ami/parser.py

Lines 145 to 153 in cc88eec

	def default_traits_view(self):
	"Default Traits/UI view definition."
	view = View(
	resizable=False,
	buttons=ModalButtons,
	title=f"{self._root_name} AMI Parameter Configurator",
	)
	view.set_content(self._content)
	return view

Change to

    def default_traits_view(self):
        "Default Traits/UI view definition."
        view = View(
            resizable=True,  # Change from False
            scrollable=True, # Add this Line
            # Maybe set a default width/height 800/600 (something smaller than the main gui.)
            buttons=ModalButtons,
            title=f"{self._root_name} AMI Parameter Configurator",
        )
        view.set_content(self._content)
        return view

PyAMI/src/pyibisami/ami/parser.py

Line 634 in cc88eec

return (HGroup(*gui_items), new_traits)

Change to:

    return (VGroup(*gui_items), new_traits)

[capn-freako]

something like the stratix10 rx model still makes a very wide or tall regardless of HGroup or VGroup

Is that true, even of my most recent check-in?
I would expect not, but please let me know if so.
In the meantime, I'll see if I happen to have the Stratix-10 model and try it myself.

Thanks,
-db

[capn-freako]

Hmmm, this is interesting: I found a site for Altera FPGA IBIS models
However, it only seems to offer the IBIS portion of the model, not the AMI portion.
@jdpatt , do you know what's going on here?

[capn-freako]

Hi @jdpatt ,

You don't happen to know the answer to this question, do you?

Thanks,
-db

[jdpatt]

So you have set the View's width and the Item's width to no avail? Did you try using a negative or fractional number from the docs to override the "optimal" width and force a width? Seem like using a positive number is just a suggestion and the toolkit will come up with another number that it thinks is best but it should still be less than width which I guess you are not seeing. https://docs.enthought.com/traitsui/api/traitsui.item.html#traitsui.item.Item.width

width = Float(-1.0)
Requested width of the editor (in pixels or fraction of available width). For pixel values (i.e. values not in the range from 0.0 to 1.0), the actual displayed width is at least the maximum of width and the optimal width of the widget as calculated by the GUI toolkit. Specify a negative value to ignore the toolkit’s optimal width. For example, use -50 to force a width of 50 pixels. The default value of -1 ensures that the toolkit’s optimal width is used.

A value in the range from 0.0 to 1.0 specifies the fraction of the available width to assign to the editor. Note that the value is not an absolute value, but is relative to other item’s whose width is also in the 0.0 to 1.0 range. For example, if you have two item’s with a width of 0.1, and one item with a width of 0.2, the first two items will each receive 25% of the available width, while the third item will receive 50% of the available width. The available width is the total width of the view minus the width of any item’s with fixed pixel sizes (i.e. width values not in the 0.0 to 1.0 range).

Item(
    "file_path",
    editor=FileEditor(),
    width=-300,          # key being the negative sign or try a fractional width=0.3
)