Giter VIP home page Giter VIP logo

google / cfu-playground Goto Github PK

View Code? Open in Web Editor NEW
442.0 28.0 118.0 40.66 MB

Want a faster ML processor? Do it yourself! -- A framework for playing with custom opcodes to accelerate TensorFlow Lite for Microcontrollers (TFLM). . . . . . Online tutorial: https://google.github.io/CFU-Playground/ For reference docs, see the link below.

Home Page: http://cfu-playground.rtfd.io/

License: Apache License 2.0

Makefile 0.29% C 3.08% Assembly 0.03% C++ 33.56% Shell 0.18% Python 12.02% Verilog 50.37% RobotFramework 0.04% Dockerfile 0.01% SystemVerilog 0.05% CMake 0.01% Scala 0.13% Jupyter Notebook 0.24%
tflite tflm tensorflow

cfu-playground's Introduction

CFU Playground

Want a faster ML processor? Do it yourself!

This project provides a framework that an engineer, intern, or student can use to design and evaluate enhancements to an FPGA-based “soft” processor, specifically to increase the performance of machine learning (ML) tasks. The goal is to abstract away most infrastructure details so that the user can get up to speed quickly and focus solely on adding new processor instructions, exploiting them in the computation, and measuring the results.

This project enables rapid iteration on processor improvements -- multiple iterations per day.

This is how it works:

  • Choose a TensorFlow Lite model; a quantized person detection model is provided, or bring your own.
  • Execute the inference on the Arty FPGA board to get cycle counts per layer.
  • Choose an TFLite operator to accelerate, and dig into that code.
  • Design new instruction(s) that can replace multiple basic operations.
  • Build a custom function unit (a small amount of hardware) that performs the new instruction(s).
  • Modify the TFLite/Micro library kernel to use the new instruction(s), which are available as intrinsics with function call syntax.
  • Rebuild the FPGA Soc, recompile the TFLM library, and rerun to measure improvement.

The focus here is performance, not demos. The inputs to the ML inference are canned/faked, and the only output is cycle counts. It would be possible to export the improvements made here to an actual demo, but currently no pathway is set up for doing so.

With the exception of Vivado, everything used by this project is open source.

Disclaimer: This is not an officially supported Google project. Support and/or new releases may be limited.

This is an early prototype of a ML exploration framework; expect a lack of documentation and occasional breakage. If you want to collaborate on building out this framework, reach out to [email protected]! See "Contribution guidelines" below.

Required hardware/OS

  • One of the boards supported by LiteX Boards. Most of LiteX Boards targets should work.
    It has been tested on the Arty A7-35T/100T, iCEBreaker, Fomu, OrangeCrab, ULX3S, and Nexys Video boards.
  • The only supported host OS is Linux (Debian / Ubuntu).

You don't need any board if you want to run Renode or Verilator simulation.

Assumed software

  • FPGA Toolchain: that depends on a chosen board. If you already have a toolchain installed for your board, you can use that.

For a board with a Xilinx XC7 part, you can use either Vivado, which must be manually installed (here's our guide), or the open-source SymbiFlow tool chain, which can be easily installed using Conda (see the Setup Guide).

For boards with Lattice iCE40, ECP5, or Nexus FPGAs, you can install the appropriate set of open source tools either via Conda (see the Setup Guide) or on your own by building from source. Or, you can use the Lattice toolchain (Radiant/Diamond).

If you want to try things out using Renode simulation, then you don't need either the board or toolchain. You can also perform Verilog-level cycle-accurate simulation with Verilator, but this is much slower. Renode is installed by the setup script.

Other required packages will be checked for and, if on a Debian-based system, automatically installed by the setup script below.

Setup

Clone this repo, cd into it, then get run:

scripts/setup

Use with board

The default board is Arty. If you want to use different board you must specify target, e.g. TARGET=digilent_nexys_video.

  1. Build the SoC and load the bitstream onto Arty:
cd proj/proj_template
make prog

This builds the SoC with the default CFU from proj/proj_template. Later you'll copy this and modify it to make your own project.

  1. Build a RISC-V program and execute it on the SoC that you just loaded onto the Arty:
make load

Use without board

If you don't have any board supported by LiteX Boards you can use Renode or Verilator to simulate it.

To use Renode to execute on a simulator on the host machine (no Vivado or Arty board required), execute:

make renode

To use Verilator to execute on a cycle-accurate RTL-level simulator (no Vivado or Arty board required), execute:

make PLATFORM=sim load

Most useful make flags

Option Explanation Example Default
PLATFORM Choose which SoC platform you want to build: hps or sim or common_soc make bitstream PLATFORM=hps common_soc
TARGET Choose one of many targets from LiteX Boards repository, common_soc will take BaseSoC from specified target.py make bitstream TARGET=nexys_video_board digilent_arty
USE_VIVADO Use Vivado toolchain make bitstream USE_VIVADO=1 0
USE_SYMBIFLOW Use Symbiflow toolchain make bitstream USE_SYMBIFLOW=1 0
UART_SPEED Choose UART baudrate make bitstream UART_SPEED=115200 3686400
IGNORE_TIMING Ignore timing contraints (only for Vivado) make bitstream USE_VIVADO=1 IGNORE_TIMING=1 0

Underlying open-source technology

  • LiteX: Open-source framework for assembling the SoC (CPU + peripherals)
  • VexRiscv: Open-source RISC-V soft CPU optimized for FPGAs
  • Amaranth: Python toolbox for building digital hardware

Licensed under Apache-2.0 license

See the file LICENSE.

Contribution guidelines

If you want to contribute to CFU Playground, be sure to review the contribution guidelines. This project adheres to Google's code of conduct. By participating, you are expected to uphold this code.

cfu-playground's People

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  avatar

Watchers

 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

cfu-playground's Issues

about proj_template demo code

Hi, @tcal-x :

I found this sample will stop output in my current setting, qmtech wukong board + buad rate 3000000. so I make some change to pass the stop problem.

here is the code.

static void do_exercise_cfu_op0(void)
{
puts("\r\nExercise CFU Op0 aka ADD\r\n");
int count = 0;
int pass_count = 0;
int fail_count = 0;

for (int a = -0x71234567; a < 0x68000000; a += 0x10012345)
{
    for (int b = -0x7edcba98; b < 0x68000000; b += 0x10770077)
    {
        int cfu = cfu_op0(0, a, b);
        if (cfu != a + b) 
        {
            printf("[%4d] a: %08x b:%08x a+b=%08x cfu=%08x FAIL\r\n", count, a, b, a + b, cfu);
            fail_count++;
        } else {
            pass_count++;
        }
        count++;
    }
}
printf("\r\nPerformed %d comparisons, %d pass, %d fail\r\n", count, pass_count, fail_count);

}

BTW, I also met the undefined code behaviour error, if I reduce the if (cfu != a + b){} statement. the gcc will complain the "a + b" is not defined. so I change the optimization level form O3 to O1 to avoid this error.

BR, Akio

crash-course/gateware.html hello_led.py with Arty A7

@tcal-x
https://cfu-playground.readthedocs.io/en/latest/crash-course/gateware.html
"If Using The Arty A7" gives some substitutions, but does not say what to do for main()
I randomly guessed:

from nmigen_boards.arty_a7 import *

if __name__ == "__main__":
  dut = TestLEDModule()
  p = ArtyA7Platform()
  p.build( dut )

but that does not work

(nmigen-tutorial) sauron:~/fpga/nmigen-tutorial/nmigen_getting_started/hello_leda7$ python leda7.py
Traceback (most recent call last):
  File "/home/merlin/fpga/nmigen-tutorial/nmigen_getting_started/hello_leda7/leda7.py", line 24, in <module>
    p = ArtyA7Platform()
NameError: name 'ArtyA7Platform' is not defined

Can't bump tflite-micro: new "PIL" (Pillow) Python dependency

I tried bumping the tflite-micro submodule to current main, and encounter "No module named 'PIL'" when building software.

I don't think we have a precedent of using pip to install a missing Python package. I tried cloning https://github.com/python-pillow/Pillow under third_party/python/, but it was not found. It may be that the Pillow repository is structured a bit differently than other Python repos -- there is a PIL directory at Pillow/src/PIL.

Or perhaps we're currently not setting up PYTHONPATH for the tflite-micro build.

Enable any LiteX-supported board to be used.

CFU-Playground currently supports Arty 35T and Nexys Video boards. The difference between them is very small, but the current setup requires duplication of at least a couple of files in the soc/ directory (arty.mk, arty.py, nexys_video.mk, nexys_video.py). Instead, the board should be a parameter so that just one .mk and one .py file are needed.

Of course, not all LiteX-supported boards have the fabric resources to handle a "full" VexRiscv variant, or the memory to handle both the loaded executable and the necessary work space (e.g. for the tensor arena), so we may want to perform some up-front checks.

about image format of hps_models

Hi:

right now, I'm trying to add some framebuffer utility functions to help me to show some information on framebuffer via qmtech wukong board's hdmi output.

I met a problem which is about image format of hps_model.
when I use https://rawpixels.net to check the mnv2's image data, it is RGB24. pixel order is RGB, packed. the image is correct shown very normal.

after apply the same setting on the image of hps_models, there is not shown correctly.
like the following image.

圖片

If i change the rawpixel setting to the following shows. I got the nearest image.

圖片

Could some body do me a favor to tell me the right format of hps_model's image ??

BR, Akio

Use litex-renode scripts to gernerate Renode configurations

Although CFU-Playground uses any board given as a parameter, Renode tests are specific to some predefined platforms.

My suggested list of steps:

  • Add a dependency for https://github.com/litex-hub/litex-renode
  • Use it in the build flow, so that the repl files are autogenerated.
  • Create a generic RESC file that loads the autogenerated REPL file from a predefined location
  • Update the running flow and instructions, so that it's used
  • Remove old RESC/REPL files
  • Update the testing scripts to use the new flow.
  • Extend the testing infrastructure to test more examples/platforms

Tensorflow model evaluation hangs when CFU support is turned off

I was building for HPS with CFU support turned off in the design, using a local hack like this:

--- a/soc/hps.mk
+++ b/soc/hps.mk
@@ -34,7 +34,7 @@ endif

 PROJ_DIR:=  $(CFU_ROOT)/proj/$(PROJ)
 CFU_V:=     $(PROJ_DIR)/cfu.v
-CFU_ARGS:=  --cpu-cfu $(CFU_V)
+#CFU_ARGS:=  --cpu-cfu $(CFU_V)

 SOC_NAME:=  hps.$(PROJ)
 OUT_DIR:=   build/$(SOC_NAME)

and then running:

make -C proj/proj_template PLATFORM=hps bitstream software

If I use the menu to try and execute CFU op0, the application freezes. This is expected, since the CPU tried to execute an illegal instruction.

If I use the menu to try and evaluate pdti8, the application also freezes here:

Tests for pdti8 model
=====================
 1: Run with zeros input
 2: Run with no-person input
 3: Run with person input
 g: Run golden tests (check for expected outputs)
 x: eXit to previous menu
pdti8> 3

Running Run with person input
Classify Person
Copied 9216 bytes at 0x0x40005680
Running pdti8

Since I am building proj/proj_template there are no customisations being applied to Tensorflow so I don't think it could be executing a CFU op. I was expecting it to evaluate the model as normal.

Hang encountered with pdti8 tests using proj/mnv2_first/.

On current main, after PR #40 , a hang can be reliably reproduced (instructions below). If printf() statements are added, the hang disappears. Thus it seems there is not a logical error with the CFU and software, but perhaps a subtle hardware error, maybe with the CPU but maybe not. No hangs were seen with mnv2.

To reproduce: build and program the bitstream as usual; build the software as usual; load the software for live interaction ("make load"). Then type "1 1 1 1". These commands specify model tests, choose pdti8, run the inference with zeros input, and finally run inference with zeros input again, at which point the hang is encountered. If you exit the interactive session with ctrl-C, and then reload the software ("make load"), then type "1 1 1", you should see the hang the first time inference is run. But if you reprogram the bitstream, then you need to run inference twice to see the hang again.

The hang can be reproduced in Verilator simulation ("make PLATFORM=sim load"). It hangs at exactly the same place of the second inference: layer 5, which is the second CONV_2D layer.

If a printf is added inside the pixel loop of CONV_2D to print out the value of "p" each iteration, the hang disappears.

I experimented building the CPU with no data cache, since data cache misses can cause instructions to be re-executed, which in particular would cause problems with stateful CFUs as is the case here; but I still saw the hang with no data cache.

RTD docs need disclaimer

"Disclaimer: This is not an officially supported Google project. Support and/or new releases may be limited."

proj_template/ make prog doesn't select which python3 it needs

I've run
sauron:~/fpga/CFU-Playground$ ./scripts/setup
and it worked fine.

Then

sauron:~/fpga/CFU-Playground/proj/proj_template$ make prog
(...)
INFO:SoC:IRQ Handler (up to 32 Locations).
IRQ Locations: (2)
- uart   : 0
- timer0 : 1
INFO:SoC:--------------------------------------------------------------------------------
Traceback (most recent call last):
  File "./common_soc.py", line 54, in <module>
    main()
  File "./common_soc.py", line 50, in main
    workflow.run()
  File "/home/merlin/fpga/CFU-Playground/soc/board_specific_workflows/general.py", line 114, in run
    self.load(soc, soc_builder)
  File "/home/merlin/fpga/CFU-Playground/soc/board_specific_workflows/general.py", line 103, in load
    prog.load_bitstream(bitstream_filename)
  File "/home/merlin/fpga/CFU-Playground/third_party/python/litex/litex/build/openocd.py", line 21, in load_bitstream
    config = self.find_config()
  File "/home/merlin/fpga/CFU-Playground/third_party/python/litex/litex/build/generic_programmer.py", line 72, in find_config
    import requests
ModuleNotFoundError: No module named 'requests'
sauron:~/fpga/CFU-Playground/proj/proj_template$ type python3
python3 is hashed (/opt/symbiflow/xc7/conda/envs/xc7/bin/python3)

../../soc/common_soc.py runs env python3 but I found nothing in
https://cfu-playground.readthedocs.io/en/latest/setup-guide.html
that selects/chooses which python3 should be run.

The system python3 works worse

    raise YosysError("Could not find an acceptable Yosys binary. The `nmigen-yosys` PyPI "
nmigen._toolchain.yosys.YosysError: Could not find an acceptable Yosys binary. The `nmigen-yosys` PyPI package, if available for this platform, can be used as fallback

and the fomu python3 doesn't work either

sauron:~/fpga/CFU-Playground/proj/proj_template$ type python3
python3 is /home/merlin/fpga/fomu-toolchain-linux/bin/python3
sauron:~/fpga/CFU-Playground/proj/proj_template$ make prog
/home/merlin/fpga/CFU-Playground/scripts/pyrun /home/merlin/fpga/CFU-Playground/proj/proj_template/cfu_gen.py
Traceback (most recent call last):
  File "/home/merlin/fpga/CFU-Playground/proj/proj_template/cfu_gen.py", line 38, in <module>
    main()
  File "/home/merlin/fpga/CFU-Playground/proj/proj_template/cfu_gen.py", line 31, in main
    new_verilog = verilog.convert(cfu, name='Cfu', ports=cfu.ports)
  File "/home/merlin/fpga/CFU-Playground/third_party/python/nmigen/nmigen/back/verilog.py", line 61, in convert
    return _convert_rtlil_text(rtlil_text, strip_internal_attrs=strip_internal_attrs)
  File "/home/merlin/fpga/CFU-Playground/third_party/python/nmigen/nmigen/back/verilog.py", line 10, in _convert_rtlil_text
    yosys = find_yosys(lambda ver: ver >= (0, 9))
  File "/home/merlin/fpga/CFU-Playground/third_party/python/nmigen/nmigen/_toolchain/yosys.py", line 228, in find_yosys
    raise YosysError("Could not find an acceptable Yosys binary. The `nmigen-yosys` PyPI "
nmigen._toolchain.yosys.YosysError: Could not find an acceptable Yosys binary. The `nmigen-yosys` PyPI package, if available for this platform, can be used as fallback
make: *** [../proj.mk:187: generate_cfu] Error 1

Switch to newlib

@danc86 points out that the way CFU-Playground currently builds mixes some elements of GCC's library with LiteX's libbase. In particular, some headers come from LiteX, and some from GCC, while linking has both libbase and GCC's libraries.

In order to avoid subtle bugs, we should find some way to compile the LiteX app without libbase. I believe newlib is the library shipped with riscv64-gcc.

Challenges:

about add new FPGA board

Hi,

I'm trying to let CFU-Playground run on qmtech wukong board. The FPGA is Xilinx Artix-7 XC7A100T.

I could build and run a 4-cores vexrisc-v + linux on this board. right now, I'm tring to add some hw design build in. the CFU-playground provides a very good way to add on custom design.

I could add qmtech wukong in CFU-playground project and generate fpga bitstream very smoothly. but I found the generated bitstream can't make fpga booting after I download the bitstream. even the BIOS boot up message doesn't show. Is any where I missed?

the following is what I done.

  1. add qmtech wukong board related setting in proj/proj.mk.
  2. add two new file in soc folder, qmtech_wukong.mk, qmtech_wukong.py.
  3. add flash code in CFU-Playground/third_party/python/litex_boards/litex_boards/targets/qmtech_wukong.py

thanks in advance.

BR, Akio

Enhancement: support a second board

Ideally one using a different FPGA family than XC7. But, depending on which board, it may require another toolchain. So...maybe that's a reason to add Symbiflow support!

Create a way to list potentially supported boards

It would be useful to have a way of generating the names of boards potentially supported by CFU-Playground. The simplest implementation would just list the boards in litex_boards/targets/. It's ok to have some boards listed that won't actually work (due to insufficient memory, or no main_ram region, or no serial/uart).

The main use is for someone who has for example an Arty board, and doesn't know what name to use ("arty"? "arty-35t"? "digilent_arty"?).

Conflicting uses of TARGET

This is the original message; see also my following replies.

Hi, @alanvgreen :

After some testing with this update, I met a problem. when compile tflm library, it complained no found to "qmtech_wukong_makefile.inc" wihch the board I used is wukong board.

Would you like to share how to solve this problem? or just simple copy the mcu_riscv_makefile.inc to digilet_arty_makefile.inc?

Many thanks.

BR, Akio

Originally posted by @akioolin in #118 (comment)

scripts/setup: If the user answers "n" to installing new packages, the script tries to install them anyway.

tim@tim-ubuntu:~/tcal-x/CFU-Playground$ ./scripts/setup 
Missing packages: ccache
Install [y]/n? n
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  distcc | icecc
The following NEW packages will be installed:
  ccache
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 121 kB of archives.
After this operation, 369 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu focal/main amd64 ccache amd64 3.7.7-1 [121 kB]
Fetched 121 kB in 1s (221 kB/s)
Selecting previously unselected package ccache.
(Reading database ... 276510 files and directories currently installed.)
Preparing to unpack .../ccache_3.7.7-1_amd64.deb ...
Unpacking ccache (3.7.7-1) ...
Setting up ccache (3.7.7-1) ...
Updating symlinks in /usr/lib/ccache ...
Processing triggers for man-db (2.9.1-1) ...
Please install vivado

try to using CFU under Linux OS

Hi, All:

I have some questions about how to enable cfu.v in litex.

  1. for currently CPU support, it seems VexRisc-V only, not for VexRisc-V SMP.
  2. from current project samples, the CFU function enable by using RISC-V custom instruction. the environment is bare metal machine. for linux enable sw/fw, is there
    any kernel driver module should be written for CFU operation.
  3. for CFU instruction issued, how about the context switch handling?
  4. for CFU design, the memory access seems still under develop. how to consider about cpu cache, DMA, DRAM, and CFU.

Many thanks.

BR, Akio

On Icebreaker, TFLM unit test fails, and microbenchmarks hang

I saw this in proj/proj_template_v/, with no models compiled in. CONV TEST fails, but DEPTHWISE_CONV TEST passes.

This is likely a generic issue with the limited memory, not specific to Icebreaker.

I suspect that the stack grows down into the allocated .data section, causing corruption/hangs.

  • We should run this in Renode to confirm that this is indeed the issue.

  • The BUF_SIZE used in the memory benchmarks should be shrunk down, at least for the boards with limited main_ram/sram.

CFU not defined on page 1

CFU isn't common enough to not be defined near the top.
in this doc it is defined a bit later on the Overview page:

The SoC has:
a VexRiscV soft CPU with a Custom Function Unit (CFU) extension

Disconnected reset in proj/mnv2_first/ CFU

With a recent PR, we renamed the top reset port on the CFU to be "reset" instead of "rst". However, now, inside of the generated cfu.v, the top port 'reset' is not connected to anything, while a signal 'rst' appears to be undriven.

I'm not sure where 'rst' is declared; I suspect it is implicit with the nMigen generation.

This was discovered by Yosys trimming away most of the CFU.

Create a non-ML template project

Create a project that does not link in any of the TFLM library or models. It would provide a starting point for software for non-TFLM based experimentation with CFUs.

Update 'renode' target to use board-specific workflows

Board-specific workflows allows us to target boards that have flows that differ from the "usual" LiteX flow. For example, with TARGET=kosagi_fomu. The workflow mechanism is used for the make TARGET=<board> prog and make TARGET=<board> software targets.

The newly-supported make TARGET=<board> renode target could perhaps(?) also use the workflow mechamism. Currently with Fomu, I see this:

% make TARGET=kosagi_fomu renode
make -C /home/tim/tcal-x/CFU-Playground/soc -f /home/tim/tcal-x/CFU-Playground/soc/common_soc.mk litex-software
make[1]: Entering directory '/home/tim/tcal-x/CFU-Playground/soc'
MAKEFLAGS=-j8 /home/tim/tcal-x/CFU-Playground/scripts/pyrun ./common_soc.py --output-dir build/kosagi_fomu.proj_template_v --csr-csv build/kosagi_fomu.proj_template_v/csr.csv --cpu-cfu /home/tim/tcal-x/CFU-Playground/proj/proj_template_v/cfu.v --uart-baudrate 3686400 --target kosagi_fomu
Traceback (most recent call last):
  File "./common_soc.py", line 54, in <module>
    main()
  File "./common_soc.py", line 50, in main
    workflow.run()
  File "/home/tim/tcal-x/CFU-Playground/soc/board_specific_workflows/general.py", line 111, in run
    soc = self.make_soc()
  File "/home/tim/tcal-x/CFU-Playground/soc/board_specific_workflows/general.py", line 74, in make_soc
    return self.soc_constructor(**base_soc_kwargs)
TypeError: __init__() missing 1 required positional argument: 'bios_flash_offset'
make[1]: *** [/home/tim/tcal-x/CFU-Playground/soc/common_soc.mk:96: build/kosagi_fomu.proj_template_v/software/bios/bios.bin] Error 1
make[1]: Leaving directory '/home/tim/tcal-x/CFU-Playground/soc'
make: *** [../proj.mk:256: litex-software] Error 2

I think we saw this same error regarding bios_flash_offset before the board-specific workflow was added.

FYI @JosephBushagour @robertszczepanski

Add some linting / sanity checks / physical design summary output

We had a situation where a small mistake caused the creation of a 2048b counter. This consumed 2000 extra LUTs and had a 85ns path, but it wasn't flagged during the build and the user (me) didn't notice anything amiss. But on the board, there were nondeterministic failures due to the long path, and only after some investigation did we find the issue. The following additions would have helped us find the issue sooner:

  • Visible printout of the LUT count and critical path delay after building the bistream
  • Maybe some linting in nMigen to flag Signals wider than say 128b
  • Others?

"make renode" fails first time, works second time. Possible race condition.

When I run the following:

make clean
make renode

...I get the following error:

  LD       software.elf
  OBJDUMP  software.elf.dis
  OBJDUMP  software.elf.sym
  OBJCOPY  software.bin
  IHEX     software.ihex
make[1]: Leaving directory '/home/tim/alanvgreen/CFU-Playground/proj/proj_template_v/build'
/home/tim/alanvgreen/CFU-Playground/soc/build/digilent_arty.proj_template_v/csr.csv not found
Running interactively under renode
/bin/cp -a /home/tim/alanvgreen/CFU-Playground/proj/proj_template_v/build/software.elf /home/tim/alanvgreen/CFU-Playground/proj/proj_template_v/renode/
pushd /home/tim/alanvgreen/CFU-Playground/proj/proj_template_v/build/renode/ && /home/tim/alanvgreen/CFU-Playground/third_party/renode/renode -e "s @digilent_arty.resc" && popd
/bin/bash: line 0: pushd: /home/tim/alanvgreen/CFU-Playground/proj/proj_template_v/build/renode/: No such file or directory
make: *** [../proj.mk:168: renode] Error 1

If I run make renode again (without doing a make clean), it then works (the two Renode windows come up).

I suspect that somewhere in our make commands, a parallel make is specified, and the dependencies are not well specified. In particular, the first error is /home/tim/alanvgreen/CFU-Playground/soc/build/digilent_arty.proj_template_v/csr.csv not found, but this file does exist when I check. So I think the consumer of this file tries to execute before (or in parallel with) the producer.

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.