LV FPGA - Calculate time since 1970 from current Time/Date information

[Aws_Khudhair]

Hi,

I have a small issue with LV FPGA, I am trying to calculate the time in ns since 12AM 1/1/1970 on FPGA. The GPS module I have gives me the time in a cluster as year-month-day-hour-min-sec-ms-nanosec. My issue is that I need to convert this time to the number of seconds since 1970, since I cannot use the LV time cluster in FPGA and do a simple subtraction between the two dates, I have to subtract the date manually.

Does anyone know of a simple way of doing this in FPGA, hopefully am missing something here.

Thank you

[mikeporter]

This is a very non-trivial problem, and I'm not clear that you could get it fit onto an FPGA even with a good algorithm. What is it that you are trying to do?

Mike...

[dan_u]

Maybe I'm missing something, but can't you just convert the date/time info into a U64 (or I64 for difference calculations since the difference can be negative) representing the time in ns since 1970? This just requires a few multiplications and additions. Once in the U64/I64 representation you can simply subtract the numbers.

[Aws_Khudhair]

That was my first approach, however, when calculating the number of ns for todays date you will get a number that is beyond the limits of I64. So you will not be able to calculate the number properly. My second approach to the problem is to simply do a date subtraction ie (2013-1970) and (Aug-Jan) etc...., however this approach does not account for leap seconds and you will always have an offset in your calculations.

My current approach to this is to calculate the number of ns since 1970 as of midnight in RT then load that number into the FPGA at startup and from that point on I just calculate the number of ns since midnight and add to the previous number. This approach works in my case since my system will never be operated around midnight. 

Any suggestions of a better way to go around doing this would be very much appriciated. 

[Aws_Khudhair]

To answre your question Mike, I am trying to implement the IEEE1588 time synchronization between the cRIO and a GigE camera, while using time information from GPS which is aquired on FPGA. The idea is to use the timestamp data on the cRIO and the camera to synchronize various information such as trigger time with the triggered frame and since the time informaiton on the camera is a nanosecond count since 1970 I need that same information on the FPGA timekeeper side.

[dan_u]

Since 1970 we have around 1.356E+18 ns, but the I64 range is approx. 1E+19, so there should not be a problem with that. It will work for another ~250 years. 

[Aws_Khudhair]

that is correct, however, you first need to calculate the total ns count for the year 2013 which already takes you out of the range, then calculate the total ns count for the year 1970 (which is already out of range) then subtract the two values (1 year = 3.156e+16ns). Hence my second attempt which was to basically calculate the number of days since 1970 and do my calculations with that.

[mikeporter]

I'm glad you brought up the topic of leap seconds. Everybody knows that we add an extra day every 4 years, but that doesn't completely correct for everything - it's still an approximation, though a somewhat closer one. The powers that be also insert an odd second or two at various times. The one time I heard an announcement on shortwave about it being done was on new years, but I don't know if that is always the plan or if there is a regular schedule like there is for leap years.

Can't you get a timestamp from the GPS at the start of the process and just go relative from there?

Mike...

[Aws_Khudhair]

The issue with that is since am dealing with a mobile application, losing GPS signal is something that will happen for sure, at that point the IEEE1588 sync will start to rely on the system time of the cRIO and when it uses that it will take the full date plus time and use that value, which will cause an issue for me if I was using a relative time at the start as my time stamps will have a sudden change in value which will break my data pipeline.

The idea here is to calculate the propper value and have the time on the FPGA synched to the time on the cRIO so that when GPS is lost i can switch between using both time for the sync without having a significant offset between the values before and after GPS signal loss.

In regards, to the leap second issue, I found a reference that provides multiplier values for calculating the date while taking the leap second into account to get the correct epoch time (http://www.epochconverter.com/ see the table under "What is epoch time?) however this does not solve the entire problem as the date calculated is still off by a couple of hours.

[AlejandroZepeda]

There is a GPS module for cRIO from NI, the NI 9467, that give you time in precisely the format you want: a u64 representing TAI time, ns since the TAI epoch of 1/Jan/1970.  Can you use that?

Alejandro