arty gpio demo

[GuiFree]

I have now downloaded Vivado 2017.4, installed it on my 64-bit linux, and managed to
'synthesize'  and 'generate bitstream' Digilent's Arty GPIO_Demo project for
the ARTY that I bought a while ago but have not yet managed to use.

A file GPIO_demo.bit appeared. Great. But now I am stuck.

1. On Basys2/Nexys3 with Xilinx ISE, I use iMPACT to turn the .bit into a .svf,
which I then use to program the board. But when I tried with the Arty GPIO_demo.bit, iMPACT
fails saying "device part 7a35ticsg324 specified in the bitstream is invalid ..."
Do I need a new IMPACT? If so, from where? Mine is "Release 14.6 iMPACT P.68d.
Or is there some other way to persuade Vivado to produce a .svf?

2. With ISE, It is more convenient to use a TTYconsole/script to synthesize the project:

/opt/Xilinx/14.6/ISE_DS/ISE/bin/lin/xtclsh /home/a/myproject.tcl rebuild_project

And everything just happens - no tiresome fiddling with GUI icons and mice.

What is the Vivado equivalent??? In ISE, the myproject.tcl file was built (once) by
clicking Project in the top left and selecting "generate tcl script". But Vivado has no Project after
File Edit in the top left corner...

PS Two vivado desktop icons appeared - Vivado 2017.4 and Vivado HLS 2017.4.
I have no idea which I should be using, so I used the first - which inside calls itself Vivado HLx Editions.

 

[GuiFree]

Thanks, I'll give "MIG" a try for DDR3. The Arty-reference-manual www page mentions “MIG Project” design resource download. Where is it?

Meanwhile...

1. I found your Nexys4 "SRAM to DDR Component" - where is the Arty "SRAM to DDR Component"? Or some other demo VHDL/Verilog source that uses it?

2. Arty_GPIO_demo2016.4.1.zip has .xdc with UART_TX twice, but no rx

3.ArtyS7-50_GPIO_demo2017.2.1.zip has .xdc with UART_TX and uart_txd_in, no rx,

David.

 

[JColvin]

Hi @adiganta,

I asked around and we're thinking it's probably PuTTY, but perhaps an older version (or different tool view for it) than what is currently available now.

Thanks,
JColvin

[adiganta]

Dear sir,

thank you very much for your reply, Tera Term and Putty is known. The GUI picture shown in the ARTY General I/O demo is different, it has so many settings. Anyway Thanks.

A DAS

[JColvin]

Hi @adiganta,

I apologize for the delay. I don't know exact serial terminal that is used in this tutorial, but you if you using a Windows OS, you can use Tera Term. If you are using Linux, you can use PuTTY. There are other serial terminals that will work as well without any problems, those are just the two that I have personally used.

Thanks,
JColvin

[adiganta]

Dear All,

I have attached a file Arty General I/O demo. If u go through the file , there is a GUI to display UART message in the computer. I am looking for the same GUI exe file. Let me know the source. Thanks.

A DAS

Arty General I_O Demo [Reference.Digilentinc].pdf

[JColvin]

Hi @GuiFree,

Looking at the release notes for Vivado, it appears that 2017.4 does not correctly support the Spartan 7-25T chip, but 2017.4.1 edition does (I received a very similar error as you when I tried to run the project). I'll uninstall and re-install Vivado to confirm this is the case and see if there is any other finagling that needs to be done first though.

ISE 14.6 does not have any support for Spartan 7 devices; if I am recalling this correctly, Xilinx did not add support for Spartan 7 devices until the 2017.2 editions and newer of Vivado.

As for the correct Arty .xdc, where are you seeing an issue? I'm not finding any mismatched signals anywhere. Otherwise, the .xdc you want to use would be this one: https://github.com/Digilent/digilent-xdc/blob/master/Arty-Master.xdc. It is labeled for Arty rev B at the top, but I cross referenced with the schematic for Rev C and did not find any differences. There was a couple of pin names (as opposed to pin location) that did not follow the convention Digilent normally uses (ja[0], ja[1], etc), but those have been updated.

Let me know if you have any other questions.

Thanks,
JColvin

[GuiFree]

Arty-S7-25-GPIO-demo fails in My Vivado 2017.4: "No parts matched 'xc7s25csga324-1'

All the other Arty versions of GPIO-demo  - Arty, Arty-S7-50, Arty-A7-35, Arty-A7-100 - synthesize and produce .bit files fine.

My ISE 14.6 has no Spartan7 type.

And I was about to add an S7-25 to my order...

What do I need to do? David.

[GuiFree]

Hi,

Thanks for the pointer, although the XSCT command names are very different from the ones I found.

Anyway, I now find that putting the same open_hw ... sequence into the end of the .tcl that
synthesizes the .vhd and produces the .bit, instead of into a separate .tcl, generates a good .svf. So problem solved.

MUCH WORSE - I now find I am using the wrong arty.xdc - signal pins on JA/B/C/D are mixed up.
I have found .xdc for arty rev A, rev B, rev D, all with the rev letter inside the file, but not in the filename.
My board has 'rev c' in small print on the back. I found an arty...part0-pins file with C.0 in the
name with JA/JB routing different from that in my .xdc, but it is not in .xdc format. Is it the correct data for my board?

Where is the Arty rev C .xdc ?

Thanks again, David.

[jpeyron]

Hi @GuiFree,

I do not have any experience with generation a .svf file. Here is a .svf script the should be helpful.

thank you,

Jon

[GuiFree]

Thanks.

1. The PULLUP stuff looks good - I'll give it a try.

2. Great!  cd /opt/Xilinx/Vivado/2016.4/bin/vivado (actually 2017.4 on my ubuntu)
   and then ./vivado works in my ubuntu too!
   Also in any directory /opt/Xilinx/Vivado/2017.4/bin/vivado works.
   And with -mode batch -source /home/a/mytcl.tcl
   it does the whole synthesis and bitfile generation and a .bit appears. Brilliant.
   
   ... where mytcl.tcl is a combination of one that appeared in the Arty_gpio-demo and the
   example on page 7 'non-project compilation flow' in UG908. ...

3. But... I tried the example on page 78 of UG908 "SVF programming"
  to convert the ArtyGPIOdemo.bit into a .svf. It completes with no error,
   but the .svf it creates is empty, 0 bytes.

open_hw
connect_hw_server
create_hw_target my_svf_target
open_hw_target
set device0 [create_hw_device -part xc7a35ticsg324-1L]
set_property PROGRAM.FILE {/home/a/Arty-GPIO/my.bit} $device0
program_hw_devices $device0
write_hw_svf /home/a/Arty-GPIO/my.svf
close_hw_target

   The corresponding  series of clicks and enters in the GUI generates a good .svf.
   Any ideas???

Thanks again in advance, David.

[jpeyron]

Hi @GuiFree,

Here is the ug912 that should be helpful with the PULLUP, PULLDOWN xdc syntax.  Here is a xilinx forum thread that discusses using tcl scripts from commend line.  I while back i ran a tcl script for the Cmod A7 for a forum thread. 

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  command  "vivado -mode batch -source prog_flash_35t.tcl" and it programmed by Cmod A7-35t. 

you will need to Alter the tcl script to work for the Arty but the attached file is a good reference. Here is some information for using xsdb.

cheers,

Jon

btn_led.bin

prog_flash_35t.tcl

[GuiFree]

Thanks. The DDR3 stuff you point to looks good - but it will take me a while to study it...

Meanwhile, I have managed to synthesize my own design and program it into the real Arty. And it works.
Great, but the process is still much more painful and time consuming than with Basys2/ISE, so:

1. How do I run a vivado tcl script from linux TTY command line, or from  a shell-script or with execve()?
    /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin/xtclsh does this in ISE, but what is the Vivado equivalent?

2. Where is there a tcl script to synthesize and generate bitstream? Without any gui clicking.
    In ISE you click ONCE on 'create tcl script' and it puts one in the project directory to use over and over again. But vivado?

3. What should I put in the vivado .xdc record for a pin to specify PULLUP, PULLDOWN and DRIVE?
    I could not find any examples in the .xdc in the Arty demo projects.
    There are several examples for ISE in the .ucf in the Basys2 demo.

Thanks again, David.

 

[jpeyron]

Hi @GuiFree,

I believe the manual is referring to the Arty Xilinx MIG Resources at the bottom of the resource center. Here is a nexys video project the uses the ddr3 in hdl.  For the 2 demos you point out they do not need to rx for the demo to work. I believe the rx and tx are in reference to the dev board.  Here is a link to a UART_RX_CTRL if you were looking for the rx.

thank you,

Jon

[JColvin]

Hi @GuiFree,

There is a Forum thread that discusses the reason for why the DDR3 is not included with the xdc for the Arty here.

What other things were you looking for in the .xdc file?

Thanks,
JColvin

[GuiFree]

Hi, there are no entries for the external DDR3 RAM in the Arty master.xdc?

Where can I find them? And whatever else is missing?

David.

 

[GuiFree]

I do not know what 'export' is, but it seems to define 'environment' strings??
So I shall try putting yours in the 'env' operand of the execve() syscall that starts the adept stuff,
together with the mysterious "HOME=/home/x" already there, without which adept fails.
And tell you what happens.

Meanwhile, at Digilent's suggestion, I have downloaded and installed the latest adept-SDK and adept-runtime
onto my 64-bit linux, and compiled+linked my jtag stuff with it into a 64-bit .elf,
which loads and runs, but DmgrOpen() returns zero.

- The Arty is plugged in, and appears in /sys/bus/usb/... and /dev/bus/usb/...

- The sourcecode with the various Djtg...() calls is EXACTLY the same as that which works in linux32,
   not even any 'C' preprocessing macros or #ifs.

- 64bit X11, which, like adept, also uses .so linking, works fine
   via (a separate instance of) the same the 32<->64 glue code.

Any ideas?

Thanks, David.

 

[jpeyron]

Hi @GuiFree,

Please enable error logging and attach the log file so that we can see why the transfer failed. This can be done by exporting two environment variables and then re-running the affected application:
a.    "export ADEPT_RT_LOGFILE=~/adept_erc.log"
b.    "export ADEPT_RT_LOGDETAIL=1"

thank you,

Jon
 

[GuiFree]

Hi, Good reply, thanks.

1.
... We don't support the use of 32-bit binaries on 64-bit Linux. ... You do not need to - linux already does.

The point is that 32-bit binaries compiled/linked in 32-bit linux work perfectly in 64-bit linux,
even non-trivial stuff with fork() execve() pipe() mmap() ioctl() on /dev/bus/usb (libusb) and much else,
UNLESS they use shared libraries and/or dynamic linking, that is, they are not actually linked,

... Cross compilation is too much of a headache ... for Digilent's engineers ... and for Digilent's customers.

... we provide everything that's required ... No.  You provide only .so (shared/dynamic libraries - the nightmare sort),
So please supply also .o binaries (the friendly static ones) for dmgr, djtg and the others so that
your customers can avoid the same headache that you want to avoid.

As a useful side effect, this would also mean no need to put stuff in /usr, so upgrading to adept2.4.2
(which I have not tried) would not kill off adept2.3.1 (which I know works).

And, of course, customers who want to use the .so libraries can continue to do so.

Or maybe there some linux tool to convert a .so back into its original .o???

2.
... How large of a data transfer? ... 20Mtck cycles (about 10 seconds) failed sometimes,
and failed always when driven to an ArtyA35 and a Nexys4DDR simultaneously, on the same USB,
using separate processes for the two adept instances.
With just the Arty, but using FS USB, 1Mtck failed a few times, 500Ktck was OK a few times...
The "constant TMS=0" versions -  just TDI, just TDO and TDI+TDO never failed. Note: This jtag
handler always uses multiples of 8tck for these - the SPI on the STM32F401 - so also when driving adept,
so no test of your handling of non-multiple-of-8 tcks for these.

... Therefore we recommend using the other functions when doing a mass data transfer in the Shift-DR tap controller state.  ... Indeed I do - and they go much faster,
I was just surprised that the Arty FT2232 interface is no better at TMS than my 10-dollar STM32F401  jtag host, which
uses an SPI driver, fast, (8 bits at a time) for constant TMS, but GPIO bit-bang, slow, for TMS+TDI+TDO transfers,
but still manages more than 2MHz tck.

3.
... Why not use the 64-bit Adept Utilities, which includes a 64-bit version of djtgcfg? ...
Because more is needed than 'cfg' - the VHDL logic itself uses jtag for all sorts of things - it is so
convenient - the cable is already connected and you know it is working (it has just configured the fpga),
and the communication - multiple DR - is much more flexible/structured than, say, a uart.
But 64-bit adept only links with 64-bit sourcecode with 8-byte pointers, and it would be a
lot of work to change the 4-byte-pointers-sourcecode into that.

Thanks again, David

 

[jpeyron]

Hi @GuiFree,

I reached out to one of our design engineers about this forum thread and they responded with "

1. We don't support the use of 32-bit binaries on 64-bit Linux. If you are using 64-bit Linux use the 64-bit Runtime and Utilities. If you want to run 32-bit binaries then run them on a 32-bit Linux distribution.

We don't support the creation of 32-bit binaries on 64-bit Linux. If you are running 64-bit Linux then compile 64-bit binaries. Cross compilation is too much of a headache due to the need to have all of the dependent libraries (GLIBC, libusb, etc) available. And actually compling is not the difficult part... it's linking that is difficult. In any case, we do not support this and never will. If someone wants cross compile they are more than welcome to figure it out on their own, as we provide everything that's required (header files, 32-bit libraries, 64-bit libraries).

2. How large of a data transfer? The Basys2 and Nexys 3 use different USB controllers than the Arty board. The DjtgPutTmsTdiBits function allows you specify TMS/TDI bit pairs for each TCK cycle. The underlying USB controller doesn't accept data in this format. In order to implement the DjtgPutTmsTdiBits function we effectively have to break it up into N x 1-bit TMS shift commands. This is far less efficient than a normal TDI/TDO shift command, which holds TMS constant and can shift a continuous data stream with up to 65536 bytes. Therefore we recommend using the other functions when doing a mass data transfer in the Shift-DR tap controller state.

3. Why not use the 64-bit Adept Utilities, which includes a 64-bit version of djtgcfg? That seems a lot easier than trying to install of the required dependencies to get the 32-bit binary to work on 64-bit Linux.

Alternatively, why not use Vivado? Version 2017.4 most definitely works with the Arty boards."

thank you,

Jon

[GuiFree]

Thanks for reply...

I have been using adeptSDK2.3.1 for years on linux-32
I downloaded adeptSDK2.4.2 the other day, but have not yet used it - it turns
out that it needs also an adept runtime...

I need a 32-bit version of Djtg, because my sourcecode expects 4-byte pointers.
But it needs to run in linux-64 - where Vivado is.

gcc with "-static" option in linux-32 produces a hello-world .elf that runs OK in linux-64.

So I tried -static when gccing my source that links to Digilent Djtg libraries,
but the linking fails - libjtg not found. (links fine without -static, but then only works in linux-32.)

>>> QUESTION 1 >>> What other magic options does gcc need for -static to work with djtg????   

I have now managed to use open_hw in Vivado's tcl command line, and managed to persuade
Vivado, after a lot of clicking, to produce a .svf from the .bit, and my old 32-bit svf player - the one that links to djtg -
successfully configures the Arty A35. Great.

>>> QUESTION 2 >>> DjtgPutTmsTdiBits() appears to fail intermittently with large transfers,
I have had no problem before with Basys2/Nexys3. Bug???
It is also VERY slow - TCK only about 2MHz - some of the other Djtg functions manage over 25Mhz - close
to the 30MHz max. Why???

 

[JColvin]

Hi @GuiFree,

Which version of the Adept 2 utilities and runtime did you install? There are both 32 bit and 64 bit versions of Adept, though I'm not certain if the 32 bit is intended be compatible with 64 bit OS's.

Thanks,
JColvin

[GuiFree]

Thanks Jon, I'll try again...

Meanwhile, I have just discovered, unexpectedly, that all my 32-bit .elf work perfectly on 64-bit linux,
just 'cd' to the old directory on the non-booted 32-bit partition and ./xyz.elf - no sourcecode changes, no recompiling, no relinking.

But Digilent's Adept utilities - binaries/elfs dadutil and djtgcfg - which work on 32-bit linux, do not work on 64-bit linux.
Neither does my application binary/elf linked to adept djtg.

Digilent bug ????

 

[jpeyron]

Hi @GuiFree,

You also need to install the digilent cable drivers manually as discussed here. You should make sure you are in the dailout group as discussed here. Please download adept 2 and see if it recognizes arty. If it does you should be able to load bit files to the arty as well.

thank you,

Jon 

[GuiFree]

Jon, thanks ...

1. Thanks for pointer explaining  "Vivado High-Level Synthesis".

2. I had already downloaded the board files and copied them into Vivado.
I also downloaded several Arty .... Master.xdc files - but I have not put them anywhere yet?
They look like the same information as .ucf files in ISE?

3.  Vivado has generated a .bit - but how do Digilent/Xilinx expect you to squirt it into the FPGA?
When I try the 'hardware manager', with the Arty USB plugged into the PC running Vivado,
there is no sign that Vivado even 'sees' the Arty board.
Does Xilinx Vivado have a USB handler to handle Digilent's Arty-JTAG implementation based on a FT2232???
Or should you use Digilent's "Adept" stuff - the djtg stuff - which works fine in 32-bit linux,
but not in the 64-bit linux that Vivado needs???

This is why converting the .bit to a .svf is so useful - once converted, you do not
need any Xilinx software to squirt it into the FPGA. You can use Digilent's adept/djtg and use the
on-board usb port, or use any available random jtag host adapter if the board has actual jtag pins - Nexys3, Nexys4.

64-bit linux can 'see' the arty-board USB,
and my 32-bit Digilent/Adept/djtg jtag host - in 32-bit linux -  can even read the jtag device IDCODE.

David.

 

[jpeyron]

Hi @GuiFree,

You chose the correct Vivado. Here is a link that will explain what Vivado HLS is used for.  Here is the Arty-A7 resource center. We have a couple of tutorials that should be helpful with Vivado. I would suggest to install the board files if you have not.

thank you,

Jon