We have tests that run over 50m limit of Travis, so they fail.
We need to temporarily comment at least one of the tests in travis.yml to bring back green CI and then find a better solution.

Travis is using tuttest to test tutorial commands in the README.md.

Tuttest is following commands from the README.md and make sure they are working.
In the README.md there is a command that is cloning repository and entering newly cloned repository:

git clone https://github.com/SymbiFlow/symbiflow-examples && cd symbiflow-examples

this means, that when someone opens PR, changes from this PR are not reflected in the tests. Always master version of the repository is used in tests.

@FFY00 has set up GitHub actions to generate Arch Linux packages for SymbiFlow at https://github.com/FFY00/symbiflow-arch-pkgs

This has a couple of really nice aspects;

• It generates a list of tasks to run based on which packages have been modified.
• It can potentially have a much clearer dependency tree described.

It seems that GitHub actions are the future here. @FFY00 has said he would be interesting to explore using it instead.

Right?

The counter example is not working as expected.

Loading the bitstreams on both the 35t and 100t produces no effects, and LEDs are not blinking as expected.
This issue was discovered in #106.

There are two different problems to be addressed:

• Missing openocd conda package (currently non-present in the environment file).
• Broken counter design.

Current

INSTALL_DIR="/opt/symbiflow/xc7"
bash conda_installer.sh -b -p $INSTALL_DIR/conda && rm conda_installer.sh
source "$INSTALL_DIR/conda/etc/profile.d/conda.sh"
conda update -y -q conda

wget -qO- https://storage.googleapis.com/symbiflow-arch-defs/artifacts/prod/foss-fpga-tools/symbiflow-arch-defs/continuous/install/4/20200416-002215/symbiflow-arch-defs-install-a321d9d9.tar.xz | tar -xJ -C $INSTALL_DIR
conda install -y -c symbiflow yosys yosys-plugins vtr-no-gui
conda install -y make lxml simplejson intervaltree git pip
conda activate
pip install python-constraint
pip install git+https://github.com/symbiflow/fasm
conda deactivate

New version

wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O conda_installer.sh
bash conda_installer.sh -b -p $INSTALL_DIR/conda

source "$INSTALL_DIR/conda/etc/profile.d/conda.sh"
conda env update --name xc7 --file xc7.yml
conda activate xc7

environment.yml

name: xc7
channels:
- SymbiFlow
- defaults
dependencies:
- symbiflow
- yosys
- yosys-plugins
- vtr-no-gui
# Packages installed from PyPI
- pip:
  - -r file:requirements.txt

requirements.txt

python-constraint
-e git+https://github.com/symbiflow/fasm

• Blinky
• Counter
• Ibex
• LiteX?

Hi i am new to Linux and working on to generate bitstream file for a Verilog file using Symbiflow for a Artix-7 FPGA. I successfully installed Conda in tool chain installation and moved to second part of tool chain installation for Artix-7 and i got errors as shown in the screenshot.

• https://github.com/enjoy-digital/usb3_pipe compiled with Vivado
• https://github.com/enjoy-digital/daisho compiled with SymbiFlow

Kind of like that PCIe demo you did previously.....

Right now we use a combination of downloading a tar.gz file, plus installing Conda packages. There is executable code/scripts in both parts. Is there a better way? It seems updating the tools to include recent additions is difficult (for example, see issue #27).

Perhaps there is some reworking already in the pipeline.

Currently, the CI's build matrix is created manually and contains all the valid combinations of different configuration variables. However, it is possible to generate the matrix automatically. An example of that can be found here:
https://github.com/SymbiFlow/symbiflow-arch-pkgs/blob/master/.github/workflows/build.yml#L9-L32
This can potentially help us simplify the CI configuration, and the tuttest setup (see #88 (comment))

It is also worth to check other possible approaches to this problem.

See comment #41 (comment).

I have replicated these results.

fpga4fun.com has an great little set of "basic" FPGA projects. We should add them to symbiflow-examples (license permitting);

Music box
LED displays
Pong game
R/C servos
Text LCD module
Quadrature decoder
PWM and one-bit DAC
Debouncer
Crossing clock domains
The art of counting

We should be testing the examples run on Mac OS X

Cause is that there is a comment included in the prepare environment snippet

# adding symbiflow toolchain binaries to PATH

Got rid of the comment and the tests run ... all pass except for the xc7-litex which i am working on and will report separately

We should move the information about the toolchain installation back to the FPGA family directory. After that, we will have a README file in every important directory. This will help potential users to navigate the project.

Hello. I want to know from which repository are the symbiflow tools (symbiflow_synth, symbiflow_pack, etc) generated. Also, I want their documentation. Is enough to point me to the right doc. Are Yosys+nextpnr+icestrom tools, for example, completely replaced by the symbiflow tools? (in this repository, there are only examples of Xilinx and QuickLogic).

Thanks,
Rodrigo

failing in travis.ci

pre-req is fixissue 65 to get tests running

progress so far fixing is that the litex stuff is being installed outside of the symbiflow-examples directory so a cd needs to happen ... see line 5

i would prefer if the install instructions gave the user a measure control on where all the Litex stuff ends up ... needs a $LITEX_INSTALL_DIR

with the cd fix, the test is now failing in litex/litex/build/xilinx/symbiflow.py", line 103, in ####_run_make

ROM usage: 20.96KiB 	(65.50%)
RAM usage: 1.63KiB 	(20.41%)
make: Leaving directory '/home/travis/build/scted/litex/litex/boards/targets/build/arty/software/bios'
Traceback (most recent call last):
  File "./arty.py", line 162, in <module>
    main()
  File "./arty.py", line 155, in main
    builder.build(**builder_kwargs, run=args.build)
  File "/home/travis/build/scted/litex/litex/soc/integration/builder.py", line 217, in build
    vns = self.soc.build(build_dir=self.gateware_dir, **kwargs)
  File "/home/travis/build/scted/litex/litex/soc/integration/soc.py", line 1054, in build
    return self.platform.build(self, *args, **kwargs)
  File "/home/travis/build/scted/litex/litex/build/xilinx/platform.py", line 53, in build
    return self.toolchain.build(self, *args, **kwargs)
  File "/home/travis/build/scted/litex/litex/build/xilinx/symbiflow.py", line 263, in build
    _run_make()
  File "/home/travis/build/scted/litex/litex/build/xilinx/symbiflow.py", line 103, in _run_make
    if tools.subprocess_call_filtered(shell + [script], common.colors) != 0:
NameError: name 'shell' is not defined`

Shouldn't it be counter_test/counter.v?

If this addressed by a PR in flight, just close this.

I'm going through the examples at https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html .

After the counter example is built, the user is told to execute the following to program the part with the bitstream:

openocd -f ${INSTALL_DIR}/conda/share/openocd/scripts/board/digilent_arty.cfg -c "init; pld load 0 top.bit; exit"

There are two things wrong with this:

• digilent_arty.cfg is not at the provided path. In fact I cannot find it at all in the installed tool directory. I have only installed the xc7 tools.
• the user is still in the xc7/ directory, so either they need to cd to the correct build directory, or top.bit should be replaced with the path to the correct file

This only affects you if you're updating README.rst.

To reproduce, remove README.rst (rm README.rst), then run make README.rst. After packages are downloaded and the conda env is entered, I see this:

touch /home/tim/symbiflow/symbiflow-examples/env/conda/envs/symbiflow-examples/bin/python
source /home/tim/symbiflow/symbiflow-examples/env/conda/bin/activate && conda activate symbiflow-examples && rst_include include README.src.rst - > README.rst
Traceback (most recent call last):
  File "/home/tim/symbiflow/symbiflow-examples/env/conda/envs/symbiflow-examples/bin/rst_include", line 5, in <module>
    from rst_include.rst_include_cli import cli_main
  File "/home/tim/symbiflow/symbiflow-examples/env/conda/envs/symbiflow-examples/lib/python3.8/site-packages/rst_include/rst_include_cli.py", line 38, in <module>
    def cli_main(traceback: Optional[bool] = None) -> None:
  File "/home/tim/.local/lib/python3.8/site-packages/click/decorators.py", line 170, in decorator
    _param_memo(f, OptionClass(param_decls, **attrs))
  File "/home/tim/.local/lib/python3.8/site-packages/click/core.py", line 1511, in __init__
    raise TypeError('Got secondary option for non boolean flag.')
TypeError: Got secondary option for non boolean flag.
make: *** [Makefile:5: README.rst] Error 1

I'm running Ubuntu 20.04.1 LTS.

This repo should use https://github.com/SymbiFlow/make-env (as submodule) rather than the older scripts copied from Google/SkyWater-pdk

After a clean install of xc7 tools according to the symbiflow-examples instructions, I get to the first example to run (https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html):

TARGET="arty_35" make -C counter_test

and this runs Symbiflow but ends with this error:

......
Serial number (magic cookie) for the routing is: 184139735
Circuit successfully routed with a channel width factor of 500.
Incr Slack updates 1 in 1.4195e-05 sec
Full Max Req/Worst Slack updates 1 in 3.823e-06 sec
Incr Max Req/Worst Slack updates 0 in 0 sec
Incr Criticality updates 0 in 0 sec
Full Criticality updates 1 in 1.8115e-05 sec
Writing Implementation FASM: top.fasm
The entire flow of VPR took 19.0291 seconds.
FASM extra: top_fasm_extra.fasm
writing final fasm
cd build/arty_35 && symbiflow_write_bitstream -d artix7 -f top.fasm -p xc7a35tcsg324-1 -b top.bit
Writing bitstream ...
/media/tim/scratch/opt/symbiflow/xc7/conda/envs/xc7/lib/python3.7/site-packages/fasm/parser/__init__.py:27: RuntimeWarning: 
Falling back on slower textX parser implementation:
  ImportError: cannot import name 'antlr_to_tuple' from 'fasm.parser' (/media/tim/scratch/opt/symbiflow/xc7/conda/envs/xc7/lib/python3.7/site-packages/fasm/parser/__init__.py)
Please install all dependencies and reinstall with:
  pip uninstall
  pip install -v fasm
  '  pip install -v fasm'.format(e), RuntimeWarning)
make: Leaving directory '/home/tim/symbiflow/symbiflow-examples/xc7/counter_test'

Maybe things are just temporarily out of sync. Feel free to close this if this is a known/expected issue.
FYI @HackerFoo in case you have any information.

In case it matters, I'm on Ubuntu 20.04.

Have spent a week on this so far. Cat() not behaving as i expect when i use slices Cat_object[slice] ...

Have tried a number of permutations ... assigning to a slice ... Cat_object[n].eq(rhs) or from a slice ... lhs.eq(Cat_object[n])

The verilog (good and bad) has been tested in HW with both Vivado and Symbiflow ... it is not the toolchain that is a problem.

Possible that I do not understand how Cat is supposed to be used but the fact remains the simulation results differ from the produced verilog.

Code I used to test here: https://github.com/scted/Cat-demo

In the code snippet (bottom), the 'lhs' and 'rhs' permutations (where slicing of the Cat_object is used) do not connect all the ins to the outs ... only the msb ends up being connected

The verilog produced for 'lhs' and 'rhs' (below) does something funky with 'slice_proxy0' and 'slice_proxy1' ...

Writing verilog for "rhs" ... something gets mangled and only the MSB is connected

/* Machine-generated using Migen */
module top(

);

reg [1:0] ins = 2'd0;
reg [1:0] outs;
wire s0;
wire s1;
wire [1:0] slice_proxy0;
wire [1:0] slice_proxy1;

// synthesis translate_off
reg dummy_s;
initial dummy_s <= 1'd0;
// synthesis translate_on

assign {s1, s0} = ins;

// synthesis translate_off
reg dummy_d;
// synthesis translate_on
always @(*) begin
	outs <= 2'd0;
	outs[0] <= slice_proxy0[0];
	outs[1] <= slice_proxy1[1];
// synthesis translate_off
	dummy_d <= dummy_s;
// synthesis translate_on
end
assign slice_proxy0 = {s1, s0};
assign slice_proxy1 = {s1, s0};

endmodule

        '''
        Different ways to implement ins(2) => cat_bus(=Cat(s0, s1)) => outs(2)
        sim the same in all cases: ins == outs
        
        "no_slicing" :: verilog == sim
        "lhs" : assign the lhs of bus from ins via slicing: verilog <> sim
        "rhs" : assign the rhs of bus to outs via slicing: verilog <> sim
        "use_signals" : assign ins/out directly to/from cat_bus: verilog == sim
        '''
        
        
        self.ins = ins = Signal(2)
        self.outs = outs = Signal(2)

        self.s0 = s0 = Signal()                                 
        self.s1 = s1 = Signal()
        
        #object of interest
        self.cat_bus = cat_bus = Cat(s0, s1)

        if permutation == "no_slicing":         #sim == verilog
            self.comb += cat_bus.eq(ins)
            
            self.comb += outs.eq(cat_bus)

        elif permutation == "lhs":              #sim <> verilog
            self.comb += cat_bus[0].eq(ins[0])
            self.comb += cat_bus[1].eq(ins[1])
            
            self.comb += outs.eq(cat_bus)

        elif permutation == "rhs":              #sim <> verilog
            self.comb += cat_bus.eq(ins)

            self.comb += outs[0].eq(cat_bus[0])
            self.comb += outs[1].eq(cat_bus[1])

        elif permutation == "use_signals":      #sim == verilog
            self.comb += s0.eq(ins[0])
            self.comb += s1.eq(ins[1])
            
            self.comb += outs[0].eq(s0)
            self.comb += outs[1].eq(s1)

It would be good if the examples also worked on the Arty 100T version.

We should be testing that the SymbiFlow examples successfully work and run on as many Linux variants as we can. This can probably be done using Docker on travis.

I started trying to get this working at https://github.com/SymbiFlow/symbiflow-examples/compare/master...mithro:multi-os-test?expand=1 kind of based off what we do for verible at https://github.com/google/verible/blob/master/.travis.yml

We should at least check;

• Supported Ubuntu versions -- specially LTS versions
• Debian stable / testing / unstable
• Supported CentOS versions
• (maybe -- or is this covered by CentOS?) Supported Red Hat Enterprise Linux versions?
• Latest Fedora

Other nice to have would be;

• Arch Linux
• Gentoo

Advanced users might want to do simulation of their system after place and route. This was something that @QuickLogic-Corp was very interested in. The VtR docs also have this functionality described at https://docs.verilogtorouting.org/en/latest/tutorials/timing_simulation/

It should be extremely simple to do this.

Examples Makefiles define PARTNAME := xc7a35tcsg324-1 => toolchain builds

I created a Migen design from scratch and migen.build.platforms.arty_ay7.Platform uses 'device="xc7a35ticsg324-1L"' as does litex.boards.platforms.arty.Platform

The migen/litex generates a buildscript that is close to but different than the one in the examples and it doesn't work ... the obvious things were 'synth' instead 'symbiflow_synth', 'place' instead of ... and similar but different argument signatures

Fixing the obvious still failed ... had also change the device to the -1 .. the -1L was failing in Yosys at step 8 ... .JSON generation

It appears we don't have any examples / demos which run on Zynq parts at the moment?

I don't know which board should be targeted?

@Dolu1990 has a SoC written entirely in SpinalHDL called SaxonSoC.. The SoC supports the Arty-A7 with things like DDR and Ethernet.

This would be another good test option for the SymbiFlow examples.

Rework the CI scripts to make them able to extract all the necessary information about the available examples directly from the sphinx-based documentation. For more information, see the discussion in #88 (comment) and #88 (comment)

Hi everyone,

I ran through these examples and I REALLY LIKED THEM. I think they were originally made to have something that ran through testing automatically every night, but they also seem like a great intro for beginners. I really liked the straightforward Makefile approach here -- I can see each step (synth/pack/place/route), look at the intermediate files, rerun a step with alterations, etc.

But I realized that once I had the bitstream, I didn't know what to do with it. I never had to directly run openOCD with other tutorials, since they always performed it, although wrapped in layers of python or CMake, so I didn't really understand what was going on. Could we either extend the Makefiles with a "prog" target that directly invokes openOCD, or maybe even make a new guide for beginners about the different ways of getting the bits on the board (openocd, Vivado, xc3sprog)? There is a bit of text here, but it skips openocd: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/docs/source/getting-started.rst#load-bitstream .

Similarly, I could have used a beginner's guide regarding making a serial connection to the board. I knew of lxterm/litex_term, but only recently learned that "picocom" and "screen" could also be used. For the picoSoc example here, I don't think I would have figured out how to connect without direct help from @acomodi to use "picocom --baud 460800 /dev/ttyUSBx" --- how is the required baudrate of 460800 determined? Is it board-dependent or design-dependent? Here, also, a one-line Makefile target would be useful so that I could learn by examining the Makefile, or maybe it's worth making a stand-alone guide that this could point to.

@rw1nkler , @mgielda , @kgugala , opinions?

My laptop has 10GB available according to /proc/meminfo. I see this error running the counter_test example with TARGET=nexys_video:

Serial number (magic cookie) for the routing is: 416094740
Circuit successfully routed with a channel width factor of 500.
Incr Slack updates 1 in 1.4106e-05 sec
Full Max Req/Worst Slack updates 1 in 4.114e-06 sec
Incr Max Req/Worst Slack updates 0 in 0 sec
Incr Criticality updates 0 in 0 sec
Full Criticality updates 1 in 1.8798e-05 sec
Writing Implementation FASM: top.fasm
/media/tim/GIT/opt/symbiflow/xc7/install/bin/vpr_common: line 116: 2752047 Killed                  genfasm ${ARCH_DEF} ${EBLIF} --device ${DEVICE_NAME} ${VPR_OPTIONS} --read_rr_graph ${RR_GRAPH} $@
make: *** [Makefile:54: build/nexys_video/top.fasm] Error 137

The file build/nexyx_video/top.fasm is left behind. Is it partially written? If I run the make command again, top.bit is generated from top.fasm. Is the top.bit file correct?

I have two concerns here:

• The user should get a clear "out of memory" error if that is indeed the case.
• When an error is encountered while generating top.fasm, that file should be removed, or else a subsequent make will use it and possibly write an incorrect top.bit file.

Note: If I close other applications to get 15GM of available memory, the flow completes without error, although I haven't had a chance to test the generated bitstream on the Nexys Video board yet.

Hi,

Thanks for the great project.

I just build the top.bit from examples/xc7/linux_litex_demo with pre-gen files.
And I tried Ethernet boot with the setup from LiteX wiki except changing my TFTP server port from 69 to 6069 because the bootloader suggests "Fetching from: UDP/6069" .

Yet the bootloader complains that it fails to fetch anything from my host.
The tcpdump log shows that it sent a lot of ARP request for knowing my where my host is :

16:53:11.817485 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:11.970841 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:12.124201 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:12.277749 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:12.431063 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:12.584230 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:12.737583 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:12.890927 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.044465 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.197815 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.350960 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.504306 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.657864 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.811210 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46
16:53:13.964525 ARP, Request who-has 192.168.100.100 tell 192.168.100.50, length 46

I also tried the serial boot, with the default image json file from Linux-on-Litex .

Yet it doesn't work either - - nothing shows up after the bootloader's "Lift off" message.

For cross-examination, I use the bitstream from Linux-on-Litex's prebuilt repo and Ethernet boot the rootfs/kernel/dtb and emulator.bin provided by this repo ( I mean symbiflow-examples). It boots.

So I'm kinda head-spinning right now with no clues about what went wrong.

The bitstream I generated is uploaded to Google Drive since GitHub prevents me from doing so.

Thanks again for any kind of help :-)

= = = = = = = =

BTW, I just went to COSCUP and told my fellow Taiwanese about how great the FOSS FPGA toolchain could be.
After the presentation, someone pinged me that SymbiFlow could go through the whole-nine-yards with VPR now.
So I'm trying to reproduce the results and thus to update the slides.

The design described at https://antmicro.com/blog/2020/05/multicore-vex-in-litex/ should be an example in this repository.

PR #111 adds various LiteX examples for arty-35 and arty-100.

Each example implements a different CPU core type, and #111 currently adds picorv32 and VecRiscv.

There are other CPU-types that can be implemented.

With fixes in the toolchain/tools

• minerva: This requires f4pga/f4pga-arch-defs#1906 to be merged. The problem is that the minerva core has a yosys attribute which sets the top-level module to be the minerva core. With the -auto-top parameter when getting the hierarchy is used, the real top module gets discarded in favour of the minerva one.
• serv: There is a .vh file which makes yosys fail due to the fact that it cannot guess the frontend for it. To solve this we need to provide the -f verilog option when calling yosys. It should be fixed in symbiflow-arch-defs
• rocket: This currently fails during the VPR clean circuit step. The resulting synthesized design is big enough to let VPR consume all RAM available (16GB on my local machine) during the clean circuit step. This requires a proper fix in VPR

Requires some additional tools

• microwatt: This requires the usage of the VHDL plugin for yosys, as well as the powerpc64le-linux cross compilation toolchain.
• mor1kx: This requires the or1k-elf binariy to compile the bios
• lm32: This requires the lm32-elf binary to compile the bios
• cv32e40p: This core is written in SystemVerilog. Unsure if it is simple enough to get it through yosys

This is just a matter of adding separate PCF/XDCs for each design plus make targets.

Example of using FuseSoC with SymbiFlow.

Static URLs are checked in at: https://github.com/SymbiFlow/symbiflow-examples/blob/master/docs/getting-symbiflow.rst

These should be updated automatically somehow to the latest version.

Related: #28, #108

I was told on IRC that setting VPR_SEED may be a workaround.
I've repeated the command, after deleting the build folder each time:
TARGET="arty_100" make | tee <LOGFILE>

1. export VPR_SEED="--seed 1341221332"
2. export VPR_SEED="--seed 12345"
3. unset VPR_SEED
   At the end of each log:

Begin loading /opt/symbiflow/xc7/install/bin/vpr_common: line 111: 26523 Killed                  genfasm ${ARCH_DEF} ${EBLIF} --device ${DEVICE_NAME} ${VPR_OPTIONS} --read_rr_graph ${RR_GRAPH} $@
make: *** [Makefile:40: build/top.fasm] Error 137

I hope this aids efforts to fix this problem.
log-seed-unset.log
log-seed-1341221332.log
log-seed-12345.log

We should be testing the examples run on Windows.

Currently we have

• symbiflow-examples/examples/xc7

The extra examples directory doesn't seem to add much value?

It would probably be better to have the following

• symbiflow-examples/xc7

It also means that a person who goes to this repo quickly sees which architectures there are examples for.

Offshoot of issue #58 .

Even if I have just gone through the conda and toolchain installation manually and entered the 'xc7' conda environment, when I attempt make README.rst, it seems to do the entire conda thing all over again. Is it slightly different? Or is the Makefile not recognizing that this dependency is already met?

Also, if this can be done automatically, triggered by the 'make', why does it have to be done manually by the user? Can we just have a 'make env' ?

https://www.fpga4fun.com/MusicBox.html

Here we teach our FPGA how to play sounds and music.
We start by generating a single tone. Then slowly more fun stuff like producing a police siren and play a tune.

While execute my code i am getting the following error:
Symbiflow_synth command not found

Make sure that all the graphics used in the documentation have a good quality, are readable, and stabilized.
See the comments in #88 (review)

It is the output of LiteX -- this demo should be an example of running LiteX using the SymbiFlow tools.