Basys3 Artix-7 FPGA Trainer Board

[AN_newbie]

Hello,

I bought a basys3 artix-7 FPGA Trainer board off of Amazon (seller: digilent), in an attempt to learn FPGA programming.

I  am having problems programming the flash.  I was going through the abacus tutorial on youtube, and had few problems downloading to the FPGA via Jtag, and getting the tutorial to work.

The problem was programming the Flash.  The particular board I am using has the Macronix part number MX25L3233FMI-08G 32Mb flash.

I downloaded the 2016.4 as per the tutorial, but the version of Vivado did not offer the particular Macronix flash as a programming option.

I tried the spansion version of the flash (size and structure similar) using Vivado 2016.4, but not surprisingly, this produced errors.

I tried to download the latest version of Vivado, but it looked totally foreign, and I didn't want to try to figure out how to get it to work.

So is there a version of Vivado that offers Macronix 32Mb flash? 

What are my options to get the flash to program? 

Buy the Spansion version of the flash and solder it in?

 

Thanks.

 

 

[Ana-Maria Balas]

It's okay. You can get back with the response whenever you want. I'm here! 

[PaulJX]

All great and thanks; Now there is a newbie's question regarding BitStream and .elf program, power-on loading from Flash:

Does elf loading from Flash only work for internal-BRAM linked programs? As such, loading external SRAM (or SDRAM) addressed program would require the help of a bootloader.elf. This is the principle preached by many a tutorial from Digilent.

If the above is not necessary, then I could simply 'combine' the RTL bitstream with my custom elf program (myapp.elf) into Download.bit and Flash that to the QSPI flash chip.

On the other hand (if it is necessary) then the Download.bit would contain the bootloader.elf and I would need to convert myapp.elf to an SREC file and write that SREC file onto the Flash chip separately (into a region away from the address range used by the bitstream, with the OFFSET known by the bootloader.elf).

Which view, of the two above, is more true ? Could you advise, such that I can avoid the agony of trial-and-error ? Thanks. --- PaulJX

 

[Ana-Maria Balas]

Yes, I think the memory test interfere with the fact that all the data and code section of the project runs from SRAM. It's good that you commented that part of code, if the project runs, then it means there is no problem with SRAM memory. 

Also if you want to see how the memory test behaves, just change in the linker script to use microblaze internal bram and you can uncomment that part of the test.

 

[PaulJX]

OK, so I proceeded to commenting out the actual memory testing actions, and then the programs moved onto the button and LED tests and seems to be alive and kicking.

This is good and I can go back to the original issue of Flash storage and boot from Flash. So it is a good milestone achieved. Thanks for your help in getting to here. --- PaulJX

[PaulJX]

Hi Ana-Maria,

Good news and 'bad' news below:

Good news first,

1) Vivado/SDK 2018.2 installation worked smoothly;

2) The OOB project successfully went through RTL all the way to Bitstream generation without incidents.

3) SDK loaded OK, but the OOB application project did not load, because there was a URI reference error that could not be resolved. So I manually created an empty application with a new name "OOBdemo1", and then copied over the <src> directory that was meant to be for the OOB-application. That seemed to have worked OK, and I was able to run the program, hooking up to a 9,600 baud CoolTerm terminal.

Then the bad news is that the program only started the first segment of the memory test and then got stuck somewhere, as shown by the following CoolTerm session output: (I started the run by right-clicking on the OOBdemo1 application, select "Run As ---> 1. Launch on Hardware (System Debugger)" ...)

--Starting Memory Test Application 20200621pw --

NOTE: This application runs with D-Cache disabled.As a result, cacheline requests will not be generated

Testing memory region: Cellular Ram

    Memory Controller: emc

         Base Address: 0x60000000

                 Size: 0x0007ffff bytes 

(and then from this point on, the program is unresponsive to any button push or any characters from the CoolTerm ...)

<Three sceenshots attached>

I am not sure how you can reproduce this effect without having a CMOD-A7 board.

I am wondering if the memory-test has an inherent conflict with the main program itself, as the program is residing in the same first segment that could be wiped out or corrupted by the memory-test process. Perhaps the memory test should skip the first segment.

Cheers, --- PaulJX

[PaulJX]

Thanks Ana-Maria for working the weekend. So far, I had setup Vivado 2016.4 (on both Windows and WSL2.0 Ubuntu 18.04 LTS), 2017.4, as.well as using 2019.2 briefly. I removed 2019.2 eventually because that version's SDK became 'merged into' Vitis that I found a little too far out for me.

Thus I am quite used to trying different versions of Vivado for fun (not really, but rather mainly for debugging out issues such as Flash and memory types).

(This morning I also discovered that I can install XCST to try things through script automation rather than through the SDK-GUI with Vivado.)

Thus I highly appreciate your finding out that 2018.2 may be the version that we can find common ground on which to debug the OOB with meaningful exchange of data.

OK, it's time for me to download and install Vivado/SDK 2018.2. Cheers, --- PaulJX

[Ana-Maria Balas]

Hello @PaulJX,

I tried to reproduce the errors and I installed Vivado 2016.4 but when I try to generate the bit-\stream, no matter what project I create, the synthesis remains blocked in "queued" mode and I cannot go further with generating the bitstream. None of the solutions I found online fixed the problem, so I don't think you or me should proceed with Vivado 2016.4 version.

I don't know why this is happening, I encountered bugs with this version of Vivado before and I don't use it at all. I recommend Vivado 2018.2 because I personally think is the most stable, free of bugs version, but it's only my opinion. I also saw that there is a release for Vivado 2018.2 for the OOB demo, I generated the bistream myself right know and I can say for sure, that you will not encounter errors. There is not difference between the two OOB projects, only the different versions of Vivado, the one for 2018.2 was upgraded from the 2016.4 version. I attach here the entire project which contains the SDK project, I set the linker script to use the SRAM memory, you only have to run the project on your Cmod because I don't have one to test it.

Cmod-A7-35T-OOB-2018.2-1.zip

However, if you want to stick with Vivado 2016.4:

-As I see from your capture image, the interfaces for gpio 2 leds and rgb led are validated in the Board Flow so I cannot figure out the reason why Vivado doesn't find the constrains for those ports, because I verified the xml files of the Cmod A7-35 board, and the name signals are spelled correctly. That is why I tried myself to recreate the error, but failed as explained above.

You could try the following solution:

-You can disconnect the interfaces for 2 LEDs and RGB LED  from Board flow (right click on them)

-Load the constrain file of the board https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc

-Change the specific pin names with the correct names found in the top file wrapper, as you can see below

## LEDs
set_property -dict { PACKAGE_PIN A17   IOSTANDARD LVCMOS33 } [get_ports { led_2bits_tri_io[0] }]; #IO_L12N_T1_MRCC_16 Sch=led[1]
set_property -dict { PACKAGE_PIN C16   IOSTANDARD LVCMOS33 } [get_ports { led_2bits_tri_io[1] }]; #IO_L13P_T2_MRCC_16 Sch=led[2]

## RGB LED
set_property -dict { PACKAGE_PIN B17   IOSTANDARD LVCMOS33 } [get_ports { rgb_led_tri_io[0] }]; #IO_L14N_T2_SRCC_16 Sch=led0_b
set_property -dict { PACKAGE_PIN B16   IOSTANDARD LVCMOS33 } [get_ports { rgb_led_tri_io[1] }]; #IO_L13N_T2_MRCC_16 Sch=led0_g
set_property -dict { PACKAGE_PIN C17   IOSTANDARD LVCMOS33 } [get_ports { rgb_led_tri_io[2] }]; #IO_L14P_T2_SRCC_16 Sch=led0_r

 

 

[PaulJX]

Ana-Maria,

I think I do have those IP blocks properly connected as shown below:

But BitGen still has the same/similar errors, thus the problem probably lies somewhere else?

Today's new error log attached.

PaulJX

 

 

OOB_errors_20200619a_003.log

[PaulJX]

OK, upon further reading, the next paragraph did say how to set the <path>:

"3.3, Open the copied init script in a text editor. Change the text “<extracted path>” in the script to the path to the extracted vivado-boards folder. Save and close the file."

So it was there I just did not read through the whole thing. But what I did (copying the board_files into the Xilinx-Vivado installation tree) should be equivalent. So there. --- PaulJX

[PaulJX]

Thanks; the instructions for installing the board files show two different ways, one is to install the *init.tcl script(s) but not being very clear in where to put the board archive source-files for the script to find the path when executed; the other instruction that is inside the README.md file that in turn points to "https://reference.digilentinc.com/vivado/installing-vivado/start#installing_digilent_board_files" says basically to copy the board files to the Windows Vivado installation directory, which is pretty straightforward to follow and that was what I did. (By the way, before encountering this issue, I had previously installed all the Arty* board files into that directory already; that is: if the problem were due to missing board files then unless my board files were outdated, it should not have happened).OK, now ready to launch and test the OOB project again. Thanks. --- PaulJX

 

[Ana-Maria Balas]

Quote

Problem ports: rgb_led_tri_o[2:0], led_2bits_tri_o[1:0]

The message error is clear, those signals rgb_led_tri_o[2:0], led_2bits_tri_o[1:0] are not constrained correctly in the xdc file. There are 2 ways to verify those types of errors:

1. Verify that the names of those signals exist at the desired pins and that are spelled correctly, as they are named in the top file of the project in the Cmod_A7.xdc constrain file.

2. The GPIO, memory, and others are directly constrained when adding and IP (AXI GPIO, AXI EMC and other) from Board flow because the signal names are specified in a file from VIVADO BOARDS ( that file is this https://github.com/Digilent/vivado-boards/blob/master/new/board_files/cmod_a7-35t/B.0/board.xml ). However if you don't have the Vivado Boards installed, then Vivado cannot find that file and therefore cannot constrain those signals.

This is where Board flow is:

In your case the person who created this project, didn't use a constrain file, but used the Board flow to add IP's for gpio, memory, which uses the internal constrain file. You can see that the features that are used are marked with yellow.

Did you installed Vivado Boards? This was specified in the Prerequisites of the tutorial which link I posted

If not:

-Close Vivado, go to the proj folder, run cleanup.cmd, this will erase the project you created.

-Install the Digilent Vivado-Boards https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1

-Recreate the project using the create_project.tcl

-Go to the Board tab and verify that the features checked, like the picture from above

[PaulJX]

Dan, Thanks for your advice and I totally agree. The only issue with this particular example is that it was provided to me as an OOB example for CMOD-A7 (by Anna-Maria) today to be a test case for resolving my original issue with Storing program in Flash . Thus it should have built squeaky clean, but may be due to a new build of Vivado-2016.4 (in 2017 according to the banner) Vivado seemed to have enforced more stringent checking than the original build (???) and resulting in these 'new' errors.

Cheers, PaulJX

[D@n]

@PaulJX,

I get these errors often enough when I add new I/O pins to any design.  They are readily fixed.  Vivado is basically saying that it can't match all of the I/O pins in your design to those declared in your XDC file.  Then, in an effort to be helpful, it tries to pick unused I/O pins to map your design to.  (This is actually really bad for most designers, but it does have a purpose for new board designers.)  The pins it picks, however, don't happen to have the same I/O standards as the pins currently in your design, and so the tools helpfulness ends here.  Personally, I think the tool should've stopped earlier when it found an I/O declaration in my design that didn't match the one in the XDC, but either way that's what's going on.  Don't try to suppress the warning--fix the problem.  Toggling random unused I/O pins might cause your design to toggle a pin that's actually connected to something which could have ... undesirable effects.  (My flash will never quite work the same as new again ...)

Dan

[PaulJX]

--- today, I ran into BitStream Generation error when running syth/implement/BigGen, due to at least a couple errors that I could not resolve even if by setting the following tcl script lines:

--- Vivado 2016.4

$$$ start TCL $$$: 

set_property SEVERITY {Warning} [get_drc_checks NSTD-1]
set_property SEVERITY {Warning} [get_drc_checks UCIO-1]

$$$ end TCL $$$:

 

=======================================

 

ERROR: [DRC 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 5 out of 40 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: rgb_led_tri_o[2:0], led_2bits_tri_o[1:0].
ERROR: [DRC 23-20] Rule violation (UCIO-1) Unconstrained Logical Port - 5 out of 40 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined.  To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.  Problem ports: rgb_led_tri_o[2:0], led_2bits_tri_o[1:0].
 

ERROR: [Vivado 12-1345] Error(s) found during DRC. Bitgen not run.
INFO: [Common 17-83] Releasing license: Implementation
14 Infos, 53 Warnings, 0 Critical Warnings and 3 Errors encountered.
write_bitstream failed
write_bitstream: Time (s): cpu = 00:00:20 ; elapsed = 00:00:12 . Memory (MB): peak = 1085.629 ; gain = 80.168
ERROR: [Common 17-39] 'write_bitstream' failed due to earlier errors.
 

OOB_errors_20200618b_002.log

[PaulJX]

This is great material. Thanks.

Please allow me a few days to test the basic configuration and all the variations (internal memory 32k vs 128k, Link to internal vs link to external, and flash the <app>.elf directly vs flashing the bootloader that will load the <app>_SREC). Thanks again, PaulJX

 

[Ana-Maria Balas]

To test the external 512 SRAM with a project that is working for sure, could you try the OOB Demo for Cmod A7-35 T please? Here are the release sources for Vivado 2016.4: https://github.com/Digilent/Cmod-A7-35T-OOB/releases

Here is the tutorial: https://reference.digilentinc.com/learn/programmable-logic/tutorials/cmod-a7-user-demo/start

Download Cmod-A7-35T-OOB-2016.4-1.zip, extract it, and follow instructions found in the tutorial above.

I wanted to add that the linker script is configured to use microblaze_0_local_memory, but you can change it to use axi_emc to test that project works from SRAM.

If it works, then you can follow the "How To Store Your SDK Project in SPI Flash" with the bistream that is generated, and verify that Flash is also working accordingly.

[PaulJX]

Just a fine-point regarding using 32kB BRAM versus using 128kB BRAM, for internal memory;

One hypothetical cause for the 128kB BRAM instantiation issue is that when the <myapp>.elf is running, it is running within the IP-integration's memory space; but when the internal memory is loaded from Flash, the loading of the BRAM is within the FPGA fabrics BRAM block-instance 'memory-space'. Thus theoretically if the IP's memory space is not aligned with the BRAM's 'slice' space assignment, the .elf may not be loaded correctly. But this is purely my speculation.

 

Then the two other separate issues of :

a) the External 512kB SRAM loading from Flash, not working, or

b) the External 512kB SRAM , in JTAG debug mode not working,

could be orthogonal and independent from the internal-memory size (32kB/vs/128kB) factor. But should they be related then it would be something that I cannot fathom.

Thanks again for your time, --- PaulJX

 

By the way, the current actual size of my application program in elf-size is only around 75 thousand Bytes; therefore the external SRAM is only very lightly used.

I am testing it only for anticipating the eventual APP elf size will grow bigger, the extent of which is up to the final complexity of the software.

 

 

[Ana-Maria Balas]

I'm sorry, I was wrong, I was thinking of SDRAM when I gave the indications from above.

Yes, you are right, you cannot use MIG but only Axi Emc. But the tutorial "How To Store Your SDK Project in SPI Flash" is still the one which should work for your need.

The Cmod A7 has 225 KB BRAM memory so I don't think the internal memory is your problem. 

On 6/7/2020 at 7:08 PM, PaulJX said:

But that .elf created with linker script that assigned everything to the axi_emc_0_MEM0 (external 512kB SRAM) would not even run in the 2016.4 SDK/Debugger at all.

I don't understand why isn't running in SDK if you updated the linkerscript and you make the connections right. 

I will try to look into this tomorrow and I'll get back to you.

[PaulJX]

Thanks Ana-Maria for your responding to me.

Since my FPGA board is CMOD-A7 (35T) I was always following the other tutorial

https://reference.digilentinc.com/learn/programmable-logic/tutorials/cmod-a7-getting-started-with-microblaze/start

that is specific to CMOD-A7, which invokes the axi-emc 512kB external SRAM IP.

On your note, supposedly I can / should use the MIG IP instead (hopefully addressing and everything can work for the CMOD-A7 SRAM) ???

Another observation that I made was, it seems that when I was using 32kB for the internal memory (BRAM instantiation), then Flash and JTAG Debug external SRAM seemed to have worked once (and only once). And after I got too comfortable, and instantiated 128kB internal memory, the Flash (without the bootloader, just <myapp>.elf) and JTAG Debug (launch as Debugging) with linker script using external SRAM do not work anymore ???

So my second question is whether the internal-memory size is also another factor?

Thanks again, PaulJX

[Ana-Maria Balas]

Hello @PaulJX,

Did you followed the tutorial How To Store Your SDK Project in SPI Flash ? I don't see the the MIG IP for configuring the SRAM memory of your Cmod A7 in the block design. That is why it doesn't work. Please read the Prerequisites and follow the steps for adding QSPI Flash and MIG IP with the right connections.

[PaulJX]

Could be that I made any mistakes in connecting up the AXi_QSPI interface from MicroBlaze to the flash part? My diagram picture is attached.

I did connect to the ext_qspi_clk with the same axi clock of 100MHz clock as advised, from some source. Thanks again, PaulJX

[PaulJX]

On 11/26/2019 at 4:08 AM, Ana-Maria Balas said:

Hello @AN_newbie,

The MX25L3233 is not supported by Vivado 2016.4. You need to use a more recent version.

I verified in Vivado 2019.1 and is supported. Even if the tutorial uses Vivado 2016.4, the steps are the same in any version.

"it looked totally foreign" - The interface for Vivado 2019.1 is not so different from Vivado 2016.4 just some design changes.

I will put here some steps, maybe it will ease your effort.

1.Link the jumper JP1 to QSPI.

2.Add xdc constraint file Basys-3-Master.xdc

3.Open Implemented Design, then Settings

4.Then check bin_file box in Bistream tab

5.Configure additional bistream settings.

6.General -> Enable bitstream compresion->TRUE

7.Configuration -> Bus width - > 4 

8.Ok -> Apply -> Ok -> Save

9.If you will look into xdc constraint, at the end of the file should appear those lines of code, one with COMPRESS TRUE and another with SPI_BUSWIDTH 4

10.Generate Bistream

Below are the steps for programing from Vivado Hardware Manager.

11.Open Hardware Manager ->  Open Target -> Auto connect

12. Add your memory. For this, right click on device (xc7a35t_0) -> Add Configuration Memory Device -> write on Search "MX25L3233" ->  select the part with mx25l3233f-spi-x1_x2_x4.

13.Right click on the flash memory (mx25l3233f-spi-x1_x2_x4) -> Program Configuration Memory Device -> add configuration file (<project_name>.bin file found in runs/impl  folder)   -> click OK 

Below are the steps for programing the flash from Vivado SDK.

11. In SDK, after you created you application and verified that it's working, go to Xilinx ->Program FPGA and beside microblaze_0 select <yourapplicationname>.elf instead of bootloop

12. Go to Xilinx -> Program Flash, then select the download.bit located inside of your hardware platform folder and leave the Offset box empty, then choose the right flah memory type. (part number is MX25L3233F )

Cheers,

Ana-Maria

Hi Dear Ana-Maria,

I am running into Programming Flash issue on the CMOD-A7 35T board, that is , <myapp.elf> works in SDK debugger using bootloop,  

but programmed-flash won't work/run, in that if I unplug the CMD-A7 from host and re-plug into USB slot it appears that the RTL bitstream

is working but the SDK program is not outputting any messages to stdio/uartlite0 as it should, nor accepting any input commands).

Board: CMOD-A7 35T; flash part is: n25q32-3.3v-spi-x1_x2_x4_0

Vivado/SDK version: 2016.4

Configured internal memory using BRAM 128kB; emc-SRAM 512kB

Parts of lscript.ld shown (below):

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x400;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x800;

/* Define Memories in the system */

MEMORY
{
   microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem : ORIGIN = 0x50, LENGTH = 0x1FFB0
   axi_emc_0_MEM0 : ORIGIN = 0x60000050, LENGTH = 0x07FFB0
}
 

Case 1: If I use only the local_memory_128K, then the <myapp> program runs in SDK-Debugger OK; that is, it can output text to stdio and accept command

from a CoolTerm virtual com port terminal running at 115,200 baud. But if I program it into flash, no text input-output from/to the CoolTerm virtual terminal,

while the RTL appears to be working OK (correctly outputting to LEDs).

Following your advice above in the thread, quoted here: "11. In SDK, after you created you application and verified that it's working, go to Xilinx ->Program FPGA and beside microblaze_0 select <yourapplicationname>.elf instead of bootloop"

Also following similar advice of other article(s) on the topic of:  "How To Store Your SDK Project in SPI Flash"

Some abundant Google search seems to indicate it is a Vivado version problem and I should upgrade to Vivaldo/SDK-2017.4.

 

Case 2: In addition, I was preparing for the future situation when <myapp>.elf size gets too big for the internal 128kB, and tried using the Boot-loader approach suggested by another Digilent CMOD-A7 article on the topic of:  "How To Store Your SDK Project in SPI Flash",

that is write to flash with the <bootloader.elf> that when it runs will load the SREC-converted <myapp>.elf from a higher address zone of the flash (programmed additionally to the RTL/bitstream).

But that .elf created with linker script that assigned everything to the axi_emc_0_MEM0 (external 512kB SRAM) would not even run in the 2016.4 SDK/Debugger at all.

However still, I went ahead and programmed the RTL bitstream added with bootloader.elf plus the <mayapp>.elf SREC at offset address 0x00300000; and 

the whole combo won't work anyways. (By the way, at the same time I also wrote a small program running on internal BRAM 128kB and 'verified' that

read/write of the 512k SRAM appears to be functioning OK within the 512kB address range, at Origin 0x6000,0000)

Do you think upgrading to 2017.4 would solve the problem or is it something that I was doing totally wrong?

Thanks. PaulJX

 

 

[AN_newbie]

Thanks.....I figured out last night I wasn’t running the correct ‘Vivado’.   A subtlety that should be documented somewhere on your tutorial page seeing that Digilent isn’t installing the spansion flash,  Macronix flash isn’t supported in Vivado 2016.4,  this is supposedly an “entry level platform” for learning, and folks like me will copy the tutorials to get up and running..... plus it isn’t obvious where that different version of vivado exists.  It doesn’t launch from the desktop icon as it did with Vivado 2016.4.

But thanks for the reply.

[Ana-Maria Balas]

You are using Vivado HLS. Open just the Vivado 2018.3 which is Vivado HL Design.

"The Vivado High-Level Synthesis compiler enables C, C++ and SystemC programs to be directly targeted into Xilinx devices without the need to manually create RTL."

Also

Quote

Well, ok, I guess I can try the Spansion.  They are similar, and after all its just SPI.

The registers and instructions are different for each flash memory, so no, they are not similar.

[AN_newbie]

11 hours ago, Ana-Maria Balas said:

 

"it looked totally foreign" - The interface for Vivado 2019.1 is not so different from Vivado 2016.4 just some design changes.

Thanks for the reply, Ana Maria.  I have to disagree with you.  The opening menus after create a new project was different.

At the 1:48 minute of the youtube video: "Getting started with Vivado and Basys3", there is a project type menu....RTL Project menu that was missing.  Then selection of kind of part menu was missing.  It was asking for some C files.  All of this is new to me.   C files?  Ok, skip that, don't have/know about C files.  Wait....now the project IDE is different?!  What?.  Where is my RTL project selection request?....that was when I abandoned 2019.2 and uninstalled it, and went to install 2016.4 as used per the video.

Ahhhh, there is my RTL project selection button.  Thankyou.  Ok, making progress now.....check, check, check.....  ok great code is working.  Now download to the flash.

Oooops, don't have the spansion flash on my board.  ok, let's try Macronix...., Ooops, no 32M available.   Well, ok, I guess I can try the Spansion.  They are similar, and after all its just SPI.

How hard can SPI be?  Oooops, Well, that didn't work. 

 

So here I sit.  Currently. I have no faith I can get 2019.2 to work, so I am downloading 2018.3 to see if my little RTL project menu appears.

I am confident I figure it out, I am sure, but I was just following along with the video to see if I could get something to work without burning a lot of brain cells, and pounding my head against the wall.  

All of the rest of your instructions are very familiar.  I am pretty sure I was doing everything per the steps in the youtube video...including enabling the SPI with JP1.

All of that was pretty common sense.  I'll be back if I get stuck.

 

 

Thankyou for your time and help!!

Ugh, 2018.3 does the same.  No RTL project selection.  It's asking about C based source files. Sigh, I guess I'll work with it.