• 0
bmentink

Artix-A7 non-GUI development

Question

Hi,

While I am waiting for my brand new board to arrive, I am setting up the tools to do primarily non-GUI development. I.E  From a Linux shell I just want to create a Makefile project that runs the tools to do the symthesis/routing etc and programming.

I have installed the Vivado tools and have them running on the command line, so I can do a simple "make bitfile" and it will do it .. however, I can't seem to find any information on this site to do the programming of the FPGA ram or Flash with command line tools, can anyone help with that.?

Also, since I am programming in Verilog, there does not seems to be a lot of examples (apart from the ADC one) that I can reference, they are in in VHDL. It would be useful to have some more Verilog examples and some more howto's on non-GUI development.

Last question :) Can anyone explain the format of the board restraints (*.xdc) file, I can understand the 1st line below, but the meaning of the 2nd one eludes me:
 

Quote

 

#set_property -dict { PACKAGE_PIN M3    IOSTANDARD LVCMOS33 } [get_ports { pio[01] }];

#IO_L8N_T1_AD14N_35 Sch=pio[01]

 

Many Thanks

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

Hi @bmentink,

Looking at the   inout wire [48:1] pio you shared of your top module above and the xadc there is a discrepancy with pio[15] and pio[16] not being included in the xdc. I would suggest to re-number pio[17] through pio[48] to pio[15] through pio[46] and in the top module have  inout wire [46:1] pio. Let us know if this resolves the xdc error you are getting.

thank you,

Jon

Share this post


Link to post
Share on other sites
  • 0

@jpeyron

That solution partially worked, but no cigar.  I get:

Quote

Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device
ERROR: [Place 30-58] IO placement is infeasible. Number of unplaced terminals (9) is greater than number of available sites (0).
The following are banks with available pins:
 IO Group: 0 with : SioStd: LVCMOS18   VCCO = 1.8 Termination: 0  TermDir:  BiDi RangeId: 1 Drv: 12  has only 0 sites available on device, but needs 9 sites.
    Term: pio[1]
    Term: pio[2]
    Term: pio[3]
    Term: pio[4]
    Term: pio[5]
    Term: pio[6]
    Term: pio[7]
    Term: pio[8]
    Term: pio[9]

 

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,

Here is a Xilinx forum that discusses this issue and might be helpful. Could you attach your new xdc. Can you post this portion of your top module like you did earlier?

module top(
  input wire CLK,
  input  wire DUO_SW1,
  input  wire RXD,
  output wire TXD,
  output wire LED,


  input  wire RXD1,
  output wire TXD1,

  inout wire [48:1] pio

  );

 

cheers,

Jon

Share this post


Link to post
Share on other sites
  • 0

Sure, my top module is:
 

Quote

 

module top(
  input wire CLK,
  input  wire DUO_SW1,
  input  wire RXD,
  output wire TXD,
  output wire LED,


  input  wire RXD1,
  output wire TXD1,

  inout wire [44:1] pio

);

 

I have attached my new .xdc file. Thanks.

CmodA7_Master.xdc

NOTE: As well as pio[15] and pio[16] missing from pio array, there is also pio[24] and pio[25], I filled that gap as well, hence the ending on 44

(Those gaps were in the original file I got from you guys ..)

Edited by bmentink

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,

I am thinking that vivado is not liking the 0 in front of the number. In the xdc could you remove the 0 from pio[01] through pio[09]  so it looks like the below text.

\set_property -dict { PACKAGE_PIN M3    IOSTANDARD LVCMOS33 } [get_ports { pio[1] }]; #IO_L8N_T1_AD14N_35 Sch=pio[01]
set_property -dict { PACKAGE_PIN L3    IOSTANDARD LVCMOS33 } [get_ports { pio[2] }]; #IO_L8P_T1_AD14P_35 Sch=pio[02]
set_property -dict { PACKAGE_PIN A16   IOSTANDARD LVCMOS33 } [get_ports { pio[3] }]; #IO_L12P_T1_MRCC_16 Sch=pio[03]
set_property -dict { PACKAGE_PIN K3    IOSTANDARD LVCMOS33 } [get_ports { pio[4] }]; #IO_L7N_T1_AD6N_35 Sch=pio[04]
set_property -dict { PACKAGE_PIN C15   IOSTANDARD LVCMOS33 } [get_ports { pio[5] }]; #IO_L11P_T1_SRCC_16 Sch=pio[05]
set_property -dict { PACKAGE_PIN H1    IOSTANDARD LVCMOS33 } [get_ports { pio[6] }]; #IO_L3P_T0_DQS_AD5P_35 Sch=pio[06]
set_property -dict { PACKAGE_PIN A15   IOSTANDARD LVCMOS33 } [get_ports { pio[7] }]; #IO_L6N_T0_VREF_16 Sch=pio[07]
set_property -dict { PACKAGE_PIN B15   IOSTANDARD LVCMOS33 } [get_ports { pio[8] }]; #IO_L11N_T1_SRCC_16 Sch=pio[08]
set_property -dict { PACKAGE_PIN A14   IOSTANDARD LVCMOS33 } [get_ports { pio[9] }]; #IO_L6P_T0_16 Sch=pio[09]

thank you,

Jon

 

 

Share this post


Link to post
Share on other sites
  • 0

@jpeyron

That did the trick, many thanks :)

Vivado seems pedantic at times, doesn't like IO port designations without placing "wire" in there as well .. ISE tools accepted it without, so do other manufacteres ..

Share this post


Link to post
Share on other sites
  • 0

@bmentink,

I recall vivado accepting I/O port declarations without the wire, at least for inputs, until I started adding

`default_nettype none

to the top of my files.  This particular directive forces Vivado to insist that you declare all your variables, rather than automatically assuming "wire" for anything undefined.  You wouldn't believe how many mis-spelled registers and nets I've caught since.  "verilator -cc -Wall module.v" also catches a lot of bugs too--usually faster than it takes Vivado to start synthesizing your code in the first place.  That way, by the time you are willing to pay the price of running Vivado, you already know you have a good chance of your code working.

Dan

Share this post


Link to post
Share on other sites
  • 0

@malexander

Hi,

I have managed to load the FPGA ram fine, but having issues using your flash programming tcl file. Can you help with the .mcs file creation?

I have the following at the moment, not sure if it is correct for the Artix-a7:

Quote

set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]

write_bitstream -force -file $output_dir/flash.bit
write_cfgmem -force -format mcs -interface SPIx4 -size 4 -loadbit "up 0x0 $output_dir/flash.bit" -file $output_dir/$output_file_name\.mcs

It seems to flash when using your tcl script, but it doesn't run ..

Is this correct? Not sure on the size .. or if I should be using 4-bit bus
EDIT: Here is the output of the script:

Quote


# program_hw_cfgmem -hw_cfgmem [get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
Mfg ID : 20   Memory Type : ba   Memory Capacity : 16   Device ID 1 : 0   Device ID 2 : 0
Performing Erase Operation...
Erase Operation successful.
Performing Program and Verify Operations...
Program/Verify Operation failed.
ftdi_read_data returned 0, expected 5
ERROR: [Labtools 27-3144] Invalid option: ftdi_read_data returned 0, expected 5
program_hw_cfgmem: Time (s): cpu = 00:00:00.17 ; elapsed = 00:00:43 . Memory (MB): peak = 1670.340 ; gain = 8.000 ; free physical = 784 ; free virtual = 4749
ERROR: [Common 17-39] 'program_hw_cfgmem' failed due to earlier errors.

    while executing
"program_hw_cfgmem -hw_cfgmem [get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]"
    (file "prog_flash_35t.tcl" line 26)
INFO: [Common 17-17] undo 'startgroup'
INFO: [Common 17-206] Exiting Vivado at Wed Oct 25 10:28:28 2017...
make: *** [Makefile:13: flash] Error 1

 

 

Edited by bmentink

Share this post


Link to post
Share on other sites
  • 0

 

@jpeyron

Thanks Jon,

Now I get the following error:
 

Quote

 

Program/Verify Operation failed.
cannot set write enable bit or block(s) protected
ERROR: [Labtools 27-3144] Invalid option: cannot set write enable bit or block(s) protected
program_hw_cfgmem: Time (s): cpu = 00:00:00.01 ; elapsed = 00:00:31 . Memory (MB): peak = 1664.430 ; gain = 2.094 ; free physical = 896 ; free virtual = 4550
ERROR: [Common 17-39] 'program_hw_cfgmem' failed due to earlier errors.

    while executing
"program_hw_cfgmem -hw_cfgmem [get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]"
    (file "prog_flash_35t.tcl" line 26)
INFO: [Common 17-17] undo 'startgroup'
INFO: [Common 17-206] Exiting Vivado at Wed Oct 25 11:44:15 2017...
make: *** [Makefile:13: flash] Error 1

 

 

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,


Here and Here are xilinx forum threads that might help.

It shows for BPI 16 width flash bin file generation is

write_cfgmem -format bin -interface bpix16 -size 128 -loadbit "up 0x0 c:/main.bit" -file main.bin

cheers,

Jon

Share this post


Link to post
Share on other sites
  • 0

@jpeyron

Hmm, thought the Flash was a 4-bit wide Micron so not sure why the BPI example .... are you saying I should use bpix4 ??

Maybe someone at  Digilent would know what -interface setting I should use .. for their hardware ...  (I don't know if you work there or not? ;) )

I went of this document, that states to use SPIx4 ...

https://forums.xilinx.com/t5/Embedded-Development-Tools/Generating-bin-file-in-Vivado-with-merged-elf/td-p/491080

Edited by bmentink

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,

Sorry for not clarifying that this is an example of the format. The above code is an example from the Xilinx forum thread from the pdf here on page 15. Based on the example I would use bpix4 instead of bpix16. I can confirm with my co-workers here at Digilent for more information tomorrow. 

cheers,

Jon

Share this post


Link to post
Share on other sites
  • 0

That did not work, I get:
 

Quote

 

Command: write_cfgmem -force -format bin -interface bpix4 -size 4 -loadbit {up 0x0 ./design_output/flash.bit} -file ./design_output/artix-A7.bin
ERROR: [Writecfgmem 68-26] Unsupported interface "bpix4".

Supported interfaces are SMAPx8, SMAPx16, SMAPx32, SERIALx1, SPIx1, SPIx2, SPIx4, SPIx8, BPIx8, BPIx16.

 

The ball is yours ... :)

Share this post


Link to post
Share on other sites
  • 0

Hello,

I don't have any technical advice to offer, but to a certain extent this conversation all seems like a problem with the Xilinx software experience since I don't think it's on Digilent to provide methods on what appears to be (from my inexperienced viewpoint) a non-standard use case. Or at least I presume Digilent isn't obligated to support non-GUI usage of Vivado. On another random side note, it may sometimes be a bit for Digilent to get responses from co-workers since there doesn't seem to be that many Digilent support people available to begin with, especially if it happens to be at the end of a business day with whatever time zone they are in. Just some random thoughts from a non-technical person who is probably wrong anyway.

~Natsu

Share this post


Link to post
Share on other sites
  • 0
49 minutes ago, Natsu said:

Hello,

I don't have any technical advice to offer, but to a certain extent this conversation all seems like a problem with the Xilinx software experience since I don't think it's on Digilent to provide methods on what appears to be (from my inexperienced viewpoint) a non-standard use case. Or at least I presume Digilent isn't obligated to support non-GUI usage of Vivado. On another random side note, it may sometimes be a bit for Digilent to get responses from co-workers since there doesn't seem to be that many Digilent support people available to begin with, especially if it happens to be at the end of a business day with whatever time zone they are in. Just some random thoughts from a non-technical person who is probably wrong anyway.

~Natsu

@Natsu

I disagree somewhat. Digilent should be able to support their boards, they made them , not Xilinx, and they should provide a howto for non-gui development on their boards, or at the very least provide differences from the xilinx boards so I can make changes to the xilinx scripts .... if I can find them.

After all, the schematics are not even complete for the cmod-a7 board .... so am I supposed to guess the connections?

>Digilent isn't obligated to support non-GUI usage of Vivado.

Why not? By your argument they don't have to  support GUI usage on Vivado either then. If Digilent want to support those of us that might want to do small/large production runs of a product that uses the cmod-a7 board, then we need to have non-GUI tools setup to program the board in production .... can't do that with a GUI. (I am making the assumption Digilent is interested in more than just single item purchases ..)

If we have to go chase up the tools/scripts necessary to do that all over the net, that is not  a good end user experience ..... I still don't have everything setup ..... after how many days?

Edited by bmentink

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,

Unfortunately, the engineers in applications,support and R & D that I was able to reach all use the GUI to generate the BIT and BIN file. I will pass on your suggestion of supporting command line for the design process for our boards in our next meeting. I would also suggest to reach out to xilinx support here. I am sorry that we do not have any further information available at this time. As a suggestion I would try using "write_cfgmem -force -format bin -interface SPIx4 -size 4 -loadbit {up 0x0 ./design_output/flash.bit} -file ./design_output/artix-A7.bin"  since the SPIx4 is a setting used in our GUI tutorial linked above. Another potential option is use the GUI to generate the bit and bin file through development until you have a final product that you want to load for production. The tcl script and the command lines that @malexander gave you will allow you to program the boards using command lines for production.  

cheers,

Jon

Edited by jpeyron

Share this post


Link to post
Share on other sites
  • 0

@jpeyron

Thanks, but as mentioned in a previous post, I had already used the SPIx4 interface option. I have posted on the xilinx forum as well, will update this post if I have any luck.

I also said I was using @malexander's script .... it is his script that is not working!

 

PS: I don't want to use the GUI intially because it plasteres files all over my nicely formated project tree .. I will just program the FPGA for now and will wait to program the flash until there is some support to do that. It just means I can't easily test my product as it is battery powered.

Edited by bmentink

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,

In you earlier post it appears that you are trying to get the generate a mcs file initially and then after my suggestion a bin file from the bit file. I am unaware of how to have the tcl script do this or to do this from the command line. I would suggest to generate the bin and bit file from the GUI.  As long as you have a bin file this tcl script works. I was able to get the tcl script to program the Cmod A7-35t in Windows 7 and on a Ubuntu 2016.04 VM.  I attached a very basic bin file. I also edited the prog_flash_35t.tcl script on line 17 to show my bin file. You should only need to change the name of the file in the tcl script.  I have attached the edited tcl script below.

In windows I have a folder on my desktop with the prog_flash_35t.tcl and the btn_led.bin file in it. In windows i opened the Vivado HLS 2017.3 command Prompt. I then cd to my folder with the  using "cd C:\Users\jpeyron\Desktop\flash_cmod" and then I enter the command "vivado -mode batch -source prog_flash_35t.tcl" and it programmed my flash on the Cmod-A7-35t.

In my Ubuntu VM i was able to get the tcl script to work as well. I needed to move both the tcl script and the bin file to /opt/Xilinx/Vivado/2016.4/bin. I then cd to the same directory and ran xsdb. Once xsdb was open I used the same command  "vivado -mode batch -source prog_flash_35t.tcl" and it programmed by Cmod A7-35t. 

let us know if the .bin file i have attached does not work for you and the error messages you get.

cheers,

Jon

btn_led.bin

prog_flash_35t.tcl

cmod_a7_command_line.jpg

cmod_a7_command_line_2.jpg

Share this post


Link to post
Share on other sites
  • 0

@jpeyron

Ok, I used your files and it flashed the led.bin file  ........ once ... the next time it error'd out with:
 

Quote

 

source prog_flash_35t.tcl
# open_hw
# connect_hw_server -url localhost:3121
INFO: [Labtools 27-2285] Connecting to hw_server url TCP:localhost:3121
INFO: [Labtools 27-2222] Launching hw_server...
INFO: [Labtools 27-2221] Launch Output:

****** Xilinx hw_server v2017.3
  **** Build date : Oct  4 2017-20:06:41
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.


# set target_name Digilent
# refresh_hw_server
WARNING: [Labtoolstcl 44-27] No hardware targets exist on the server [localhost:3121]
Check to make sure the cable targets connected to this machine are properly connected
and powered up, then use the refresh_hw_server command to re-register the hardware targets.
ERROR: [Labtoolstcl 44-199] No matching targets found on connected servers: localhost
Resolution: If needed connect the desired target to a server and use command refresh_hw_server. Then rerun the get_hw_targets command.
ERROR: [Common 17-39] 'get_hw_targets' failed due to earlier errors.

    while executing
"get_hw_targets *$target_name*"
    invoked from within
"current_hw_target [get_hw_targets *$target_name*]"
    (file "prog_flash_35t.tcl" line 5)
INFO: [Common 17-206] Exiting Vivado at Thu Oct 26 16:07:24 2017...
make: *** [Makefile:16: flash] Error 1

 

It seems the HW server crashes after programing the device, it will only program again if I reboot the machine ...

I also see the USB device fails enumeration after the one program .... which also maybe the issue .. I get in dmesg:

Quote

[ 1258.986362] usb 1-1.1: new high-speed USB device number 6 using ehci-pci
[ 1259.143034] usb 1-1.1: new high-speed USB device number 7 using ehci-pci
[ 1259.303035] usb 1-1.1: new high-speed USB device number 8 using ehci-pci
[ 1259.723041] usb 1-1.1: device not accepting address 8, error -71
[ 1259.796376] usb 1-1.1: new high-speed USB device number 9 using ehci-pci
[ 1260.216386] usb 1-1.1: device not accepting address 9, error -71
[ 1260.216607] usb 1-1-port1: unable to enumerate USB device

I have to move the device onto another usb hub to get a  good enumeration ... or reboot.

 

EDIT:

SUCCESS: After a reboot, my bin file also programs .... once ... I wonder if the hw server is crashing and tying up the USB port so it cannot program a second time .. oh, well at least I know the script works ...  also, sometimes the programming just locks up, never returns, have to kill -9 the hw server process ..

Many thanks for your help Jon

 

Edited by bmentink

Share this post


Link to post
Share on other sites
  • 0

@bmentink,

This sounds like a power issue--like the CModA7 is browning out once it starts to draw power.

You might wish to try either another USB cable, another port on your machine, or a dedicated (and powered) USB hub,

Dan

Share this post


Link to post
Share on other sites
  • 0

@D@n

I don't think that is the issue ... a powered hub or different port made no difference. Also I have the same issue on another PC.

Also, I measured the 5V current while it was performing the erase/programming stage and it goes right down to 5ma, then back up to 130mA run current  on reset which is no where near the USB 500mA allocation.

A program after the 1st boot up of the PC always works ... subsequent ones don't .... if it was a power issue I would expect variable results on the 1st program as well ..

I have tried multiple cables.

Cheers,

EDIT:

I see another poster is having similar USB issues here:

https://forums.digilentinc.com/topic/3500-cmod-a7-hw-target-shutdown/?page=0#comment-12972

Like me, the poster had problems programming the board after the initial one time.

Maybe there is a USB issue with the board? @jpeyron Any more feedback from the hardware engineer on this issue.

 

UPDATE: I tried a USB cable just 6" long and that seems to work ok. Anything longer and I have issues. For me it is only a problem for Flashing, if I program the FPGA direct, that works fine will all cables. I would suggest that either the USB hardware on this board is marginal .... ;) .. or there is some issue with the flashing code ..

Edited by bmentink

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now