Topic: Clock tree reset bit in CPLD Register MAP  (Read 8771 times)

vicmarher October 23, 2013, 12:03 PM

  • Member
  • *
  • Posts: 43
Hi again!
We've updated the FMC116 Reference Software to run in a rtems embedded application in our Virtex ML605 board. When we run the application, everything seems correct till function FMC116_cpld_resetSPIclocktree is called.


When writing the reset bit on the cpld register, we can see in a post check read that no value can be written to this register. Whatever we try to write to it, we always read the same value it had before trying to write the reset bit. Most of the times in fact, the constant value is 0x20, meaning the reset bit is always set. After a hardware reset, now we always get 0x0...




So the question is, is it a read-only register? is the write access to the register different than the read access, as we can see for example with CLPD_REG2? does it take a lot to reset bit and that's why a later read is not still updated (we've tried with 1second Sleep with same results)?


Thanks a lot!!


Víctor Martín, IEEC

Kyu October 24, 2013, 03:50 PM (#1)

  • Member
  • *
  • Posts: 154

Hello Victor,


It's a write/read register. You should see 0 before clock reset is written because registers are inialized to 0. What do you mean by hardware reset? Do you see 0x20 after power cycle the board?


Thank you,
Kyu

vicmarher October 25, 2013, 04:29 AM (#2)

  • Member
  • *
  • Posts: 43
Hellow Kyu,
thanks for your fast response.
What I mean by hardware reset is switch off/on the whole fpga board where the fmc116 is plugged. Once I did it, I could read 0x0, but still couldn't write. But next day in the morning, I was able to read and write in the expected way without having changed a line of code. Do you have any explanation?


When I asked about read/write capabilities, I meant that register CPLD_REG02 has different acces for reading and for writing as can be read in documentation, and I suspected that this could be the case of the first register.


So now it seems that it's working, but I'm not very sure that everything is ok, and what to do if it happens again.


Thanks a lot!


Víctor, IEEC

Kyu October 25, 2013, 11:43 AM (#3)

  • Member
  • *
  • Posts: 154

Victor,


I'm not sure why it happened. Maybe the MS Visual C++ issue? Did the software run successfully when you had the issue? Honestly, I never had or heard this issue. Please let me know if it happens again. I will investigate this issue.


CPLD_REG2 is a read/write register as well. As you see in the user manual, this has the status information. If you write the register, you can visually check the one status signal with a LED on the FMC116. If you read the register, you can have a software debug for 5 status signals.


Thanks,
Kyu

vicmarher November 19, 2013, 10:30 AM (#4)

  • Member
  • *
  • Posts: 43
Hi again Kyu,
unfortunately, we are having the same problem with the reset bit in CPLD register.
First I could write the reset bit (0x20), but then, after trying to write 0x0 again to clean the reset, a later read tells that the value is still 0x20.
After that, i turned off the whole fpga where fmc116 is plugged on, and after restarting the application, I'm not even able to write the 0x20 value, and the value that i read in the register after my try to write 0x20 is always 0x00.


Like in previous times, this happens after having changed NO LINE of code, and using the Reference Software application, adapted to our rtems/leon architecture.


Please, if you have any idea, just let me know.


THANKS IN ADVANCE!!


Víctor Martín, IEEC

vicmarher November 19, 2013, 01:44 PM (#5)

  • Member
  • *
  • Posts: 43
Hi again.
I've discovered more interesting things.
Trying to debug what happened, I've written several printf's, between the register writing and the later read to check, and suddenly it started to work correctly again... so i changed the printf for sleeps, having the same results.


So I suppose that depending on the register that I write, it takes more or less time to be written. What I don't know is what conditions can affect it to be different in different days.


I don't know if a write access can affect a pending previous write access, but I think that my solution of read after write to check if what I wrote is there, is not a bad thing, and this way I assure that no more than I writing action is performed at a time.


So, regarding the original issue, do you think is just a matter of time? is there a known maximum time to be considered for my Sleep call? In your reference software it's plenty of sleep calls that I suppose that had same intention.


Thanks!


Víctor Martín, IEEC

Kyu November 19, 2013, 02:30 PM (#6)

  • Member
  • *
  • Posts: 154

Victor,


We do not have the ready signal implementation so we use a sleep function to wait the operations. Thus, it can be matter of time.


What operating system do you use? Could you post the where you added a printf or sleep?


Thanks,
Kyu

vicmarher November 19, 2013, 02:53 PM (#7)

  • Member
  • *
  • Posts: 43
Hi Kyu,
well, first let me explain you a little what we have done.
We have implemented a LEON3 CPU 120 Mhz in our Xilinx Virtex ML605 board, put an RTEMS application, and created a task that executes your reference software. So your reference software is running under RTEMS. We've made small changes to adapt it (compilation issues), but the most important change is that we run this application in the same board that FMC116 is plugged, we don't need another PC connected to it.


So the access to the registers is not via ethernet and your libs. We have implemented an AMBA peripheric for the LEON architecture as a wrapper, and we use APB access to this peripheric, translating it to commands that Stellar IP understands. In fact, we have changed your SIP_MAC_ENGINE for our peripheric.


I hope you understand what I've tried to explain you. I think is important because of course now the times to access to parameters are completely different. In your reference software, each access had to go via ethernet if I'm not wrong, but now, it's just access to the bus in the same board, so I suppose that is quite faster.




In my implementation of sipif_writesipreg, what I do is generate the SIP write command, execute it, and then, in case a postcheck must be done, I make a while with 4 tries reading again the value to check if writing has been done. After each try, if I don't read what I expect, is where I do the sleep. First version had 10ms for each sleep. If I use 1000ms sleep, it seems to work properly in 99% of cases.


Also in read functions, what I do is access to my peripheral with the read command, and then wait in a loop with 4 tries for the ACK command to be read. On each of the tries, I have also an sleep of 10 ms.


The sleeps of your reference software haven't been changed.


It must also be taken into account that there are several printf's that has the same effect than sleep calls in the sense of write timings.


I hope you understand it all. Let me know if it's not the case.


THANKS A LOT!!


Víctor Martín, IEEC

Kyu November 19, 2013, 05:52 PM (#8)

  • Member
  • *
  • Posts: 154

Victor,


Our reference design is based on Windows. If you use a LEON3 CPU, it may require a longer delay.


Thank you for your feedback,
Kyu

vicmarher November 20, 2013, 03:50 AM (#9)

  • Member
  • *
  • Posts: 43
OK, thanks!!


Víctor Martín, IEEC