Skip to content
Snippets Groups Projects
Commit 94103ebe authored by Jonathan Hargreaves's avatar Jonathan Hargreaves
Browse files

Merge branch 'master' of git.astron.nl:desp/hdl 

Needed before changes can be pushed
parents 9c5728f8 c2393629
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 1075 additions and 349 deletions
applications/lofar2/doc/prestudy/desp_howtools_erko.txt 0 → 100755
+ 143
− 0
View file @ 94103ebe
* GIT workflow
* Confluence
* Polarion
* Latex
*******************************************************************************
* GIT workflow
*******************************************************************************
difftool ?
mergetool ?
* Pro Git book by Scott Chacon: https://git-scm.com/book/en/v2
* YouTube : David Mahler part 1,2,3
Part 1:
# After GIT install
git version
git config --global http://user.name "EricKooistra"
git config --global http://user.email "erkooi@gmail.com"
git config --list
touch .gitignore # create .gitignore if it does not already exist
.gitignore # file with working tree dirs and files to ignore, must also be commited
# To start a repo
cd ~/git
git init # start new repo at this dir, creates .git/
git clone # get and start with existing repo
git clone git@git.astron.nl:desp/args.git
git status # what is in stage area and what is modified
Three areas:
* working tree # local directory tree
| git add
v
* staging area (index)
|
v git commit
* history # .git repository with entire commit graph
# To use a repo
git add <dir>/<file> # add to stage area, set for commit. Cannot add empty dir, need empty file in it
git add . # add all new and modified to stageing area
git diff # diff between file in working tree and staging area
git diff --staged # diff between file in staging area and history
git rm <filename> # remove file from working tree and stage the delete
git checkout -- <filename> # revert a working tree change
git reset # clear stage area
git reset HEAD <filename> # revert staged change
git log -- <filename> # show history of file
git checkout <version hash> -- s2 # retrieve file from history into staged area and working tree
Part 2:
git commit -m "" # commit what is in stage area
git commit -a -m "" # add to stage area and commit what is in stage area
alias graph="git log --all --decorate --oneline --graph"
git branch <branch name> # creat branch
git branch # show branches
git checkout <branch name> # change working tree and stage area to branch
git checkout master
git merge <branch name> # Fast forward merge of branch name to master if there is a direct path
# by moving master to branch name, this is when there have been no updates
# on the master branch since the branch was created.
# Three way merge combine the differences of the branch and the master
# compared to their common version, this can lead to merge conflicts if
# changes on both branches occur at same parts of a file.
git branch --merged # show branches that ghave been merged to master
git branch -d <branch name> # remove branch
git checkout <commit hash> # detached HEAD because it points to a version not a branch
git branch <branch name> # start a branch from the commit hash, HEAD is attached again
# Stash area to store working tree
git stash save "comment" # store working tree and stage area to get a clean
git stash list # show all stashes
git stash apply <label> # restore stash
git stash apply # restore last stash
Part 3: Remote repositories (Github, Gitlab, Bitbucket, ...)
create repo on Github
http://README.md # md = mark down
git clone <url:.../<repo name>.git> # get copy from url
cd <repo name>
git config --local http://user.name "EricKooistra"
git config --local http://user.email "erkooi@gmail.com"
git remote # origin
git remote -v # full url
# To align with remote repo
# update from remote
git status # shows also origin/master, but not live
git fetch origin
git status # shows also origin/master, now with latest remote
git merge origin/master
git pull # get latest from remote repo, combines fetch and merge
# upload to remote
git push
git push origin master # put local repo to remote repo
# On Github fork is a copy of the a repo in Github to get a repo on your account
git clone <url of fork> # get copy of fork repo, will be origin
git remote add upstream <url of original repo on Github> # will be upstream
git fetch upstream
git status
# commit local change on branch
# git push origin <branch name> # push to my fork repo on Github
# pull request on Github
# delete branch and fetch npstream if the pull request was accepted
git remote remove <remote name> # remove a remote repo
*******************************************************************************
* Confluence:
*******************************************************************************
- space tools menu links onder om secties the ordenen.
*******************************************************************************
* Polarion:
*******************************************************************************
*******************************************************************************
* LaTeX
*******************************************************************************
- \sigma \sqrt{}
- 4.15 \cdot 10^{15}
- M =
\left[ {begin{array}{cc}
1 & 2 & 3 & 4\\
5 & 6 & 7 & 8\\
\end{array} } \right]
.
\ No newline at end of file
applications/lofar2/doc/prestudy/desp_radiohdl_article.txt 0 → 100644
+ 259
− 0
View file @ 94103ebe
*******************************************************************************
* 1) Article topics
*******************************************************************************
Title: RadioHDL build environment for FPGA firmware
*******************************************************************************
* 2) User guide topics
*******************************************************************************
a) Introduction:
RadioHDL is a highly flexible automated build environment for HDL source code. The HDL is
organized in HDL libraries. The HDL libraries promote code reuse. The top level component
that can run on an FPGA is also a HDL library. The parameters for HDL libraries, the build
tools and target FPGA are kept in configuration files. The configuration files and source
code are the inputs for the RadioHDL tool. The output is a build result that depends on
which build tool is used. The buil result can e.g. be a project file for Modelsim to
simulate the HDL, a project for Quartus to synthesize the HDL, a report log from a
regression test that simulated the HDL.
Technology dependent IP for e.g. PLL, RAM, FIFO, transceivers, DDR4 is included via HDL
libraries as well. The technology dependent IP is pregenerated and instantiated using wrapper
HDL. The wrapper HDL around the technology dependent IP makes the IP vendor agnostic. The
wrapper HDL can select one or more vendor IP. The wrapper IP can also select a behavioral
simulation model of the IP, to speed up the HDL simulation or to simulate without any vendor
dependence.
Features:
- Gear scripting based on Pyhton 3.x
- Configuration files to define the sources and how to build them
- Separation of source files and build result files
- All HDL organised in HDL libraries that
. provide hierarchical structure and promote reuse
. allow separation of technology dependent libraries, board specific libraries, general
libraries and application specific libraries
. can be used to build different revisions of the same source code based on generics
. can include local test benches to verify the library in a regression test
b) Quick start:
c) Config files:
hdllib.cfg :
. Each HDL Library has a local hdllib.cfg configuration file that defines the sources and
supported tools
. many, each local per HDL library in a sub directory of $RADIOHDL_WORK
hdl_buildset_<buildset_name>.cfg
. A central hdl_buildset_<name> build configuration file defines the combination of sources,
FPGA type and version and tool versions that are needed to build target FPGA type (board)
and type and version of the tools for synthesis, simulation.
. defines a combination of board, FPGA and tool versions
. one central per buildset located at $RADIOHDL_CONFIG
hdl_tool_<tool_name>.cfg
. A central hdl_tool_<name>.cfg tool configuration file that defines central setting for
that tool. Typical tools are e.g. Modelsim for simulation and Quartus for synthesis, but
other tool vendors can also be supported and other tools like a reggression test that
runs a set of test benches for a set of HDL libraries.
. defines tool specific settings (e.g. modelsim, quartus)
. one central per tool located at $RADIOHDL_CONFIG
d) Environment setup
* Operating system
RadioHDL supports both Windows and Linux operating systems. The following tools need to be
availabel in order to build target files (TBC):
- Make (available in /bin for win32 platforms)
- Python 3.x
- Pyhton libraries (numpy, pylatex, yaml)
* Environment variables
.bashrc
- ALTERA_DIR is set to where Altera tool version is installed (i.e. Quartus)
- MENTOR_DIR is set to where Mentor tool version is installed (i.e. Modelsim)
- MODELSIM_ALTERA_LIBS_DIR is set to where the compiled Altera tool versions HDL libraries
for simulation with Modelsim are stored
init_<my_project>.sh
- RADIOHDL_WORK is set to location of this init_<my_project>.sh and defines the root
directory from where all HDL libraries source files (hdllib.cfg) can be
found
- RADIOHDL_BUILD_DIR is set to ${RADIOHDL_WORK}/build and defines where all build results will
be put
- HDL_IOFILE_SIM_DIR is set to ${RADIOHDL_BUILD_DIR}/sim and defines where Modelsim simulation
will keep temporary file IO files.
init_radiohdl.sh
- RADIOHDL_GEAR is set to location of this init_radiohdl.sh and defines the root directory
of where the RadioHDL tool is installed.
- RADIOHDL_CONFIG is set to ${RADIOHDL_GEAR}/config if not already defined by the user and
defines where the central configuration scripts for buildsets (unb1, unb2b)
and tools (modelsim, quartus) are kept.
Environment variables for build tools (e.g. modelsim, quartus) are set automatically (TBC)
MODEL_TECH_DIR
* Environment files
Altera hdl_user_components.ipx:
This hdl_user_components.ipx defines where Quartus QSYS searches for user components. The
init_<my_project>.sh copies hdl_user_components.ipx from $RADIOHDL_WORK to
${ALTERA_DIR}/ip/altera/user_components.ipx.
f) Directory structure
RadioHDL requires that:
- the HDL source code is organised in one or more HDL libries
- each HDL library has a dedciated directory and hdllib.cfg file
- all HDL library directories can be found from a common root directory
Hence a single VHDL file in a single HDL library is enough to get started with RadioHDL. For a
larger firmware design that contains all source code and configuration settings to build an
application that can be synthesized and run on an FPGA a the directory structure can be:
- applications/ -- application specific top level HDL libraries and application specific support
HDL libraries
- boards/ -- board specific HDL top level HDL libraries and board specific support HDL
libraries
- libraries/ -- general HDL libraries
base/ -- common low level functions (FIFO, block RAM, register, multiplexer,
reordering, packetizing, ..)
dsp/ -- digitial processing (FFT, FIR filter, filterbank, beamformer, ...)
io/ -- input/output (DDR, transceivers, Ethernet, flash, ADC, I2C, ...)
external/ -- RTL style HDL code from other parties
technology/ -- Tecnhology wrapper liobraries of vendor IP, vendor IP libraries, behavioral
model IP libraries (clock, memory, IO)
For example the board support package (BSP) firmware of an FPGA on a certain board can be placed
in the boards/<board name>/libraries/bsp/ directory.
Each board is assumed to have a single board support package library that includes all code
required to use the FPGA on the board, this includes e.g. a 1GbE interface for control, a flash
interface for storing the FPGA image.
This BSP can be instantiated into a minimal firmware image that can run on an FPGA and
can be placed in the boards/<board name>/designs/<board_name>_minimal/
A different version of a board will result in a different board_name, escpecially if the new
version of the board contains another FPGA type or version or requires a new tool version.
A more elaborate firmware application that runs on the board will instantiate the BSP and a
combination of application specific code and general components. The application specific
componentts can be grouped in applications/<application_name>/libraries and the application itself
in applications/<application_name>/designs/<design_name>. If the top level entity of the application
has generics then it is possible to build different revisions of the same design source code in
applications/<application_name>/designs/<design_name>/revisions. The boards and applications build
upon general HDL libraries. The directories may be structure with sub directories with at the
lowest level the sub directory of a HDL library that typically uses that library name <lib_name> or
an derivative of it as directory name. The HDL library directories are typically organized by
purpose source (src) or testbench (tb) and by HDL language (vhdl, verilog). However this sub
directories are only for convenience, because the hdllib.cfg can refer to the code from anywhere
within <lib_name>. There is also a doc directory to put any documentation that is relevant for the
library.
<lib_name>/hdllib.cfg
/src/vhdl
/tb/vhdl
/doc
When deciding on how to divide HDL code into libraries the following general rules should be
followed:
- HDL Libraries within the /libraries directories should be single purpose and not associated with
a particular hardware platform.
- Hardware specific functions should be placed into the /boards/<board>/library directory.
- Small modules that will be frequently reused in other libraries or generic wrappers for vendor
specific IP should be placed in /libraries/base/<hdl library>. Higher level libraries should be
placed in /libraries/io/<hdl library> or /libraries/dsp/<hdl library> depending on functionality.
- Externally supported code should be placed in /libraries/external/<hdl library>
- Vendor IP should be placed into /libraries/technology/<hdl library> and grouped according to
function area i.e. memory, fifo, mac_10g.
Technology independence:
The technology/ directory contains several technology dependent libraries of vendor IP that is
pre generated and then wrapped by a technology agnostic wrapper entity. These wrapper entities
are then used by the other libraries.
g) Top level HDL library:
A top level HDL library is defined as a HDL library that contains a top level entity and
configuration parameters to synthesize it to an FPGA image that can run on an FPGA.
A top level HDL library should not be reused in other HDL libraries, to avoid confusion
that can occur due to conflicting or dupplciate
*******************************************************************************
* Run RadioHDL with GIT
> cd ~/git/hdl
> . ./init_hdl.sh # setup development environment for hdl/
# hdl/libraries, hdl/boards and hdl/applications are developed simultaneously and therefor in one git hdl/ repository
# automatically also sources ../radiohdl/init_radiohdl.sh if necessary
> compile_altera_simlibs unb1 # creates build/unb1/hdl_libraries_ip_stratixiv.txt
# creates build/quartus/<tool version> simulation models that need to be moved to /home/software/modelsim_altera_libs
> generate_ip_libs unb1 # creates build/unb1/qmegawiz/
# creates build/unb1/quartus_sh --> empty dir, why is it there?
> quartus_config unb1 # creates build/unb1/quartus/<hdllib libraries> for synthesis
# creates build/unb1/quartus/technology_select_pkg.vhd
> modelsim_config unb1 # creates build/unb1/modelsim/<hdllib libraries> for simulation
# creates build/unb1/modelsim/modelsim_project_files.txt for Modelsim commands.do
# creates build/unb1/modelsim/technology_select_pkg.vhd
> run_qsys unb1 unb1_minimal_qsys
*******************************************************************************
* Run RadioHDL with SVN
echo "Uniboard trunk is selected"
export SVN=${HOME}/svnroot/UniBoard_FP7
#Setup RadioHDL environment for UniBoard2 and and new Uniboard1 applications
. ${SVN}/RadioHDL/trunk/tools/setup_radiohdl.sh
# Support old UniBoard environment (including Aarfaac and Paasar)
. ${SVN}/RadioHDL/trunk/tools/setup_unb.sh
*******************************************************************************
* 3) Programmers guide topics
*******************************************************************************
RadioHDL gear directory structure
$RADIOHDL_GEAR/config # central config files for buildsets and tools
/core # RadioHDL gear scripts
/doc # manuals
/ise # scripts for Xilinx ISE, Impact tools
/modelsim # scripts for Mentor Modelsim tool
/quartus # scripts for Altera Quartus, SOPC, QSYS tools
init_radiohdl.sh # Initialize RadioHDL for a project at $RADIOHDL_WORK
generic.sh # Collection of useful functions
# Scripts to adopt RadioHDL configuration parameters as environment variables
# or paths
set_config_path # expand config paths
set_config_variable # export config variables
set_hdllib_variable # export hdllib variables
*******************************************************************************
* Open issues:
*******************************************************************************
- Support more roots in RADIOHDL_WORK for searching HDL libraries
- Central HDL_IO_FILE_SIM_DIR = build/sim --> Project local sim dir
- avs_eth_coe.vhd per tool version? Because copying avs_eth_coe_<buildset>_hw.tcl to $HDL_BUILD_DIR
copies the last <buildset>, using more than one buildset at a time gices conflicts.
- RadioHDL improvements requested by CSIRO for Vivado
\ No newline at end of file
applications/lofar2/doc/prestudy/station2_opc_ua.txt
+ 36
− 0
View file @ 94103ebe
......@@ -14,6 +14,13 @@ https://en.wikipedia.org/wiki/OPC_Unified_Architecture
- Service oriented architecture (SOA) using asynchronous request/response pattern
- transport: via TCP in binary or web based
- data model: more than hierarchy of files/folder/registers, object oriented nodes that can send meta information and data
- build in models for:
. data access
. alarm conditions
. historic data and events
. programs (= methods)
. device description (= meta data, properties)
- expandability via profiles:
. DI = device integration
. DA = data access
......@@ -21,6 +28,35 @@ https://en.wikipedia.org/wiki/OPC_Unified_Architecture
. HDA = historical data access
- security
- authentication
- authorisation
- encryption
Modbus looks like MM protocol, with coils (= releis = bit) and registers (words), but has
limited ranges.
XML for data language
RTD = real time data
OPC-UA tag = value + properities = information
properties : units, significatn digits, thresholds
HMI = Human Machine Interface
|
|
|
OPC-UA client (consume data)
|
|
|
OPC-UA server (expose data of device)
|
|
|
driver
|
|
|
field devices (one or many data points)
Needed:
- OPC-UA SDK (software development kit)
......
applications/lofar2/doc/prestudy/station2_sdp_firmware_planning.txt
+ 504
− 140
View file @ 94103ebe
*******************************************************************************
* SDP Firmware planning
*******************************************************************************
Includes design, implementation, verification on HW, technical commissioning.
v1 v2
Infrastructure
10 20 - Development environment using GIT, RadioHDL, updating existing components
20 . - BSP using Gemini Protocol, ARGS
10 . - Ethernet access (OSI 1-4)
10 20 - Ring access
Application:
15 . - ADC ingress and time stamp
20 10 - Subband filterbank (critically sampled)
0 30 - Subband filterbank (oversampled)
10 . - Beamformer
20 . - Subband correlator
25 . - Transient buffer (DDR4 interface, subband select and DM >= 0, packet format, M&C, RW access via M&C)
20 . - Transient detection
20 . - Subband offload
0 . - 160 MHz
35 . Integration
5 - FPGA pinning
10 - Interface test designs unb2c
5 - Design revisions and lab tests
15 - Technical commissioning
1 week = 100% project allocation, bruto 40 hours, netto 40 * 0.8 = 32 hours = 4 days
sprint = 100% project allocation, bruto 3 weeks, netto 12 days
v1 : 10 + 20 + 10 + 10 + 15 + 20 + 10 + 20 + 25 + 20 + 20 + 35 = 215 bruto weeks --> 215 / 40 = 5.4 FTE ~ 3 people each 2 years
v2 : 10 less for critically sampled PFB
10 more for updating existing components
10 more for ring access
30 for oversampled PFB
. consider unb2c test part of SDP FW integration and of SDP HW
15 technical commisioning relies on proper Systems Engineering, otherwise may become 50 weeks
==> EK, JH: v1 estimate of April 2019 is still valid as v2 on 10 Oct 2019.
v3 :
Infrastructure
20 - Development environment using GIT, RadioHDL, updating existing components
5 - unb2c FPGA pinning
10 - unb2c FPGA interface test designs
20 - Board Support Package using Gemini Protocol and ARGS
20 - Ring access
10 - 10GbE access (OSI 1-4)
Application:
15 - ADC input and time stamp
10 - Subband filterbank (critically sampled)
20 - Subband correlator
10 - Beamformer
25 - Transient buffer
20 - Subband offload for AARTFAAC
20 - Transient detection
30 - Oversampled subband filterbank
0 - Support 160 MHz
Integration:
10 - Lab tests
5 - Technical commissioning Dwingeloo
5 - Technical commissioning Prototype Station
All:
20 + 5 + 10 + 20 + 20 + 10 + 15 + 10 + 20 + 10 + 25 + 20 + 20 + 30 + 0 + 10 + 5 + 5 = 255
No oversampled filterbank:
20 + 5 + 10 + 20 + 20 + 10 + 15 + 10 + 20 + 10 + 25 + 20 + 20 + 0 + 10 + 5 + 5 = 225
*******************************************************************************
* SDP Workpackage (UniBoard2 HW + FW)
*******************************************************************************
Changed tasks:
- T4.6 : 20 weeks booked explicitely for Required documents
- T4.1 : 10 weeks, because GIT, RadioHDL finished
- T4.2 : 10 weeks, because some FW done
- T4.2 : ? weeks, hardware effort
Firmware FPGA images:
- the SDP has one main firmware design unb2c_sdp,
- the integrated design of SDP is revision unb2c_sdp_station,
- per task there are revisions of unb2c_sdp that contain subsets of the SDP functionality,
Deliverables (D) = an item, product : items that are needed for a milestone
Milestones (M) = a moment in time, achievement : 'cake moments' when you demonstrate or review
deliverables as part of a larger system
- integration passed
- review passed
Planning for LOFAR2.0 Station Workpackage 4 : Station Digital Processing
Below is the planning in weeks per task, the work includes:
- UniBoard2 hardware
- Firmware that runs on UniBoard2
weeks task description
10 T4.1 Maintain firmware development environment (GIT, RadioHDL, HDL libraries)
10 T4.2 UniBoard2 test firmware (enable mass production of UniBoard2)
? T4.2 UniBoard2 board hardware
20 T4.3 UniBoard2 board support package (BSP, M&C via Gemini Protocol, use ARGS for doc, C, VHDL)
10 T4.4 Network access via 10GbE (support ARP and ping)
20 t4.5 Ring access using test data and BSN monitor (support ring)
20 T4.6 Required documents (SDP RS, detailed design, ICDs, FW manual)
15 T4.7 ADC input and timestamp (RCU2 interface, capture timestamped data for offline analysis)
10 T4.8 Subband filterbank (Fsub, critically sampled, SST)
20 T4.9 Subband correlator (XC, one subband per 1 s integration)
10 T4.10 Beamformer (BF, BST, beamlet output to CEP)
10 + 10 + ? + 20 + 10 + 20 + 20 + 15 + 10 + 20 + 10 = 145 + ? weeks
Milestone : SDP ready for CDR:
All major technical UniBoard2 hardware and SDP firmware risks are mitigated:
- by design
- SDP hardware and interfaces validated with at least two UniBoard2 using JTAG, firmware for BSP,
ring and ADC
- Station TD validated using BF beamlet output to CEP
The remaining tasks concern completing the applications that the firmware needs to perform.
weeks task description
25 T4.11 Transient buffer (TB, ADC data, subband data)
20 T4.12 Transient detection (TDET)
20 T4.13 Subband offload (SO) for AARTFAAC2.0
20 T4.14 Station integration tests (using unb2c_sdp_station)
25 + 20 + 20 + 20 = 85 weeks
*******************************************************************************
* Planning defintions
*******************************************************************************
1 year = 40 weeks = 1600 hours, so each Quarter has 10 weeks.
1 week = 100% project allocation, bruto 40 hours, netto 40 * 0.8 = 32 hours = 4 days
sprint = 100% project allocation, bruto 3 weeks, netto 12 days.
The week/hour estimates concern time that is booked on the project. For example if a tasks has
alloacted 1 week, then:
- 40 hours will be booked on the project
- the lead time (doorlooptijd) wiil be about 1/0.8 = 1.25 longer
There are 52 / 3 = 17 sprints in a year, so about 4 sprints per Quarter. Hence each sprint can
contain about 10 / 4 = 2.5 weeks of booked work per person at 100% project allocation.
With e.g. 230 weeks and 3 persons allocated 100%, then the project lead time will be:
230 (booked weeks) / 40 (weeks/year) / 3 (persons) * 1.25 (netto) = 2.4 years
This then means that with the SDP work starting 1 jan 2020 it can complete mid 2022.
*******************************************************************************
* L3 integration test platforms towards CDR
*******************************************************************************
1) Laboratory tests
Objectives: Verification of (parts of) individyual elements and their interfaces
- 1 UniBoard2 Rev 2 (use different FPGA on same UniBoard for FW, SW tests)
Setups for:
- SW
- FW
- Analogue chain
- Cabinet
- Complete signal chain
2) Dwingeloo Test Station (DTS) - First-light Sep 2020
Objectives: Verify that a complete signal chain using the first iteration of L3 hardware design
shows no serious issues and that it can be reliably installed in a LOFAR station.
- 1 UniBoard2 Rev 2
- First iteration of electronic boards --> 2 UniBoard2 Rev 3a
3) Prototype Test Station (PTS) - First-light Mai 2021
Objectives: Verify Station L2 requirements through testing and analysis, and provide evidence to
the CDR review panel that the designs ensure compliance with all L2 requirements.
- Second iteration of electronic boards --> 4 UniBoard2 Rev 3b
- 4 UniBoard2 Rev 3b in two subracks (one for LBA with 32 RCU2, one for HBA with 32 RCU2)
- Output to CEP for correlation with other stations
*******************************************************************************
* Station reviews
*******************************************************************************
0) Station PDR close out 31 jan 2020
1) Station DDR ? 2020
2) Station CDR Dec 2021
Objectives: Compliance with all L2 requirements, all risks mitigated, ready for production
Relevant project dates:
- 5-2020 Station DDR ?
- 9-2020 first light DTS (will use Rev 2, and 4 RCUs with JESD ADC)
- 10-2020 Working UniBoard2 Rev 3a
- 5-2021 first light PTS (can use 2x Rev 3a, but goal is to use 4x Rev 3b, 32 RCU2_L, 32 RCU2_H)
- 7-2021 Working UniBoard2 Rev 3b
- 12-2021 Station CDR
- 6-2022 Station rollout start
*******************************************************************************
* SDP Firmware planning
*******************************************************************************
Includes design, implementation, verification on HW, technical commissioning.
v1 v2
Infrastructure
10 20 - Development environment using GIT, RadioHDL, updating existing components
20 . - BSP using Gemini Protocol, ARGS
10 . - Ethernet access (OSI 1-4)
10 20 - Ring access
Application:
15 . - ADC ingress and time stamp
20 10 - Subband filterbank (critically sampled)
0 30 - Subband filterbank (oversampled)
10 . - Beamformer
20 . - Subband correlator
25 . - Transient buffer (DDR4 interface, subband select and DM >= 0, packet format, M&C,
RW access via M&C)
20 . - Transient detection
20 . - Subband offload
0 . - 160 MHz
35 . Integration
5 - FPGA pinning
10 - Interface test designs unb2c
5 - Design revisions and lab tests
15 - Technical commissioning
v1 : 10 + 20 + 10 + 10 + 15 + 20 + 10 + 20 + 25 + 20 + 20 + 35 = 215 bruto weeks --> 215 / 40
= 5.4 FTE ~ 3 people each 2 years
v2 : 10 less for critically sampled PFB
10 more for updating existing components
10 more for ring access
30 for oversampled PFB
. consider unb2c test part of SDP FW integration and of SDP HW
15 technical commisioning relies on proper Systems Engineering, otherwise may become
50 weeks
==> EK, JH: v1 estimate of April 2019 is still valid as v2 on 10 Oct 2019.
v3 :
Infrastructure
20 - Development environment using GIT, RadioHDL, updating existing components
5 - unb2c FPGA pinning
10 - unb2c FPGA interface test designs
20 - Board Support Package using Gemini Protocol and ARGS
20 - Ring access
10 - 10GbE access (OSI 1-4)
Application:
15 - ADC input and time stamp
10 - Subband filterbank (critically sampled)
20 - Subband correlator
10 - Beamformer
25 - Transient buffer
20 - Subband offload for AARTFAAC
20 - Transient detection
30 - Oversampled subband filterbank
0 - Support 160 MHz
Integration:
10 - Lab tests
5 - Technical commissioning Dwingeloo
5 - Technical commissioning Prototype Station
All:
20 + 5 + 10 + 20 + 20 + 10 + 15 + 10 + 20 + 10 + 25 + 20 + 20 + 30 + 0 + 10 + 5 + 5 = 255
No oversampled filterbank:
20 + 5 + 10 + 20 + 20 + 10 + 15 + 10 + 20 + 10 + 25 + 20 + 20 + 0 + 10 + 5 + 5 = 225
*******************************************************************************
* SDP Workpackage (UniBoard2 HW + FW)
*******************************************************************************
Changed tasks:
- T5.6 : 20 weeks booked explicitely for Required documents
- T5.1 : 10 weeks, because GIT, RadioHDL finished
- T5.2a : ? weeks, hardware effort
- T5.2b : 10 weeks, because some FW done
- T5.3a : FW side of M&C
- T5.3b : SW side of M&C idendified separately
Firmware FPGA images:
- the SDP has one main firmware design unb2c_sdp,
- the integrated design of SDP is revision unb2c_sdp_station,
- per task there are revisions of unb2c_sdp that contain subsets of the SDP functionality,
Deliverables (D) = an item, product : items that are needed for a milestone
Milestones (M) = a moment in time, achievement : 'cake moments' when you demonstrate or review
deliverables as part of a larger system
- integration passed
- review passed
Planning for LOFAR2.0 Station Workpackage 4 : Station Digital Processing
Below is the planning in weeks per task, the work includes:
- UniBoard2 hardware
- Firmware that runs on UniBoard2
weeks task description
10 T5.1 Maintain firmware development environment (GIT, RadioHDL, HDL libraries)
30 T5.2a UniBoard2 board hardware
10 T5.2b UniBoard2 test firmware (enable mass production of UniBoard2)
20 T5.3a UniBoard2 board support package (BSP, M&C via Gemini Protocol, use ARGS for doc,
C, VHDL)
T5.3b SW driver for GP
10 T5.4 Network access via 10GbE (support ARP and ping)
20 T5.5 Ring access using test data and BSN monitor (support ring)
20 T5.6 Detailed design SDP firmware (Required documents: SDP RS, FW detailed design,
ICDs, FW manual)
15 T5.7 ADC input and timestamp (RCU2 interface, capture timestamped data for offline
analysis)
10 T5.8 Subband filterbank (Fsub, critically sampled, calibrated subbands, SST)
20 T5.9 Subband correlator (XC, one subband per 1 s integration)
10 T5.10 Beamformer (BF, BST, beamlet output to CEP)
25 T5.11 Transient buffer (TB, ADC data, subband data)
10 + ? + 10 + 20 + 10 + 20 + 20 + 15 + 10 + 20 + 10 + 25 = 160 + ? weeks
Milestone : SDP ready for CDR:
All major technical UniBoard2 hardware and SDP firmware risks are mitigated:
- by design
- SDP hardware and interfaces validated with at least two UniBoard2 using JTAG, firmware for BSP,
ring and ADC
- Station validated using BF calibrated beamlet output to CEP and correlated with other Stations
The remaining tasks concern completing the applications that the firmware needs to perform.
weeks task description
20 T5.12 Transient detection (TDET)
20 T5.13 Subband offload (SO) for AARTFAAC2.0
20 T5.14 Station integration tests (using unb2c_sdp_station)
20 + 20 + 20 = 60 weeks
Weeks Task Person Date Platform Deliverable description
10 T5.1 Maintain firmware development environment (GIT, RadioHDL,
ARGS, HDL libraries)
PD * HDL libraries in git/hdl
PD * RadioHDL in git/radiohdl
PD * ARGS in git/args
PD - Maintain ARGS (e.g. for improved document generation)
DS - HDL libraries regression test in git/hdl repository
EK - Code review procedure using GIT, branches and Jira
EK - Updated RadioHDL user guide
EK - Updated RadioHDL programmers guide
EK - Paper on RadioHDL
EK - Updated ARGS user guide
EK - Design document for ARGS HDL code generation
EK - General HDL coding
. Paper on RTL coding style
. Global reset in sosi record
. Map between AXI bus and Avalon bus (both MM, ST)
25 T5.2a UniBoard2 board hardware
1 GS 12-2019 D UniBoard2 Detailed Design document
9 GS 4-2020 D Production package proto UniBoard2
GS 4-2020 M Design review UniBoard2 Rev 3a
7 GS 10-2020 D UniBoard2 proto type Rev3a
GS,JH 10-2020 Lab M Working UniBoard2 Rev 3a
GS 12-2020 M UniBoard2 Rev 3b review
5 GS 1-2021 D Production package UniBoard2
3 GS 7-2021 D UniBoard2 production version Rev3b
GS,JH 7-2021 Lab,PTS M Working UniBoard2 Rev 3b
10 T5.2b UniBoard2 test firmware + lab tests to enable mass
production of UniBoard2
JH 2-2020 D unb2c_test_pinning (using 10GbE)
JH 2-2020 D unb2c_test_pinning_jesd (using JESD204b)
JH 2-2020 D unb2c_heater (verify speed grade using clk = 256 MHz)
JH 2-2020 - M Complete pinning + heater firmware package for unb2c
Test designs unb2c_test_* can be prepared using UCP BSP, but
aim to use GP BSP at 7-2020. Converting from UCP to GP
involves instantiating new GP BSP VHDL and using peek/poke
via CSIRO GP driver.
JH 4-2020 D unb2c_test_ddr4 (both slots)
JH 4-2020 D unb2c_test_10GbE (front = QSFP + ring, back)
JH 4-2020 D unb2c_test_adc (= lofar2_unb2b_adc_one_node for unb2c)
PD 6-2020 D unb2c_minimal_gp (BSP) (= unb2b_minimal_gp for unb2c)
. 1GbE (two revisions, one for each port)
. PPS
. Flash
. internal FPGA monitor (temperature)
JH 6-2020 M Complete test + BSP firmware package for unb2c HW
20 T5.3a UniBoard2 FW board support package (BSP, M&C via Gemini
Protocol (GP), use ARGS for doc, C, VHDL)
LH 2-2020 D Gemini LRU board for initial SW M&C tests
PD 5-2020 D unb2b_minimal_gp (BSP + M&C)
PD 5-2020 Lab M Working BSP unb2b_minimal_gp + SW M&C
Aim is to automate using ARGS, fallback is to do by hand:
10-2020 D ARGS for VHDL slave generation (design in Task 5.1)
? T5.3b UniBoard2 SW driver
10-2020 d ARGS for SW driver generation
. CSIRO generates C header file for Gemini Protocol and
MM register map.
10 T5.4 Network access via 10GbE (support ARP request and ping
response)
RW 4-2020 D unb2c_network (10GbE + MAC statistics + ARP + ping + M&C)
20 T5.5 Ring access, transport and alignment (using BG)
D lofar2_unb2c_ring_sum
D lofar2_unb2c_ring_mux
. Control ring transport
. Monitor ring transport, latency, alignment and timing
12-2020 Lab M Working ring + SW M&C
20 T5.6 Detailed design SDP (Required documents: SDP RS, FW detailed
design, ICDs, FW manual)
EK D SDP requirements specification (for DDR, CDR)
EK D SDP architectural design document (for DDR, CDR)
. toplevel structure of lofar2_unb2c
. bsp
. timing (+ ICD STF-SDP)
. ring
. adc (+ ICD RCU2S-SDP)
. subband filterbank
. beamformer
. correlator
. transient buffer
. transient detection
. subband offload
EK D ICD STAT.SDP-CEP
EK d ICD TM-STAT.SC
EK,GS d ICD SC-SDP
GS . SDP UniBoard2 hardware M&C
GS . UniBoard2 HW representation
EK . SDP firmware M&C via Gemini protocol
EK . SDP firmware register map
EK . FW representation
EK d ICD RCU2S-SDP
GS d ICD STF-SDP
GS D ICD SDP-STCA
EK 6-2020 DDR M Complete SDP document package for Station DDR
all 12-2021 CDR M Complete SDP document package for Station CDR
D Test & verification report per firmware deliverable
. requirement + test case + result (readme.txt or doc)
15 T5.7 ADC input and timestamp (RCU2 interface, capture timestamped
data for offline analysis)
2-2020 Lab D lofar2_unb2b_adc_one_node (12 ADC + DB + M&C JESD + M&C)
. use data buffer (DB) to read captured samples via M&C
. on two nodes and power cycle to verify synchronisation
5-2020 Lab D lofar2_unb2b_adc_full
. waveform generator (WG)
. timestamp (ToD, BSN)
. delay buffer
. statistics (mean, power, histogram))
JH 9-2020 DTS M Working ADC input and timestamp + SW M&C
10 T5.8 Subband filterbank (Fsub, critically sampled, calibrated
subbands, SST)
6-2020 D lofar2_unb2c_filterbank_sst (12 ADC + SST + M&C)
9-2020 D lofar2_unb2c_filterbank_full (+ calibration weights)
9-2020 DTS M Working subband filterbank + SW M&C
. read and plot SST
. control calibration weights
15 T5.9 Subband correlator (XC, one subband per 1 s integration)
9-2020 D lofar2_unb2c_correlator_one_node (12 ADC + M&C)
D lofar2_unb2c_correlator_full (+ ring)
7-2021 PTS M Working Subband correlator + SW M&C
. control crosslet selection
. read and plot crosslet statistics (XST)
15 T5.10 Beamformer (BF, BST, beamlet output to CEP)
9-2020 DTS D lofar2_unb2c_output_one_input (1 ADC + output via 10GbE)
. select subbands from one input
. packetize subbands into packet
. control beamlet output (scaling, packetizing)
all 9-2020 DTS M Entire signal chain available at DTS
. XC for one node
. BF output for one ADC input
D lofar2_unb2c_beamformer_output (12 ADC + BST + output via
10GbE + M&C)
D lofar2_unb2c_beamformer_full (+ ring)
7-2021 PTS M Working Station beamformer + SW M&C
. read and plot beamlet statistics (BST)
25 T5.11 Transient buffer (TB, ADC data, subband data)
D lofar2_unb2c_transient_buffer_ddr4_access (direct read and
write of DDR4 via M&C)
D lofar2_unb2c_transient_buffer_one_node (12 ADC + setup,
write ADC data, freeze, read via M&C)
12-2020 Lab M Working Transient buffer and read DDR4 via M&C
7-2021 Lab D lofar2_unb2c_transient_buffer_output (+ read out via 10GbE)
7-2021 PTS D lofar2_unb2c_transient_buffer_full (+ ring)
12-2021 PTS M Working Transient buffer and read via 10GbE + SW M&C
20 T5.12 Transient detection (TDET)
12-2021 PTS D lofar2_unb2c_transient_detection (12 ADC, detection and
trigger + M&C)
12-2021 Rollout M Working Transient detection + SW M&C
20 T5.13 Subband offload (SO) for AARTFAAC2.0
12-2020 Lab D lofar2_unb2c_subband_offload_output (12 ADC + packetized
output via 10GbE + M&C)
6-2022 PTS D lofar2_unb2c_subband_offload_full (+ ring)
6-2022 Rollout M Working Subband offload + SW M&C
20 T5.14 Station test and verification
12-2021 PTS D lofar2_unb2c_sdp_station (all BF, XC, TD, TDET, SO)
6-2022 Rollout M Operational Station Firmware (all BF, XC, TD, TDET, SO)
+ SW M&C
SDP milestones:
Weeks Task Person Date Platform Milestone description
JH 2-2020 - M Complete pinning + heater firmware package for unb2c
GS 4-2020 M Design review UniBoard2 Rev 3a
PD 5-2020 Lab M Working BSP unb2b_minimal_gp + SW M&C
JH 6-2020 M Complete test + BSP firmware package for unb2c HW
EK 6-2020 DDR M Complete SDP document package for Station DDR
JH 9-2020 DTS M Working ADC input and timestamp + SW M&C
9-2020 DTS M Working subband filterbank + SW M&C
all 9-2020 DTS M Entire signal chain available at DTS
. XC for one node
. BF output for one ADC input
GS,JH 10-2020 Lab M Working UniBoard2 Rev 3a
GS 12-2020 M UniBoard2 Rev 3b review
12-2020 Lab M Working ring + SW M&C
12-2020 Lab M Working Transient buffer and read DDR4 via M&C
GS,JH 7-2021 Lab,PTS M Working UniBoard2 Rev 3b
7-2021 PTS M Working Subband correlator + SW M&C
7-2021 PTS M Working Station beamformer + SW M&C
12-2021 PTS M Working Transient buffer and read via 10gbE + SW M&C
12-2021 PTS M Working Transient detection + SW M&C
all 12-2021 CDR M Complete SDP document package for Station CDR
6-2022 Rollout M Working Subband offload + SW M&C
6-2022 Rollout M Operational Station Firmware (all BF, XC, TD, TDET, SO)
+ SW M&C
*******************************************************************************
* Comparision Oct 2018 AAD estimates and dec 2019 PDR estimation
*******************************************************************************
- PDR estimates (dec 2019)
SDP HW : Task 5.2a : 25 weeks
SDP FW : Task 5.1-5.13 : 10 + 10 + 20 + 10 + 20 + 20 + 15 + 10 + 15 + 15 + 25 + 20 + 20 =
210 weeks
Task 5.14 : 20 weeks
==> HW total 25 weeks
==> FW total 230 weeks
- AAD estimnates (okt 2018)
AAD FW : FW Application : 4.8 FTE = 4.8 * 40 = 192 weeks
FW Commissioning : 35 weeks --> 192 + 35 = 230 weeks
. I/O 20
. BSP 30
. ADC 30
. Fsub 30 (~10 critical, ~30 oversampled)
. BF 20
. XC 20
. TBB 60
. FW for control 40
Sum: 20 + 30 + 30 + 10 + 20 + 20 + 60 + 40 = 230 with critical Fsub
weeks AAD task description
10 T5.1 Maintain FW development environment
25 T5.2a UniBoard2 board hardware
10 20 I/O T5.2b UniBoard2 test firmware (enable mass production of UniBoard2)
20 30 BSP T5.3a UniBoard2 board support package
T5.3b SW driver for GP
10 T5.4 Network access via 10GbE (support ARP and ping)
20 BF/TBB T5.5 Ring access
20 T5.6 Detailed design SDP firmware
15 30 ADC T5.7 ADC input and timestamp
10 10 Fsub T5.8 Subband filterbank (Fsub, critically sampled, calibrated subbands, SST)
15 T5.9 Subband correlator (XC, one subband per 1 s integration)
15 20 BF T5.10 Beamformer
25 60 TBB T5.11 Transient buffer (TB, ADC data, subband data)
20 TBB T5.12 Transient detection (TDET)
20 T5.13 Subband offload (SO) for AARTFAAC2.0
20 35 Comm T5.14 Station test and verification (using unb2c_sdp_station)
The AAD estimates for I/O + BSP + ADC + Fsub + BF + TBB + FW control =
20 + 30 + 30 + 10 + 20 + 20 + 60 + 40 = 230 weeks with critical Fsub
These tasks include detailed design and TBB includes TB + TDET.
JH,PD already spend about 30 weeks in 2019.
==> FW total 230 weeks, does not include
- PDR work on SDP in relation to rest if Station and LOFAR2.0 for ADD and SDP work package
management (EK spend about 30 weeks for this in 2019)
- Subband offload for AARTFAAC2.0 (about 20 weeks)
- Comparision
The 'corrected' 2019 AAD estimate is:
2019 AAD estimate = 2018 AAD estimate - (planned 2019 work JH,PD)
+ (unplanned AARTFAAC2.0)
= 230 - 30 + 20 = 220
2019 PDR estimate = 230
So the difference is -10 weeks, which means that the 2019 PDR is about -10 / 230 = 5 % more
time then the 2018 AAD estimate.
applications/lofar2/doc/prestudy/station2_sdp_icd.txt
+ 83
− 9
View file @ 94103ebe
STAT L2 ICDs for SDP
- L1 ICD 11108 STAT-NW
- L1 ICD 11109 STAT-CEP
- L2 ICD 11211 SC-SDP
- L2 ICD 11207 RCU2S-SDP
- L2 ICD 11209 STF-SDP
- L2 ICD 11218 SDP-STCA
ICD interface types:
m - Mechanical (structural, loading, tooling, etc)
f - Fluid (pneumatic, cooling, heating, condensate, fuels, lubricants, waste, exhaust, feedstocks etc)
......@@ -11,6 +21,10 @@ ICD interface types:
h - Human-Machine Interface (special combination of some of the above)
###################################################################################################
# L1 ICD 11108 STAT-NW
UDP link control
- flow control = end-to-end
- congestion control = peer-to-peer within the network
......@@ -27,6 +41,18 @@ UDP link control
> ping <IP address> # to find MAC address for IP address ?
###################################################################################################
# L1 ICD 11109 STAT-CEP
Included:
A) Beamlet data
B) Transient buffer read out
Not included:
. SST, BST, XST, because these are for monitoring and calibration, not for science data
. Subband offload for AARTFAAC2.0 will have own EICD
LFAA-CSP_Low : OSI (Open Systems Interconnection) layers
7 Application : Not applicable, this is the level where the STAT and CEP products each perform their
......@@ -70,17 +96,9 @@ LFAA-CSP_Low : OSI (Open Systems Interconnection) layers
- Ethernet standard [IEEE Std 802.3-2015], 40 GbE
1 Physical :
- Ethernet standard [IEEE Std 802.3-2015], 40 GbE
L1 ICD 11109 : STAT - CEP
. Beamlet data
. Transient buffer read out
Not included:
. SST, BST, XST, because these are for monitoring and calibration, not for science data
. Subband offload for AARTFAAC2.0 will have own EICD
STAT-CEP Beamlet data interface:
A) STAT-CEP Beamlet data interface:
- VERSION_ID 8b
. 2,3,4 for LOFAR1
......@@ -154,4 +172,60 @@ STAT-CEP Beamlet data interface:
- Data
. X, Y paired dual polarization beamlets
B) STAT-CEP Transient data read out
###################################################################################################
# L2 ICD 11211 SC-SDP
1) Uniboard2 board
a) I2C via PCC
b) actuators, sensors
2) Firmware
a) 1GbE per 4 FPGA / 10GbE at SCU
b) FPGA register access via Gemini Protocol/UDP/IPv4
c) FPGA register map:
- BSP : info, PPS, flash
- ring
- adc : JESD, WG, timestamp, input buffer, data buffer (DB), statistics (mean, power, histogram)
- Fsub : subband weights, SST
- XC : subband selection, XST
- BF : subband selection, beamlet weigths, BST, beamlet output header
- TB : recording, direct DDR4 access, reading
- TDET : setup, release, info
- SO : subband selection, subband offload header
d) Concepts
- firmware runs on array of FPGA[]
- all FPGA run the same firmware image, they can behave differently dependent on:
. their static location (node ID)
. the dynamic setup via M&C
- no need to be aware of UniBoard2 or that there are 4 FPGAs per UniBoard2
d) OPC-UA representation (by OPC-UA servers)
- arrays of signal inputs, subbands, beamlets, no need to be aware of FPGA[] array
- per device, there are devices for (fig 3.3.1-1):
. HBA analogue beamformer
. Station digital beamformer
. Subband correlator
. Transient buffer
. Transient detection
###################################################################################################
# L2 ICD 11207 RCU2S-SDP
###################################################################################################
# L2 ICD 11209 STF-SDP
###################################################################################################
# L2 ICD 11218 SDP-STCA
\ No newline at end of file
applications/lofar2/doc/prestudy/station2_to_do_erko.txt
+ 40
− 191
View file @ 94103ebe
*******************************************************************************
* Netherlandse Code of conduct for research integrety:
*******************************************************************************
Vijf principes:
- Eerlijkheid
- Zorgvuldigheid
- Transparantie
- Onafhankelijkheid
- Verantwoordelijkheid
*******************************************************************************
* SKA experience:
*******************************************************************************
......@@ -15,177 +28,6 @@
. analogue complex gain calibration (temperature dependent)
. beam shape tapering? (fixed)
*******************************************************************************
* LaTeX
*******************************************************************************
- \sigma \sqrt{}
- 4.15 \cdot 10^{15}
- M =
\left[ {begin{array}{cc}
1 & 2 & 3 & 4\\
5 & 6 & 7 & 8\\
\end{array} } \right]
*******************************************************************************
* Run RadioHDL with SVN
*******************************************************************************
echo "Uniboard trunk is selected"
export SVN=${HOME}/svnroot/UniBoard_FP7
#Setup RadioHDL environment for UniBoard2 and and new Uniboard1 applications
. ${SVN}/RadioHDL/trunk/tools/setup_radiohdl.sh
# Support old UniBoard environment (including Aarfaac and Paasar)
. ${SVN}/RadioHDL/trunk/tools/setup_unb.sh
*******************************************************************************
* Run RadioHDL with GIT
*******************************************************************************
> cd ~/git/hdl
> . ./init_hdl.sh # setup development environment for hdl/
# hdl/libraries, hdl/boards and hdl/applications are developed simultaneously and therefor in one git hdl/ repository
# automatically also sources ../radiohdl/init_radiohdl.sh if necessary
> compile_altera_simlibs unb1 # creates build/unb1/hdl_libraries_ip_stratixiv.txt
# creates build/quartus/<tool version> simulation models that need to be moved to /home/software/modelsim_altera_libs
> generate_ip_libs unb1 # creates build/unb1/qmegawiz/
# creates build/unb1/quartus_sh --> empty dir, why is it there?
> quartus_config unb1 # creates build/unb1/quartus/<hdllib libraries> for synthesis
# creates build/unb1/quartus/technology_select_pkg.vhd
> modelsim_config unb1 # creates build/unb1/modelsim/<hdllib libraries> for simulation
# creates build/unb1/modelsim/modelsim_project_files.txt for Modelsim commands.do
# creates build/unb1/modelsim/technology_select_pkg.vhd
> run_qsys unb1 unb1_minimal_qsys
*******************************************************************************
* GIT workflow
*******************************************************************************
difftool ?
mergetool ?
* Pro Git book by Scott Chacon: https://git-scm.com/book/en/v2
* YouTube : David Mahler part 1,2,3
Part 1:
# After GIT install
git version
git config --global http://user.name "EricKooistra"
git config --global http://user.email "erkooi@gmail.com"
git config --list
touch .gitignore # create .gitignore if it does not already exist
.gitignore # file with working tree dirs and files to ignore, must also be commited
# To start a repo
cd ~/git
git init # start new repo at this dir, creates .git/
git clone # get and start with existing repo
git clone git@git.astron.nl:desp/args.git
git status # what is in stage area and what is modified
Three areas:
* working tree # local directory tree
| git add
v
* staging area (index)
|
v git commit
* history # .git repository with entire commit graph
# To use a repo
git add <dir>/<file> # add to stage area, set for commit. Cannot add empty dir, need empty file in it
git add . # add all new and modified to stageing area
git diff # diff between file in working tree and staging area
git diff --staged # diff between file in staging area and history
git rm <filename> # remove file from working tree and stage the delete
git checkout -- <filename> # revert a working tree change
git reset # clear stage area
git reset HEAD <filename> # revert staged change
git log -- <filename> # show history of file
git checkout <version hash> -- s2 # retrieve file from history into staged area and working tree
Part 2:
git commit -m "" # commit what is in stage area
git commit -a -m "" # add to stage area and commit what is in stage area
alias graph="git log --all --decorate --oneline --graph"
git branch <branch name> # creat branch
git branch # show branches
git checkout <branch name> # change working tree and stage area to branch
git checkout master
git merge <branch name> # Fast forward merge of branch name to master if there is a direct path
# by moving master to branch name, this is when there have been no updates
# on the master branch since the branch was created.
# Three way merge combine the differences of the branch and the master
# compared to their common version, this can lead to merge conflicts if
# changes on both branches occur at same parts of a file.
git branch --merged # show branches that ghave been merged to master
git branch -d <branch name> # remove branch
git checkout <commit hash> # detached HEAD because it points to a version not a branch
git branch <branch name> # start a branch from the commit hash, HEAD is attached again
# Stash area to store working tree
git stash save "comment" # store working tree and stage area to get a clean
git stash list # show all stashes
git stash apply <label> # restore stash
git stash apply # restore last stash
Part 3: Remote repositories (Github, Gitlab, Bitbucket, ...)
create repo on Github
http://README.md # md = mark down
git clone <url:.../<repo name>.git> # get copy from url
cd <repo name>
git config --local http://user.name "EricKooistra"
git config --local http://user.email "erkooi@gmail.com"
git remote # origin
git remote -v # full url
# To align with remote repo
# update from remote
git status # shows also origin/master, but not live
git fetch origin
git status # shows also origin/master, now with latest remote
git merge origin/master
git pull # get latest from remote repo, combines fetch and merge
# upload to remote
git push
git push origin master # put local repo to remote repo
# On Github fork is a copy of the a repo in Github to get a repo on your account
git clone <url of fork> # get copy of fork repo, will be origin
git remote add upstream <url of original repo on Github> # will be upstream
git fetch upstream
git status
# commit local change on branch
# git push origin <branch name> # push to my fork repo on Github
# pull request on Github
# delete branch and fetch npstream if the pull request was accepted
git remote remove <remote name> # remove a remote repo
*******************************************************************************
* Confluence:
*******************************************************************************
- space tools menu links onder om secties the ordenen.
*******************************************************************************
* RadioHDL
*******************************************************************************
Open issues:
- Central HDL_IO_FILE_SIM_DIR = build/sim --> Project local sim dir
- avs_eth_coe.vhd per tool version? Because copying avs_eth_coe_<buildset>_hw.tcl to $HDL_BUILD_DIR
copies the last <buildset>, using more than one buildset at a time gices conflicts.
*******************************************************************************
* To do:
......@@ -220,6 +62,8 @@ Open issues:
- Use GIT
- Understand AXI4 streaming (versus avalon, RL =0)
. wrap between AXI4 - Avalon for MM and DP
- Global reset only on sosi info not on sosi data
- Use ARGS to define peripherals
. check docs and article
- Learn how gmi_minimal HDL code works to prepare for porting to unb2b_minimal_gmi
......@@ -232,8 +76,6 @@ Open issues:
. cause of reboot (power cycle, overtemperature, ...)
- RCU2S-SDP signal input allocation:
Decided:
. LBA and HBA on seperate RCUs and also on seperate subracks and on independent rings, so SDP is independent
......@@ -260,7 +102,6 @@ Open issues:
*******************************************************************************
* System engineering:
*
*******************************************************************************
- Requirements,
......@@ -269,6 +110,7 @@ Open issues:
Requirements map to functions at any level
- Products
- ICDs
- Roles
Polarion:
- Maintain hierarchy of functions and link them to products
......@@ -482,17 +324,20 @@ STIN
*******************************************************************************
- H4
. SDP dynamisch bereik figure versimpelen + formule + simuleer processing gain van FFT voor real input
. SDP dynamisch bereik figure versimpelen + formule + simuleer processing gain van FFT voor real
input
. Check timing dither with PK, because this would require detailed timing control for SDP and RCU2
. In SDP JESD details maybe too detailed design, purpose here is to explain JESD in own words to understand it without
having to read references.
. In SDP JESD details maybe too detailed design, purpose here is to explain JESD in own words to
understand it without having to read references.
. Check that +48 v is mentioned (not -48 V)
. io_ddr in FN beamformer uses 26 M9K waarvan 10 in de IP. De IP gebruikt ook 1 M144K (~= 16 M9K). De FN beamformer gebruikt 1 DDR3 module.
--> voor twee DDR modules zou je ongeveer (26 + 10) * 2 = 72 block RAM verwachten, terwijl TBB-base in LOFAR1 maar 6 gebruikt volgens MP
syntesis report.
. io_ddr in FN beamformer uses 26 M9K waarvan 10 in de IP. De IP gebruikt ook 1 M144K (~= 16 M9K).
De FN beamformer gebruikt 1 DDR3 module.
--> voor twee DDR modules zou je ongeveer (26 + 10) * 2 = 72 block RAM verwachten, terwijl
TBB-base in LOFAR1 maar 6 gebruikt volgens MP syntesis report.
. Timimg fixed op interne sync of op single or periodic timestamp set by SC.
- let SDP send event for each interne sync, to help SC align its time critical control and monitoring
- possibly use linear interpolation for BF weights to relieve SC from tigth 1 Hz control and to allow fast tracking of satellites
- let SDP send event for each interne sync, to help SC align its time critical M&C
- possibly use linear interpolation for BF weights to relieve SC from tigth 1 Hz control and to
allow fast tracking of satellites
- define timestamp as 32b seconds and 32b blocks within second
......@@ -501,9 +346,11 @@ STIN
PK:
. Write design decision on dithering (meant to make ADC effectively more linear):
1) none
2) level using additative CW --> suppress RFI harmonics already at ADC by making the ADC sampling more linear by crossing more levels
3) time using delays --> does this work anyway, because the digital BF already suppresses RFI from all directions in which it does not point.
The dithering makes that it looks like the RFI comes from all directions, this does not help, does it?
2) level using additative CW --> suppress RFI harmonics already at ADC by making the ADC
sampling more linear by crossing more levels
3) time using delays --> does this work anyway, because the digital BF already suppresses RFI
from all directions in which it does not point. The dithering makes that it looks like the
RFI comes from all directions, this does not help, does it?
PDR:
- Polarization correction at station via subband weights, via BF weights?
......@@ -516,11 +363,12 @@ PDR:
- TB size
- S_sub_bf = 488
- Subband weights update rate > 10 min is sufficient?
- There are >= 488 independent Station beams per polarization. This also implies that the polarizations can have independent
Station beams, so different frequencies and pointings. In LOFAR 1.0 a subband and a beamlet are defined as a X,Y tuple.
For LOFAR 2.0 the beamlets are still output as tuples but the X and Y are treated independently, so beamlet index i for X
may use a different subband frequency and pointing than beamlet index i for Y. Therefore in LOFAR 2.0 define a subband and
a beamlet per single polarization.
- There are >= 488 independent Station beams per polarization. This also implies that the
polarizations can have independent Station beams, so different frequencies and pointings. In
LOFAR1 a subband and a beamlet are defined as a X,Y tuple. For LOFAR2.0 the beamlets are still
output as tuples but the X and Y are treated independently, so beamlet index i for X may use
a different subband frequency and pointing than beamlet index i for Y. Therefore in LOFAR2.0
define a subband and a beamlet per single polarization.
- How to continue SE after PDR:
. Update ADD with OAR answers and internal remarks from team
. Mapping of function tree, L2 requirements and L3 products in ADD
......@@ -528,7 +376,8 @@ PDR:
. Add station functions from ADD to function tree in Polarion?
- what is the purpose of the function tree, does it provide a check list?
- how deep will the function tree go, till the lowest level products?
. Do we need more SE views then that we already have with states/modes, requirements, functions and products?
. Do we need more SE views then that we already have with states/modes, requirements, functions
and products?
. ICDs
. L4 requirements?
. L4 products?
......
libraries/io/tr_10GbE/src/vhdl/tr_10GbE.vhd
+ 10
− 9
View file @ 94103ebe
......@@ -229,17 +229,18 @@ BEGIN
);
---------------------------------------------------------------------------------------
-- TX: FIFO: dp_clk -> tx_clk and with fill level so we can deliver packets to the MAC fast enough
-- TX: FIFO: dp_clk -> tx_clk and with fill level/eop trigger so we can deliver packets to the MAC fast enough
---------------------------------------------------------------------------------------
gen_dp_fifo_fill_dc : FOR i IN 0 TO g_nof_macs-1 GENERATE
u_dp_fifo_fill_dc : ENTITY dp_lib.dp_fifo_fill_dc
gen_dp_fifo_fill_eop : FOR i IN 0 TO g_nof_macs-1 GENERATE
u_dp_fifo_fill_eop : ENTITY dp_lib.dp_fifo_fill_eop
GENERIC MAP (
g_technology => g_technology,
g_data_w => c_xgmii_data_w,
g_empty_w => c_tech_mac_10g_empty_w,
g_use_empty => TRUE,
g_fifo_fill => g_tx_fifo_fill,
g_fifo_size => g_tx_fifo_size
g_technology => g_technology,
g_use_dual_clock => TRUE,
g_data_w => c_xgmii_data_w,
g_empty_w => c_tech_mac_10g_empty_w,
g_use_empty => TRUE,
g_fifo_fill => g_tx_fifo_fill,
g_fifo_size => g_tx_fifo_size
)
PORT MAP (
wr_rst => dp_rst,
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment