Arduino Forum

Products => MKR Boards => MKRVIDOR4000 => Topic started by: famo on Jan 07, 2019, 05:34 pm

Title: A clear and simple flow
Post by: famo on Jan 07, 2019, 05:34 pm
Hi all.
I want to make my own FPGA projects.

1- I develop it into Quartus 18.1 Lite using the MKRVIDOR4000_template found on GitHub,
    then compile and generate the .ttf file
    As first step a simple 7-bit counter using as output the MKA_A pins, eliminating all other logic
    from the MKRVIDOR4000_top.v file
     --> done (Modelsim fails to find dffas module in its libraries, but this is an Intel open case)

2- As sketch I use "template_bare", why not?
    How to proceed?
    --> it seems I need to compile the Quartus output in a "Arduino library" using the
          assemble_library.sh provided with the VidorBitstream-release

    It is a bash shell script so I need a Linux shell on my Win10 PC, right?
   
    When I have this compiled library, what next?

Thanks for the help
    Fabio
Title: Re: A clear and simple flow
Post by: Limba on Jan 08, 2019, 12:28 am
You can run these shell scripts in NIOS II Command Shell. This uses cygwin linux shell so you can run all provided scripts from here.
You just need to add script folder to path that you can run these under current project folder.
Title: Re: A clear and simple flow
Post by: famo on Jan 08, 2019, 09:54 am
OK, now I have Cygwin.

The folder structure is as in attachement, project folder is MKRVIDOR4000_prova.
In which folder to go in order to run the script?
What should be the result (what folder should be created, what files, what to do
next) ?

Sorry to ask for that but I cannot find any instructions.
Thanks
   Fabio
Title: Re: A clear and simple flow
Post by: riscvdev on Jan 08, 2019, 11:26 am
if you configure your arduino vidor 4000 as USBBLASTER SAM emulator
you can generate a fpga bistream with altera quartus ( .sof  file ) and upload directly from altera quartus


( and generate arduino code with ttf only at the end of fpga project development)
Title: Re: A clear and simple flow
Post by: famo on Jan 08, 2019, 12:19 pm
so
   https://github.com/vidor-libraries/USBBlaster

this opens another branch to my main attempt to write a FPGA+Arduino custom project.

When the main flow will work I'll try with USBBlaster, thanks.
Title: Re: A clear and simple flow
Post by: ergoen on Jan 08, 2019, 11:03 pm
Hi famo,

To make things a bit more (less?) confusing, I actually found that Philippe's guide is slightly less cumbersome to follow, as it only requires one extra java program (apart from the arduino ide). Google translate actually does a good job in translating his step-by-step tutorial:
https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fsystemes-embarques.fr%2Fwp%2Ftelechargement%2F
Title: Re: A clear and simple flow
Post by: famo on Jan 08, 2019, 11:11 pm
While I was writing this post I've received the reply from ergoen.
Thank-you, I'll go to see your link, anyway my post is below.

-----------------

Well, this is what I learned so far:

1- the VidorBitstream-release comes with a BareMinimum stuff:
   VidorBitstream-release/projects/<PROJ NAME>/software/arduino/examples/BareMinimum/BareMinimum.ino
                                                   .                               ..../src/<files necessary to BareMinimum.ino>

  If I try to compile BareMinimum.ino the only way to success is to copy the src folder
  in the same BareMinimum.ino folder and to change the #include path
  --> why? If this is really the only way to compile, why to distribute a wrong file structure?

  So I have to copy src as /examples/BareMinimum/libraries  folder and change the #include path
  to "libraries/xVidorTemplateBare.h"

  The Quartus project seems must be placed here:
   VidorBitstream-release/projects/<PROJ NAME>/projects/<QUARTUS PROJ NAME>

  If I try to load in Quartus the BareMinimum project the CycloneV is the selected family,
  no constraint files linked and so on, so I've rescued my previous simple project from
  MKRVIDOR4000_template.

2- I can see the src folder contains the .ttf file, very likely copied (to be done by hand?)
   from the Quartus project folder.

3- the VidorBitstream-release has a TOOLS/scripts folder with the assemble_library.sh that should
   be the script to be executed in order to have a not well defined "distribution library".

   Where to run the scripts? After several attempts, very likely in project/<PROJ NAME>.

   If I do that a VidorBitstream-release/distrib folder is created, here the Cygwin log translated
   to english:

cp: impossible to execute stat of './projects/MKRVIDOR4000_prova/build/output_files/app.ttf': No such file or directory
cp: impossible to execute stat of './projects/MKRVIDOR4000_prova/build/output_files/signature.h': No such file or directory

   My Quartus project doesn't contain the build folder. I can copy manually the app.ttf file but
   I cannot have a new signature.h file, I keep the existing one in the VidorBitstream-release.
   ---> If it is wrong, where to find/how to generate it?

   So, what is the distrib folder content?

   <PROJ NAME>/examples/BareMinimum/BareMinimum.ino
                        .........../BareMinimum/libraries/<files necessary to BareMinimum.ino>
                ...../src/<files necessary to BareMinimum.ino>
    All seems to be a simple copy of the working folders.

4- Well, what next? I suppose I have to load all into the board.

   I open the BareMinimum.ino in the distrib folder, compile and load it into Vidor4000.
   There are no errors, but the simple counter bits in FPGA I've done are not visible on the A[6:0]
   board pins.
   Very funny: I cannot simulate the Quartus compiled circuit because Modelsim doesn't find
   dffsa unit ... still no answer from Intel.

   Note that if I modify the .ino in the distrib folder there are some permission errors, so the
   distrib seems for "as is/read" use only.

OK, if I don't see the counter pins could be my error, but why I cannot find somewhere
a simple production flow from a Quartus/Verilog empty template to the final board programming?
I don't need now IPs or Nios o whatever, I need simply to write my own Verilog code, produce
the right programming files and to program the board.

In the "Arduino stile" it should be easy and perfectly documented, isn't it?
I'm able to do the Quartus project but following steps are not explained.

I'm still waiting for someone who has already done what I'm trying to do, so he can
explain the right flow.

Thanks again
  Fabio



Title: Re: A clear and simple flow
Post by: famo on Jan 09, 2019, 11:37 am
Hi famo,

To make things a bit more (less?) confusing, I actually found that Philippe's guide is slightly less cumbersome to follow, as it only requires one extra java program (apart from the arduino ide). Google translate actually does a good job in translating his step-by-step tutorial:
https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fsystemes-embarques.fr%2Fwp%2Ftelechargement%2F
Here some results following your link.

The FPGABlinkLED_Sketch/_FPGA is supposed to be a 26-bit counter usign an
"80-MHz FPGA internal oscillator" instantiated in the Verilog file as cyclone10lp_oscillator.
The MSbit is routed to the board MKR_D[6] pin that should be the connector pin marked "6".

If I load the FPGABlinkLED_Sketch as it comes from the above web site, the load time on
Vidor4000 is 4.670 seconds.
After the automatic reboot the red led is steady ON (checked with an oscilloscope) and
the aboce pin "6" is steady = 0.

If I recompile the Quartus project, change the app.h with a new app.h (Quartus output.ttf),
the load time is 11.878 seconds but the result is the same.

In both cases none of the 14+14 connectors pins toggle, the red led is steady ON.

Well, another black hole is in front of me:

- is the FPGA internal 80 MHz clock running? I could route it to a board connector pin and see ...
- is the output.ttf --> app.h copy the right thing? No idea.
- is there someone in the world able to see this "tutorial" working? I'm do not!
- is the so called "tutorial" buggy? (if yes, no hope for me)
---





Loading the FPGABlinkLED_Sketch I can verify with an oscilloscope that the red led is steady ON,
not pulsed
Title: Re: A clear and simple flow
Post by: famo on Jan 09, 2019, 11:56 am
- is the FPGA internal 80 MHz clock running? I could route it to a board connector pin and see ...

Done, nothing is "running", but looking into .ino I note this:

  // Disable all JTAG Pins (usefull for USB BLASTER connection)
  pinMode(TDO, INPUT);
  pinMode(TMS, INPUT);
  pinMode(TDI, INPUT);
  pinMode(TCK, INPUT);

Strange, there is an  #include "jtag.h" but the pins are later disabled?

Anyway, is the bootloader that programs the FPGA or the JTAG/USB Blaster software is
required in each Arduino project to have a FPGA programming at boot time?
Is the https://github.com/vidor-libraries/USBBlaster mandatory?

Why nobody from Arduino staff gives some reply?

Title: Re: A clear and simple flow
Post by: philippe_at_sysemb on Jan 09, 2019, 12:40 pm
Hi famo,

my tutorial should work without problem. Many users have succeeded.

I disable JTAG pins because (in my case) there are only used in the Init phase (to tell the FPGA to load a user configuration).

The pin which should toggle is the pin marked "6" on the MKR connector (the board LED red is not driven by the FPGA)

To test the internal oscillator clock, you can output it on another connector pin :
try to add "assign bMKR_D[7] = wOSC_CLK; " in top level file.

Perhaps FPGA user configuration is not load : if you have a HDMI screen, try to connect it (Arduino logo should disappear when my configuration is loaded).
Also if you have a screen connected , you can try my sketch which used DVI out.
Title: Re: A clear and simple flow
Post by: ergoen on Jan 09, 2019, 12:50 pm
Hi famo,

Just running Philippe's FPGABlinkLED_Sketch through the Arduino IDE (with the pre-supplied app.h) produces the behaviour on my Vidor as shown in the attached video. (My LED has a built-in resistor)

I did encounter similar problems to what you are describing before (where nothing really happened irrespective of what I was trying to load). For me, this was a firmware issue, I had to restore the bootloader according to the other thread on this forum and then update to the latest bootloader through the Arduino IDE (File->Examples->(Examples for Arduino MKR Vidor 4000)->SAMD_BootloaderUpdater
Title: Re: A clear and simple flow
Post by: Limba on Jan 09, 2019, 01:08 pm
I think first vidors had very bad bootloader and I recommend to do bootloader update for it.
I also had uploading problems before update. About 1/25 times it was working.

I more like to use USB Blaster clone. Recommend to take copy of vidor_bare project and start with that. In that project it also includes pinout file from constraits forder. Without that file it's really mess when synthesis randonly place pins.
Title: Re: A clear and simple flow
Post by: famo on Jan 09, 2019, 01:48 pm
Hi famo,

Just running Philippe's FPGABlinkLED_Sketch through the Arduino IDE (with the pre-supplied app.h) produces the behaviour on my Vidor as shown in the attached video. (My LED has a built-in resistor)

I did encounter similar problems to what you are describing before (where nothing really happened irrespective of what I was trying to load). For me, this was a firmware issue, I had to restore the bootloader according to the other thread on this forum and then update to the latest bootloader through the Arduino IDE (File->Examples->(Examples for Arduino MKR Vidor 4000)->SAMD_BootloaderUpdater
I confirm: right now I've reinstalled the bootloader using the VidorFPGARecovery files.
The Philippe's blinking led now works (!) but my own project stops uploading ad 37%.
I remember this 37% has been experienced by someone in the forum, I have to search the thread.

Do you know if VidorFPGARecovery is equivalent to SAMD_BootloaderUpdater?
Title: Re: A clear and simple flow
Post by: famo on Jan 09, 2019, 02:02 pm
I confirm: right now I've reinstalled the bootloader using the VidorFPGARecovery files.
The Philippe's blinking led now works (!) but my own project stops uploading ad 37%.
I remember this 37% has been experienced by someone in the forum, I have to search the thread.

Do you know if VidorFPGARecovery is equivalent to SAMD_BootloaderUpdater?

Very funny: further attempts to load the Philippe's example now hangs all at 62%
(also after power supply reboot)

Title: Re: A clear and simple flow
Post by: ergoen on Jan 09, 2019, 02:10 pm
Hi famo,

I had similar issues, after updating the bootloader with SAMD_BootloaderUpdater, they went away.
Title: Re: A clear and simple flow
Post by: famo on Jan 09, 2019, 02:55 pm
Thanks, now the download doesn't hang anymore.

The Philippe's led blink example works each time I upload it but if I recompile it under my Quartus 18.1
replacing the old app.h with the new app.h (app.ttf), I don't see the signal on D6.


Philippe, what is missing?

Title: Re: A clear and simple flow
Post by: philippe_at_sysemb on Jan 09, 2019, 03:45 pm
Just to be sure : Have you bit reverse the stream generated by quartus ?

You have to execute java ReverseByte MKRVIDOR4000.ttf app.h

where :
- MKRVIDOR4000.ttf is the quartus output file (or anything.ttf)
- app.h will be the generated file to include in the sketch

Java executable ReverseByte is available here :

https://systemes-embarques.fr/wp/wp-content/uploads/2018/10/ReverseByte_V2.zip (https://systemes-embarques.fr/wp/wp-content/uploads/2018/10/ReverseByte_V2.zip)
Title: Re: A clear and simple flow
Post by: famo on Jan 09, 2019, 07:05 pm
Just to be sure : Have you bit reverse the stream generated by quartus ?


No, I didn't know, only right now I see your site
https://systemes-embarques.fr/wp/archives/mkr-vidor-4000-programmation-du-fpga-partie-1/

before I was directed on
https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fsystemes-embarques.fr%2Fwp%2Ftelechargement%2F


Reversing the byte it works.

Question: is this step mandatory for ANY project or your project has something special?

Tomorrow I'll have to try with my 7-bit counter project from VidorBitstream-release//BareMinimum.

Thanks a lot for your help, at the end I have to write a little user manual for my colleagues.
Title: Re: A clear and simple flow
Post by: ergoen on Jan 09, 2019, 11:15 pm
Sorry, my bad, I thought I had linked the google translate of the guide, not the download page ><.
Reversing is needed for everything you build, also using the "official" scripts, there it is done with a go-program instead of the java one :P.
Title: Re: A clear and simple flow
Post by: famo on Jan 10, 2019, 12:47 pm
Well, it seems that if I use the Philippe's project as starting point all works and I'm very satisfied!

Thanks to everyone!

The internal oscillator freq is 66.66 MHz (more or less, measured with a 100 MHz Rigol oscilloscope).
Th external signal iCLK as FPGA input freq is 48 MHz.

Now I'm going to write my experience to be duplicated by colleagues and students.

If I'll have some difficulties I'll post again.

My case at Intel regarding Modelsim simulation is

https://forums.intel.com/s/question/0D50P00004B61NMSAZ/modelsim-instantiation-of-dffeas-failed-the-design-unit-was-not-found?language=en_US

could be interesting.

Thanks again
   Fabio
Title: Re: A clear and simple flow
Post by: DarioPennisi on Jan 10, 2019, 09:35 pm
Hi guys,
Sorry to jump in late. Looks like we still need to clarify documentation but in the meantime thank you for your patience and enthusiasm.

The infrastructure we put together assumes you will use JTAG bridge and softcore to communicate with arm. This is why the Arduino stuff in the arm side stops working when you start from the bare project which doesn't have the above.

The issue we didn't document well is that template bare does not produce a library to be loaded via ide because you would not be able to communicate. This is for sure my fault and I apologise for this. Also, note that if you manage to load the fpga bitstream it would work only after you call fpga.begin as that enables clock output from samd, which is used by the ppl that generates all the clocks in the fpga. In the next days I'll try to update stuff so that things get a bit easier...
Title: Re: A clear and simple flow
Post by: Limba on Jan 10, 2019, 11:25 pm
Also there should be documents how to use direct jtag-avalonmm for memory access. In this case we use quartus jic for programming fpga config flash.

Only unknown part is how to start SAMD21 side communication for jtag and enable FPGA clock without FPGA library or with USB Blaster lib.

Other issue may be to use JTAG AvalonMM with active signaltap. Workaround would be to use SPI/uart for communication to FPGA?
Uart to Avalon MM should be pretty easy solution.

Title: Re: A clear and simple flow
Post by: DarioPennisi on Jan 11, 2019, 01:04 am
Hi Limba,
tomorrow morning you'll see updates in the readme of the git repo which will contain much more info on how projects are working and how to correctly generate an arduino library out of the toolchain.
regarding your questions...
1) we're not using Intel's JTAG to avalon MM bridge because it has too much overhead. our bridge source code is in the ip dir in github and if you just want to use that without softcore then you can simply use the writeBuffer and readBuffer methods of VidorJTAG object (defined here: https://github.com/vidor-libraries/VidorBitstream/blob/release/ip/RPC/arduino/VidorUtils/src/VidorJTAG.cpp) and used for example here: (https://github.com/vidor-libraries/VidorBitstream/blob/e098c778ef6aaaec204a66dfb3e1bebdc395ca13/ip/RPC/arduino/VidorUtils/src/VidorMailbox.cpp#L40)
unfortunately at the moment these files are in the RPC ip which is not that correct (VidorJTAG should be under the JTAG Bridge IP) but it's clean up work in progress...
2) enabling FPGA clock from SAMD side is done calling enableFpgaClock function, defined in the core here: https://github.com/arduino/ArduinoCore-samd/blob/67bf93e52e52ccb75142bbbeb6588ecf9b042952/variants/mkrvidor4000/variant.cpp#L221
3) we're working on having JTAG bridge running in parallel with signaltap and other functions. unfortunately there's some Intel magic we are trying to demistify...

hope this helps
Title: Re: A clear and simple flow
Post by: tcmichals on Jan 29, 2019, 03:34 pm
>3) we're working on having JTAG bridge running in parallel with signaltap and other functions. unfortunately there's some Intel magic we are trying to demistify...

Can you please provide more information on this issue?  (I'm also trying to understand how to use signaltap with jtag etc)

From JTAG_BRIDGE.v, the code still uses the megafunction VJTAG_INST from Intel?   

Also, the NIOS processor does not process the request, it just pushes the request onto the Avalon bus? 

(Thank you)
Tim
Title: Re: A clear and simple flow
Post by: Limba on Jan 29, 2019, 06:34 pm
From JTAG_BRIDGE.v, the code still uses the megafunction VJTAG_INST from Intel?   

I think main problem with this is in SAMD side. Now they have to provide binary library of USB Blaster (because of licensing) and that won't allow jtag commands from sketch. So for memory access you need to use other serial connection.
Title: Re: A clear and simple flow
Post by: DarioPennisi on Jan 31, 2019, 04:27 pm
Hi,
the issue with having Quartus/Eclipse functions work in parallel to SAMD is simply that USB Blaster just receives "raw" JTAG signal states so on the SAMD side we should know where to interrupt the stream without breaking what's being transmitted from the other side... right now this is still somehow not always well defined, hence having the two working reliably in parallel is not yet doable
Title: Re: A clear and simple flow
Post by: famo on Feb 07, 2019, 10:08 am
After project design in Quartus and simulation with Modelsim, last step:
the sketch.

On the Philippe's tutorial I see the JTAG pins mapped on pins 12,13,14,15:

#define TDI 12
#define TDO 15
#define TCK 13
#define TMS 14

--> I suppose the pin named TDI is mapped on physical pin 12 of the processor, right?

If yes, looking at MKRVidor400 schematic, I see the pins 12,13,14,15 are not for JTAG purpose.
I'd like to use the processor pin 12 (pin A6 on the shield connector) and 13, 14, 15 for my project.

Questions:
1- is the above JTAG a mapping error?
2- (I'm new to Arduino) is the 12 on the above #define the processor physical pin number?

Thanks
   Fabio





 
Title: Re: A clear and simple flow
Post by: Limba on Feb 07, 2019, 12:02 pm
What I checked from schematics JTAG is in PA12-PA15 (pins 21-24). JTAG is only between ARM and FPGA. There are place for 10 pin connector or cable buttom side of pcb.


JTAG connection library is in Users\<User_Name>\Documents\Arduino\libraries\VidorPeripherals\src\utility and jtag_host.cpp file

So defined numbers are PA io numbers.
Title: Re: A clear and simple flow
Post by: famo on Feb 07, 2019, 12:37 pm
Thanks Limba.

Do you know if the JTAG pins #define on Philippe's sketch are needed in order to make
the boot to work? (Can I comment them?)

If they are needed, why the pins are different from schematics one and how they can
work there?

Title: Re: A clear and simple flow
Post by: famo on Feb 07, 2019, 03:06 pm
Waiting for a reply from Philippe,

his example inlcudes a local (with .ino file) jtag.h.
Opening the .ino, the IDE opens also app.h, jtag.h and jtag.c (this is local as jtag.h).
I cannot find any #include of jtag.c, but it is needed because there are calls to its routines.

So, I try to:

1- comment   //#include "jtag.h"
  --> jtagInit()  not found

2- replace   #include "jtag.h" --> #include <jtag_host.h>  which is in the place you indicated
   --> jtag_host.c  file not found

How to include the path Users\<User_Name>\Documents\Arduino\libraries in the sercah path
for compilation?

Where the search paths are defined?

Thanks for the help.
Title: Re: A clear and simple flow
Post by: famo on Feb 08, 2019, 11:48 am
What I checked from schematics JTAG is in PA12-PA15 (pins 21-24). JTAG is only between ARM and FPGA. There are place for 10 pin connector or cable buttom side of pcb.


JTAG connection library is in Users\<User_Name>\Documents\Arduino\libraries\VidorPeripherals\src\utility and jtag_host.cpp file

So defined numbers are PA io numbers.
In my jtag_host.cpp I see

#define TMS     28 // PA14             | SERCOM2/ PAD[2]
#define TCK     27 // PA13 -> SPI CLK  | SERCOM2/ PAD[1]
#define TDO     29 // PA15 -> MISO     | SERCOM2/ PAD[3]
#define TDI     26 // PA12 -> MOSI     | SERCOM2/ PAD[0]


What are the numbers 26 ... 29?

Also, I've printed the LED_BUILTIN that I can switch on/off and it is 32.
On the schematic it is on PB08.

What is the formula that gives the pin #define value?


Title: Re: A clear and simple flow
Post by: philippe_at_sysemb on Feb 09, 2019, 01:01 pm
Hi all,

if I look in the SAMD21G datasheet PA12, PA13, PA14 and PA15 (TDI, TCK, TDS, TDO) are on pins 21,22,23 and 24.

(https://systemes-embarques.fr/wp/wp-content/uploads/2019/02/SAMD21G_Pinout.gif)


So board's schematic and SAMD21G datasheet are coherent :)

Now looking in the samd21g18a.h file in the arduino's package PA12..PA15 are define from 12 to 15.

So, and it's of course to be confirmed by arduino's guys , I think it's one right method to associate port number, Pin and #define.


Update : I was wrong : values from 12 to 15  work only with low level jtag functions.
All other arduino's functions have to use values from 26 to 29
Title: Re: A clear and simple flow
Post by: famo on Feb 09, 2019, 05:38 pm
Thanks a lot Philippe,
I didn't know about the "Arduino15" folder ... very funny.

So, in your tutorial I see two places where the jtag pins are defined: in jtag.h and in the .ino .

jtag.h comes first, so the winner should be .ino (right?).

Please try to run your tutorial using this #define in the sketch main file

#define TMS     28 // PA14             | SERCOM2/ PAD[2]
#define TCK     27 // PA13 -> SPI CLK  | SERCOM2/ PAD[1]
#define TDO     29 // PA15 -> MISO     | SERCOM2/ PAD[3]
#define TDI     26 // PA12 -> MOSI     | SERCOM2/ PAD[0]

it seems all goes well (or all goes bad but doesn't touch the previuos good programming).

Please let me know, thanks again.
Title: Re: A clear and simple flow
Post by: philippe_at_sysemb on Feb 09, 2019, 06:31 pm

Redefining #define is a very very bad practice.   :smiley-sad:
I'm surprised the compiler is not insulting me.
All the jtag functions in jtag.c file haven't visibility with the #define in the .ino file, so they will  used those presents in the "jtag.h"
The correct #define for the JTAG are from 12 to 15. Even if they are the same, thanks to comment my mistake in the .ino file.

PA26 and PA29 don't exist on the SAMD21 pinout, so in best case setting them will have no effect.
For PA27 it's the FPGA's clock send by the SAMD21, so it's better to keep it as output.
And finaly PA28 is the interruption signal send by the FPGA to the SAMD21 when it has,  if I remember well finishes its work (it was planned but I don't know if new libraries implement it).
Title: Re: A clear and simple flow
Post by: famo on Feb 09, 2019, 07:19 pm
Redefining #define is a very very bad practice.   :smiley-sad:
I'm surprised the compiler is not insulting me.
All the jtag functions in jtag.c file haven't visibility with the #define in the .ino file, so they will  used those presents in the "jtag.h"
The correct #define for the JTAG are from 12 to 15. Even if they are the same, thanks to comment my mistake in the .ino file.
The redefine was there from beginning as duplicate of that in jtag.h,
I've only changed the numbers, and the compilator gives a detailed warning about them.

So I will delete them and will use the samd21g18a.h  file to know the I/O pins #define.

Just yesterdays I've completed the first version of my project on MKRVidor4000 using your tutorial
as starting point.
It receives short pulses from small cosmic ray detectors performing counting, coincidence and time stamping
all on FPGA, and configuration/readout commands with a simple user interface on the processor.

Thanks again Philippe.

Title: Re: A clear and simple flow
Post by: jcristine on Feb 10, 2019, 11:05 pm
if you configure your arduino vidor 4000 as USBBLASTER SAM emulator
you can generate a fpga bistream with altera quartus ( .sof  file ) and upload directly from altera quartus


( and generate arduino code with ttf only at the end of fpga project development)

Can somebody provide steps to "configure your arduino vidor 4000 as USBBLASTER SAM emulator"?

I've been trying for hours.  Maybe I don't understand the use case.  I have Xilinx/Altera Vivado/ISE/Qaurtus experience so I've assumed that if I compile and upload the "USB Blaster" example sketch, the Vidor 4000 board should then enumerate as an Altera USB Blaster so that I can use native Quartus programming tools to upload a bitstreams to the FPGA.

No Luck.  The USB Blaster Sketch compiles and uploads, the board resets and the LED blinks as it should but the Vidor 4000 does not show as a USB Blaster.  It shoes as "MKR Vidor 4000"

Using Win 10, IDE 1.8.8, SAMD Core 1.6.25.

Thank you,

Jeff

Title: Re: A clear and simple flow
Post by: tksm372 on Feb 11, 2019, 04:18 am
Hi,

In my case, I uninstalled the driver and re-connect the usb plug, then unknown device was appeared.
After that, I updated its driver and manually chose the "Altera USB-Blaster" (ver. 2.12.0.0), then it works fine.

https://github.com/vidor-libraries/USBBlaster
"windows trying to load the original Altera driver (which does not expose a composite interface).
Fix: uninstall the original driver before plugging in the board"
Title: Re: A clear and simple flow
Post by: jcristine on Feb 12, 2019, 01:25 am
"I uninstalled the driver and re-connect the usb plug, then unknown device was appeared."

I have no driver installed.  When I plug the Vidor MKR 4000 board in is appears as "Arduino MKR Vodor 4000", not "unkown device"

Thank you,

Jeff
Title: Re: A clear and simple flow
Post by: jwestmoreland on Feb 12, 2019, 03:30 am
jcristine,

I have this working - I am not sure what your issue may be.  (I've switched to using the actual USB-Blaster (II) for all of this.)

Please do a complete uninstall of all FTDI drivers - VCP and D2XX - and reinstall those.

Go to the FTDI site and make sure you have the latest:

https://www.ftdichip.com/Drivers/VCP.htm

To be completely thorough, uninstall, reboot, then reinstall.

I've definitely got this working - on both a Win10 machine and a Win7 laptop - but I also have the USB-Blaster I & II as mentioned above (from past projects).

Edit:  Of course, this is SAM Atmel USB - so, downloading the latest SAM-BA stuff may help.
Sorry - wrong board.

The machine(s) I use have the (complete) Atmel tools installed - could explain why I didn't have any issues. 

Install the SAM-BA and Microchip IDE's if you still have trouble (Atmel was purchased by Microchip).  All downloads are 'free' - initially anyway - what's needed here is definitely free.

YAE:  I'm going to install everything on a new machine - if I see this problem - I will post the procedure I did to resolve it.

HTH,
John W.
Title: Re: A clear and simple flow
Post by: famo on Feb 12, 2019, 10:16 am
So I will delete them and will use the samd21g18a.h  file to know the I/O pins #define.

Big problem if I use the pin #define in samd21g18a.h  file!

The only way to have a working pin #define if I want to use the shield connector pins
A0..A6, D5 (marked as -5 on the connector)
is the following:

#define SCLK     A0                          //  pin A0 on the connector
#define SDATA_IN_TO_FPGA   A1        // pin A1 on the connector
#define SDATA_OUT_TO_PROC A2       // pin A2 on the connector
#define READ_FROM_FPGA      A3       // pin A3 on the connector
#define WRITE_TO_FPGA_ENABLE A4  // pin A4 on the connector
#define TRIGGER A5                         // pin A5 on the connector
#define TRIGGER_RESET  A6              // pin A6 on the connector
#define globalReset  5                      // pin -5  on the connector

Using tha above defines I can operate and check by an oscilloscope
each pin, setting it to 1 and to 0.

If I use the defines from samd21g18a.h file, looking at the schematic

#define SCLK     2                            //  pin A0 on the connector, PIN_PA02
#define SDATA_IN_TO_FPGA   34        // pin A1 on the connector, PIN_PB02
#define SDATA_OUT_TO_PROC 35       // pin A2 on the connector, PIN_PB03
#define READ_FROM_FPGA      4         // pin A3 on the connector, PIN_PA04
#define WRITE_TO_FPGA_ENABLE 5    // pin A4 on the connector, PIN_PA05
#define TRIGGER     6                       // pin A5 on the connector, PIN_PA06
#define TRIGGER_RESET  7               // pin A6 on the connector, PIN_PA07
#define globalReset  43                     // pin -5  on the connector, PIN_PB11


So, what are the "magic" numbers of the working defines?
(decimal values)
                                                               
A0 = 15                                                                         
A1 = 16                                                                         
A2 = 17                                                                         
A3 = 18                                                                         
A4 = 19                                                                         
A5 = 20                                                                         
A6 = 21 

As bonus the LED_BUILTIN that should be attached to processor
 PB08 --> #define PIN_PB08   40  /**< \brief Pin Number for PB08 */
but results to be defined as 32

LED_BUILTIN = 32

With the defines from samd21g18a.h file,
after the program upload the usb communication with MKRVidor4000 doesn't work
anymore, for successive programming and with my terminal emulator.
I can see the usual USB COM port comes up after boot but:
- the terminal emulator hangs at startup and doesn' open its window
- If I want to upload another program, first I have to reprogram the bootloader
using the onboard reset button double-click

Maybe I'm wrong, so I ask here is someone of you has developed a program using the
shield pins and how he has defined the pins.






Title: Re: A clear and simple flow
Post by: tksm372 on Feb 12, 2019, 11:38 am
"I uninstalled the driver and re-connect the usb plug, then unknown device was appeared."

I have no driver installed.  When I plug the Vidor MKR 4000 board in is appears as "Arduino MKR Vodor 4000", not "unkown device"
Today I tried on another PC in which Quartus lite 18.1 is also installed.

As you said, "Arduino MKR Vidor 4000" (with a small alert icon) was appeared in the device manager, but at the same time, additional COM port was also appeared. I think it means the device is enumerated and recognized as a composite device.

Then I manually update the driver of "Arduino MKR Vidor 4000" by the following steps:

1. right-click the "Arduino MKR Vidor 4000" and click "Update driver software..."
2. choose "Browse my computer..."
3. choose "Let me pick from a list..."
4. all device categories are listed, select "Show All Devices", and click "Next"
5. click "Have Disk..."
6. click "Browse..." and choose "C:\intelFPGA_lite\18.1\quartus\drivers\usb-blaster\usbblstr.inf". Click "OK".
7. models are listed, choose "Altera USB-Blaster", and clisk "Next".
8. a compatibility warning is appeared, but click "Yes".

Finally "Altera USB-Blaster" came out on the device manager.

Please note that step 4 is important. When I chose a category other than "Show All Devices", the .inf file was rejected at step 6.
Title: Re: A clear and simple flow
Post by: jwestmoreland on Feb 12, 2019, 11:59 am
jcristine,

On a new machine - all I did was install the arduino nightly build - and I have a USB Blaster (I) and MKRV4K - installed the lib(s); and downloaded the USB Blaster sketch.

Now - both are showing -
Other Devices:
          Arduino MKR Vidor 4000
          USB Blaster

Installed Quartus programming tools:
          Pointed USB Blaster to update driver here:
C:\intelFPGA\18.1\qprogrammer\drivers\usb-blaster

That worked OK.

To be continued....
Edit:  Minatsu Tukisima above has answered - that's the best procedure.

Regards,
John W.
Title: Re: A clear and simple flow
Post by: jcristine on Feb 12, 2019, 09:41 pm
@tksm372:

This:

1. right-click the "Arduino MKR Vidor 4000" and click "Update driver software..."
2. choose "Browse my computer..."
3. choose "Let me pick from a list..."
4. all device categories are listed, select "Show All Devices", and click "Next"
5. click "Have Disk..."
6. click "Browse..." and choose "C:\intelFPGA_lite\18.1\quartus\drivers\usb-blaster\usbblstr.inf". Click "OK".
7. models are listed, choose "Altera USB-Blaster", and clisk "Next".
8. a compatibility warning is appeared, but click "Yes".

WORKS PERFECTLY - Thank you!

It's been years since I've had to install a driver from a ".inf" file and I don't think that I've ever had to do it on Win 10 so with your help, and STEP 4, it works and now Quartus can see the Mkr Vidor 4000 as a Altera USB Blaster so I expect that I can upload VHDL bitstreams directly to the FPGA (I'm not done with the first test yet.)

Prior to this I was just pointing to the drivers folders and checking "include sub-folders" -- that does not work.

Arduino Folks:  it may be wise to copy and paste "tksm372" into both the usb blaster sketch as well as the GitHub page.  It would have saved me hours of frustration.

Thanks again.

Jeff
Title: Re: A clear and simple flow
Post by: tksm372 on Feb 13, 2019, 04:24 am
@tksm372:

This:

1. right-click the "Arduino MKR Vidor 4000" and click "Update driver software..."
2. choose "Browse my computer..."
3. choose "Let me pick from a list..."
4. all device categories are listed, select "Show All Devices", and click "Next"
5. click "Have Disk..."
6. click "Browse..." and choose "C:\intelFPGA_lite\18.1\quartus\drivers\usb-blaster\usbblstr.inf". Click "OK".
7. models are listed, choose "Altera USB-Blaster", and clisk "Next".
8. a compatibility warning is appeared, but click "Yes".

WORKS PERFECTLY - Thank you!
Thank you for your report.
I am glad that it worked well :)
Title: Re: A clear and simple flow
Post by: famo on Feb 13, 2019, 10:46 am
I reiterate my post, perhaps it is appeared in a wrong place.


-------------------------------------
Big problem if I use the pin #define in samd21g18a.h  file!

The only way to have a working pin #define if I want to use the shield connector pins
A0..A6, D5 (marked as -5 on the connector)
is the following:

#define SCLK     A0                          //  pin A0 on the connector
#define SDATA_IN_TO_FPGA   A1        // pin A1 on the connector
#define SDATA_OUT_TO_PROC A2       // pin A2 on the connector
#define READ_FROM_FPGA      A3       // pin A3 on the connector
#define WRITE_TO_FPGA_ENABLE A4  // pin A4 on the connector
#define TRIGGER A5                         // pin A5 on the connector
#define TRIGGER_RESET  A6              // pin A6 on the connector
#define globalReset  5                      // pin -5  on the connector

Using tha above defines I can operate and check by an oscilloscope
each pin, setting it to 1 and to 0.

If I use the defines from samd21g18a.h file, looking at the schematic

#define SCLK     2                            //  pin A0 on the connector, PIN_PA02
#define SDATA_IN_TO_FPGA   34        // pin A1 on the connector, PIN_PB02
#define SDATA_OUT_TO_PROC 35       // pin A2 on the connector, PIN_PB03
#define READ_FROM_FPGA      4         // pin A3 on the connector, PIN_PA04
#define WRITE_TO_FPGA_ENABLE 5    // pin A4 on the connector, PIN_PA05
#define TRIGGER     6                       // pin A5 on the connector, PIN_PA06
#define TRIGGER_RESET  7               // pin A6 on the connector, PIN_PA07
#define globalReset  43                     // pin -5  on the connector, PIN_PB11


So, what are the "magic" numbers of the working defines?
(decimal values)
                                                               
A0 = 15                                                                         
A1 = 16                                                                         
A2 = 17                                                                         
A3 = 18                                                                         
A4 = 19                                                                         
A5 = 20                                                                         
A6 = 21 

As bonus the LED_BUILTIN that should be attached to processor
 PB08 --> #define PIN_PB08   40  /**< \brief Pin Number for PB08 */
but results to be defined as 32

LED_BUILTIN = 32

With the defines from samd21g18a.h file,
after the program upload the usb communication with MKRVidor4000 doesn't work
anymore, for successive programming and with my terminal emulator.
I can see the usual USB COM port comes up after boot but:
- the terminal emulator hangs at startup and doesn' open its window
- If I want to upload another program, first I have to reprogram the bootloader
using the onboard reset button double-click

Maybe I'm wrong, so I ask here is someone of you has developed a program using the
shield pins and how he has defined the pins.

-------------------------------------
Title: Re: A clear and simple flow
Post by: tksm372 on Feb 13, 2019, 12:27 pm
Hi famo,

I found pin mappings are defined in the following file:
"C:\Users\(your_id)\AppData\Local\Arduino15\packages\arduino\hardware\samd_beta\1.6.25\variants\mkrvidor4000\variant.cpp"


like this.
Quote
+------------+------------------+--------+-----------------+--------+-----------------------+---------+---------+--------+--------+----------+----------+
| Pin number |  MKR  Board pin  |  PIN   | Notes           | Peri.A |     Peripheral B      | Perip.C | Perip.D | Peri.E | Peri.F | Periph.G | Periph.H |
|            |                  |        |                 |   EIC  | ADC |  AC | PTC | DAC | SERCOMx | SERCOMx |  TCCx  |  TCCx  |    COM   | AC/GLCK  |
|            |                  |        |                 |(EXTINT)|(AIN)|(AIN)|     |     | (x/PAD) | (x/PAD) | (x/WO) | (x/WO) |          |          |
+------------+------------------+--------+-----------------+--------+-----+-----+-----+-----+---------+---------+--------+--------+----------+----------+
|            | FPGA             |        |                 |        |     |     |     |     |         |         |        |        |          |          |
| 26         |                  |  PA12  | FPGA TDI        |   12   |     |     |     |     |  *2/00  |   4/00  | TCC2/0 | TCC0/6 |          | AC/CMP0  |
| 27         |                  |  PA13  | FPGA TCK        |   13   |     |     |     |     |  *2/01  |   4/01  | TCC2/1 | TCC0/7 |          | AC/CMP1  |
| 28         |                  |  PA14  | FPGA TMS        |   14   |     |     |     |     |   2/02  |   4/02  |  TC3/0 | TCC0/4 |          | GCLK_IO0 |
| 29         |                  |  PA15  | FPGA TDO        |   15   |     |     |     |     |  *2/03  |   4/03  |  TC3/1 | TCC0/5 |          | GCLK_IO1 |
| 30         |                  |  PA27  | FPGA CLK        |   15   |     |     |     |     |         |         |        |        |          | GCLK_IO0 |
+------------+------------------+--------+-----------------+--------+-----+-----+-----+-----+---------+---------+--------+--------+----------+----------+
Title: Re: A clear and simple flow
Post by: famo on Feb 13, 2019, 03:02 pm
Thanks a lot Minatsu!

Are the A0 ... D0 ...  defines  (-->   #define <mySignal> A0) at higher level, as
Arduino shield connector standard?
Title: Re: A clear and simple flow
Post by: philippe_at_sysemb on Feb 13, 2019, 04:04 pm
Thanks to famo's question, I finally looked further in arduino's libraries code and discovered how it works.

The JTAG's pin definition in jtag.h file are the real pin assigments for the processor.
So TDI = 12, TDO = 15, TCK = 13 and TMS = 13.

These defines are used by low level functions (ex : port_pin_set_output_level).

For compatibility problems between arduino cards, the high level functions (pinmode, digitalWrite,...) do not use real processor pin number but an index in the structure g_APinDescription[] (in variant.cpp file).

So the TDO pin (as an example) is at index 29 in the structure with the port number (ulPort = PORTA) and real pin number (ulPin = 15).

To use high level functions, correct #define are :
TDI = 26, TDO = 29,TCK = 27
 and TMS = 28.




Title: Re: A clear and simple flow
Post by: famo on Feb 13, 2019, 04:59 pm
Ok, this is what you have discovered looking into the some file.
Very likely it is not necessary for an Arduino user/programmer to search for
the variant file to know what number he have to put in the pins #define.

Well, were is the manual for that?

here   https://www.arduino.cc/en/Tutorial/DigitalPins
"Digital pin 13 is harder to use as a digital input than the other digital pins because it has an LED and resistor attached ...", this should be valid for any Arduino?

here again "... digital pin 13 ...", chip pin number or what port number?
https://www.arduino.cc/reference/en/language/functions/digital-io/pinmode/


here is mnemonic https://www.arduino.cc/reference/en/language/functions/analog-io/analogread/
analogRead(pin)
"pin: the name of the analog input pin to read from (A0 to A5 on most boards,
A0 to A6 on MKR boards, A0 to A7 on the Mini and Nano, A0 to A15 on the Mega)"

What seems clear is that ALL Arduino boards have the signal names on the shield
connectors, A0 ... An for the possible analog inputs (but good for digital i/o use too),
0 ... m  for the digital i/o, and so on.
These names must be used in pinMode, digitalRead, digitalWrite, ... functions.


Title: Re: A clear and simple flow
Post by: philippe_at_sysemb on Feb 13, 2019, 08:53 pm
I have just corrected all sketches available on my website https://systemes-embarques.fr/wp/ (https://systemes-embarques.fr/wp/) with right #include and #define.
Sorry if it has been a source of confusion for some of you.

Regards
Philippe

Update : I add also a column with values to use for high level functions in the MKR connector description https://systemes-embarques.fr/wp/brochage-connecteur-mkr-vidor-4000/ (https://systemes-embarques.fr/wp/brochage-connecteur-mkr-vidor-4000/)