On Wed, 22 Jun 2016, 03:53 Adam Isaacson, <aisaac...@ska.ac.za> 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 <jackhick...@gmail.com> > 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 bleeding edge, where things are, well, bloody. >> >> Cheers, >> >> Jack >> >> On Tue, 21 Jun 2016 at 06:06 Andrea Melis <andrme...@gmail.com> wrote: >> >>> Hi Jack, >>> >>> how are you doing? >>> >>> I would ask you a question, I am interested in developing projects fully >>> in VHDL into the ROACH2 (equipped with ADC 5GS and mezzanine cards SFP+), >>> is available the VHDL code for the various blocks of the CASPER library? Is >>> the code generated after the compiling? >>> >>> In particular I would need a “template” VHDL containing especially the >>> I/O parts like the ADCs and the 10 Gbe outputs blocks, in order to have a >>> VHDL skeleton as a starting point for whatever digital signal processing >>> on-chip. >>> >>> Please let me know whether it already exists or whether it can be >>> technically done, I thank you in advance >>> >>> Cheers >>> >>> >>> Andrea >>> >> > > > -- > > Adam Isaacson > > DBE: FPGA Engineer > > SKA-SA > > 3rd Floor > > The Park > > Park Road > > Pinelands > > 7405 > > > Tel: +27215067300 (W) > > Fax: +27215067375 (W) > > Cell: +27825639602 >
