Giter Club home page Giter Club logo

fpga-tool-perf's Introduction

fpga-tool-perf

Analyze FPGA tool performance (MHz, resources, runtime, etc).

Setup

fpga-tool-perf uses the Miniconda (conda) package manager to install and get all the required tools. Currently, the following tools are available in conda:

  • vtr
  • nextpnr-xilinx
  • yosys (+ yosys-plugins)
  • prjxray

Prior to setting up the conda environment, the F4PGA and QuickLogic data files need to be installed through the following commands:

make install_f4pga
make install_quicklogic

The install packages are extracted in env/<toolchain>/.

To setup the conda environment, run the following commands:

TOOLCHAIN=f4pga make env
TOOLCHAIN=quicklogic make env
TOOLCHAIN=nextpnr make env

fpga-tool-perf can also run Vivado, which is not available in the conda environment and it needs to be installed by the user separately. The user also needs to set the VIVADO_SETTINGS environmental variable, which points to the settings64.sh file to enable Vivado.

Running

With the conda environment correctly installed, run the following to activate the environment:

source env.sh

Once the environment settings have been sourced, you are ready to proceed with the tests, as described below.

Quick start example

python3 fpgaperf.py --toolchain vivado --project oneblink --board arty-a35t

or

python3 fpgaperf.py --toolchain vpr --project oneblink --board basys3

For example, to compare a pure Vivado flow and Yosys -> Vivado flow for an xc7z device, use the following:

# Yosys -> Vivado
python3 fpgaperf.py --toolchain yosys-vivado --project oneblink --board basys3
# Pure Vivado
python3 fpgaperf.py --toolchain vivado --project oneblink --board basys3

Use --help to see additional parameters for the fpgaperf.py script.

Supported toolchains can be queried as follows:

$ python3 fpgaperf.py --list-toolchains
nextpnr-ice40
nextpnr-xilinx
nextpnr-xilinx-fasm2bels
vivado
vpr
vpr-fasm2bels
yosys-vivado

You can check if you have the toolchain environments correctly installed as follows:

$ python3 fpgaperf.py --check-env --toolchain vpr
vpr
  yosys: True
  vpr: True
  prjxray-config: True

Supported projects can be queried as follows:

$ python3 fpgaperf.py  --list-projects
baselitex
blinky
bram-n1
bram-n2
bram-n3
dram-test-64x1d
hamsternz-hdmi
ibex
murax
oneblink
picorv32
picosoc
picosoc-simpleuart
picosoc-spimemio
vexriscv
vexriscv-smp

Exhaustive build

Use exhaust.py to automatically test all projects, toolchain and boards supported:

python3 exhaust.py

It's also possible to run a test against specific project(s), toolchain(s), and/or board(s):

python3 exhaust.py --project blinky oneblink --toolchain vpr

See the build directory for output.

Project structure

This section describes the file and data structure used by this project to let you better understand its inner workings.

  • the project directory contains all the information relative to a specific test in respective YAML files. The data includes:

    • srcs: all the source files needed to run the test
    • top: top level module name of the design
    • name: project name. Note: project names shouldn't contain underscores such that they are clearly separated from other fields when combined into folder names.
    • data: all of the data/memory files needed to run the test
    • clocks: all the input clocks of the design
    • required_toolchains: all the toolchains that are required to correctly run to completion.
    • vendors: all the vendors that are enabled for this project (e.g. xilinx, lattice). Each vendor requires a list of boards enabled for the test project.
  • the src directory contains all the source files needed to build the test project. It also contains the constraints files relative to the various boards supported.

  • the other directory contains two YAML configuration files, describing all the supported boards and vendors in this test suite.

  • the toolchains directory contains the Python scripts that enable a toolchain to be run within fpga-tool-perf.

  • the infrastructure directory contains Python scripts to control the fpga-tool-perf framework to run the tests

Development

Wrapper

wrapper.py creates a simple Verilog interface against an arbitrary verilog module. This allows testing arbitrary Verilog modules against a standard pin configuration. The rough idea is taken from Project X-Ray.

Run wrappers.sh to regenerate all wrappers. Requires pyverilog.

wrapper.py (iverilog based) has the following known limitations:

  • Bidrectional ports are not supported
  • Spaces inside numbers are not supported (ex: 8' h00 vs 8'h00)
  • Attributes (sometimes?) are not supported (ex: (* LOC="HERE" *) )

As a result, sometimes the module definition is cropped out to make running the tool easier (ex: src/picorv32/picosoc/spimemio.v was cropped to src/picosoc_spimemio_def.v).

Inserting a New Project into fpga-tool-perf

These are the basic steps to inserting an existing project into fpga-tool-perf:

Step 1.

Add a folder within fpga-tool-perf/src under the name of the project (make sure there are no underscores - '_' - in the name). For example, for the project named counter:

cd ~/fpga-tool-perf/src
mkdir counter
cd counter

Add the source (Verilog) and data/memory files to this directory.

Create a constr subdirectory, and within it, add the project's .pcf (for F4PGA) and .xdc (for Vivado) files under the name of the board it uses.

mkdir constr
touch constr/basys3.pcf
touch constr/basys3.xdc

If you don't have both the .pcf and .xdc files, you can look at the other projects for examples of how the .xdc and .pcf code correspond.

Step 2.

Within the project directory, create a YAML file with the name of the project.

srcs:
  - src/counter/counter.v
top: top
name: counter
clocks:
  clk: 10.0
vendors:
  xilinx:
    - arty-a35t
    - arty-a100t
    - basys3
required_toolchains:
  - vivado
  - yosys-vivado
  - vpr

Step 3.

Test the newly added project with VPR and Vivado. For example:

python3 fpgaperf.py --project counter --toolchain vpr --board basys3
python3 fpgaperf.py --project counter --toolchain vivado --board basys3

There may be errors if your .xdc or .pcf files have the wrong syntax. Debug, modify, and run until it works, and you have successfully added a new project to fpga-tool-perf.

fpga-tool-perf's People

Contributors

acomodi avatar adamolech avatar ajelinski avatar dependabot-preview[bot] avatar dependabot[bot] avatar hackerfoo avatar jeffherman avatar johndmcmaster avatar kamilrakoczy avatar kboronski-ant avatar kgugala avatar litghost avatar mcmasterg avatar mgielda avatar mithro avatar mkurc-ant avatar mtdudek avatar pgielda avatar robertszczepanski avatar rw1nkler avatar ryancj14 avatar symbiflow-robot avatar tcal-x avatar tgorochowik avatar tjurtsch avatar tmichalak avatar umarcor avatar wtatarski avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fpga-tool-perf's Issues

Add license header to top of all code files

See https://opensource.google/docs/releasing/licenses/

We can either use;

Copyright (C) 2020  The SymbiFlow Authors.

Use of this source code is governed by a ISC-style
license that can be found in the LICENSE file or at
https://opensource.org/licenses/ISC

Or put the full license at the top;

Copyright (C) 2020  The SymbiFlow Authors.

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Allow "sweeping" of a given VPR parameter

There is a number of VPR parameters we will want to investigate the best value for soon. I think the best way is to just "sweep" the value and see what it comes up with.

I think this would be similar to the seed stuff you added previously?

One primary argument we are interested in is the --target_ext_pin_util argument. This controls how aggressively the cluster will pack things into tiles (which can affect routing).

The help from vpr for this argument;


  --target_ext_pin_util TARGET_EXT_PIN_UTIL [TARGET_EXT_PIN_UTIL ...]            
                    Sets the external pin utilization target during clustering.
                    Value Ranges:                                               
                    * 1.0: The packer to pack as densely as possible (i.e. try  
                           to use 100% of cluster external pins)        
                    * 0.0: The packer to pack as loosely as possible (i.e. each
                           block will contain a single mollecule) Values in
                           between trade-off pin usage and packing density
                                                                           
                    Typically packing less densely improves routability, at     
                    the cost of using more clusters. Note that this is only
                    a guideline, the packer will use up to 1.0 utilization if
                    a molecule would not otherwise not in any cluster type.    
                                                                             
                    This option can take multiple specifications in several   
                    formats:
                    * Single Value (e.g. '0.7'): the input pin utilization for 
                                                 all block types (output pin
                                                 utilization defaults to 1.0)   
                    * Double Value (e.g. '0.7,0.8'): the input and output pin
                                                 utilization for all block types
                    * Block Value (e.g. 'clb:0.7', 'clb:0.7,0.8'): the pin
                                                 utilization for a specific
                                                 block type  
                    These can be used in combination. For example:
                       '--target_ext_pin_util 0.9 clb:0.7'                  
                    would set the input pin utilization of clb blocks to 0.7,
                    and all other blocks to 0.9.                         
                     (Default: 1.0)   

Another example would be the --timing_tradeoff argument (in the placement stage) and the --criticality_exp arguments.

  --timing_tradeoff TIMING_TRADEOFF
                    Trade-off control between delay and wirelength during   
                    placement. 0.0 focuses completely on wirelength, 1.0
                    completely on timing (Default: 0.5)

  --max_criticality MAX_CRITICALITY
                    Sets the maximum fraction of routing cost derived from delay
                    (vs routability) for any net. 0.0 means no attention is paid
                    to delay, 1.0 means nets on 

Add timeout mechanism

Some jobs may run for far longer than expected. Add a way for them to time out and record that to the JSON

radiant strategy broken

Was known to not be working. I just observed some tcl error in the output complaining about wrong number arguments.

Refactor and clean up the build system

Currently, there are two things that could be made better, to have a cleaner build system for the tests:

  1. Restructure the ways in which the constraints files are selected to run the exhaust script. This would avoid files duplication.
  2. Allow picking to have a dependency structure, so that a test is performed using another one's results: this comes in hand when running, for instance, the fasm2bels flow, in which data generated from the vpr flow could be re-used, allowing us to have separate fasm2bels tool, which is not incorporated within the VPR flow.

Add support for extracting the VPR "routing information table"

When VPR is running, it outputs the following table when running placement

------- ------- ---------- ---------- ---------- ---------- ------- ---------- -------- ------- ------- ------- ------ --------- ------
      T    Cost Av BB Cost Av TD Cost Av Tot Del P to P Del     CPD       sTNS     sWNS Ac Rate Std Dev R limit    Exp Tot Moves  Alpha
------- ------- ---------- ---------- ---------- ---------- ------- ---------- -------- ------- ------- ------- ------ --------- ------
  0.059  0.9998  1405.0470 44676      1.2679e+05 7.4374     156500000000.000  -1.62e+14 -156500000000.000  0.9980  0.0089 37.0000  1.000     6060  0.500
  0.030  0.9973  1404.2358 45429      1.2656e+05 7.4485     152500000000.000  -1.63e+14 -152500000000.000  0.9941  0.0045 37.0000  1.000    12120  0.500
  0.015  0.9910  1402.7112 44757      1.2695e+05 7.4821     154000000000.000  -1.61e+14 -154000000000.000  0.9875  0.0072 37.0000  1.000    18180  0.500
  0.007  0.9866  1404.5965 45357      1.2669e+05 7.4978     153000000000.000  -1.56e+14 -153000000000.000  0.9752  0.0048 37.0000  1.000    24240  0.500
  0.004  0.9947  1386.8590 46141      1.259e+05  7.4402     150000000000.000  -1.62e+14 -150000000000.000  0.9512  0.0049 37.0000  1.000    30300  0.900
  0.003  0.9878  1385.0031 42649      1.2599e+05 7.4897     160000000000.000  -1.61e+14 -160000000000.000  0.9467  0.0064 37.0000  1.000    36360  0.900
  0.003  0.9941  1384.8312 46297      1.261e+05  7.4572     150000000000.000  -1.62e+14 -150000000000.000  0.9348  0.0050 37.0000  1.000    42420  0.900
  0.003  0.9930  1377.3164 47336      1.2568e+05 7.4401     144000000000.000  -1.67e+14 -144000000000.000  0.9290  0.0080 37.0000  1.000    48480  0.900
  0.002  0.9952  1383.4054 43231      1.2583e+05 7.4167     160500000000.000  -1.65e+14 -160500000000.000  0.9276  0.0050 37.0000  1.000    54540  0.900
  0.002  0.9975  1379.3081 44056      1.2557e+05 7.4138     156000000000.000  -1.62e+14 -156000000000.000  0.9167  0.0052 37.0000  1.000    60600  0.900
  0.002  0.9922  1367.5716 40780      1.2539e+05 7.3734     172500000000.000  -1.64e+14 -172500000000.000  0.9031  0.0046 37.0000  1.000    66660  0.900
  0.002  1.0070  1366.0199 46003      1.2529e+05 7.3377     144500000000.000  -1.55e+14 -144500000000.000  0.8861  0.0060 37.0000  1.000    72720  0.900
  0.002  0.9882  1364.4663 45681      1.2505e+05 7.4373     145500000000.000  -1.66e+14 -145500000000.000  0.8848  0.0051 37.0000  1.000    78780  0.900
  0.001  1.0062  1362.4004 43692      1.2489e+05 7.2775     157000000000.000  -1.62e+14 -157000000000.000  0.8756  0.0045 37.0000  1.000    84840  0.900
  0.001  0.9938  1357.4930 45085      1.2473e+05 7.3188     146500000000.000  -1.57e+14 -146500000000.000  0.8639  0.0046 37.0000  1.000    90900  0.900
  0.001  0.9811  1341.4549 47280      1.244e+05  7.3691     138500000000.000  -1.57e+14 -138500000000.000  0.8408  0.0067 37.0000  1.000    96960  0.900
  0.001  0.9984  1338.5302 45890      1.2418e+05 7.2875     142500000000.000  -1.54e+14 -142500000000.000  0.8282  0.0055 37.0000  1.000   103020  0.900

And the following table when running routing;

Confirming router algorithm: TIMING_DRIVEN.
---- ------ ------- ------- ------- ------- ----------------- --------------- -------- ---------- ---------- ---------- ---------- --------
Iter   Time    Heap    Heap  Re-Rtd  Re-Rtd Overused RR Nodes      Wirelength      CPD       sTNS       sWNS       hTNS       hWNS Est Succ
      (sec)    push     pop    Nets   Conns                                       (ns)       (ns)       (ns)       (ns)       (ns)     Iter
---- ------ ------- ------- ------- ------- ----------------- --------------- -------- ---------- ---------- ---------- ---------- --------
   1   13.7 1.3e+07 2194666    5088   16982    6450 ( 2.743%)  197170 (56.6%) 117500000000.000 -1.644e+14 -117500000000.000 -3.640e+11 -9000000000.000      N/A
   2   14.9 1.6e+07 2321755    3442   14609    3255 ( 1.384%)  195842 (56.2%) 132000000000.000 -1.687e+14 -132000000000.000 -2.642e+12 -25500000000.000      N/A
   3   16.1 1.9e+07 3057604    2748   12825    3399 ( 1.445%)  198408 (56.9%) 153500000000.000 -1.608e+14 -153500000000.000 -4.625e+12 -25000000000.000      N/A
   4   18.1 2.2e+07 3653020    2691   12794    3529 ( 1.501%)  201321 (57.7%) 150500000000.000 -1.774e+14 -150500000000.000 -1.538e+12 -25000000000.000      N/A
   5   19.2 2.4e+07 4088265    2354   12334    2070 ( 0.880%)  208846 (59.9%) 168500000000.000 -1.903e+14 -168500000000.000 -8.756e+12 -38500000000.000      N/A
   6   20.5 2.8e+07 4885353    2261   12022    1846 ( 0.785%)  209549 (60.1%) 158500000000.000 -2.291e+14 -158500000000.000 -4.228e+12 -25000000000.000      N/A
   7   22.3 3.0e+07 5754771    2242   11875    1524 ( 0.648%)  211368 (60.6%) 153000000000.000 -2.045e+14 -153000000000.000 -2.848e+12 -30000000000.000      N/A
   8   23.9 3.3e+07 7030596    2108   11635    1131 ( 0.481%)  215623 (61.8%) 168500000000.000 -2.440e+14 -168500000000.000 -1.147e+13 -60000000000.000      N/A
   9   21.7 2.8e+07 6330047    2008   11393     763 ( 0.324%)  218738 (62.7%) 253500000000.000 -3.972e+14 -253500000000.000 -1.041e+14 -119500000000.000      N/A
  10   17.9 2.3e+07 5469541    1957   11374     552 ( 0.235%)  218191 (62.6%) 253000000000.000 -2.301e+14 -253000000000.000 -1.306e+14 -119500000000.000       36
  11   18.2 2.3e+07 5481704    1938   11261     452 ( 0.192%)  219443 (62.9%) 256500000000.000 -2.265e+14 -256500000000.000 -1.308e+14 -119500000000.000       30

These tables give us an understanding of how well the router / placer is doing. It would be to capture and preserve them.

vpr_xml.sh: remove VPR environment var requirement

As of this writing, symbiflow-arch-defs conda has an incompatible vpr version (its been mostly ignored due to rapidly moving vpr). As a result, vpr_xml.sh is currently requiring an explicit VPR version to be given. Lets remove this once this is fixed

Support carry / no_carry options?

It might be interesting to support running arachne, nextpnr and vpr with and without carry support.

It's something which is interesting now but might not be interesting in the future. I'm currently just just modifying the script directly.

Don't know if we could support that for radiant or icecube?

nextpnr doesn't need -nocarry in synth script

nextpnr has stable carry support now, no need to include the -nocarry any more.

Also, looks like the VPR synth script runs ABC twice which may give better results than arachne or nextpnr's scripts which only run ABC once. This should probably be using synth_ice40 -vpr instead.

Investigate 1 I/O tile on 2 I/O design

Running:

python3 fpgaperf.py --toolchain icecube2-synpro --project oneblink --device "lp8k" --package "cm81" --pcf project/oneblink_lp8k-cm81.pcf

gives

Max frequency: 195.790 MHz
Resource utilization
  BRAM:                0
  CARRY:               23
  DFF:                 24
  GLB:                 1
  IOB:                 1
  LUT:                 24
  PLL:                 0

Set up "cycle" builder / CI system

A cycle builder does the following;

while true:
   if new_upstream_revision:
      update_to_new_revision()
      i = 0
   run_all_tests --seed=i
   save_data(i, revision)
   i++

Basically, it sits at the current HEAD and just runs the build over and over collecting the results.

Generate nicer reports

as suggested by @mithro in #50 (comment) we should generate the following reports:

Settings
================================

+-----------+--------------+
| Setting   | Value        |
+-----------+--------------+
| Family    | xc7          |
| Device    | a35ti        |
| Package   | csg324-1L    |
| Project   | litex-linux  |
| Toolchain | vivado       |
| Strategy  | None         |
| Carry     | False        |
| Seed      | default      |
+-----------+--------------+


================================
FPGA Resource Utilization
================================

+----------+------+--------+---------+
| Resource | Used | Out of | Percent |
+----------+------+--------+---------+
| BRAM     | 40.5 |  8000  |   XXX%  |
| CARRY    | 260  |  8000  |   XXX%  |
| DFF      | 4883 |  8000  |   XXX%  |
| IOB      | 89   |  8000  |   XXX%  |
| LUT      | 6207 |  8000  |   XXX%  |
| PLL      | 1    |  8000  |   XXX%  |
+----------+------+--------+---------+

================================
Clocks
================================

+------------------------------+-----------+---------+-----------+---------+
| Clock Domain                 | Requested | Actual  | Satisfied |  Margin |
+------------------------------+-----------+---------+-----------+---------+
| clock domain soc_pll_clk200  | 200MHz    | 849 MHz | Yes       |  649MHz |
| clock domain soc_pll_clk100  | 100MHz    | 249 MHz | Yes       |  149MHz |
| clock domain soc_pll_clk800  | 800MHz    | 249 MHz | No        | -561MHz |
+------------------------------+-----------+---------+-----------+---------+

================================
Toolchain Resource Usage
================================

+----------------------+-----------+-------------+
|                      | Run Time  | Peak Memory |
| Stage                | (seconds) | (megabytes) |
+----------------------+-----------+-------------+
| preparing            |    0.004  |     100     |
| verilog to bitstream |  178      |    2567     |
|  - synth             |  +XX      |             |
|  - pnr               |  +XX      |             |
|  - bitgen            |  +XX      |             |
+----------------------+-----------+-------------+

Output metadata on failures

Right now metadata is only written on success, not on failure. Even if it has very limited info, failure .csv/.json would be useful to scrape for failures on the performance tracking build server

radiant-lse fails with "fixme: package" with my up5k

$ ./up5k.sh --verbose --fail --toolchain radiant-lse
+ set -e
+ mkdir -p build
+ exhaustive
+ echo 'Running exhaustive project-toolchain search'
Running exhaustive project-toolchain search
++ python3 fpgaperf.py --list-projects
+ for project in '$(python3 fpgaperf.py --list-projects)'
+ '[' -n murax -a murax '!=' murax ']'
++ python3 fpgaperf.py --list-toolchains
+ for toolchain in '$(python3 fpgaperf.py --list-toolchains)'
+ '[' -n radiant-lse -a radiant-lse '!=' arachne ']'
+ continue
+ for toolchain in '$(python3 fpgaperf.py --list-toolchains)'
+ '[' -n radiant-lse -a radiant-lse '!=' icecube2-lse ']'
+ continue
+ for toolchain in '$(python3 fpgaperf.py --list-toolchains)'
+ '[' -n radiant-lse -a radiant-lse '!=' icecube2-synpro ']'
+ continue
+ for toolchain in '$(python3 fpgaperf.py --list-toolchains)'
+ '[' -n radiant-lse -a radiant-lse '!=' icecube2-yosys ']'
+ continue
+ for toolchain in '$(python3 fpgaperf.py --list-toolchains)'
+ '[' -n radiant-lse -a radiant-lse '!=' nextpnr ']'
+ continue
+ for toolchain in '$(python3 fpgaperf.py --list-toolchains)'
+ '[' -n radiant-lse -a radiant-lse '!=' radiant-lse ']'
+ echo

+ run radiant-lse murax
+ toolchain=radiant-lse
+ project=murax
+ '[' project/murax_up5k-sg48.pcf = '' ']'
+ pcf_arg='--pcf project/murax_up5k-sg48.pcf'
++ python3 fpgaperf.py --list-seedable
+ [[ arachne
nextpnr
vpr = *\r\a\d\i\a\n\t\-\l\s\e* ]]
+ seed=
+ run2
+ python3 fpgaperf.py --toolchain radiant-lse --project murax --device up5k --package sg48 --seed '' --pcf project/murax_up5k-sg48.pcf --out-prefix build --verbose
Writing to build/ice40-up5k-sg48_radiant-lse_murax_default_pcf
Copying data file src/murax/Murax.v_toplevel_system_ram_ram_symbol0.bin to build/ice40-up5k-sg48_radiant-lse_murax_default_pcf/Murax.v_toplevel_system_ram_ram_symbol0.bin
Copying data file src/murax/Murax.v_toplevel_system_ram_ram_symbol2.bin to build/ice40-up5k-sg48_radiant-lse_murax_default_pcf/Murax.v_toplevel_system_ram_ram_symbol2.bin
Copying data file src/murax/Murax.v_toplevel_system_ram_ram_symbol1.bin to build/ice40-up5k-sg48_radiant-lse_murax_default_pcf/Murax.v_toplevel_system_ram_ram_symbol1.bin
Copying data file src/murax/Murax.v_toplevel_system_ram_ram_symbol3.bin to build/ice40-up5k-sg48_radiant-lse_murax_default_pcf/Murax.v_toplevel_system_ram_ram_symbol3.bin
Running: /home/tansell/fpga-tool-perf/radiant.sh --syn lse --strategy default
Running: (/home/tansell/fpga-tool-perf/radiant.sh --syn lse --strategy default) |&tee -a /home/tansell/fpga-tool-perf/radiant.sh.txt; (exit $PIPESTATUS )
  cwd: build/ice40-up5k-sg48_radiant-lse_murax_default_pcf
fixme: package
Traceback (most recent call last):
  File "fpgaperf.py", line 907, in <module>
    main()
  File "fpgaperf.py", line 904, in main
    run(args.family, args.device, args.package, args.toolchain, get_project(args.project), out_dir=args.out_dir, out_prefix=args.out_prefix, strategy=args.strategy, seed=seed, verbose=args.verbose, pcf=args.pcf)
  File "fpgaperf.py", line 790, in run
    t.run()
  File "fpgaperf.py", line 672, in run
    self.cmd(root_dir + "/radiant.sh", "--syn %s --strategy %s" % (syn, self.strategy), env=env)
  File "fpgaperf.py", line 146, in cmd
    subprocess.check_call(cmdstr, shell=True, executable='bash', cwd=self.out_dir, env=env)
  File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '(/home/tansell/fpga-tool-perf/radiant.sh --syn lse --strategy default) |&tee -a /home/tansell/fpga-tool-perf/radiant.sh.txt; (exit $PIPESTATUS )' returned non-zero exit status 1
+ false

Build Problems and OS X Support

I'm trying to get this toolchain (minus vivado) running on Mac OS 10.14.6, and have run into a few problems; some may be Mac related, and perhaps that's unsupported, but some seem more general.

Following the Readme:
Set up all tools and added them to my path, set appropriate environment variables.
$ source settings.sh
no such file. From the git history, it looks like it's been renamed env.sh, so I used that instead.
$ make env
no such target. Looks like make conda might be appropriate, since we're setting up a python environment. So I ran that, and did some manual setup that I don't recall at the moment to get things running.
$ python3 fpgaperf.py --toolchain arachne --project oneblink --device "hx8k" --package "ct256" --board "breakout"
fpgaperf.py: error: --family argument required. Looks like it's missing a required flag. Looking at the next example, I set family to xc7. This may well be wrong, but it made the tool run.
That ran the Yosys portion successfully, but then generated the following error:

End of script. Logfile hash: af0a50ac80, CPU: user 0.38s system 0.06s
Yosys 0.9+1706 (git sha1 2bda51ac, gcc 10.0.1 -fPIC -Os)
Time spent: 44% 12x read_verilog (0 sec), 14% 1x share (0 sec), ...
arachne-pnr -d 8k -P ct256 -q -p empty.pcf oneblink.blif -o oneblink_arachne.asc
oneblink.blif:10: fatal error: unknown directive '.subckt'
make: *** [oneblink_arachne.asc] Error 1
rm oneblink.blif

This looks like something I've run into before when trying to read hierarchical blifs with tools that don't support them. But at this point I decided to ask for help.
It seems like the readme is out of date; if anyone could direct me on how to properly get started with this tool, I'd really appreciate it.

Thanks,
Scott

vpr_xml.sh: use tarball instead

Currently we cd into symiflow-arch-defs and execute special targets to make the architecture XML files. However, ideally symiflow-arch-defs would spit out a distribution directory and/or archive such that we don't strictly need the symiflow-arch-defs repo to run VPR. I don't believe symiflow-arch-defs has this today, but update fpga-tool-perf once this is possible

icetime fails on up5k output?

export FOUNDRY="/opt/lscc/iCEcube2.2017.08/LSE"
export SBT_DIR="/opt/lscc/iCEcube2.2017.08/sbt_backend"
export TCL_LIBRARY="/opt/lscc/iCEcube2.2017.08/sbt_backend/bin/linux/lib/tcl8.4"
export LD_LIBRARY_PATH="/opt/lscc/iCEcube2.2017.08/sbt_backend/bin/linux/opt:/opt/lscc/iCEcube2.2017.08/sbt_backend/bin/linux/opt/synpwrap:/opt/lscc/iCEcube2.2017.08/sbt_backend/lib/linux/opt:/opt/lscc/iCEcube2.
2017.08/LSE/bin/lin64"
+ cp my.tmp/outputs/bitmap/toplevel_bitmap.bin my.bin
+ cp my.tmp/outputs/bitmap/toplevel_bitmap_glb.txt my.glb
+ cp my.tmp/outputs/placer/toplevel_sbt.pcf my.psb
+ cp my.tmp/outputs/netlist/toplevel_sbt.v my.vsb
+ cp my.tmp/outputs/netlist/toplevel_sbt.sdf my.sdf
+ cp my.tmp/outputs/netlist/toplevel_timing.rpt my.rpt
+ '[' -n '' ']'
// Reading input .asc file..
// Warning: Device type 'hx8k' and chip '5k' do not match.
// Reading 5k chipdb file..
// Creating timing netlist..

Add Murax SoC as test example

From https://github.com/SpinalHDL/VexRiscv#murax-soc

Murax is a very light SoC (it fits in an ICE40 FPGA) which can work without any external components.

Depending the CPU configuration, on the ICE40-hx8k FPGA with icestorm for synthesis, the full SoC has the following area/performance :

  • RV32I interlocked stages => 51 Mhz, 2387 LC 0.45 DMIPS/Mhz
  • RV32I bypassed stages => 45 Mhz, 2718 LC 0.65 DMIPS/Mhz

This should be small enough to fit on the up5k and the hx8k (and the lp8k) making a good target which hits all our boards?

We should probably generate the verilog once and push it to a repo so people don't have to use the SpinalHDL stuff.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.