As a user,

It would be nice to have the "Observed Value" Field be standardized to show percentages of "successful" validations, vs a mix of 0% / 100%. This causes confusion as there are different levels of validation outputs with different verbage (making someone not used to the expectations confused) I've given an example below in a screenshot for what I mean:

![image](https://user-images.g

Hi there,

I think there might be a mistake in the documentation. The Understanding Scaled F-Score section says

The F-Score of these two values is defined as:

$$ \mathcal{F}_\beta(\mbox{prec}, \mbox{freq}) = (1 + \beta^2) \frac{\mbox{prec} \cdot \mbox{freq}}{\beta^2 \cdot \mbox{prec} + \mbox{freq}}. $$

$\beta \in \mathcal{R}^+$ is a scaling factor where frequency is favored if $\beta

SUMMARY

When you create a BOM, you can add additional attributes columns (thanks for that, it is really useful).
But it is not saved. You have to enter it each time.

SOLUTION

Quick fix, remember the added attributes during a session.

For the future, add this in the project settings when it is saved.

FuseSoC supports use flags, but doesn't document which use flags are actually set. This needs to be documented.

Currently we set:

• A target use flag target_TARGETNAME, e.g. target_sim if fusesoc is called with --target=sim.
• A tool use flags tool_TOOLNAME, e.g. tool_verilator if fusesoc is called with --tool=verilator

Support for user-defined use flags is being developed in #26

Proposed Behaviour

None of the core VPR algorithms should care if the relevant t_physical_tile is an input / output / IO type.

Current Behaviour

Some behavior is still dependent on whether a tile is an input / output / IO type.

Possible Solution

The relevant code shouldn't need to care. Once all callsites of is_input_type/is_output_type/is_io_type are removed, the

Adding a description for the parameters will help the users understand how to specify values for each parameter. For example, the format of the longitude in Yelp.businesses table; the maximum limit of the results that a user can expect (if we incorporate limit parameter in the future).

It would be great if there was an option to preserve the original order of variables in plot_histogram(). Currently, variables within each page of the output seem to be ordered alphabetically but the pages themselves follow the original order.

Here is a simple example for Vivado.

https://github.com/SymbiFlow/fpga-tool-perf/blob/f8438d0447ae808fd1434073b037fa30b274c423/fpgaperf.py#L444-L506

    def vivado_resources(self):
        report_path = self.out_dir + "/" + self.project_name + ".runs/impl_1/top_utilization_placed.rpt"
        with open(report_path, 'r') as fp:
            report_data = fp.read()
            repo