06-18-2015 02:51 AM
Good morning gents and ladies,
First off, I'm not sure if this is the right place to ask, but my problem is kind of related to TCL and the TCL shell command line.
Right now, I'm using Vivado 2014.2 and TCL to build my system. However, sooner or later, I'll need to switch to the latest version, which would be 2015.1. Up until now, I've been using data2mem to imprint ELF files, but that is longer an option. With 2015.1 I either need to use the STR/STC ELF association or UpdateMem.
Now, STR/STC ELF association doesn't work with my build system, as some parts of my design are build in OOC mode and happend to contain Microblazes. Xilinx already acknowledged that ELF association doesn't work in conjunction with OOC build designs and will fix this in 2015.3. So, until then I'll have to use UpdateMem, which is fine with me, as its use case is almost the same as data2mem.
However, when I apply Updatemem on my resulting bitfile, it apperantly clears the USR_ACCESS register, which I use to timestamp the bitfile. This is kind of odd and my question would be: anyone else using UpdateMem and USR_ACCESS timestamps?
06-24-2015 07:42 AM
Thank you. Do you have any related information on this?
I guess it's time to open a case via my customer, that'll be faster than getting any Xilinx attention here.
06-25-2015 07:50 AM
Yes please open a SR on this. The behavior is extremely odd that USR_ACCESS is being affected. Updatemem should only be working on the BRAMs in the design
06-25-2015 09:56 AM
well, if ELF is attached to Microblaze in Vivado, then all is fine, if the same elf is merged into the same bit file by SDK then usr_access timestamp is erased.
03-08-2016 11:30 AM
I am having the same problem.
When I use updatemem, my timestamp info in USR_ACCESS is being set to 0. Is this bug not fixed ?
I am creating a new bistream from SDK>
07-12-2017 04:23 PM
I'm using Vivado 2015.3 and this problem still exists with updatemem. Data2mem seems to work: it does not set USR_ACCESS to 0. Can we get someone from Xilinx to: