FPGA programming and JTAG

Official Hardware MKR Family MKR Vidor 4000
1

FPGA firmware can be stored in external flash (so that the board boots automatically) or in RAM (which requires loading each time).
As of today the supported upload method is via USB through SAM D21 which allows to burn the program in flash so that it can be read back from the FPGA at boot.

We are have a partially working USB blaster compatibility on SAM D21 so in the future you should be able to see SAM D21 USB port as a jtag interface compatible with quartus and this will allow you to use programmer, signaltap, nios ide etc.

Finally the board has a provision for a JTAG connector (which is not mounted). Pinout is compatible with USB blaster but pitch is not so you’ll have to adapt the wiring, eventually by using the 10 pin to flying terminals cabling supplied with Atmel-ICE.

The only downside of using direct jtag connection is that it will interfere with SAM as it also is using JTAG to communicate with FPGA, so it should be used only with SAM in boot mode or in a state where it does not use JTAG.

some final remarks on flash images: we currently have dual boot and flash is 2 Megabytes so the first 512K host the boot image that produces the arduino logo on HDMI and is able to program or launch the second image, located in the second 512K page, which is the one that can be updated by simply including its header in the arduino code.

this means that there is 1MB in flash free for your usage...

2

Dario,

Few items I need clarification on:

  • Am I correctly interpreting the schematic when I conclude the Cyclone 10 is configured for single device Active Serial (AS) configuration?
  • Can you elaborate on the software/hardware configuration required to burn the FPGA image to external flash via USB?

Backstory: Ordered a board just yesterday - I have a pre-existing application (custom parallel RGB video, proto'd on MAX10 and Cyclone 10) that I'd like to move to this platform, leveraging the D21 for more rapid sensor integration and it's onboard ADC's.

3

Hi Dario, When reading the config from flash how long does that take?

4

Yes, device is configured for active serial. The officially supported flow is that you include a library in the Arduino ide and that will link a ttf file at the end of the Sam application, along with an header carrying destination location and checksum. If you want to burn your image then you need to create your own header file including your ttf and go through a script that creates the header. I'll try to post instructions on this shortly.

Configuration at boot is very fast as fpga loads from flash at around 40 MHz if I'm not wrong and bitstream is around 300kbyte. The only caveat is that we go through two bitstreams now. The first is automatically loaded and the second is loaded after Sam boots and issues the load command to the fpga. If you want to avoid this you can replace the boot image with your customer one.

5

Thanks Dario, will stay tuned for the instructions!

So in AS mode, are you downloading a serial flash loader (SFL) to the FPGA via JTAG? I'm trying to understand how the FPGA knows the correct address to start from at boot, since there are several bitstreams and user space available on the NV flash. I see how the destination address makes it into the Sam image, however.

6

Hi Dario and all,

i´m so glad you finally done a board which has an FPGA on it.

As this is, at least to me, the next level of hardware design.

Currently i use a full open source toolchain based FPGA: http://icoboard.org/ on my RasPi to learn about FPGA.

A cool as this is, it lacks in a userbase. Therefore i really hope your new board, will be
the board of choice when it comes to hobbyist FPGA stuff, the same way as the UNO has become for 8bit MCU world.

I began my DIY MCU stuff with the 68HC11 back in the early 90s and the toolchain was DOS/texteditor/moto-assembler and a moto-debugger.

Also i quit my DIY MCU stuff when they come up with various Win 3.1 toolchains, nearly one for every MCU, different versions needed their own driver subsets and also DOS preperations....

I came back to the MCU world when i played around with the Arduino IDE, as i can focus on programming rather than installing/maintaining toolchains...I still run a 1.3.x arduino IDE for one of my first projects and it still works nice off a SD-Card :slight_smile:

Therefore i really hope your Vidor 4000 will have the same impact, but for programming an FPGA, i already took a look at the 4000 docu...and it´s very promissing, regarding the FPGA in particular:

If i understand it right, i can write and compile my own FPGA modules using the arduino IDE...?

Only my "two-cents" but i really appreciate your step into the FPGA stuff.

cheers,
TC

7

Hi TC,
thank you for your kind words, i really appreciate them and for sure your enthusiasm helps driving our efforts.
i'm sorry that the tutorial let you think you'll be able to program in HDL in Arduino IDE as this is not the case, at least for now. the idea behind the tutorial was to give you some tools to better understand the functionality of our blocks that are being published open source.
right now HDL coding is reserved to who has already some experience with FPGAs and is able/willing to use Quartus. everyone else will have to stick with our precompiled images which we are releasing progressively, at least for a while. right now there is one called "vision" which incorporates QR code marker finder, camera interface, hdmi output with graphics drawing acceleration, neopixel, pwm and quadrature encoder. a second image nicknamed peripherals with 8 serial ports, 5 spi, 4 I2C, pwm, quad encoder and neopixel is coming in the next few days. more will follow...
by october we plan to release our web based "ip assembler" which will allow you to create your own blend of peripherals by chosing which and how many ip blocks you want to include in the image.
i would tend to exclude support for HDL in Arduino IDE as HDL requires additional tools for simulation and so on which are quite more complex than what Arduino IDE is designed for and we have to keep that simple for the larger Arduino audience.
in any case suggestions are always more than welcome.

8

Will Quartus projects mentioned here:
"precompiled images which we are releasing progressively, at least for a while. right now there is one called "vision" which incorporates QR code marker finder, camera interface, hdmi output with graphics drawing acceleration, neopixel, pwm and quadrature encoder. a second image nicknamed peripherals with 8 serial ports, 5 spi, 4 I2C, pwm, quad encoder and neopixel is coming in the next few days. more will follow"

be also be available in source? i.e Quartus porject? The reason is to also understand how projects are development and the ins and outs of FPGA programming.

9

Hi TC,
not immediately as part of it contains IP from Intel we slightly modified and we are working out ways to publish it other than providing patches to install in Quartus.
in any case, i am working on publishing a template project with at least some of those IP blocks so that you can see how they work and derive your project from it.
good news is that for example QR code marker finder is our IP so we'll be publishing it right away!

just a side note... if you are new to FPGAs i would strongly recommend to use the precompiled images we are providing at least for now. when working directly with Quartus there are several caveats that make it difficult to achieve something working in a reliable way and this is the reason why we are working on the web tool to assemble IP blocks...

of course if you want to play with Quartus and have an understanding on how RTL works it's great but developing something there may be quite disgusting for who's not used to it and we want you guys to have fun not to suffer with tools that are meant for ASIC engineers and that are punishing also for them...

10

Hi Dario and all,

thanx for your reply :slight_smile:

Please take a look at icoboard, they already made a open source toolchain for the lattice iCE 40HX8k FPGA,
may you can adapt something from it.

It´s not a good idea to use an FPGA along with "precoded" stuff only....i know nothing comming out of the blue.
But as time goes by more and more people are willing/wanting to do their own FPGA stuff.

May you need to develop your own "FastProGrAmino" FPGA envoirement...or alike. That´s why the guys behind the icoboard and the toolchain reverse engineered that iCE FPGA in order to set up their very own toolchain. As
lattice wheren´t willing to support the DIY scene.

I also think intel doesn´t want that (n)either.....

And i also don´t want to use proprietary tools, which require cloud usage and/or registration and a forced login, in order to use GB wasting local storrage space toolchains which also require online coding/logins. Which are ridiculus/unnessesarily complex and nearly unusable by newbies/hobbyists...... furthermore if the vendor decide to drop/end support for a specific FPGA you´re pretty much doomed, with a nice brick on your workbench....

I don´t know if processing is able to handle inline stuff....if so, you could just parse the FPGA code and hand it over to the FPGA toolchain.

Or another approach could be that you simply define tiny "bricks" for input, output and add, sub, or, xor and DSP "butterflies" for FFT...or even discrete cosine transform and implement some arduino IDE subset FGPA functions.

like:

setup
{
//the usual stuff
}
FGPA
{
//user includable predefined tiny brick functions like

FPGA_FFT (input , ouput (real_,complex*));
FPGA_MUL(input, ouput );
FPGA_sine(....);
FPGA_cosine(....);
FPGA_SQRT(....);
FPGA_AudioINSample(....);
}
loop
{
/
user code which also call
FPGA functions which retur
the result here
/
//my nice 255 bin realtime FFT using the FPGA*
//leaving the vidor 4000 MCU (mostly) idle_

for (byte i=0, i>254, i++)
{
FPGA_AudioINSample(sample(i)); // the HTML here doesn´t quite like rect brackets...
FPGA_FFT(sample(i),outputR(i),outputC(i));
FGPA_QMul(outputR_,outRQ*);
FPGA_QMul(outputC,outCQ);
array=FGPA_SQRT(outRQ,outCQ);
}
// now do some fancy GFX for a nice*
// visual FFT output, may with FastLed, or direct on a
// HDMI connected monitor._

this would be a nice "workaround" for not being able to code native FPGA stuff, until there is a way
someday....:wink:
Cheers,
TC

11

Hi TC,
thank you for your remarks. We are absolutely willing people to get involved with FPGA coding and look forward to have contributions to VidorFPGA repository where we already published most of the IP blocks available in the precompiled images.
At the same time we know very well that FPGA programming is a bit hard and for sure not for the masses so we the last thing we want is letting people think we have a recipe to let anyone code FPGAs.
As i tried to stress several times for most users Vidor should be seen as a microcontroller board with a flexible, reprogrammable set of peripherals. think about it as having the possibility to modify the block diagram of the processor's internal architecture.
I know very well makers are willing to dig into topics and most times do a great job in doing the impossible but at the same time i don't want to fuel false expectations and that's the reason we have a vey well defined roadmap:

  1. at release support only precompiled images and roll out as many as possible, also taking feedback from users (See other posts on audio applications)
  2. by early october release the web based UI that allows assembling your blend of IP blocks. this will allow most people to tailor the FPGA image for their specific needs
  3. gradually produce tutorials and tools to support developers able and willing to help us fuel the IP ecosystem

regarding tools and open source... i'll not comment on the preferences of using exclusively open source stuff but i have to say that right now we are focused on creating content for who wants to create applications that weren't possible before rather than build the tools to do what we're doing. i've learnt that if you want to design a car it's not very wise to start reinventing its wheels so for now we'll stick using whatever tools we have available that allow us to deliver, then if some usable and performant open source alternative at some point pops up be sure we'll look into it.

regarding C to hardware be informed that there are already several (closed source) tools available from FPGA vendors, mostly for free, that allow translating high level languages to FPGA. most of these are for higher end devices and tend to be sub optimal for small blocks but this is for sure something we have in our radar. again the biggest issue is delivering something easy to use AND reliable. unfortunately most of these tool now require strong surveillance on their output in order to get something usable so i'd say that for now they may not be ready for what we are targeting but things change rapidly so stay tuned.

finally, as i wrote we DO encourage native development and will be shortly releasing some tools to help with that.. if you know how to handle FPGA coding you'll have something to play with shortly, in the meantime check our work on the vidorFPGA repo (GitHub - vidor-libraries/VidorFPGA: repository for Vidor FPGA IP blocks and projects).
Dario

12

Hi Dario and all,

thanx for your reply :wink:

i know it takes a resonable time to set up and integrate a whole new envoirement, so i do know you need some time to open the FPGA to the users, please don´t get me wrong here....:wink:

As i already said nothing´s comming out of the blue, take your time. I don´t want to push you. I gonna try the vidor 4000 no matter what, just because there´s already an FPGA on it.

Also i´m very happy with the 10 years old UNO especially the ability to use the 328 in my own circuits. I also made a shield-alike (more a bunch of flex-cables with a dip socket on one end, and two rows of pins which fit into the UNO connectors on the other) thing that plugs into the 28pin dip socket of my designs.. Using this i can test my code in the final unit without changing the 328 every time, nor i don´t need to reserve/exclude pins for ISP programming.

That´s one of the main reasons why i use the 328/UNO continuity....ten years is a very long time in the MCU world....and the IDE still accepts code from the early days...

So please take my above written stuff like a whish - not a "i want it now -- or i don´t buy the vidor4k"
It would be perfect if the user would be able to do his/her own FPGA code in the future.
Also it´s a good step forward to integrate an FGPA - no matter what - and just use it as a changable hardware (I/O) block.

By the way, did i already mentioned that i´m an arduino fanboy....see attach....as i can´t put it displayable in here...:wink:

Cheers,
TC

IMG_20-145840.jpg
IMG_20-145840.jpg2912×1636 1.81 MB

13

Hi agan Dario and all,

i just took a look at the (GitHub - vidor-libraries/VidorFPGA: repository for Vidor FPGA IP blocks and projects) and it seems that i tried to open, already open doors...

Ok, it needs the original FPGA vendor stuff, but since it´s the only way, i gonna accept the challenge and take a look at quartus.

I already did some basic beginners stuff using the icoboard...(some adders and a 7segment clock).

Of course using an FPGA just for adders and a slooow speed clock is may be just wasted time and recourses, but i needed to start somewhere...
And doing stuff i already know on one sort of technology can be more easily transfered to another technology than a complete new idea.

Many thanx, Dario for sharing this link.
Helps a lot...:slight_smile:
Cheers,
TC

14

Hi Dario and all,

this is just a link to something i want to do as well someday, using WS2812b hardback stripes (150LED/mtr.)

I already did a bunch of VU/peak meters using an UNO and up to 64x WS2812 with an added audio hardware OpAmp frontend.

But a nice fast WS2812 at full color weighted patterns along with resonable update rate and FFT processing/weighting with more than 8 bands needs something like an FPGA:

Have fun watching and think about what could be possible using an FPGA and having a large vital userbase in the back, pushing unchanged low end technology to it´s limits... :sunglasses:

Cheers,
TC

15

DarioPennisi:
If you want to burn your image then you need to create your own header file including your ttf and go through a script that creates the header. I'll try to post instructions on this shortly.

Hi Dario,

thanks a lot for your support here! I got my vidor a few days ago and already got to play around with it and so far managed to successfully get the VidorPeripherals sketch to work and blink my LED via the FPGA :slight_smile:
Is there any update regarding the procedure you mentioned above, on how to include your own FPGA-images? In particular, on how to generate the .ttf-file? I can generate ttf-files from my own quartus designs, but so far, I have not managed to get them to work on the device itself (by including them in the application image). Is there some kind of a special preparation/transformation necessary before including the .ttf generated by quartus?
Also, what about the fpga_bitstream_signature?
For the VidorGraphics, the checksum is seemingly the sha256sum of the app.ttf, but for VidorPeripherals, it seems to be something different... the size-field of the signature is also a little mysterious.

I appreciate any pointers. I don't expect a tool that automates all of this for me -- a mere mention of what is what with respect to the signature and the ttf, or a pointer to some place in the code that does the actual uploading or so would probably be helpful, and maybe allow me to figure out the rest.

Cheers,
Julian

16

Hi Julian,
The tool to convert fpga images is coming very soon but first we have to release a bit more stuff such as software drivers running on embedded processor to drive the up blocks we already released.
The hint I can give you is that the ttf needs to be bit reversed as quartus generates them in the opposite bit endianness required by the flash. Note also that along with the fpga bitstream we are also including nios firmware run in place from flash. Btw if you just bit reverse the ttf from quartus you should be able to immediately load your fpga but it won't help much to integrate with our sw infrastructure unless you plan to just use JTAG bridge directly connected to peripherals, thus bypassing the RPC mechanism we set up.
I would ask to be patient as we're scrambling to solve a few issues we had with the early sw release and we're trying to ease the experience for those who want to deal with fpga directly. As I mentioned somewhere else we are dealing with Intel to have the possibility to push some sw to enable USB blaster emulation via SAMD21 and some modifications we made to IP blocks to make them work more efficiently.
Thank you for your patience...

17

Hi Dario,

thanks a lot for your pointers! Indeed, flipping the bits did the trick :slight_smile: With this change, I have now successfully uploaded and tested my own blinky-LED-FPGA image :slight_smile:

But you are right, things would be much easier and more fun, if the USB-Blaster emulation would be available. Until this is available, I guess I will have to be patient...

Thanks again & best regards!

18

Dario;
I have recently been made aware of the Vidor 4000 and a friend of mine thinks it may be the tool we need in our efforts to investigate the CDMA communications between our Model Trains and their controller.

I have been reading the posts regarding the Vidor 4000 and I noticed you mention there are currently no tools for programming the FPGA.

You also mention Quartus.

I have recently been using a CPLD development board at school from RSR Electronics (PLDT2) and the Altera EPM7128SLC84 CPLD chip on the board.

The software I downloaded is Quartus II v7.2 SP3. I run it on a PC under MS Windows XP or Win7.
The PCs I use have a parallel port, which is what the PLDT2 wants to connect to.

Can I use my Quartus v7.2 SP3 setup to program the FPGA on the Vidor 4000?
Thanks
Ray

19

Hi Ray,
You can use quartus along with USB blaster but you will need a more recent version of quartus that supports cyclone 10 lp.
In order to use USB blaster ( or byte blaster if understand correctly) then you would need to mount the JTAG header on the board.
I would not however recommend going this route. We are about to release a sketch that allows sam d21 to emulate USB blaster so you could directly program fpga from Vidor USB connector. Actually if you look at the procedure to restore fpga boot image you will see that the first step loads a sketch that allows second step to upload a svf file as generated by quartus. The sketch is not USB blaster compatible but would do the job if you just want to load the fpga in ram. Elsewhere you will see someone successfully loaded in flash his own image manipulating ttf files generated by quartus but once again I would not recommend this as we're about to release the full flow for this.
The reason why it's taking a while to release these tools is that first if all we need to settle some legals with Intel and secondly we want to polish them a bit more to avoid issues.
Stay tuned...

20

Hi Dario, what is the update on this?