gps nmea design using verilog

Sure, its quite simple:
1. Learn Verilog
2. Learn NMEA protocol
3. Write a simulation model containing NMEA interface, UART, and 
protocol decoder
4. Make your model synthesizable and implement it for FPGA or ASIC, 
whatever you prefer.

Thanks for reply...

Hi,

I have implemented gps to parsing nmea data from gps receiver through 
uart Interface.
For this I have used zync ultra scale processor and uart rx interface.

But the problem is I am getting $gntxt  01,01,01 getting more than 100 
frame errors and uart rx was disabled.

and one more thing is is there any way to do without using zync ultra 
scale processor.

Damrr wrote:
> I have implemented gps to parsing nmea data from gps receiver through
> uart Interface.

Have you tested your design in the simulation?
Does it work as intended?

Damrr wrote:
> But the problem is I am getting $gntxt  01,01,01 getting more than 100
> frame errors and uart rx was disabled.

Sorry, without Code we cannot find errors. It looks like you output an 
incorrect UART signal with wrong timing.
That can be simulated and checked too.

Damrr wrote:
> and one more thing is is there any way to do without using zync ultra
> scale processor.

Maybe, maybe not. We do not know what you do in your project. Do you run 
code on the CPUs in the Zynq?

Damrr wrote:
> I have implemented gps to parsing nmea data from gps receiver through uart 
Interface.
> For this I have used zync ultra scale processor and uart rx interface.
>
> But the problem is I am getting $gntxt  01,01,01 getting more than 100
> frame errors and uart rx was disabled.

1.) Sounds you‘re using an u-Blox GPS/GNSS Receiver.
2.) ... and sending data TO the receiver
3.) ... with wrong UART settings (Baudrate/Start/Stopbits/Parity). The 
u-Blox Receivers are quite sensitive to this and will disable their RX 
port.

When you POLL the receiver for NMEA Data (even at high rates), then you 
should revisit your concept. The u-Blox Receivers offer a nice config 
setting (UBX-CFG-PRT) for automated transfer of ubx and nmea messages.

Homework_Service @ Nightshift wrote:
> Damrr wrote:
> I have implemented gps to parsing nmea data from gps receiver through
> uart Interface.
>
> Have you tested your design in the simulation?
> Does it work as intended?
>
> Damrr wrote:
> But the problem is I am getting $gntxt  01,01,01 getting more than 100
> frame errors and uart rx was disabled.
>
> Sorry, without Code we cannot find errors. It looks like you output an
> incorrect UART signal with wrong timing.
> That can be simulated and checked too.
>
> Damrr wrote:
> and one more thing is is there any way to do without using zync ultra
> scale processor.
>
> Maybe, maybe not. We do not know what you do in your project. Do you run
> code on the CPUs in the Zynq?

Yes, I have run the code with zynq ulta Scale processor.

For my project they asked design without using zync processor.

I have used uart rx at receiver side and there is signal 'urx" which is 
not connected to any other devices and only clk and reset connected.
I am not sure about vivado block design that I have attached above. 
Please check

After getting nmea results ($GNGGA) I need to convert to epoch Time.

Please find gps design link I have used .

http://www.labbookpages.co.uk/electronics/gumstix/gps.html

Yes I am using ublox receiver.
I have used 9600, parity 0 , data bit 8 and stop bit 1.

I getting full nmea format with no errors.

Can u please check vivado block design where at receiver I have used 
uart rx (check ports).

Damrr wrote:
> Yes, I have run the code with zynq ulta Scale processor.

But WHY? It is not connected to your UART module.

Damrr wrote:
> For my project they asked design without using zync processor.

Then leave it out.

Damrr wrote:
> I am not sure about vivado block design that I have attached above.
> Please check

Then why do you use block design at all?

Damrr wrote:
> I have used 9600, parity 0 , data bit 8 and stop bit 1.

Did you write your UART verilog component on your own?

Damrr wrote:
> Can u please check vivado block design where at receiver I have used
> uart rx (check ports).

The block design is not of much use to find bugs. Code would be much 
better.

Damrr wrote:
> Yes I am using ublox receiver.
> I have used 9600, parity 0 , data bit 8 and stop bit 1.

The default setting of uBlox modules is:
9600,n,8,1

> I getting full nmea format with no errors.
The ReceiverProtocolDescription (M8 in this case) says:

"As of Protocol version 18+, the UART RX interface will be disabled when 
more than 100 frame errors are detected during a one-second period. This 
can happen if the wrong baud rate is used or the UART RX pin is 
grounded. The error message appears when the UART RX interface is 
re-enabled at the end of the one-second period."

So:
You are SENDING data to the receiver using WRONG UART settings or the RX 
Pin is grounded. From our experiences with ublox receivers the UART is 
VERY stable - if used correctely ;)

Best, Stephan

No,  I have used  uart receiver part acts like slave .

Homework_Service @ Nightshift wrote:
> Damrr wrote:
> Yes, I have run the code with zynq ulta Scale processor.
>
> But WHY? It is not connected to your UART module.
>
> Damrr wrote:
> For my project they asked design without using zync processor.
>
> Then leave it out.
>
> Damrr wrote:
> I am not sure about vivado block design that I have attached above.
> Please check
>
> Then why do you use block design at all?
>
> Damrr wrote:
> I have used 9600, parity 0 , data bit 8 and stop bit 1.
>
> Did you write your UART verilog component on your own?
>
> Damrr wrote:
> Can u please check vivado block design where at receiver I have used
> uart rx (check ports).
>
> The block design is not of much use to find bugs. Code would be much
> better.

Actually I need to use tod master clock .
Net timer logic 's time of day master clock is a full hardware only 
implementation of a synchronisation core able to synchronise a time of 
day sink via nmea over uart.
The whole message creation, algorithms and calculations are implemented 
in the core , no cpu is required.
This allows running tod synchronisation completely independent and 
standalone from user application