[WORKFLOW RELEASE] Vidor sample projects are opensource!

Hardware MKR Family MKRVIDOR4000
#1

Hi everyone!

We are finally announcing the availability of both source code and build tools to kickstart your next project with MKRVidor4000!

All the code is available at https://github.com/vidor-libraries/VidorBitstream ready to be forked, compiled, modified and contributed back.

The projects we previously released as precompiled libraries (VidorGraphics and VidorPeripherals) have been adapted to a new, more flexible architecture, which allows to dynamically discovery which IPs are instantiated in the FPGA and, in case they need to control hardware pins, to require them very easily.

Moreover, we also release an experimental USB Blaster "emulator" that can run on the SAMD21 and provide a full fledged JTAG programmer directly connected to the Cyclone10 FPGA. Unfortunately we could only release it in precompiled format due to licensing issues, so you'll need SAMD core 1.6.25 (already available via Board Manager) to compile and link the library.

So, what are you waiting? Let's start hacking 8) !

#2

Looking forward to trying this and learning some fpga programming! I would like to give a head-up about a problem with the Quartus patch however. On my Windows installation (latest 18.1) Quartus comes with source files with both CRLF and LF line endings. This causes the patch to fail with multiple errors like "Hunk #1 FAILED at 34 (different line endings).". The trivial fix of changing the path command to use the --binary flag also fails since some of the target files are CRLF and some are LF.

One suggestion would be to split up the patch files into two parts, one for each line ending. I'm not sure if this is the best (most pragmatic?) approach though.

#3

Hi,
Patches are for 18.0. I had a look at your issue and have a fix for the crlf issue but there’s a change that prevents a file to be updated so on 18.1 it’s going to fail anyway. We’re looking into it and will update soon, maybe even today

#4

hi, an update has been pushed to git. please update and let us know if this fixes compilation. this should fix both CRLF issues and 18.1 compatibility. note that when patching you will still receive an error on a hunk but that is ok as there is a difference between the 18.0 and 18.1 IP blocks and the hunk that does not apply is not required anymore for 18.1

#5

Hello, thank's for posting this. Can you please clarify some points?

  1. I can see major part of this project is a kind of quartus ip optimizations and build system extensions. But can I still just take default vanilla Quartus lite with no patches, build some simple Verilog project with no or minimal deps to external ip (for example, this one taken as a template https://github.com/vidor-libraries/VidorFPGA/tree/master/projects/MKRVIDOR4000_template) to ttf file, convert ttf, produced by Quartus, with createCompositeBinary utility and then incorporate converted ttf to Arduino cpp library. Would some basic staff work in this way or I will still miss something and will have to patch Quartus and use suggested build system anyway?

  2. About createCompositeBinary utility readme says:

https://github.com/vidor-libraries/VidorBitstream/tree/release/TOOLS/makeCompositeBinary

Bitstreams produced by Quartus (in ttf format) are not suitable to be directly burned on the flash since their nibble encoding is reverse.

How come Altera (Intel) chip can't be burned with firmware produced by Altera's (Intel's) software? Where can I read about this?

  1. I am looking at the way ttf file is incorporated to Arduino library and see it is loaded to bitstream array in VidorFPGA class like this:
__attribute__ ((used, section(".fpga_bitstream_signature")))
const unsigned char signatures[4096] = {
 #include "signature.h"
};
__attribute__ ((used, section(".fpga_bitstream")))
const unsigned char bitstream[] = {
 #include "app.ttf"
};

bitstream array constant is not used anywhere else in the code and attribute instruction says its content should be placed to special ".fpga_bitstream" section inside Arduino compiled firmware file. So I can assume, that ".fpga_bitstream" section inside Vidor SAM chip is somehow connected to FPGA's firmware memory at hardware level (or loaded from SAM to FPGA either by SAM's or by FPGA's bootloader code at the start). So what is the actual way of ttf contents inside ".fpga_bitstream" section (when ttf is incorporated to Arduino library) coming to FPGA?

thank's

#6

Hi, Interesting questions. Let me try to answer them in a clear way... 1a) quartus patches are required only if your project uses qspi or serial port as these were modified by us. 1b) the template_bare project is really empty and just contains pinout and a pill. Template_mbox contains a qsys system where the mailbox between Sam and fpga is instantiated. There you can add in qsys your IP blocks and control them using the infrastructure we created (see mailbox and RPC docs under each IP for for reference). 2) the ttf produced by quartus has bits in bytes arrange in the opposite way the FPGA requires them as serialized by the flash. Actually quartus could produce a end file with proper order but it requires post processing as it's not generated at compile time and needs to be converted to text in order to be compiled with the arm application. To summarize, no, quartus does not produce a text file which can be directly compiled and loaded in flash and in any case usually it produces binary files loaded directly by quartus via JTAG. 3) in order create a single binary image we are loading fpga code in a section loaded after the end of Sam d21 flash. This is a trick that allows bossac and bootloader to figure out that the binary file is to be loaded somewhere else, by sending that data to JTAG instead of Sam d21 flash. The idea is that when data exceeding d21 memory is received, that is sent to fpga that writes it to locations of the fpga application space (located after the fpga boot image). 4) fpga flash memory mapped is structured as follows: first 512k are used for fpga boot image, second 512k are used by application image (around 300k are used for fpga binary and the rest for nios application code). The remaining 1mb is going to be used for user applications.. we're actually developing a flash file system to store resources such as fonts, bitmaps, etc.

Hope this clarifies things a bit

#7

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.

#8

Hello, what differences does the VHDL code/commands I write for a Xilinx have, comparing to the VHDL I am going to write for the MKRVidor4000?

#9

alex5678:
Hello, what differences does the VHDL code/commands I write for a Xilinx have, comparing to the VHDL I am going to write for the MKRVidor4000?

FPGA is synthesized with Quartus Prime. They plan to use premade images for several usecase. If I remember right there was plan to do some web integration for fpga build.

Hardcore users download VidorBitstream repository and create own fpga bit files with Quartus Prime Lite or full version. When using nios console you can use provided shell scripts to build libraries for arduino ide.

Top module is made with verilog.

Here is something info about Coding Conventions and bus interface.

#10

Hello,

If I understood correctly, I use VHDL commands with a prefix to each to command in order to be accepted from the Arduino Vidor's FPGA, right?

Thank you...

#11

It’s just naming convention for interface signals.

You just use Verilog or VHDL with specific module interface that their upcoming web tool supports.

You can create FPGA image from scratch or use github templates for creating your own bitstream and library for arduino. For this you need Quartus Prime or Quartus Prime Lite.

#12

Hello Dario,

Regarding your post above:

4) fpga flash memory mapped is structured as follows: first 512k are used for fpga boot image, second 512k are used by application image (around 300k are used for fpga binary and the rest for nios application code). The remaining 1mb is going to be used for user applications.. we're actually developing a flash file system to store resources such as fonts, bitmaps, etc.

Is this ready and/or what is the ETA for release of the flash file system?

Also - is there a detailed memory map of the system? Would be great to see the absolute addresses of the system.

Thanks, John

#13

Hi John, a memory map is not available simply because it depends on what you have instantiated in the FPGA. the only firm thing is that we have reserved the first MB of flash for two FPGA images. since images are smaller than 512K we have set an arbitrary pointer in flash, after the flash images, to which the processor is jumping to execute code.

internally in the FPGA you can get a memory map of the peripherals connected to the processor by looking at the system.h file in the bsp directory generated by the toolchain in the build/software dir of the project

#14

I have followed all instructions on how to build one of the provided projects, but I continuously receive an error when attempting to run "build_all.sh" from within NIOS II:

Error (12006): Node instace "u0" instantiates undefined entity "MKRVIDOR4000_peripherals_lite_sys". Ensure that required library paths are specified correctly, define the specified entity, or change the instantiation. If this entity represents Intel FPGA or third-party IP, generate the synthesis files for the IP. File: C:/intelFPGA_lite/18.1/VidorBitstream-release/projects/MKRVIDOR4000_peripherals/rtl/MKRVIDOR4000_peripherals_top.v Line: 399

This happens for both MKRVIDOR4000_peripherals as well as MKRVIDOR4000_graphics. Bare does not do this (I assume because there are no peripheral IPs included).

Quartus Prime Lite 18.1 is installed, patches script applied, Go installed, running build_all.sh from within project folder...not sure what else to try?

#15

Peripherals project have _lite.qsys files in repository.

It's first building qsys netlist that is used as component in top verilog where your building fail.

I think I had some discussion before and posted some buildscript fixed for lite version

#16

Figured it out, thanks.

Had to open the projects/MKRVIDOR4000_peripherals_lite_sys project, open Settings, Files and click Add All (then remove non Lite version qsys file).

Re-ran build_all.sh and Arduino project now compiles successfully!

#17

Hi,

what about video performance? As I read Cyclone 10 LP is pretty slow device. Spec sheet says 640 Mbps in LVDS mode while MIPI is up to 1Gbps pre lane.

Are HDMI max resolution and fps known?

Best regards, Sergei

#18

Sorry for linking Xilinx appnote

There you can find different display resolution vs needed bandwith in TMDS.

With 650 Mbps you can have XGA (1024x768@60fps 24b)

#19

thank you, Limba. I am OK with Xilinx :)

#20

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.