Added the docs: Workpackages WR Test System, and Drawings:Proposal of Architecture and Test System

bf591d54 · Cesar Prados · 14ae2290 · bf591d54 · bf591d54 · bf591d54
Commit bf591d54 authored Jan 31, 2012 by Cesar Prados
8 changed files
--- a/doc/spec/WR_Testbencher_Func_Spec_v1.pdf
+++ b/doc/spec/WR_Testbencher_Func_Spec_v1.pdf
--- a/doc/spec/WR_Testbencher_Func_Spec_v1.txt
+++ b/doc/spec/WR_Testbencher_Func_Spec_v1.txt
+WR Testbencher
+
+
+Description of the WR Testnecher’s components, please read with the drawing of the WR Testbencher, at the end of the document, by hand:
+
+
+Testbencher GUI and User App.
+
+
+1. The interface presents configuration of the system, tests and results. 
+2. The user can load template of the tests based on the RFC 2544/2889 and WR test, stored in a data base.
+3. The user can modify and save new tests in the data base.
+4. Before be able to run a test, the App must check that the system configuration and the DUT fulfils the requirements of the test.
+5. Transmission of the test to the WR Testbencher.
+
+
+Implementation
+
+
+C/C++ and Qt
+
+
+Test and Result Data Base
+
+
+1. Contains the tests template (RFC 2544/2889 and WR test) and stores the new test save by the user.
+2. Stores the results of the Tests.
+
+
+Implementation
+
+
+MySQL or other open data base.
+
+
+Collector
+1. Receives the test configuration from the GUI&App 
+2. Processes and shapes the test information 
+
+
+Length Frame
+	Payload
+	Frame Rate
+	N° Trials
+	Burst Size
+	Destination Address
+	Traffic Direction
+	Load per Port
+	Interframe gap
+	VLAN flags
+	
+
+1. Transmits the processed test information to the Engine
+2. Gathers the results of a test and sends them to the data base
+3. Creation of pseudo-random/specific destination MAC address 
+4. Creation of pseudo-random/specific payload
+5. Creates a destination port table for a test that send different traffic, rate etc...  in every  port.
+
+
+Testbencher Engine
+
+
+1. Stores the result of a test in memory and sens to the Collector , once is finished the test.
+2. Organizes the parameters of the test (length frame, payload etc..) and uses them to load, trigger and stop the Frame Generator
+3. Receives from the Frame Detector information of the test or DUT and stores the relevant information in memory.
+4. Modifies on-the-fly parameters of the running test, if the information received from DUT fulfils pre-defined conditions. 
+
+
+Frame Generator
+
+
+1. Generates frames with parameters: legnth, rate etc.. received from the Engine
+2. Indicates to the Frame2Port Allocator the destination port of the frames
+
+
+Implementation
+
+
+Maciej has developed a frame generator for testing the FEC, we could reuse it. 
+
+
+Frame Detector
+
+
+1. Detects pre-defined frames sensible for the test, either from the DUT or from the traffic’s test 
+2. Propagate the detected frames to the Engine, or to the WRPTP/RSTP dameon.
+
+
+Frame2Port Allocator
+
+
+1. Allocates a frame in the queue of a destination port in the corresponding level of priority  according to the information provided from the Frame Generator.
+
+
+ Implementation
+
+
+It is quite similar to the part of the swcore_spec, from (what is so call in the swcore_spec) Input block to the Output block. 
+
+
+
+
+CoS Queues and Queue Manager
+
+
+1. Hosts accordingly the frames in seven (or less) queues coming from Frame2Port Allocator
+2. The Queue Manager transmits to its port the frames from the queues accordingly an algorithm defined to respect a different levels of priority.
+
+
+ Implementation
+
+
+The Queue Manager algorithm is being researched in GSI in the frame of a Master Thesis. 
+The CoS Queues is a similar to the Output Block in the swcore
+
--- a/doc/spec/WR_Testbencher_Workpackages_v1.pdf
+++ b/doc/spec/WR_Testbencher_Workpackages_v1.pdf
--- a/doc/spec/WR_Testbencher_Workpackages_v1.txt
+++ b/doc/spec/WR_Testbencher_Workpackages_v1.txt
+WR Testbencher Work Packages
+
+
+Description of the WR Testbencher’s workpackages, please read with the drawing of the WR Testbencher by hand:
+
+
+WorkPackage
+	Responsable
+	Duration
+	Priority
+	A Test Definition
+	
+
+	
+
+	
+
+	A.1 Test Methodology 
+	Cesar
+	2 days
+	High
+	A.2 PTP Tests 
+	Maciej
+	
+
+	High
+	A.3 RSTP/SNMP Test 
+	Integrasys
+	
+
+	Low
+	B Software
+	
+
+	
+
+	
+
+	B.1 GUI and User App.
+	Marcus Zweig 
+	
+
+	Medium
+	B.2 Data Base
+	Marcus Zweig
+	
+
+	Medium
+	B.3 CPU-FPGA communication
+	Rubini?
+	
+
+	High
+	B.3 Collector
+	
+
+	
+
+	High
+	B.4 Collector Driver
+	Cesar 
+	2 weeks
+	High
+	B.5 WR/PTP porting/integration
+	Rubini?
+	
+
+	High
+	B.6 RSTP porting/integration
+	Seven Solutions
+	
+
+	Low
+	C Gateware
+	
+
+	
+
+	
+
+	C.1 Frame Generator
+	Maciej? 
+	
+
+	High
+	C.2 Frame Detector
+	
+
+	
+
+	High
+	C.3 Engine
+	
+
+	
+
+	High
+	C.4 QDRII Controller   
+	Seven Solutions 
+	done?
+	High
+	C.5 Queue Management 
+	GSI
+	
+
+	High
+	D Integration
+	
+
+	
+
+	
+
+	D.1 Integration Soft
+	
+
+	
+
+	Long Term
+	D.2 Integration Gateware
+	
+
+	
+
+	Long Term
\ No newline at end of file
--- a/doc/spec/wr_testbencher.svg
+++ b/doc/spec/wr_testbencher.svg
--- a/doc/spec/wr_testbencher_mod_v1.pdf
+++ b/doc/spec/wr_testbencher_mod_v1.pdf
--- a/doc/spec/wr_testbencher_mod_v1.svg
+++ b/doc/spec/wr_testbencher_mod_v1.svg
--- a/doc/spec/wr_testbencher_mod_v2.svg
+++ b/doc/spec/wr_testbencher_mod_v2.svg