Please check out the wiki (https://github.com/AlphamaxMedia/netv2-fpga/wiki) for more documentation on the NeTV2 project.
Grab the latest update by first ensuring the NeTV2 is on the network, then plugging a keyboard and mouse into the NeTV2's USB ports and typing 'ctrl-q'. Double click the "Update FPGA" icon that appears on the left hand side of the screen. The screen should blank for about a minute, and then come back.
As of September 2019, the latest update enables 1080p, 1080i, and 720p auto-resolution support, and you can also pick YCrCb chroma coding for the overlay. If your overlay shows up looking pink and green, this is likely the issue. You can pick YCrCb by logging into your NeTV2 via SSH and running the command ~/code/netv2mvp-scripts/set_ycrcb.sh. This command only appears after the latest update.
Note that the NeTV2 hardware uses primarily torx screws. You will need a Torx T6 bit to open the case, and a 2.5mm hex key (or Torx T10) bit to remove the motherboard from its standoffs.
If you're using the NeTV2 as "just a board" without the Raspberry Pi attached, please read https://github.com/AlphamaxMedia/netv2-fpga/wiki/Using-NeTV2-as-a-Dev-Board for more on how to use it.
IMPORTANT: If you want to connect a regular HDMI cable to the "overlay" port, you will need to re-build the FPGA with the correct pattern of differential pair inversions to match an HDMI cable. See https://github.com/AlphamaxMedia/netv2-fpga/blob/master/netv2mvp.py#L148. The pattern of inversions checked into the master branch targets the custom M2M jumper, which swaps some differential pairs to improve routing.
These instructions can be used to quickly start FPGA development.
git clone --recurse-submodules https://github.com/AlphamaxMedia/netv2-fpga.make installed.All OS installer Single-File DownloadDesign Tools / Vivado Design Suite / Vivado and Devices / Production Devices / 7 Series./netv2mvp.py (or python3 ./netv2mvp.py)To update the repo to the upstream version, including all dependencies, run:
git pull
git submodule update --recursivelxbuildenv is a Python module. It sets up the build environment and ensures you have the correct dependencies. To use it, start your program off with:
#!/usr/bin/env python3
import lxbuildenvlxbuildenv.py has some very surprising behaviors that you should be aware of:
PYTHONHASHSEED, lxbuildenv will actually re-exec the Python interpreter. This will, among other things, cause the pid to change. This is why lxbuildenv should be imported first.PYTHONPATH is replaced to include every directory under deps/. If you rely on PYTHONPATH to be something else, this may surprise you.lxbuildenv has several command line parameters that it can accept. To display these, run your command with the --lx-help parameter.deps/ directory includes its own site.py implementation, adapted from a Debian implementation. This is because some distros force /usr/share/python/site-packages/ to be first in the dependency list, which causes confusing dependency interactions. If you're relying on site packages being in a certain order, this may cause problems. You can try deleting deps/site/ in order to disable this behavior.In exchange for some deviation from other build environments, lxbuildenv gives you several benefits that come in handy for hardware projects:
git to track dependency versions, this build becomes more reproducible.lxbuildenv environment doesn't rely on opaque environment variables, or otherwise have a special environment you enter. Everything is documented behind --help flags.Dependencies are managed through git, and managing their usage is largely an exercise
in working with git.
For example, if you would like to make a change to litex, go into deps/litex and checkout
a new branch and create a new upstream repo. If you're working on Github, you would do
something like fork the repo to your own organization.
As an example, assume sutajiokousagi has forked upstream litex:
$ cd deps/litex
$ git checkout -b new-feature
$ git remote add kosagi git@github.com:sutajiokousagi/litex.git
$ cd -Then, make changes to deps/litex as needed.
When you want to merge changes upstream, go into deps/litex/ and push the branch to your remote:
$ cd deps/litex
$ git push kosagi new-feature
$ cd -Then you can go and open a Pull Request on Github.
Dependencies are designed to be independent, and you should update them as needed. To update a particular
dependency, go into that dependency's subdirectory and run git pull. You may also find it easier to
pull updates from a particular dependency and merge them. For example, if you're working on the new-feature
branch of litex and want to pull changes from upstream, run:
$ cd deps/litex
$ git fetch origin
$ git merge master
$ cd -This will merge all changes from upstream onto your own branch.
NeTV2 uses Migen for its HDL, and uses many components from the LiteX project. These are primarily written in Python, which has a large number of options available for configuring installs, ranging from global installs, virutlalenv, conda, as well as several others. Everyone has an opinion on what's right.
These instructions ignore all of that, in favor of simplicity. You likely already
have a copy of make and python, and you probably have a compiler
installed for other projects. It's also more challenging to work on submodules
when they're combined together in a site-packages repository and outside of version control.
lxbuildenv takes a different approach in that it doubles-down on using native
components and simply modifies several magical environment variables to make
it all work. As a bonus, it works on platforms where Conda doesn't, such as
platforms where packages might not be available.
There is a wrapper script in this repo to run support programs such as litex_server and litex_term. These may be invoked either with python (python bin/litex_server udp) or on shebang-aware systems they may be executed directly (./bin/litex_server udp).
If your Xilinx install is in the default path (C:\\Xilinx on Windows, /opt/Xilinx on Linux), then the build system should be able to automatically find Xilinx.
If not, you can add the Xilinx bin directory to your PATH.
To use PyCharm, open this directory as a Project by going to the File menu and selecting Open.... Make sure you open the entire directory, and not just a single file in this directory.
When you first open this project, you'll see lots of red squiggly lines indicating errors. PyCharm needs to know about the dependency structure in order to allow you to drill down into modules and auto-complete statements.
Open this directory in PyCharm and expand the deps/ directory. Then hold down Shift and select all subdirectories under deps/. This will include litedram, liteeth, and so on.
Then, right-click and select Mark directory as... and select Sources Root. The red squiggly lines should go away, and PyCharm should now be configured.
When running your module from within PyCharm, you may find it useful to set environment variables. You can use the --lx-print-env command. For example: ./netv2mvp.py --lx-print-env > pycharm.env to create a .env-compatible file. There are several PyCharm plugins that can make use of this file.
Visual Studio Code needs to know where modules are. These are specified in environment variables, which are automatically read from a .env file in your project root. Create this file to enable pylint and debugging in Visual Studio Code:
$ python ./netv2mvp.py --lx-print-env > .envThere's a number of scripts used to assist with integration into the Raspberry Pi runtime environment. They are all located in https://github.com/alphamaxmedia/netv2mvp-scripts/. In this location, you'll find the scripts that do the one-click update, openocd manipulation of bitstream and SPI ROM, publishing of status info to JSON feed, and Magic Mirror config info. This repository is just for the FPGA design.