Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

About malexander

  • Rank
    Prolific Poster

Profile Information

  • Gender

Recent Profile Visitors

3396 profile views
  1. @sgk I think Xilinx's suggestion to scope the JTAG signals is reasonable - it's good to look at the rise and fall times, setup time, hold time, and the AC overshoot/undershoot. That's something I always do as part of the board bring up/validation process. From a software testing perspective I would do the following with fTCK = 30 MHz: 1. Navigate through test logic reset to Shift-DR (the IDCODE instruction is loaded) 2. Generate N bits of random data, where N is a large number 3. shift N + 32 bits of data 4. compare the first 32 bits against the known IDCODE of th
  2. @sgk From my contact: "We did not come up with any reasonable explanation other than there may have been some signal integrity issue (ex glitch) that occurred during the efuse programming. Given that the ramp on the edges of the dlc10 cable are quite slow, we have observed that this cable ends up being more immune to ringing or other signal integrity related issues. So our hypothesis is that there may be some marginal case where their JTAG signals is more sensitive due to board load or other PCB related issues that may make the JTAG signals more sensitive when programming their ef
  3. @sgk I asked for a status update and will let you know when I hear something. Thanks, Michael
  4. @gojisan Does the problem return if you boot back into standard (non-Linux) mode? I wonder if the issues related to the thumb drives are related to current consumption. Two of the host ports are limited to 500mA each, while the other two are capable of providing 1 amp. I've never paid any attention to which ones I use when using a thumb drive but I'm also using a Sandisk drive. I have noticed that some of the supported wifi dongles will brown out on the 500mA ports when transmitting and are only usable on the 1 amp ports. It may be worth trying the 1amp ports the next time you use th
  5. @michael Inbar Which Spartan 6 board are you attempting to communicate with using a JTAG-HS2? To the best of my knowledge all of our Spartan 6 FPGA boards ship with an onboard JTAG programmer. Also - have you tried using the Xilinx tools? Since you are targeting a Spartan 6 you'd need to use ISE and iMPACT, which are no longer supported in Window 🙁
  6. @sgk Xilinx is still investigating the issue but the feedback I received is that this should be working with 2018.2 of Vivado. You can try a newer version of Vivado, but I'm unaware of any additional firmware versions or timing margin adjustments for eFuse programming.
  7. @Erik Hartwig I'm unable to replicate the issue on an M1 Mac Mini running Mac OS 11.5.2 using Waveforms 3.16.36 with the latest standard mode firmware, Linux image, and adept-bridge software. Can you please upgrade to the latest Linux image and adept-bridge application and see if the intermittent issue goes away in Linux? This is a two step process at the moment that requires a thumb drive with a FAT32 file system: 1. Download ADP3450/ADP3250 Linux Image version 9: here 2. Extract the zip file 3. Copy "deploy.env", "emmc.img", and "usb-image.ub" to the root of a FAT32 USB thumb
  8. @sgk No, the SMT3 and DLC10 use different USB controllers and run completely different pieces of software so it's not possible to downgrade or upgrade to the DLC10 firmware. The firmware images are included alongside the Vivado installation. You can check to see which version you have by searching the Vivado installation directory for "FTDIFW_57*": find /opt/Xilinx/Vivado/2019.1/data -iname FTDIFW_57* /opt/Xilinx/Vivado/2019.1/data/xicom/cable_data/digilent/lnx64/firmware/ The naming scheme is as follows: FTDIFW_<fwid>_&
  9. @sgk It's being investigated by Xilinx but there's no update.
  10. @sgkXilinx is investigating this. Can you please tell me approximately how many units passed and how many failed programming? Thanks, Michael
  11. @sgk Can you tell me the full part number for the Virtex 7 device that you are targeting? Thanks, Michael
  12. @BryanS These are the ones with fixed names: "/tmp/digilent-adept2-shm-dvtbl" "/tmp/digilent-adept2-shm-dvtopn" "/tmp/digilent-adept2-shm-ftdevcmg" "/tmp/digilent-adept2-shm-ftdmgr" "/tmp/digilent-adept2-mtx-dvtopn" "/tmp/digilent-adept2-mtx-dvtbl" "/tmp/digilent-adept2-mtx-ftdevcmg" "/tmp/digilent-adept2-mtx-otinit" This last one has a variable name based on an index that can have a value between 0 and 63. "/tmp/digilent-adept2-mtx-devlock%2.2X" It's in hexadecimal so if the index was 63 decimal then the file name would be "/tmp/digilent-adept2-mtx-devlo
  13. @BryanS @attila I spent some time debugging this and discovered that the Adept Runtime is receiving EACCES when trying to open files with read/write permission in "/tmp". The following call results in -1 being returned when the file already exists and was created by another user, other than root: open("/tmp/digilent-adept2-shm-dvtbl", O_CREAT | O_RDWR, S_IRWXU | S_IRWXG | S_IRWXO ); This will ultimately lead to error code 3090 (initialization failed) because we use these files for locking while performing certain operations and if they can't be opened then the system won't fun
  14. Hi @BryanS @attila Error code 3090 means that something failed during initialization. It works for me in Ubuntu 16 and Ubuntu 18 but I was able to replicate the issue in Ubuntu 20. It has something to do with the file locks that are created in /tmp. If I run the DmgrEnumEx with my standard account (malexander) it works fine and I can run it as many times as I want. If I run it as root then I get error code 3090. If I then execute "rm /tmp/digilent-adept2-*" to remove the files that we create in /tmp then it works again without error even if I run it with a non-root account. What's weird i
  15. @Daniel Carrasco IC8 is an inverter powered at 2.3V so if you are measuring 3.3V at R5 (the input, pulled up) and 2.3V at output (R35, pull down to ground) then the inverter is not working correctly. Maybe IC8 was somehow damaged or there is a solder bridge underneath. How many modules do you have experiencing this behavior? Can you look at IC8 on the boards that work with a magnifying glass or microscope and see if it appears visibly different than the ones that don't? Thanks, Michael