Jump to content
  • 0

Artix-A7 non-GUI development

bmentink

Asked by bmentink,

Question

bmentink Frequent Visitor

bmentink

Posted
Posted

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

Link to comment
Share on other sites

55 answers to this question

Recommended Posts

Natsu Member

Natsu

Posted
Posted

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

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

@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.

Link to comment
Share on other sites
jpeyron Prolific Poster

jpeyron

Posted
Posted

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

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted
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?

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

@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 ..

Link to comment
Share on other sites
JColvin Prolific Poster

JColvin

Posted
Posted

Hi @bmentink,

One of our design engineers spent some time looking into this issue. It appears that some of the USB cables we tested had all four conductors twisted together in a manner such that noise or GROUND or VBUS could couple into D+ or D- but not necessarily both. This is bad because that noise won’t be rejected and can result in data errors. Unfortunately it seems that a number of the cables out in world including some that Digilent provides as well have this issue. We are working on getting a new cable set to rectify this. At this point in time, we recommend that you ensure that you are using a USB .org certified high speed cable that has the proper wire construction as no errors were encountered when using those cables.

Thanks,
JColvin

Link to comment
Share on other sites
JColvin Prolific Poster

JColvin

Posted
Posted

@bmentink,

Agreed. From my personal understanding, this issue only becomes an issue during high speed communication and is somewhat uncommon, or at least I was quoted from testing that the USB error occurred sometime between 9k and 300k iterations, so I imagine this does not come up frequently during single use cases as much as one would think from a poorly constructed cable.

Thanks,
JColvin

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

@JColvin

> 9k and 300k iterations

Not sure what that means: You did 300k programs on the one cable?

Testing should be trying a number of cables, because doing multiple tests on the same cable is pointless. (After all, the definition of madness is to repeat the same thing expecting a different result) :)

> I imagine this does not come up frequently during single use cases as much as one would think from a poorly constructed cable.

For me, and at least one other on this forum, it errors out every time on a cable and we tried  a bunch of cables. .... and I mean a bunch. I tried 7 different cables and they all did not program, it was only when I used a real short 6" cable that it worked. The other person refered to in a previous post had the same issue. I don't think you can deflect the problem onto just cables .. they all can't be bad, that's just not logical, especially given the fact that they work just fine doing high speed programming on other boards.

I would suggest you have a USB impedance matching / track layout issue on the board. If the design was "open" ;) us engineers could peer review it for you free of charge, but we can't.

My 2c.

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

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 ... :)

Link to comment
Share on other sites
jpeyron Prolific Poster

jpeyron

Posted
Posted

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

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

@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

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

 

@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

 

 

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

@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

 

 

Link to comment
Share on other sites
D@n Prolific Poster

D@n

Posted
Posted

@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

Link to comment
Share on other sites
jpeyron Prolific Poster

jpeyron

Posted
Posted

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

 

 

Link to comment
Share on other sites
bmentink Frequent Visitor

bmentink

Posted
  • Author
Posted

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 ..)

Link to comment
Share on other sites
jpeyron Prolific Poster

jpeyron

Posted
Posted

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

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to question listing
×
×
  • Create New...