lerwys / bpm-sw-old-backup Goto Github PK
View Code? Open in Web Editor NEWMain repository for the BPM firmware and software
License: GNU Lesser General Public License v3.0
Main repository for the BPM firmware and software
License: GNU Lesser General Public License v3.0
============================================================================== Repository containing the Beam Position Monitor FPGA firmware and software. ============================================================================== Folder Hierarchy organization: * | |-- hdl: | | HDL (Verilog/VHDL) cores related to the BPM. | | | |-- ip_cores: | | | Third party reusable modules, primarily Open hardware | | | modules (http://www.ohwr.org). | | | | | |-- etherbone-core: | | | Connects two Wishbone buses, either a true hardware bus | | | or emulated software bus, through Ethernet. | | |-- general-cores (fork from original project): | | General reusable modules. | | | |-- modules: | | | Modules specific to BPM hardware. | | | | | |-- custom_common: | | | Common (reusable) modules to BPM hardware and possibly | | | to other designs. | | |-- custom_wishbone: | | Wishbone modules to BPM hardware. | | | |-- platform: | | Platform-specific code, such as Xilinx Chipscope wrappers. | | | |-- sim: | | Generic simulation files, reusable Bus Functional Modules (BFMs), | | constants definitions. | | | |-- syn: | | Synthesis specific files (user constraints files and top design | | specification). | | | |-- testbench: | | Testbenches for modules and top level designs. May use modules | | defined elsewhere (specific within the 'sim" directory). | | | |-- top: | Top design modules. | |-- sw: | | Software related to interfacing the BPM carrier board with a PC | | via PCIe. | | | |-- drivers: | | Linux Kernel code for device drivers | | | |-- include: | | Header files for device structures and definitions | | | |-- lib: | Utilities and API functions exported by the drivers | |-- embedded-sw (based on the original project by Alessandrio Rubini | | and others <http://www.ohwr.org/projects/wrpc-sw>): | | | | Embedded software that runs inside the LM32 softcore processor. | | | |-- arch: | | Architecture specific code, like linker scripts and boot code. | | | |-- boards: | | Board specific parameters and initialization. | | | |-- dev: | | Device specific code, such as UART, GPIO and DMA interfaces | | | |-- include: | | | General headers, mostly API device headers. | | | | | |-- hw: | | | Device specific registers and structures. This definitions | | | are included by the more general headers located inside | | | the "include" top directory. | | | | | |-- memmgr: | | Memory pool for "dynamic" allocated memory. | | | |-- lib: | | Utilities and general functions, such as the memmgr subsystem | | and a printf-like function. | | | |-- tests: | | Folder dedicated to software testing. | | | |-- tools: | | General tools for generating RAM loadable file by the firmware | | FPGA. ============================================================================== Cloning this repository: This repository makes use of git submodules, located at 'hdl/ip_cores' folder: hdl/ip_cores/general-cores hdl/ip_cores/etherbone-core To clone the whole repository use the following command: $ git clone --recursive git://github.com/lerwys/bpm-sw.git (read only) or $ git clone --recursive [email protected]:lerwys/bpm-sw.git (read+write) For older versions of Git (<1.6.5), use the following: $ git clone git://github.com/lerwys/bpm-sw.git or $ git clone [email protected]:lerwys/bpm-sw.git $ git submodule init $ git submodule update To update each submodule within this project use: $ git submodule foreach git rebase origin master ============================================================================== Simulation instructions: Go to a testbench directory. It must have a top manifest file: cd /hdl/testbench/path_to_testbench Run the following commands. You must have hdlmake2 command available in your PATH environment variable. Create the (ISim) simualation makefile $ hdlmake2 --make-isim Compile the project $ make Create the simulation executable ELF file $ make fuse TOP_MODULE=<top_level_testbench_module_without_the_extension> Execute the simulation with GUI and aditional commands $ ./isim_proj -view wave.wcfg -tclbatch isim_cmd -gui ============================================================================== Synthesis instructions: Go to a syn directory. It must have a top manifest file: cd /hdl/top/path_to_top_design Run the following commands. You must have hdlmake2 command available in your PATH environment variable. Create the synthesis makefile and an ISE project $ hdlmake2 --make-ise --ise-proj Compile the source files locally $ make local Load the generated .bit file with iMPACT or other tool $ impact ============================================================================== Known Issues: wb_fmc150/sim/: This folder containts behavioral simulation models for memories (ROMs). However, the xilinx initialization file (.mif) paths are absolute to a specific machine! You either have to change the path to match your machine or figure a way to specifies a relative path (specifiying only the name of the mif file does not work as the simulator is not called within this folder). Try a relative path based on the simulation folder.
It would be nice and very useful to support etherbone core from ohwr repository (http://www.ohwr.org/projects/etherbone-core).
By doing this, "real " testing could be done easily and scripts could be set up for
executing them automatically.
There is an issue regrading the sampling the data from the ISLA216 with the IDDR primitive. There needs to be an investigation to why this happens, but the solution is very simple...
Consider removing it or improving this part of the code
We should always test our designs before committing it!
/home/lerwys/Repos/bpm-sw-test-pcie/hdl/top/pcie/top_ml605.vhd" Line 183: Formal port/generic <rst_act_low> is not declared in <bpm_pcie_ml605>
There is a need to have multiple acquisition paths acquiring data simultaneous,
in a multiplexed way.
This is the traditional use case for our case, in that 1 AFC handles 2 BPMs signals.
So, at least we must decouple the acquisition paths from the 2 different BPMs
Implement a generic structure to support multiple instances of the fmc516 core, for example.
A simple way would be to create a generic identification structure in which the drive functions would poll in order to determine the correct core (which SPI, I2C, etcc) core to act
The ADC data channels 1 and 2 seems to be 1 clock out of sync with data channels 0 and 3.
Fix BUFIO/BUFR/BUFG clk generation in adc_clk.vhd entity, when 7SERIES FPGAs are selected
Especially with SPI 3-wire mode
"The CLOCK_DEDICATED_ROUTE=FALSE workaround is typically for source clocks which are not assigned to global clock input pins -- a completely different problem."
This could be the issue related to driving clock buffers from non GCLK pins.
The interface between the register core and the var_loadable/variable delay register is very confusing. Fix it!
Add them to wishbone_pkg.vhd in general cores?
This will allow selecting if we want the incoming clock to be routed to BUFIO and/or BUFR primitive. This effectively will clock an IDDR primitive with BUFIO and local FPGA logic with BUFR. Later, all data will be synch'ed to a global reference clock.
Cauting is taken to ensure safe passage from one clock domain to another with Async FIFOs
Then this git repository could be reference as a sub-module in bpm-sw
It should be Read-Only from the wishbone side and read as 0's!
It's just what it is described in the title...
Would it be viable to implement a mux in order to separate between etherbone packages and
other ones?
This is done for the white rabbit design. Specifically for the wr-core in which etherone packages
are redirect to etherbone and other messages to the rest of the FPGA fabric.
Study this possibility
These are the same primitive, but the former instructs the mapper to use only global clock nets
(GCLK pins). BUT, as we know, we need to use non global clock nets in order to use BUFIO/BUFR primitives.
This possibly causes the error:
"ERROR:Place:1119 - The I/O components "adc_clk1_p_i" and "adc_clk1_n_i" are the
P- and N-sides of a differential I/O pair. The component "adc_clk1_p_i"
needs to be placed in a IOBM site and component "adc_clk1_n_i" in the
adjacent IOBS site within the same I/O tile. The following issue has been
detected:
Some of the logic associated with this structure is locked. This should cause
the rest of the logic to be locked. A problem was found at site BUFR_X0Y3
where we must place IOB adc_clk1_n_i in order to satisfy the relative
placement requirements of this logic. It is not legal to place this component
in this site. "
The default behavior of the module is to clock the data with 2 clocks. In this way,
we have to sync the data of all 4 data chains to a single clock. By default, the first used clock will be used for this.
While perfomring simulation with DDR3 Xilinx Controller and DDR3 model the
"phy_init_done" signal from the controller is never asserted. Thus, causing
the simulation to hang forever
It is necessary o module to implement automatic delay calibration, as it is not pratical nor
robust to manually input them.
There is a need to reset the ADCs and the clock output clock reset (for synchronization of
multiple ADC chips).
Also, they need to be software controllable.
There is a timing violation in that 1.4 acquisition window is not sufficient for IDDR, as reported
by timing analyzer.
Calibrate the delay from clock and data to match them.
It is necessary a wishbone wrapper to Xilinx MIG generated core.
In this way, we can store the large ammounts of DSP data.
useful links:
http://www.xilinx.com/support/documentation/ip_documentation/mig/v3_92/ug406.pdf
http://www.xilinx.com/support/documentation/ip_documentation/ds186.pdf
http://www.ohwr.org/projects/ddr3-sp6-core/wiki
It would be better if the wishbone streaming interface could be more generic,
allowing data sizes of 16, 32, 64 or 128 bits wide. Moreover, the xwb_source and
xwb_sink modules wouls have to be modified.
There is a mix in this folder, as this synthesis test is not under development yet!
I think the best way to correct this is to create the synth test in the wb-fmc516-devel branch
and leave it untouched in the other ones.
It is necessary to cleanup the wb_acq_core and implement the missing features like
external data-driven triggered acquisitions
It is necessary to improve and make a more generic approach to the FMC boards
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.