Experience so far with MKR Vidor 4000

I thought this might help someone who is considering (or not) the Vidor 4000:

I purchased this board to investigate using an FPGA to collect frequency data from quartz crystal based acceleration and pressure sensors. Conventional wisdom says these sensors require DSPs to convert the sensor output to calibrated results. For the application I am considering, low power and simplicity are essential, if I can get the frequency data, it is OK to do further processing on a server somewhere. The frequency outputs are around 40 kHz and need to be measured with accuracies better than 1 part in 1E6. The MKR 4000 has everything that’s needed for a proof-of-concept design: the FPGA, a processor and a network interface. I have tinkered with Arduinos in the past and am familiar with their tools and documentation, so this seemed like a natural fit.

After receiving the board, I realized I was faced with a long and daunting learning curve to get the FPGA to do anything. It’s been over 30 years since I did digital design in college, but at least the concepts of state machines, Karnaugh maps, registers and, most importantly, clocking, have somehow stayed with me. (More about clocking later.) Back then, we wired everything up using LS series logic. Now we are faced with Quartus Prime. Of all the resources on the internet, I found fpga4fun.com to be the most accessible.

Naturally you can’t get very far without understanding the MKR board itself. Many, many (beaucoup) thanks to https://systemes-embarques.fr/wp/, without which I would have gotten nowhere. The tutorials, examples and templates are all excellent. My French is rustier than my digital design theory, but I managed to follow this with only occasional help from Google Translate. Both the Quartus project template and the Arduino sketch template are essential starting points. I can confirm that both work fine when you add your own code.

I have not yet tried the bit blaster emulation sketch. For me, loading the bit stream during setup is OK, but at some point I will give the bit blaster a try. Either way, there are extra steps involved in loading the FPGA. Option 1: compile in quartus prime, copy ttf file, flip the bits, include in Arduino sketch. Option 2: load Arduino with bit blaster, compile and download with Quartus, load your own sketch. The fact that I’m on a Mac and using Quartus in a VM means that, with Option 1, I don’t need to mess with drivers for the VM. By the way, the whole reverseByte thing seems just bizarre, surely this could be handled as an option in the JTAG library or otherwise hidden from the user, but I digress.

So, what have I managed to accomplish? I created a simple SPI implementation on the FPGA. The SAMD sends a byte to the FPGA using 8 digital I/O lines, the FPGA grabs this and sends it back to the SAMD using SPI. The sent and received bytes are then sent to the serial interface for comparison. I mostly followed the fpga4fun.com SPI code. Remarkably, only two stupid mistakes separated me from something that worked. The first was a basic Verilog mistake – you can’t load a register from two different always blocks –this requires a multiplex and apparently Quartus can’t figure out where to put the mux if the register is referred to from two different always statements.

The second mistake regarded clocking. I left the PLL wOSC_CLK from the tutorial example and this did not work. Once I changed the FPGA clock to the basic 48 MHz clock from the SAMD (iCLK) everything was fine. Clearly, I will need to look into clocking a bit more. To improve the precision of the frequency counter, I would like the FPGA counters to run as fast as possible, something around 150 MHz would be nice.

Anyway, now that I know I can get data off the FPGA and into the SAMD, which is really pretty exciting, I am ready to proceed to the main objective. I’ve already figured out a state machine that will count clock and signal pulses; this should not be too hard to write in Verilog. I need to find a test signal generator before proceeding any further as well. Hopefully I will get back to this in the coming weeks.

In conclusion, if they tell you the Vidor cannot be used to learn FPGA development, they are wrong. The combination of an FPGA and the SAMD is very powerful. If your focus is only on FPGA or learning the basics of digital design, then, yes, you are probably better off with one of the many development boards. If you hope to add networking or want a general purpose processor for an IoT project, then the Vidor 4000 may be your answer.

Thanks so much for sharing your experiences with the MKR Vidor 4000 and the knowledge you've gained along the way stlentz! It sounds like you've gotten to the point where you're having some good fun working with this board.

It's good to hear someone is using this board and it's are where FPGA is really good solution.

I would use PPS signal from GPS to get time reference. This is repeating 1s pulse and should give pretty good timing reference. Because Vidor4000 don't have VCO that we can adjust then I would use that PPS for reference value for algoritms in SAMD.

What is frequency of quartz crystal?

I was thinkin should we just use that for one counter that use control signals from other clockdomain. This can be good example for new FPGA users how to do clock domain crossing (CDC). Like how use CDC for streched signals and how to do handshake for bus.

For getting that 150 MHz clock just use PLL from IP library in quartus. If you want to use iCLK then it need to be enabled from SAMD.

For that your test example I would use 8bit + rising edge trigger. in cpu you just write data and toggle trigger. If these are in same IO register then you can clear trigger when writing new data and after that rise trigger.

fpga4fun.com and nandland.com is pretty good place to start.
nandland also has verilog and vhdl tutorial + videos in youtube.

Edit:
I have used MS Visio for creating top, block and timing diagrams. I think you can do same with LibreOffice Draw. It really helps when you start to write VHDL or verilog and if you want someone to review if it's working right.