[WORKFLOW RELEASE] Vidor sample projects are opensource!

VStrakh: Hi.

Apparently, the port of Adafruit GFX for VidorBistream needs some adjustments. The code for filling the primitives will mostly use writeVLine() function, while SDRAM would much prefer the horizontal lines.

Also that's pretty slow if you have lite version NIOS II e. Recommend to use HW acceleration for H lines and BMP copy

What's the rules on using 'update_fw.sh' script?

I always get error from 'quartus_cdb' and 'quartus_asm', telling that I should run 'quartus_map' first with the top-level entity. Is it about the paths to database? When I explicitly enter the /build subdir in the project, those steps are performed ok when done manually. But then the entire 'update_fw.sh' won't run from within /build subdir. Adding 'build/' path in front of $PROJECT_NAME in 'update_fw.sh' seemingly achieves the desired effect.

I think you have to call build_all.sh in project folder. you have to add scripts folder to path env variable.

Limba: I think you have to call build_all.sh in project folder. you have to add scripts folder to path env variable.

Well, the whole idea of 'update_fw.sh' is to update the data to be put in on-chip ram, without recompiling the entire fpga project. Maybe it's not used by the devs at all, or wasn't adapted to the flow/environment that was published on github...

you have compiled project at least one time?

Yes, of course. There would be nothing to update if 'build_all.sh' run wasn't successfully completed at least once :)

Hello I am arduino/VHDL user, and I wanted more powerful camera for my project with parallel data connection, it can be used as bridge between my fpga and camera with standard 1080p, 480p in highspeed .

for this purpose i need to connect ov4689 camerachip with MIPI interface, is it possible to use this and how about source code in vhdl ? source code in vhdl which is MIPI to parallel data and HDMI output (to check whther it works or not )

can you provide all source codes free ?

Were you planning to use mipi_rx_st ip in another device than vidor? Maybe study that that ip how mipi receiver is done and create your own ip. IP is done with System Verilog.

If you have C/C++/C# experience then System Verilog syntax is not that hard.

MIPI_RX_ST Input: MIPI RX and MIPI CLK. Ouput: Avalon steam master

Edit: It also seems to do Bayer to RGB filtering. There's more info in wikipedia and it's commented in code.

Not sure if this is the place to do it but I can’t seem to build the MKRVIDOR4000_template_mbox project

First of all the output looks completely different from when I try to compile MKRVIDOR4000_template_bare (which seems to work)

As far as I can figure out the issue seems to be this bit

2019.06.12.11:59:41 Info: Adding qspi [arduino_generic_quad_spi_controller2 18.1]
2019.06.12.11:59:41 Warning: qspi: Component type arduino_generic_quad_spi_controller2 is not in the library

I also included the whole output in the case that is needed.

$ I:/Downloads/VidorBitstream/TOOLS/scripts/build_all.sh
2019.06.12.12:10:48 Info: Saving generation log to I:/Downloads/VidorBitstream/projects/MKRVIDOR4000_template_mbox/build/MKRVIDOR4000_template_mbox_lite_sys/MKRVIDOR4000_template_mbox_lite_sys_generation.rpt
2019.06.12.12:10:48 Info: Starting: <b>Create HDL design files for synthesis</b>
2019.06.12.12:10:48 Info: qsys-generate I:\Downloads\VidorBitstream\projects\MKRVIDOR4000_template_mbox\build\MKRVIDOR4000_template_mbox_lite_sys.qsys --synthesis=VERILOG --output-directory=I:\Downloads\VidorBitstream\projects\MKRVIDOR4000_template_mbox\build\MKRVIDOR4000_template_mbox_lite_sys\synthesis --family="Cyclone 10 LP" --part=10CL016YU256C8G
2019.06.12.12:10:48 Info: Loading build/MKRVIDOR4000_template_mbox_lite_sys.qsys
2019.06.12.12:10:48 Info: Reading input file
2019.06.12.12:10:48 Info: Adding JTAG_BRIDGE_0 [JTAG_BRIDGE 1.0]
2019.06.12.12:10:48 Info: Parameterizing module JTAG_BRIDGE_0
2019.06.12.12:10:48 Info: Adding clk [clock_source 18.1]
2019.06.12.12:10:48 Info: Parameterizing module clk
2019.06.12.12:10:48 Info: Adding flash_clk [clock_source 18.1]
2019.06.12.12:10:48 Info: Parameterizing module flash_clk
2019.06.12.12:10:48 Info: Adding flash_spi [tiny_spi 1.0]
2019.06.12.12:10:48 Info: Parameterizing module flash_spi
2019.06.12.12:10:48 Info: Adding mb [MAILBOX 1.0]
2019.06.12.12:10:48 Info: Parameterizing module mb
2019.06.12.12:10:48 Info: Adding nina_spi [tiny_spi 1.0]
2019.06.12.12:10:48 Info: Parameterizing module nina_spi
2019.06.12.12:10:48 Info: Adding nios2_gen2_0 [altera_nios2_gen2 18.1]
2019.06.12.12:10:48 Info: Parameterizing module nios2_gen2_0
2019.06.12.12:10:48 Info: Adding onchip_memory2_0 [altera_avalon_onchip_memory2 18.1]
2019.06.12.12:10:48 Info: Parameterizing module onchip_memory2_0
2019.06.12.12:10:48 Info: Adding pex_pio [PIO 1.0]
2019.06.12.12:10:48 Info: Parameterizing module pex_pio
2019.06.12.12:10:48 Info: Adding qspi [arduino_generic_quad_spi_controller2 18.1]
2019.06.12.12:10:48 Warning: qspi: Component type <b>arduino_generic_quad_spi_controller2</b> is not in the library
2019.06.12.12:10:48 Info: Parameterizing module qspi
2019.06.12.12:10:48 Info: Adding sam_pio [PIO 1.0]
2019.06.12.12:10:48 Info: Parameterizing module sam_pio
2019.06.12.12:10:48 Info: Adding sam_pwm [PWM 1.0]
2019.06.12.12:10:48 Info: Parameterizing module sam_pwm
2019.06.12.12:10:48 Info: Adding sdram [altera_avalon_new_sdram_controller 18.1]
2019.06.12.12:10:48 Info: Parameterizing module sdram
2019.06.12.12:10:48 Info: Adding sysid_qsys_0 [altera_avalon_sysid_qsys 18.1]
2019.06.12.12:10:48 Info: Parameterizing module sysid_qsys_0
2019.06.12.12:10:48 Info: Adding timer_0 [altera_avalon_timer 18.1]
2019.06.12.12:10:48 Info: Parameterizing module timer_0
2019.06.12.12:10:48 Info: Adding wm_pio [PIO 1.0]
2019.06.12.12:10:48 Info: Parameterizing module wm_pio
2019.06.12.12:10:48 Info: Building connections
2019.06.12.12:10:48 Info: Parameterizing connections
2019.06.12.12:10:48 Info: Validating
2019.06.12.12:10:49 Info: Done reading input file
2019.06.12.12:10:51 Error: MKRVIDOR4000_template_mbox_lite_sys.qspi: Component <b>arduino_generic_quad_spi_controller2 18.1</b> not found or could not be instantiated
2019.06.12.12:10:51 Info: MKRVIDOR4000_template_mbox_lite_sys.sdram: SDRAM Controller will only be supported in Quartus Prime Standard Edition in the future release.
2019.06.12.12:10:51 Info: MKRVIDOR4000_template_mbox_lite_sys.sysid_qsys_0: System ID is not assigned automatically. Edit the System ID parameter to provide a unique ID
2019.06.12.12:10:51 Info: MKRVIDOR4000_template_mbox_lite_sys.sysid_qsys_0: Time stamp will be automatically updated when this component is generated.
2019.06.12.12:10:51 Warning: MKRVIDOR4000_template_mbox_lite_sys.JTAG_BRIDGE_0: Interrupt sender <b>JTAG_BRIDGE_0.irq</b> is not connected to an interrupt receiver
2019.06.12.12:10:51 Warning: MKRVIDOR4000_template_mbox_lite_sys.flash_spi: Interrupt sender <b>flash_spi.irq</b> is not connected to an interrupt receiver
2019.06.12.12:10:51 Warning: MKRVIDOR4000_template_mbox_lite_sys.nina_spi: Interrupt sender <b>nina_spi.irq</b> is not connected to an interrupt receiver
2019.06.12.12:10:51 Warning: MKRVIDOR4000_template_mbox_lite_sys.JTAG_BRIDGE_0: <b>JTAG_BRIDGE_0.event</b> must be connected to an Avalon-MM master
2019.06.12.12:10:51 Error: MKRVIDOR4000_template_mbox_lite_sys.qspi.avl_mem: Data width must be of power of two and between 8 and 4096
2019.06.12.12:10:51 Info: MKRVIDOR4000_template_mbox_lite_sys: Generating <b>MKRVIDOR4000_template_mbox_lite_sys</b> "<b>MKRVIDOR4000_template_mbox_lite_sys</b>" for QUARTUS_SYNTH
2019.06.12.12:10:53 Info: Interconnect is inserted between master JTAG_BRIDGE_0.avalon_master and slave mb.mst because the master has address signal 32 bit wide, but the slave is 9 bit wide.
2019.06.12.12:10:53 Info: Interconnect is inserted between master JTAG_BRIDGE_0.avalon_master and slave mb.mst because the master has waitrequest signal 1 bit wide, but the slave is 0 bit wide.
2019.06.12.12:10:53 Info: Interconnect is inserted between master JTAG_BRIDGE_0.avalon_master and slave mb.mst because the master has readdatavalid signal 1 bit wide, but the slave is 0 bit wide.
2019.06.12.12:10:55 Error: null

Thanks in advanced for any help or advice.

Kergadon:
2019.06.12.11:59:41 Info: Adding qspi [arduino_generic_quad_spi_controller2 18.1]
2019.06.12.11:59:41 Warning: qspi: Component type arduino_generic_quad_spi_controller2 is not in the library

Did you apply patches to Quartus? You need to do it once.

Run the NIOS II Command shell, move to the TOOLS/scripts directory of the VidorBistream repository, and launch the ‘apply_quartus_patches.sh’

I ran into the build error as well and found I had to run through the following on Windows 10 64-bit to get a successful build: NOTE: This was parsed from the vidor-libraries/VidorBitstream github repo under: "Things to know before getting started"

  1. Open the NIOS II Command shell and set the PATH variable: $ PATH=$PATH:/cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/TOOLS/scripts NOTE: This was valid for my config.

  2. Then change directories to the VidorBitstream directory. NOTE: I did this from one directory up instead.

$ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/

or

$ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga

  1. Set the permissions to the files under VidorBitstream

$ chmod -R a+rw *

  1. Then under the TOOLS/scripts directory, run the patch script $ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/TOOLS/scripts

$ apply_quartus_patches.sh

  1. Download and install the GO Programming language and build makeCompositeBinary. $ cd ../makeCompositeBinary

$ go build -o makeCompositeBinary make_composite_binary.go

  1. Build an example: $ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/projects/MKRVIDOR4000_graphics

$ build_all.sh

This resulted in the following for me:

Info: Quartus Prime Shell was successful. 0 errors, 352 warnings
    Info: Peak virtual memory: 4626 megabytes
    Info: Processing ended: Sat Jun 22 02:28:30 2019
    Info: Elapsed time: 00:06:33
    Info: Total CPU time (on all processors): 00:00:05
create ram + flash app.ttf
Jun 22, 2019 2:28:30 AM - (INFO) elf2flash: args = --input=build/software/MKRVIDOR4000_graphics/MKRVIDOR4000_graphics_lite.elf --output=build/output_files/MKRVIDOR4000_graphics_lite.flash --base=0x008E0000 --end=0x008FFFFF --verbose --save
Jun 22, 2019 2:28:30 AM - (FINE) elf2flash: Starting
Jun 22, 2019 2:28:30 AM - (FINE) elf2flash: Done
projects
ip
cp: omitting directory './ip/GFX/arduino/Vidor_GFX/examples'
cp: omitting directory './ip/QUAD_ENCODER/arduino/VidorEncoder/examples'
cp: omitting directory './ip/NEOPIXEL/arduino/VidorNeopixel/examples'
cp: omitting directory './ip/MIPI_RX_ST/arduino/VidorCamera/examples'

I hope this is on topic.

After perfoming the VidorBistream build process and replacing the existing VidorGraphics Arduino IDE libraries folder with that built from VidorBitstream, ex;VidorBitstream\distrib\MKRVIDOR4000_graphics, as Martino explained to me has rendered my Vidor 4000 Graphics as non functional. I put the original library files back in place but still no luck; none of the VidorGraphics examples or code I had previously created and which were working are working now. All I get on the HDMI output is a white screen with the Arduino log in the middle but not the one from the DrawLogo example.

Okay, so I downloaded, built and loaded VidorBoot from the vidor-libraries GitHub repro and all is right again with the Vidor 4000.

I just built VidorGraphics from the VidorBitstream repo (using Quartus 18.1), and successfully flashed the VidorQrRecognition example sketch to my board.

I have a camera and an HDMI monitor connected, and the monitor shows the camera video fine, but the QR recognition is not working - the blue crossmarks in QR markers are not shown.

If I use the pre-built VidorGraphics (downloaded through "Manage Libraries"), the QR recognition works correctly.

I also note that the pre-built VidorGraphics has version no. "1.1.0" in "Manage Libraries", and my built-from-source version also has version no. "1.1.0" in library.properties, but they are not identical - for example, the "VidorQrRecognition" example from the pre-built library has the famous "while (!Serial);" line, but the VidorQrRecognition example from the github VidorBitstream repo does not.

Is there a known bug regarding QR recognition when building from the github repo? If not, any suggestions on how to troubleshoot?

Hm, it seems the problem is more general than the QR demo:

When I do a cold boot of the Vidor after flashing my source-built code, the HDMI monitor is stuck on only showing the Arduino logo on white background. Graphics commands like vcam.vgfx.Cross() are not working (and no camera video), but the sketch loop() is running, as I can see debug printouts with Serial.print() in the console.

What I did yesterday, was to flash my source-built firmware over the stock firmware/QrRecognition example, without power cycling. After flashing and "soft reset", I got the behaviour described in my previous post (i.e. camera video working, but no QR recognition).

I added some more vcam.vgfx.Cross() and Serial.print() lines for debugging, and it seems that both QR recognition and graphics drawing are broken after soft reset. The sketch receives no QR markers, and also cannot draw any graphics.

If I flash the stock firmware again, I can replicate this behaviour over and over. That is: 1) Flash stock fw 2) Power cycle [ 3) Everything works ] 4) Flash source-built fw without power cycling 5) Camera video still works, but QR recognition / graphic overlay stopped working 6) Power cycle 7) Stuck on white screen w. logo

Is there something wrong with communication between the MCU/sketch and the FPGA? How do we troubleshoot?

Ok, now I'm really confused. I did a really basic test to see that my app.ttf is loaded correctly:

1) Installed precompiled VidorGraphics from Library Manager 2) Flashed the QR example to the board - QR recognition works

3) Built the VidorPeripherals app.ttf from source (e.g: NOT the VidorGraphics app.ttf) 4) Put my custom-built VidorPeripherals app.ttf into the VidorGraphics precompiled library's folder (overwriting the precompiled app.ttf for VidorGraphics) 5) Once again flashed the QR example to the board

6) QR recognition is STILL WORKING?!

But - I flashed the sketch using the wrong app.ttf (VidorPeripherals), which should not contain the necessary things for camera + QR recognition??

So why is QR recognition still working? Has the app.ttf not been flashed to the FPGA at all?

Can someone please describe how they got the VidorBitstream workflow to work correctly? Am I missing something obvious?

rymen: Ok, now I'm really confused. I did a really basic test to see that my app.ttf is loaded correctly:

1) Installed precompiled VidorGraphics from Library Manager 2) Flashed the QR example to the board - QR recognition works

3) Built the VidorPeripherals app.ttf from source (e.g: NOT the VidorGraphics app.ttf) 4) Put my custom-built VidorPeripherals app.ttf into the VidorGraphics precompiled library's folder (overwriting the precompiled app.ttf for VidorGraphics) 5) Once again flashed the QR example to the board

6) QR recognition is STILL WORKING?!

But - I flashed the sketch using the wrong app.ttf (VidorPeripherals), which should not contain the necessary things for camera + QR recognition??

So why is QR recognition still working? Has the app.ttf not been flashed to the FPGA at all?

Can someone please describe how they got the VidorBitstream workflow to work correctly? Am I missing something obvious?

This is exactly what I've been trying to solve, I cleared (keep the file but delete all the contents) both app.ttf and signature.h and nothing changed

ergoen: Hi,

Thanks for the updated files, the Quartus patches seem to work fine now!

I am having problems running the example files however (starting with a slightly modified bare example that should set an output pin to 1 lighting up an LED). If I merely create an Arduino library (as is suggested in the github readme), the Arduino IDE complains that FPGA is defined twice (once in the VidorFPGA.cpp file in the VidorPeripherals library and once in my test library). I can comment out the offending lines in either of the libraries, but I am not certain how to figure out which app.ttf gets loaded in the end.

I have not yet managed to turn the output LED on through code written in Quartus. It seems to me that no matter what app.ttf I try to load, the example sketches from VidorPeripherals (setting outputs to on and off) seem to work. This indicates to me that I am always just loading the pre-compiled FPGA code, am I misunderstanding something?

I have also tried running the blinking example sketch written by Philippe which was posted here earlier and while Quartus indicates that everything compiles fine, the LED connected to port 6 never blinks. Is there a way for me to debug whether I have a problem with my FPGA? (The VidorPeripheral examples work!)

EDIT: Turns out I had screwed up something during my early debugging attempts, restoring the bootloader (according to the other thread) fixed my issue.

Hello, I'm also having the same problem. I tried multiple app.ttf (even with app.ttf with no contents), the results are all the same. I'm pretty confused as the code does try to read app.ttf and signature but the contents don't matter.

Ok, I think I found the problem (but just you wait, there are more problems coming... ^^)

If I re-flash the FPGA bootloader before I upload my sketch containing a new app.ttf, then everything seems to work. It seems that I have to flash the bootloader anew before every sketch upload, for the app.ttf to be written.

The tools for re-flashing the bootloader can be found in this thread: https://forum.arduino.cc/index.php?topic=561393.0

Seems like a really convoluted and error-prone workflow... Would be great if the normal "modus operandi" of a sketch would be to use JTAG (or some other "native" method) to flash the FPGA in the first place, and not be dependent on a working bootloader in the FPGA to receive the app.ttf!

Anyway, now I can consistently flash a new app.ttf.

However, the VidorGraphics library is absolutely useless when built from source with the free version of Intel Quartus. The VidorBitstream repo's README notes that the NIOS2 softcore in Quartus Lite is a crippled version that runs much slower than the one in the paid Quartus Standard.

I can confirm that this causes all graphics commands (like fillRect(), fillCircle() etc.) to run EXTREMELY slowly - you'll watch the picture being drawn pixel-by-pixel, it'll take almost a minute for the VidorDrawLogo example to finish drawing. o.O

Also, I cannot get the VidorEnableCam example to work at all with the source-built library/app.ttf. First, the screen is (pretty slowly) filled with white. Then, when vcam.begin() is called, the screen is (even more slowly) filled with black (pixel by pixel). This is the VidorCamera library filling the graphics overlay with "transparent" pixels, to unveil the underlying camera stream (see here: https://forum.arduino.cc/index.php?topic=560517.msg3824792#msg3824792 and check out VidorCamera::begin() in VidorCamera.cpp).

However - there's no camera video underneath, just black. With the precompiled library/app.ttf, again, it does work.

Sigh. I'm starting to very much regret my purchase of the (expensive!) Vidor, that was being touted as an Arduino with a programmable FPGA! Not as an Arduino with a black-box IC (that technically happens to be an FPGA) which cannot be used for anything but a few useless precompiled toy functions.

A good start would be for Arduino to re-write the FPGA parts of the library to be completely functional when built from source with the free Quartus version.

Even better would be to redesign the board with something like the Lattice ECP5 or Xilinx Zynq-7000 and use the fully open source toolchains available for those! :) That would've been awesome.

Also, the "KISS" mentality would serve well: the Vidor FPGA workflow is very convoluted with all the "infrastructure" in the build environment to stitch together different IP blocks and binary images in god-only-knows-what way - it is a very opaque system for the newbies, much harder to figure out than necessary.

Sticking to plain, simple Verilog projects without softcores, bootloaders etc. would be much easier on the beginner.

I was planning to do a pretty simple project based on the QR reader, where I modified the reference firmware to track visual features in a slightly different way.

After wasting many days on just trying to get this crazy build workflow going, I have now pretty much decided to scrap my project, as it doesn't seem doable unless I rewrite the whole FPGA part from scratch. That was NOT part of my intention, and is also way harder to do for a beginner, than what I was planning to do.

For anyone reading this who is thinking about purchasing the Vidor to get started with Verilog/FPGA development, I would very strongly recommend against it. Go get a Lattice Icestick, Xilinx/Digilent Zybo board or the ULX3S Lattice ECP5 board instead, use the open source toolchains, and you'll likely have a much better time! :)

Thanks for the post. Just curious, have you ever tried to re-flash the bootloader, then program the board with a blank app.ttf and signature.h? I tried it and I saw no change after clearing the ttf and .h, very weird.

Also I saw what you talked about the slow update - but that only happened to me when I used the distrib output from the project compilation using NIOS II command shell. Weird, again.

I'm looking at the USB blaster to solve my 1st problem mentioned.