chipsalliance / f4pga-examples Goto Github PK
View Code? Open in Web Editor NEWExample designs showing different ways to use F4PGA toolchains.
Home Page: https://f4pga-examples.readthedocs.io
License: Apache License 2.0
Example designs showing different ways to use F4PGA toolchains.
Home Page: https://f4pga-examples.readthedocs.io
License: Apache License 2.0
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.
@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.
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
Kind of like that PCIe demo you did previously.....
@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 seems that GitHub actions are the future here. @FFY00 has said he would be interesting to explore using it instead.
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.
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:
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.
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?
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
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
Make sure that all the graphics used in the documentation have a good quality, are readable, and stabilized.
See the comments in #88 (review)
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.cd
to the correct build directory, or top.bit
should be replaced with the path to the correct fileHi 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.
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
This repo should use https://github.com/SymbiFlow/make-env (as submodule) rather than the older scripts copied from Google/SkyWater-pdk
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.
It would be good if the examples also worked on the Arty 100T version.
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.
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>
export VPR_SEED="--seed 1341221332"
export VPR_SEED="--seed 12345"
unset VPR_SEED
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
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.
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;
Other nice to have would be;
Example of using FuseSoC with SymbiFlow.
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.
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)
See comment #41 (comment).
I have replicated these results.
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.
-auto-top
parameter when getting the hierarchy is used, the real top module gets discarded in favour of the minerva one..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-defsclean 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 VPRpowerpc64le-linux
cross compilation toolchain.or1k-elf
binariy to compile the bioslm32-elf
binary to compile the biosCurrently, 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.
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.
We should be testing the examples run on Mac OS X
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.
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.
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
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.
While execute my code i am getting the following error:
Symbiflow_synth command not found
This is just a matter of adding separate PCF/XDCs for each design plus make targets.
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' ?
We should be testing the examples run on Windows.
The design described at https://antmicro.com/blog/2020/05/multicore-vex-in-litex/ should be an example in this repository.
Shouldn't it be counter_test/counter.v
?
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
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 is the output of LiteX -- this demo should be an example of running LiteX using the SymbiFlow tools.
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:
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`
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.