Re: [casper] MMAP on Roach-1
Hi Andrew and Wes, You've both convinced me to write a parser for the core_info.tab file - It's more transferable and less likely to screw things up. Cheers, Ross On Mon, Oct 21, 2013 at 11:58 PM, Andrew Martens and...@ska.ac.za wrote: Hi Ross 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? I am assuming that you want to write code that has the addresses hard-coded in some way. The best would be not to do this and have your code figure out the addresses from the core_info.tab file. If you must, build your design till the last stage (uncheck the EDK and ISE part). Then go hand edit the system.mhs file in the XPS_ROACH_BASE directory. You will find your registers and brams and where you they are on the bus. You can change where they are in the address space. When you are done, perform the final stage in the build (uncheck everything except the EDK, ISE part and build). Take some time to figure out how the address space is organised (most devices are hard-coded but the registers and shared brams are allocated address space within a specific area at compile time). If you have many yellow blocks you may have to also figure out how opb bridges work. Good luck Regards Andrew 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)
Re: [casper] MMAP on Roach-1
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)
[casper] Random failures on Compile
I'm in a rather frustrating situation where the casper tools will only compile in a seemingly random nature. I can load up a design that I know compiles into simulink and run it and I will get an error like the following: Error reported by S-function 'sysgen' in 'ccat_corr_lowbits/ADC0/Constant6': An internal error occurred in the Xilinx Blockset Library. There is nothing obviously wrong with the constant (and the whole .slx has compiled as is before) Shutting down and starting up matlab sometimes fixes the issue - trying to compiled a different .slx and then going back to the one that doesn't work sometimes fixes it (Sometimes does not) - I can screw around a whole day trying to get it to compile and the next day it works fine. Has anyone experienced this (pseudo) random compile problems and know of a good sequence to make a model compile again? Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Random failures on Compile
Hi Guys I have never experienced this. Can you provide the versions of the tool and OS you are running? Wes On 22 Oct 2013 20:51, Ryan Monroe ryan.m.mon...@gmail.com wrote: I've also experienced these. The most common cause seems to be a constant which is not sampled. I don't have a good rule, but sometimes when I start removing components on my design, it starts working, which shows me the element at fault. In general, placing a component which is known to work on its own into a larger system does not cause problems. Then there's also the times where I reduce the entire system to something trivial like a counter and it still happens. In that case I save copies of everything and reboot. Followed by anger management. On Oct 22, 2013 11:44 AM, Ross Williamson rwilliam...@astro.caltech.edu wrote: I'm in a rather frustrating situation where the casper tools will only compile in a seemingly random nature. I can load up a design that I know compiles into simulink and run it and I will get an error like the following: Error reported by S-function 'sysgen' in 'ccat_corr_lowbits/ADC0/Constant6': An internal error occurred in the Xilinx Blockset Library. There is nothing obviously wrong with the constant (and the whole .slx has compiled as is before) Shutting down and starting up matlab sometimes fixes the issue - trying to compiled a different .slx and then going back to the one that doesn't work sometimes fixes it (Sometimes does not) - I can screw around a whole day trying to get it to compile and the next day it works fine. Has anyone experienced this (pseudo) random compile problems and know of a good sequence to make a model compile again? Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)