Re: [casper] VHDL for ROACH2
On Wed, 22 Jun 2016, 03:53 Adam Isaacson, wrote: > Hi Jack and Andrea, > > I have tested the JASPER tool flow (matlab/python hybrid) on SNAP (no > hardware, just compiling) and we are in the process of testing on skarab. > We still have a lot more testing to do, so there may be bugs - you have > been warned. There is currently no support for ROACH2 or rather, this still > needs to be added at some point, as far as I am aware. The current CASPER > toolflow (matlab only and no python) supports ROACH2. > H'interesting - thanks for the setting me straight, Adam. There was a point, quite a long time ago, when jasper could at least compile tutorial 2 (ten gig Ethernet) for roach2. I thought this had been developed further - guess not! Mea culpa. J > @Andrea: Just so you know. We have are working with Optinum Solutions here > in South Africa and one of the tasks is to target the ROACH2 using > MathWorks HDL-Coder i.e. the HDL code will get generated from the MathWorks > environment. The problem with the MathWorks tools are that they are very > expensive and it is not always a viable option. If you are from an academic > institution then they offer really good deals. It may be worthwhile looking > at this. We hope to have ROACH2 targeted by the end of the year. The idea > is to compare HDL-Coder's code generation efficiency with our current > toolflow. > > @Andrea: A lot of effort has been spent on developing the CASPER and > JASPER toolflow. It really is a one-click toolflow, which when complete > generates the project files and programming files. These project files can > then be opened using the Vivado or ISE GUI just the same way as if you had > created the VHDL or verilog source yourself. > > Good luck! > > > Kind Regards, > > Adam > > On Tue, Jun 21, 2016 at 11:47 PM, Jack Hickish > wrote: > >> Hi Andrea, cc-ing maillist, since I don't think you're the only one to do >> (or want to do) this, >> >> What you are suggesting is absolutely technically possible, though (as >> much as I dislike simulink), I'd think really hard before going through >> with it. Note also, if you don't use the toolflow, you become completely >> responsible for managing the FPGA's memory-mapped devices, and will have to >> manually build a boffile if you want to use the katcp/borphserver >> programming environment. That said, others may already have done all the >> legwork for you. >> >> Anyway, with that cautionary note >> >> The VHDL (or verilog) for the various CASPER blocks is available as part >> of the various pcores of the roach2 base package -- >> https://github.com/casper-astro/mlib_devel/tree/master/xps_base/XPS_ROACH2_base/pcores >> . >> >> The instantiation of these interface blocks is performed by the toolflow >> at compile time, which generates a Xilinx EDK spec system.mhs top level >> file. If you want to find out how to instantiate these blocks yourself, >> using the toolflow as a guide, here is where you climb into the CASPER >> rabbit hole. >> >> There is an EDK template for a compile in the base package: for ROACH2 -- >> https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/system.mhs >> . >> In theory, if you strip out the #IF#s in this file, you'll have a top-level >> model description you can add stuff to -- but it still won't be in VHDL, >> even if the instantiated modules are. Constraints are in >> https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/data/system.ucf >> >> The toolflow adds to this template in a variety of ways -- >> * individual yellow blocks can add code via the MATLAB object-oriented >> infrastructure via the gen_mhs_ip and gen_ucf methods of the xps class -- >> eg. >> https://github.com/casper-astro/mlib_devel/tree/master/xps_library/%40xps_adc5g >> * or via an overridden gen_mhs_ip or gen_ucf -- eg. >> https://github.com/casper-astro/mlib_devel/blob/master/xps_library/%40xps_bram/gen_mhs_ip.m >> * or via all the #IF# statements in the base package system.mhs/system.ucf >> >> If (#IF#?) you want to dig through the matlab block classes, and >> system.mhs looking for what a particular yellow block *does* when it is >> instantiated, you probably could. But it will still be an EDK file, not >> vhdl. >> You could also fire up simulink, compile a design with appropriate yellow >> blocks in and then grab the system.mhs it generates and use that as a >> template. >> You could also look in an old ROACH2 testing repository where firmware >> was tested prior to being casperized -- >> https://github.com/ska-sa/roach2_test_gateware/blob/master/modules/toplevel/hdl/toplevel.v >> which >> is all VHDL/Verilog, but probably doesn't have all the modules you need. >> >> You might find the yellow block casper tutorial is useful in figuring out >> where various aspects of the interface code is instantiated. >> >> As a final note -- the latest version of the Vivado-based CASPER toolflow >> (aka, JASPER), includes (thanks, Adam & Wes in SA!) the abi
Re: [casper] VHDL for ROACH2
Hi Jack and Andrea, I have tested the JASPER tool flow (matlab/python hybrid) on SNAP (no hardware, just compiling) and we are in the process of testing on skarab. We still have a lot more testing to do, so there may be bugs - you have been warned. There is currently no support for ROACH2 or rather, this still needs to be added at some point, as far as I am aware. The current CASPER toolflow (matlab only and no python) supports ROACH2. @Andrea: Just so you know. We have are working with Optinum Solutions here in South Africa and one of the tasks is to target the ROACH2 using MathWorks HDL-Coder i.e. the HDL code will get generated from the MathWorks environment. The problem with the MathWorks tools are that they are very expensive and it is not always a viable option. If you are from an academic institution then they offer really good deals. It may be worthwhile looking at this. We hope to have ROACH2 targeted by the end of the year. The idea is to compare HDL-Coder's code generation efficiency with our current toolflow. @Andrea: A lot of effort has been spent on developing the CASPER and JASPER toolflow. It really is a one-click toolflow, which when complete generates the project files and programming files. These project files can then be opened using the Vivado or ISE GUI just the same way as if you had created the VHDL or verilog source yourself. Good luck! Kind Regards, Adam On Tue, Jun 21, 2016 at 11:47 PM, Jack Hickish wrote: > Hi Andrea, cc-ing maillist, since I don't think you're the only one to do > (or want to do) this, > > What you are suggesting is absolutely technically possible, though (as > much as I dislike simulink), I'd think really hard before going through > with it. Note also, if you don't use the toolflow, you become completely > responsible for managing the FPGA's memory-mapped devices, and will have to > manually build a boffile if you want to use the katcp/borphserver > programming environment. That said, others may already have done all the > legwork for you. > > Anyway, with that cautionary note > > The VHDL (or verilog) for the various CASPER blocks is available as part > of the various pcores of the roach2 base package -- > https://github.com/casper-astro/mlib_devel/tree/master/xps_base/XPS_ROACH2_base/pcores > . > > The instantiation of these interface blocks is performed by the toolflow > at compile time, which generates a Xilinx EDK spec system.mhs top level > file. If you want to find out how to instantiate these blocks yourself, > using the toolflow as a guide, here is where you climb into the CASPER > rabbit hole. > > There is an EDK template for a compile in the base package: for ROACH2 -- > https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/system.mhs > . > In theory, if you strip out the #IF#s in this file, you'll have a top-level > model description you can add stuff to -- but it still won't be in VHDL, > even if the instantiated modules are. Constraints are in > https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/data/system.ucf > > The toolflow adds to this template in a variety of ways -- > * individual yellow blocks can add code via the MATLAB object-oriented > infrastructure via the gen_mhs_ip and gen_ucf methods of the xps class -- > eg. > https://github.com/casper-astro/mlib_devel/tree/master/xps_library/%40xps_adc5g > * or via an overridden gen_mhs_ip or gen_ucf -- eg. > https://github.com/casper-astro/mlib_devel/blob/master/xps_library/%40xps_bram/gen_mhs_ip.m > * or via all the #IF# statements in the base package system.mhs/system.ucf > > If (#IF#?) you want to dig through the matlab block classes, and > system.mhs looking for what a particular yellow block *does* when it is > instantiated, you probably could. But it will still be an EDK file, not > vhdl. > You could also fire up simulink, compile a design with appropriate yellow > blocks in and then grab the system.mhs it generates and use that as a > template. > You could also look in an old ROACH2 testing repository where firmware was > tested prior to being casperized -- > https://github.com/ska-sa/roach2_test_gateware/blob/master/modules/toplevel/hdl/toplevel.v > which > is all VHDL/Verilog, but probably doesn't have all the modules you need. > > You might find the yellow block casper tutorial is useful in figuring out > where various aspects of the interface code is instantiated. > > As a final note -- the latest version of the Vivado-based CASPER toolflow > (aka, JASPER), includes (thanks, Adam & Wes in SA!) the ability to generate > an ISE-spec project (i.e., a ucf file and a top level verilog file) from a > simulink model. I don't know which yellow blocks are currently supported > for ROACH2, but if the ones you need work, this is probably the easiest > route to generating a template ISE project. If this is the way you want to > go, we should talk more somewhere. But you should be aware that you'll be > placing yourself on the
