GuiFree

Members
  • Content Count

    12
  • Joined

  • Last visited

About GuiFree

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. GuiFree

    arty gpio demo

    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.
  2. GuiFree

    arty gpio demo

    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.
  3. GuiFree

    arty gpio demo

    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.
  4. GuiFree

    arty gpio demo

    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.
  5. GuiFree

    arty gpio demo

    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.
  6. GuiFree

    arty gpio demo

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

    arty gpio demo

    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.
  8. GuiFree

    arty gpio demo

    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
  9. GuiFree

    arty gpio demo

    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???
  10. GuiFree

    arty gpio demo

    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 ????
  11. GuiFree

    arty gpio demo

    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.
  12. GuiFree

    arty gpio demo

    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.