Projects/PTP

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
{{privateptp}}
+
{{privatePTP}}
 
{{TOC right}}
 
{{TOC right}}
  

Revision as of 08:41, 28 February 2014

Template:PrivatePTP

Contents

PTP was an internal research project on the IEEE Std 1588 - Precision Time Protocol. A diploma work with the same topic has been executed by Johan Droz in 2012. While Droz concentrated on the two-step sync_msg mechanism, the project PTP focused on the one-step sync mechanism. In this case the timestamping is carried out by the NS DP83640 Precision PHYTER.

An FPGA is used to control the phyter. The HES-SO FPGA Rack Board holds a DP83640 connected to a Spartan-6 LX FPGA. During this project we used the XC6SLX100 variant. Furthermore the USB port on these boards is used in RS232 mode to send the collected timestamps to a computer and to access the phyter's registers. A dedicated RS232 terminal has been developed to capture the timestamps on the computer and store them in a CSV file. This tool is written with C++/Qt.

A PTP node can be assigned to be master or slave. As master it sends a Sync message on the Ethernet interface every second. Upon reception of a Delay_Request a Delay_Response is returned. A slave sends a Delay_Request every time a Sync message is received. When the Delay_Response arrives, all collected timestamps are sent out via RS232.

All project data are accessible on the PTP svn repository. All path descriptions below refer to this database.

This project is been executed by guo and supervised by cof.

VHDL development

VHDL development has been done with HDL-Designer 2011.1. Make a copy of .\PTP\devel\vhdl\hdlDesigner.bat and modify the paths inside to match your system and execute it to launch the design in HDL-Designer with all the correct paths set.

toplevel

The toplevel of the design in the library PTP contains four major blocks.

control

The controlling block contains a state-machine for master mode and one for slave mode. Their tasks are to control this mode and also to command the other blocks. In master mode the node sends a Sync message each second or upon release of button1. A slave simply reacts on incoming messages according to the PTP protocol.

Interfaces

  • cmd out, evt in

Commands

The following commands are always set and hold until the reception of the corresponding event.

phy_init
This command is issued each time the mode changes between master and slave and starts the initialization process of the phyter.
phy_mstslv
This status field indicates the current mode.
tx_msg_typeec
Initiates the sending of message of the given type (sync, delayResp, delayReq) on the Ethernet port.
tx_encap_type
Chooses between UDP/IP4 or L2 mode for the message to send.

Events

To know what's going on in the rest of the design, the control block receives events.

phy_init_done
Issued after the execution of the phyter initialization process.
tx_send_done
Indicates that a message has been sent on the Ethernet port.
rx_irq
Informs the controlling block about the reception of a message on the Ethernet port.

rs232

The RS232 interface is not really needed for the PTP functionality, but serves as controlling and observation interface. There is a single internal register which defines the mst/slv mode of a device. Furthermore the phyters registers can directly be accessed. Finally all collected timestamps on the a slave are sent out over this interface.

Interfaces

  • rs232
  • fifo (rx/tx)

phyter

This block controlls the MIIM register access of the phyter as well as it's initialization. Inside it there are three main blocks, a control block, a init action and the MIIM fifo. The control block receives the init command, controlls the reset phase of the phyter, initializes its registers and then allows the direct access to the phyter by the fifo interface. The init action block simply writes the correct values to the corresponding registers during the initialization phase. Finally the MIIM fifo sends all data presented on its input interface to the given address on the MIIM interface. All data received on the MIIM side is made available on the fifo side.

Interfaces

  • miim
  • fifo (rx/tx)
  • cmd in, evt out

ethernet

This blocks sends the commanded messages on the Ethernet interface and returns the collected timestamps. Each sending of an Ethernet message is confirmed with an event. Also each reception of an Ethernet message is signaled with an event. After the reception of a delayResp message, the collected timestamps are delivered on the fifo interface. These timestamps are then, with the help of the rs232 block to a computer where they can be analyzed with the program written by Droz.

Interfaces

  • mii
  • cmd in, evt out
  • fifo (tx)

VHDL testbench

There exists a VHDL testbench where two PTP toplevels are connected by their Ethernet interfaces. Once the toplevel_tb is loaded into ModelSim, the simulation can be executed with the command: do ../../Simulation/runsim.do. This will open a wave window with some important signals and also run the simulation for 16 ms.

In a first step we test the initialization and the mode change feature. For the simulation, the reset time of the phyter has been reduced to 1 ms. After that time you should see 12 write access on the MDIO interfaces which configure the phyter. Both PTP toplevels are now configured in slave mode. At 1.5 ms one of the PTP toplevels is configured to be a master. You should see the write accesses on one RS232 interface. After that the reset output to the phyter of the master is again activated and at about 3.5 ms the phyter is configured in master mode again with 12 write accesses on the MDIO interface.

The next step is to verify the basic PTP behavioral. At 5 ms button1 is released an this triggers a synchronization sequence. On the Ethernet interface you should see the exchange of the corresponding messages. The sync message from master to slave. Then the delayReq message from slave to master, which returns the delayResp message. This should not take more than 0.3 ms. After that the slave should send the collected timestamps on the rs232 interface.

Finally two tests, a read and a write, of the rs232 access to the phyter registers are executed. At about 12.4 ms the write access is started on the master's rs232 interface. At around 13.5 this access should be sent out over the MDIO interface. The read access is started shortly after at about 14 ms and passed on the MDIO interface at about 14.7 ms.

These three tests verify the basic behavior of the design. The testbench can easily be modified or extended for further specific tests.

Synthesis and PAR

The toplevel for the FPGA Rack board can be found in the Library Board and is called fpga_rack. Of this design a concatenated file has to be generated at .\devel\vhdl\mine\Board\concat\concatenated.vhd. Then the prepareSynth.bat file in the same folder has to be executed. After that the Synplify Pro 2012.03 project at .\devel\vhdl\mine\Board\synplify\fpgaRack\TBD can be launched and synthesized. The current resource utilization is around some percents and can be seen in .\doc\hes\guo\synthesis results.xlsx. Place and route is done with Xilinx ISE 14.1. The project at .\devel\vhdl\Board\ise\PTP_fpgaRack\PTP_fpgaRack.xise contains a reference to the netlist generated with Synplify and the constraints file and therefore the Generate programming file task can simply be run.

Breadboard testing

The design has been tested by loading it onto two FPGA Rack boards. Then the two Ethernet ports driven by the DP83640 phyter are connected together. On the computer the rs232 terminal tool .\PTP\devel\tools\customSerialProgram\bin\csp.exe has to be be launched. As next the QtCreator project at .\devel\tools\Qt_UART\uartassistant.pro has to be launched and compiled for release. Then both tools have to be configured to connect to one of the boards. The correct COM port has to be chosen and the baudrate to be set to 9600 baud. In the commands list on the right of the CSP tool double-click on the line below the line = Set as master. With the commands reg y\nwr 0001 FFFF\nreg n this node will be configured as master. Once you see light up LED1 on the FPGA Rack boards the reinitialization of the phyter is finished. If not yet done, the connection in the UARTassistant can be enabled. Now you should see there a long line of numbers appear each second. These are the collected timestamps from the slave. Once you feel that you have accumulated enough timestamps, close the connection on the UARTassistant and open the .csv file that has been generated at the same location where you compiled the UARTassistant executable. If you open it with a spreadsheet office tool, you should see the different timestamps in separated columns as well as a column with the calculated delay.

Like in the simulation, all basic functions of the design are verified. More detailed tested or debugging however is not so easy to achieve.

Limitations, Bugs, Recommendations

There are some features that are already implemented but not activated or verified.

  • On incoming messages only the messageType field is used to detect the messsage type. A mechanism to verify the other fields has been implemented but never been tested.
  • There seems to be a problem with the DR_INSERT bit in the PTP_TXCFG0 register of the phyter. As soon as it is set, the received timestamp t1 in sync messages is a constant value. This means we always receive the same value. When DR_INSERT is disabled, t1 is received correctly. But then t3 is not included in the delay_resp message and should be fetched from the phyter's registers. This has not been tried yet.
  • We had quite some problems with the communication between the FPGA and the phyter. That's one reason why we moved from the old phyter board to the FPGArack. As we never verified on the FPGArack if the communication between FPGA and phyter also works at other speeds, we recommend to leave it's frequency as is.
Personal tools
Namespaces
Variants
Actions
Navigation
Browse
Toolbox