Hi, Wes,
Just to clarify, some device offsets are hardcoded in HDL and/or the system.mhs
template, but other device offsets (e.g. software registers and shared BRAMs)
are dynamically generated by the toolflow as part of casper_xps.
In any case, your main point is spot on: the core_info.tab file is
informational only; it reflects the device offsets generated for a given build.
Modifying core_info.tab does not have any effect on the actual device offsets.
The core_info.tab file is stored in the BOF file along with the FPGA bitstream.
FWIW, I've written a BOF file parser that can extract the core_info.tab file
information from a given BOF file (optionally compressed). The code, which
includes a fair amount of reverse engineered BOF format documentation in the
comments, can be found here:
git clone http://astro.berkeley.edu/~davidm/rb-bof.git
It includes a script, readbof.rb, that will output the core info file for a
given bof:
$ readbof.rb roach2_fengine_2013_Sep_24_2154.bof.gz
sys_board_id 304
sys_rev344
sys_rev_rcs384
sys_scratchpad 3c4
sys_clkcounter 3 104
adc16_controller 32 9000
sfp_gpio_data_in 364
sfp_gpio_data_out 3600044
sfp_gpio_data_oe 3600084
sfp_gpio_data_ded 36000c4
sfp_mdio_sel 3600104
sfp_op_issue 3600144
sfp_op_type3600184
sfp_op_addr36001c4
sfp_op_data3600204
sfp_op_result 3600244
sfp_op_dbg 3600284
sfp_op_dbg136002c4
ctmode 3 1004
delay_03 10001004
[snip]
The first column is the device name, the second column is some flags (almost
always 3 meaning read/write), the third column is the hexadecimal device offset
(in bytes), and the fourth column is the hexadecimal device length (in bytes).
Dave
On Oct 21, 2013, at 11:31 PM, Wesley New wrote:
Hi Ross,
The coreinfo.tab file serves only to tell borph there the registers are
located, so changing it would only give borph the wrong mapping. These
registers are hard-coded in the HDL in the sys_block. Why do you need to
change these addresses?
To change them you would need to modify the HDL and the coreinfo.tab (if you
wanted access to them, by name, from borph) and then ensure that the
BASE_ADDR and HIGH_ADDR parameters are set correctly. Be aware that this
might cause multiple devices to be mapped to the same space and go BOOM!
Probably only when you try to access that address ;)
Wes
Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za
On Tue, Oct 22, 2013 at 3:04 AM, Ross Williamson
rwilliam...@astro.caltech.edu wrote:
Hi Wes and all,
So the MMAP is working really quite well on a ROACH-1 - This question
is more my lack of understanding of the tool-chain.
Does anybody know how to fix the memory address for the various CASPER
brams and registers. I edited the core_info.tab inside the copied
XPS_ROACH_BASE and unchecked Copy base package but It still was
overwritten (I'm assuming this is in the system generator stage). I'd
rather not hack the top level core_info.tab so what would be the best
way to define the memory locations?
Ross
On Tue, Oct 15, 2013 at 4:48 PM, Ross Williamson
rwilliam...@astro.caltech.edu wrote:
Hi Wes,
Thanks - I got the MMAP up and running on a ROACH1 with those instructions.
R
On Tue, Oct 15, 2013 at 12:19 AM, Wesley New wes...@ska.ac.za wrote:
Hi Ross,
The steps should be outlined here.
https://casper.berkeley.edu/wiki/FPGA_Device_Driver_Memo
I am not sure if these steps work for ROACH1 and 2 but at least it is a
starting point.
Wes
Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za
On Tue, Oct 15, 2013 at 3:09 AM, Ross Williamson
rwilliam...@astro.caltech.edu wrote:
Hi All,
I know from the CASPER meeting that MMAP is available for the ROACH-1.
Are there any instructions anywhere on getting it up and running?
Best regards,
Ross
--
Ross Williamson
Research Scientist - Sub-mm Group
California Institute of Technology
626-395-2647 (office)
312-504-3051 (Cell)
--
Ross Williamson
Research Scientist - Sub-mm Group
California Institute of Technology
626-395-2647 (office)
312-504-3051 (Cell)
--
Ross Williamson
Research Scientist - Sub-mm Group
California Institute of Technology
626-395-2647 (office)
312-504-3051 (Cell)
