HCAL BCP Integration Test at B512

Table of Materials at B512

Part Quantity Origin Notes Picture
HB RM 1 904    
HB Backplane 1 904    
HB Power Card 1 904    
HB Power Jumper 1 904 Unused  
HE Backplane 1 904 Unused  
HE Power Card 1 904 Unused  
ngCCM Emulator Control Card #1 1 Baylor    
ngCCM Emulator Clock Card #1 1 Baylor    
ngCCM Emulator Control Card #2 1 904 Unused, CPLD broken?  
Raspberry Pi 1 904    
Breadboard 1 904    
MTP, 24 -> 12 x 2 1 904    
MTP -> LC breakout (12 fiber) 2 904    
LC splitters 4 904    
LC couplers 10 904    
TSX1820P LV supply 1 CERN EPool    
NI GPIB/USB adapter 1 CERN EPool    
ATCA crate 1 512    
BCPv1 1 512    
DTH 1 512    
PidgeonPoint Shelf Manager 1 512    

Test Stand Description and Fibering

Test Stand Diagram

HcalBcp512_teststand.svg

BCP Diagram

BCP_Scaled_Block_Diagram_6.png

(from Stephen's twiki at https://twiki.cern.ch/twiki/bin/viewauth/CMS/BcpDemo)

Fibering Diagram

** needs to be updated. See below for current mapping*

HcalBcp512_fibering.svg

Network Diagram

HcalBcp512_network.svg

HB Front-End

The HB front-end (FE) consists of a bare HB RM3/4 backplane with associated power card which is powered by a TSX1820P LV supply. The LV supply is connected to ndpc2 via a GPIB interface for remote control and monitoring.

There is a single HB RM3 inserted into the backplane and in place of the ngCCM is an ngCCM emulator (both control and clock cards). Interface with the ngCCM emulator and thereby with the RM is accomplished via a RaspberryPi. The raspberry pi is connected via ethernet to ndpc2 at static IP 192.168.16.11. The RaspberryPi is connected to the ngCCM emulator by means of an I2C bus.

ATCA Back-End

The back-end (BE) consists of an ATCA crate in which is a BCPv1, a DTH, and a PidegeonPoint Shelf Manager.

At this point the DTH is unused and the BCPv1 is used only to read out the Data Link from the FE. All control of the FE is currently through the ngCCM emulator + RaspberryPi.

Fibering

***needs to be updated! see the detailed mapping section instead

The BCP has 4 12-channel RX fireflies. These are combined into 2 groups of 24 channels each of which go to 2 24-channel RX MTP connectors on the front panel.The 24 fibers of the RX1 MTP are separated out into 2 12-channel MTP fibers. The 12-channel MTP with channels 12-23 (0 indexed) is plugged into the MTP connector on HB RM3. On the RM, the middle 8 channels (thus channels 14-21) are active.

Each Firefly serves 3 4-channel GTH banks. The current test stand uses the 4 channels of bank 232. These four channels correspond to the middle four channels of Firefly_231_232_233, thus channels 16-19 on the RX1 MTP, which in turn are connected to the outputs of the middle two QIE cards of HB RM3.

Detailed Mapping

FE Mapping

Fixed mapping from FE coordinates to output fiber:

RM QIE slot GEO addr I2C addr igloo2 Fiber# color
3 6 4 0x1C top 5 white
3 6 4 0x1C bot 6 red
3 7 3 0x1B top 7 black
3 7 3 0x1B bot 8 yellow
3 8 2 0x1A top 9 violet
3 8 2 0x1A bot 2 green
3 9 1 0x19 top 3 brown
3 9 1 0x19 bot 4 slate

BE Mapping

Fixed mapping from front-panel optics to transceivers:

MTP port Fiber # Fiber # on 12x MTP (12-23) color Firefly channel GTH bank GTH channel
RX1 16 4 slate 4 232 1
RX1 17 5 white 5 232 0
RX1 18 6 red 6 232 3
RX1 19 7 black 7 232 2

FE <-> BE coupling

Variable mapping corresponding to the LC-LC coupler:

FE Fiber # FE color BE Fiber # BE Fiber # on 12x MTP (12-23) BE color
7 black 16 4 slate
5 white 17 5 white
3 brown 18 6 red
9 violet 19 7 black

FE <-> BE quick reference

Variable mapping of FE coordinates to BCP transceiver.

Note: You can always figure this out from the previous three tables but I put it here for quick reference. If you update the FE <-> BE coupling try to update this as well (or at least indicate that it is not up to date)

RM QIE slot igloo2 MTP port GTH bank GTH channel
3 6 top RX1 232 0
3 7 top RX1 232 1
3 8 top RX1 232 2
3 9 top RX1 232 3

Front-End Control and Monitoring

ngCCM emulator control with RaspberryPI

Connect to the RaspberryPi

The RaspberryPi is connected to ndpc2 with static IP 192.168.16.11. Thus to connect, first ssh to ndpc2 from within the CERN network

ssh <user>@ndpc2

then from ndpc2 ssh into the pi, with username "pi".

ssh pi@192NOSPAMPLEASE.168.16.11

You will be prompted for a password. If you do not know the password contact the admin.

Note: For some reason there is a long delay (~30 seconds) to be prompted for the password. This isn't a big problem, as once you are logged in to the pi the connection is fine.

Once on the pi, various control scripts can be found in ~/bc/control_scripts.

Check the temperatures:

On the pi:

~/bc/control_scripts/get_temps.py

Example output:

~/bc/control_scripts/get_temps.py
RM3 Slot 9 temp: 41.79 C
RM3 Slot 8 temp: 41.36 C
RM3 Slot 7 temp: 40.25 C
RM3 Slot 6 temp: 36.16 C

Note that sometimes there is an error where one or more of the temperatures may show an unreasonable value. If this occurs, just run the command again.

Control Igloo2 power

To power up the igloos run (on the pi):

~/bc/control_scripts/igloos_up.py

And to power down:

~/bc/control_scripts/igloos_down.py

You can check the igloo power status by reading out the 'ones register':

~/bc/control_scripts/get_igloos_ones.py

Powered up igloos should return:

RM3 slot 9 igloo top: ['0 255 255 255 255']
RM3 slot 9 igloo bot: ['0 255 255 255 255']
RM3 slot 8 igloo top: ['0 255 255 255 255']
RM3 slot 8 igloo bot: ['0 255 255 255 255']
RM3 slot 7 igloo top: ['0 255 255 255 255']
RM3 slot 7 igloo bot: ['0 255 255 255 255']
RM3 slot 6 igloo top: ['0 255 255 255 255']
RM3 slot 6 igloo bot: ['0 255 255 255 255']

while powered down igloos will return insttead:

RM3 slot 9 igloo top: ['1 0 0 0 0']
RM3 slot 9 igloo bot: ['1 0 0 0 0']
RM3 slot 8 igloo top: ['1 0 0 0 0']
RM3 slot 8 igloo bot: ['1 0 0 0 0']
RM3 slot 7 igloo top: ['1 0 0 0 0']
RM3 slot 7 igloo bot: ['1 0 0 0 0']
RM3 slot 6 igloo top: ['1 0 0 0 0']
RM3 slot 6 igloo bot: ['1 0 0 0 0']

Get igloo status registers

On the pi, run:

~/bc/control_scripts/get_igloos_status.py

Example:

~/bc/control_scripts/get_igloos_status.py
RM3 slot 9 igloo top status: ['0 3 0 32 0']
RM3 slot 9 igloo top status: ['0 3 0 32 0']
RM3 slot 8 igloo top status: ['0 3 0 32 0']
RM3 slot 8 igloo top status: ['0 3 0 32 0']
RM3 slot 7 igloo top status: ['0 3 0 32 0']
RM3 slot 7 igloo top status: ['0 3 0 32 0']
RM3 slot 6 igloo top status: ['0 3 0 32 0']
RM3 slot 6 igloo top status: ['0 3 0 32 0']

The first byte is an I2C exit code (0=no errors). The remainder of the bytes are the contents of the igloo status registers:

StatusReg               [31:0]      8'h10   RO    10-bit InputSpyWordNum, InputSpyFifoEmpty, InputSpyFifoFull, Qie_DLLNoLock[12:1], BRIDGE_SPARE[5:0], bc0_gen_locked, PLL 320MHz Lock
* PLL 320MHz Lock = Lock flag of the PLL inside the igloo2 which generates a 
* ~320 MHz clock (precisely is 8x the LHC freq). It is good when it is "1".
* BRIDGE_SPARE[0] = 1 indicates that the igloo2 detects that it is plugged on slot 1, need Bridge fw v 0x1020c13 or higher.
* Qie_DLL_NoLock =  each QIE10 ASIC has an internal DLL, with an output called NoLock; this output is sent 
* to the igloo2 which puts it on its StatusReg (but really is about the status of the QIE10). Good = "0".
* InputSpyWordNum indicates the number of words contained in the InputSpyFifo (Fifo depth = 512).

(from https://gitlab.cern.ch/cms-hcal-fpga/hf_rm_igloo2/blob/master/docs/Register_List_IGLOO2.txt )

LV supply control with GPIB

not yet implemented

Note: until remote control of the LV supply is possible, the default state of the HB FE should be with the igloo2s powered down. In this state the temperatures should all remain below 40C.

Monitoring script

not yet implemented

Take a screenshot on ndpc3

gnome-screenshot -a -f <path/to/image>

Then select and area to capture, or

gnome-screenshot -d <delay_seconds> -f <path/to/image>

to capture the whole screen after a delay of <delay_seconds> seconds.

Back-End Control and Configuration

Note: Most of the following commands are specific to the HCAL test stand. More details on these commands can be found on the Ndpc3Remote page.

Crate Management

BCP Power

To power cycle the BCP, from ndpc3 telnet to the IPMC

telnet ipmc10011

(contact admins for the password).

On the impc, run

payload.power_level 0 force

payload.power_level 1 force

If the BCP is powered and in a good state, the ELM should be pingable:

ping -c 3 elm10011
PING elm10011 (192.168.40.205) 56(84) bytes of data.
64 bytes from elm10011 (192.168.40.205): icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from elm10011 (192.168.40.205): icmp_seq=2 ttl=64 time=0.126 ms
64 bytes from elm10011 (192.168.40.205): icmp_seq=3 ttl=64 time=0.136 ms

--- elm10011 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.103/0.121/0.136/0.018 ms

FPGA Interface

XVC

First (from ndpc3) ssh to the ELM:

ssh root@elm10011

(contact admins for the password)

To check if XVC is running:

ps a | grep xvc

If XVC is running you will see a process like

1398 root 198:19 xvc 192.168.40.254

If XVC is not running then start it with

xvc 192.168.40.254 &

Vivado

Launch Vivado in ndpc3 (see Ndpc3Remote for instructions).

Once Vivado has opened, under 'Tasks' go to 'Hardware Manager'.

vivado_start.png

In the Hardware Manager's 'Hardware' pane, click 'Autoconnect'

vivado_autoconnect.png

If you see something like the following, you are good to go:

vivado_xcku115.png

If not, you may have to add the XVC. RIght click on localhost and select 'Add Xilinx Virual Cable'

vivado_xvc.png

Then enter the following and hit ok:

vivado_xvc2.png

Now you should see an xcku115 FPGA at IP 192.168.40.205.

To program the FPGA, right click the xcku115 at IP 192.168.40.205. Select 'Program Device'

vivado_program.png

The select the programming file and hit 'ok'.

Clock Configuration

From ndpc3 ssh to the ELM

ssh root@elm10011

(contact admins for the password)

/mnt/persistent/bcp_user/HCAL_clock_cfg.sh

Firefly Optical Power

From ndpc3 ssh to the ELM

ssh root@elm10011

(contact admins for the password)

bcp-firefly -o 7

Example output:

Chan RX LOS RX Power
==== == ========
00: LOS Low
01: LOS Low
02: ok ok
03: ok ok
04: ok ok
05: ok ok
06: ok ok
07: ok ok
08: ok ok
09: ok ok
10: LOS Low
11: LOS Low

Channels 04-07 correspond to bank 232. 'ok' in both columns means that the Firefly detects optical power on the RX.

Data Analysis

1: Export ILA data

Note: The following assumes that you have programmed an xcku115 FW which supports ILA.

1.0: Connect to the FPGA in Vivado

Follow the instructions in the section FPGA Interface / Vivado above. If you have correctly loaded a FW version with ILA support, you should now see some ILAs under the xcku115 device in the HardwareManager 's 'Hardware' pane:

ilas.png

1.1: Trigger the ILA

In the 'Hardware' pane, double-click an ILA to open it. Then in the ILA control bar, click 'Trigger':

trigger.png

If the Trigger is successful, the ILA should be populated by signals:

signals.png

1.2: Export the data

In the ILA control bar, click 'Export ILA Data'

export.png

Name the data something sensible and save in format CSV (not LegacyCSV):

export2.png

2: Analysis

2.0: Get the analysis scripts

Clone the scripts from github:

git clone https://github.com/jmariano-cern/HcalBcpIlaAnalyzer.git

2.1: Edit the main analysis loop

The analyzer consists of two python files.

IlaData.py just defines an object which unpacks and stores ILA data and contains a built in analyzer. The user should not have to edit this file.

analyze_rxdata.py is the userfile. A basic template looks like this:

#!/usr/bin/python

# import the IlaData object
from IlaData import IlaData
# import python os interface to list directories
from os import listdir

# analyze each file in this directory
data_dir = "/home/jomarian/ila_data"
# save analysis results here
analysis_dir = "/home/jomarian/analysis"
# check for these signals in each file
# it is fine if not all signals are present in a given file
rxdata_signals = [
"hb0_gtwiz_userdata_rx_int_1[15:0]" ,
"hb1_gtwiz_userdata_rx_int_1[15:0]" ,
"hb2_gtwiz_userdata_rx_int_1[15:0]" ,
"hb3_gtwiz_userdata_rx_int_1[15:0]" ,
]

# loop over files in the data directory
for data_file in listdir(data_dir):
# get full path for each file
data_file_path = data_dir+'/'+data_file
# print update to terminal
print "Analyzing: "+ data_file_path
# create an IlaData object for the file
analyzer = IlaData (data_file_path)
# set the oputput directory for the new analyzer
analyzer.analysis_dir = analysis_dir
# set the rxdata signals for the new analyzer
analyzer.rxdata_signals = rxdata_signals
# run the analysis
analyzer.full_analyze()

The variables which the user will want to change are bolded here.

data_dir is the directory where the analyzer expects to find ila data files. It will loop over every file in this directory and try ot analyze them all. Make sure that only ILA data files are stored in this directory or else you can have errors.

analysis_dir is the directory where the analyzer will dump the results of the analysis. The specific format of the results are discussed in the next section.

rxdata_signals is an array of signal names which the analyzer will try to unpack as rxdata. If these signals are not present there should be no problem, but there could be errors if the user provides the name of a signal which is present, but is not rxdata.

2.2: Run the analysis

Note that analyze_rxdata.py should be in the same directory as IlaData.py or else errors can occur.

You can run the analysis by executing the userscript:

./analyze_rxdata.py

As the script runs it will output the name of each file that it analyzes and a small message for each FAILED test. Example:

Analyzing: /home/jomarian/ila_data/test_data.csv
TEST FAILED: hb1_gtwiz_userdata_rx_int_1[15:0] QIE_ADC5 mean = 6.48466257669
TEST FAILED: hb1_gtwiz_userdata_rx_int_1[15:0] QIE_ADC5 stdev = 3.0443668753
TEST FAILED: hb1_gtwiz_userdata_rx_int_1[15:0] QIE_ADC7 stdev = 5.30943936883
Analyzing: /home/jomarian/ila_data/10-11-2020_14-07.csv
TEST FAILED: hb1_gtwiz_userdata_rx_int_1[15:0] QIE_ADC5 mean = 6.12345679012

Thus the output is usually pretty quiet, but it can be very verbose if you run on bad data:

./analyze_rxdata.py | wc
2554 23531 189731

Note that you do not need to save this output as it is also logged in the analysis results.

2.3: Interpreting the results

You should now have one directory for each ila data file in your analysis_dir:

{jomarian@ndpc3:analysis} ls -lrt
total 0
drwxr-xr-x. 6 jomarian jomarian 198 11 nov. 12:37 10-11-2020_13-50
drwxr-xr-x. 6 jomarian jomarian 191 11 nov. 12:38 test_data
drwxr-xr-x. 6 jomarian jomarian 198 11 nov. 12:38 10-11-2020_14-07
drwxr-xr-x. 6 jomarian jomarian 196 11 nov. 12:38 test_good_data
drwxr-xr-x. 6 jomarian jomarian 195 11 nov. 12:38 test_bad_data
drwxr-xr-x. 6 jomarian jomarian 202 11 nov. 13:28 FW07_RECCLK_11-11-20

Inside of each of these directories you will find a logfile and one subdirectory for each rxdata signal:

{jomarian@ndpc3:FW07_RECCLK_11-11-20} ls -lrt
total 116
drwxr-xr-x. 2 jomarian jomarian 4096 11 nov. 13:28 hb0_gtwiz_userdata_rx_int_1[15:0]
drwxr-xr-x. 2 jomarian jomarian 4096 11 nov. 13:28 hb1_gtwiz_userdata_rx_int_1[15:0]
drwxr-xr-x. 2 jomarian jomarian 4096 11 nov. 13:28 hb2_gtwiz_userdata_rx_int_1[15:0]
drwxr-xr-x. 2 jomarian jomarian 4096 11 nov. 13:28 hb3_gtwiz_userdata_rx_int_1[15:0]
-rw-r--r--. 1 jomarian jomarian 100267 11 nov. 13:30 FW07_RECCLK_11-11-20.txt

Each of these signal subdirectories contains plots and histograms which may help to understand the test results.

We can search for failed tests by grepping through the logfile:

grep FAIL FW07_RECCLK_11-11-20.txt

which should produce a list of all failed tests. To understand why a given test failed, it can be useful to look at the corresponding plots. Most tests are very simple checks of whether or not the mean and stdev of a given data sample fall within acceptable ranges. These ranges can be found in the next section.

One tip for a quick way to browse through all of the plots is to use a browser like Firefox. First get the full path of the analysis directory:

{jomarian@ndpc3:analysis} readlink -f FW07_RECCLK_11-11-20/
/home/jomarian/analysis/FW07_RECCLK_11-11-20

Next in the browser, go to the URL:

file://<fullpath&gt;

So, in my case I go to

file:///home/jomarian/analysis/FW07_RECCLK_11-11-20

And from here I can browse around the subdirectories and open the figures in the browser:

browser.png

2.4: More on tests

The test parameters are defined near the beginning of the IlaData.py file. I copy them here for quick reference.

The lower and upper limits for the acceptable means for each datatype are defined by

# "datatype" : (mean_min,mean_max)
self.mean_limits = {
"Comma" : (188.0,188.0) ,
"isAnyTDC63" : (0.0,0.0) ,
"isAnyTDC62" : (0.0,0.0) ,
"isAnyTDC59" : (0.0,0.0) ,
"isAnyTDC58" : (0.0,0.0) ,
"CapID" : (1.4,1.6) ,
"CapErr" : (0.0,0.0) ,
"TDCbad" : (0.0,0.0) ,
"QIE_ADC0" : (3.0,6.0) ,
"QIE_ADC1" : (3.0,6.0) ,
"QIE_ADC2" : (3.0,6.0) ,
"QIE_ADC3" : (3.0,6.0) ,
"QIE_ADC4" : (3.0,6.0) ,
"QIE_ADC5" : (3.0,6.0) ,
"QIE_ADC6" : (3.0,6.0) ,
"QIE_ADC7" : (3.0,6.0) ,
"TDC3" : (3.0,3.0) ,
"TDC2" : (3.0,3.0) ,
"TDC1" : (3.0,3.0) ,
"TDC0" : (3.0,3.0) ,
"TDC7" : (3.0,3.0) ,
"TDC6" : (3.0,3.0) ,
"TDC5" : (3.0,3.0) ,
"TDC4" : (3.0,3.0) ,
}

and the upper and lower limits on the acceptable stdevs are:

# "datatype" : (std_min,std_max)
self.std_limits = {
"Comma" : (0.0,0.0) ,
"isAnyTDC63" : (0.0,0.0) ,
"isAnyTDC62" : (0.0,0.0) ,
"isAnyTDC59" : (0.0,0.0) ,
"isAnyTDC58" : (0.0,0.0) ,
"CapID" : (1.0,1.2) ,
"CapErr" : (0.0,0.0) ,
"TDCbad" : (0.0,0.0) ,
"QIE_ADC0" : (0.0,1.5) ,
"QIE_ADC1" : (0.0,1.5) ,
"QIE_ADC2" : (0.0,1.5) ,
"QIE_ADC3" : (0.0,1.5) ,
"QIE_ADC4" : (0.0,1.5) ,
"QIE_ADC5" : (0.0,1.5) ,
"QIE_ADC6" : (0.0,1.5) ,
"QIE_ADC7" : (0.0,1.5) ,
"TDC3" : (0.0,0.0) ,
"TDC2" : (0.0,0.0) ,
"TDC1" : (0.0,0.0) ,
"TDC0" : (0.0,0.0) ,
"TDC7" : (0.0,0.0) ,
"TDC6" : (0.0,0.0) ,
"TDC5" : (0.0,0.0) ,
"TDC4" : (0.0,0.0) ,
}

The only other tests which are performed at the moment are a test to verify that expected BC0 K-characters are arriving at the beginning of each (assumed) frame and a test to verify that the capIDs are rotating as expected.

-- JosephPatrickMariano - 2020-11-04

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng BCP_Scaled_Block_Diagram_6.png r1 manage 310.6 K 2020-11-05 - 23:02 JosephPatrickMariano  
SVG (Scalable Vector Graphics)svg HcalBcp512_fibering.svg r3 r2 r1 manage 59.0 K 2020-11-06 - 13:43 JosephPatrickMariano  
XMLxml HcalBcp512_fibering.xml r2 r1 manage 3.7 K 2020-11-06 - 13:41 JosephPatrickMariano .xml source files for diagrams. Edit with draw.io
SVG (Scalable Vector Graphics)svg HcalBcp512_network.svg r1 manage 16.1 K 2020-11-06 - 13:36 JosephPatrickMariano  
XMLxml HcalBcp512_network.xml r1 manage 1.6 K 2020-11-06 - 13:46 JosephPatrickMariano xml source
SVG (Scalable Vector Graphics)svg HcalBcp512_teststand.svg r2 r1 manage 34.4 K 2020-11-05 - 22:51 JosephPatrickMariano  
XMLxml HcalBcp512_teststand.xml r1 manage 3.0 K 2020-11-05 - 22:57 JosephPatrickMariano .xml source files for diagrams. Edit with draw.io
PNGpng browser.png r1 manage 37.5 K 2020-11-11 - 13:44 JosephPatrickMariano  
PNGpng export.png r1 manage 90.8 K 2020-11-11 - 13:01 JosephPatrickMariano  
PNGpng export2.png r1 manage 11.3 K 2020-11-11 - 13:06 JosephPatrickMariano  
PNGpng ilas.png r1 manage 16.1 K 2020-11-11 - 12:47 JosephPatrickMariano  
PNGpng signals.png r1 manage 40.8 K 2020-11-11 - 12:56 JosephPatrickMariano  
Unknown file formatext testlog r1 manage 5.4 K 2020-11-17 - 17:20 JosephPatrickMariano test log from mapping investigation
PNGpng trigger.png r1 manage 87.4 K 2020-11-11 - 12:53 JosephPatrickMariano  
PNGpng vivado_autoconnect.png r1 manage 12.8 K 2020-11-06 - 15:55 JosephPatrickMariano  
PNGpng vivado_hardware.png r1 manage 5.3 K 2020-11-06 - 15:55 JosephPatrickMariano  
PNGpng vivado_program.png r1 manage 237.0 K 2020-11-06 - 15:55 JosephPatrickMariano  
PNGpng vivado_start.png r1 manage 192.5 K 2020-11-06 - 15:55 JosephPatrickMariano  
PNGpng vivado_xcku115.png r1 manage 33.6 K 2020-11-06 - 15:55 JosephPatrickMariano  
PNGpng vivado_xvc.png r1 manage 72.9 K 2020-11-06 - 15:55 JosephPatrickMariano  
PNGpng vivado_xvc2.png r1 manage 7.2 K 2020-11-06 - 16:00 JosephPatrickMariano  
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r8 - 2020-11-17 - JosephPatrickMariano
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback