Hi John, Jack, Benjamin and Mitch, Thanks for all this information. I was just thinking of your RFSOC parameterized yellow block yesterday Mitch. I am happy to have your expertise too. We are not using Vitis for now (we are creating our own DFX partition/static shell), but we will have the capability to do so in the future.
John, we are also using the XDMA for control messages. We are using the 100GbE core for our AXI streaming for now - tested at 98.8Gbps (not with our tool flow setup yet) in its own project. I prefer to keep data and control separate for debugging, unlike SKARAB. I will be in touch. Thanks for sparking all this interest, Jack. Kind regards, Adam On Wed, 06 Oct 2021, 4:48 AM Mitch Burnett, <mitch.burn...@byu.edu> wrote: > Hi Jack, Adam, Benjamin, > > I hope you do not mind me chime in a bit on the block diagram/IPI/RTL > discussion a bit. As you point out Jack, handling IPI/block designs in the > toolflow was clunky. But, adding RFSoC to the toolflow to fully support the > platform for any board with the part and add the RFDC yellow block required > IPI and Vitis. I believe that the way this was addressed removes much of > that clunkiness that also provides a a general reuse framework for the > development of an HBM yellow block and any other IP that we may want to > support that is best targeted by that flow. > > A little about how this is done and what it looks like: A block design is > created and persistent through the life time of the middleware stage of the > toolflow. This allows yellow blocks to now access the block design, > instance the target IP, apply parameters, and expose its interface to the > rest of casper and the design. Collecting parameters form the mask and > applying them to IPI is done by a mapping or proxy-like object approach > were the parameters presented/gathered by simulink are parsed into a python > class that the yellow block can use as it needs to make its decisions but > is also automatically parsed out to create the required tcl command for the > IPI portion of the design. To support this there are added methods to > follow much of what was already a familiar way these generator objects > worked to hopefully provide a consistent developer framework. From here, > supporting Vitis extended off this and works very similar by adding the > required classes/methods but also following other conventions in the > toolflow that make it familiar and extendable. > > If you think this may help you I would be interested in hearing your > thoughts and am happy to get together to go over more of the details and > help in any way I can. > > Best, > > Mitch > > On Oct 5, 2021, at 12:02 PM, Adam Isaacson <aisaac...@sarao.ac.za> wrote: > > Hi Benjamin and Jack, > > Nice to hear from you Benjamin :). Yes, I agree that IPI is much easier to > use than RTL. We are targeting the toolflow to generate a Block Diagram > with the HBM integrated within it. The idea is to connect and test in > Vivado first. > Then create a tcl script based on the block diagram and then get the > toolflow to generate the tcl script for us. We will need to parameterise > our yellow block to be inline with the IPI generation, so that is > cumbersome, but once it is > finalised then it won't be too much effort - I hope! > > I will definitely be in touch. Thanks, Benjamin, this is useful > information. What were you using the HBM for? Are you continually writing > and reading? Are you using Random memory access? Are you using > sequential memory access? How are you testing the HBM? > > Kind regards, > > Adam > > On Tue, Oct 5, 2021 at 12:55 PM Jack Hickish <jackhick...@gmail.com> > wrote: > >> Thanks Benjamin -- I've had a look at the IPI stuff and it seems like it >> should be straightforward to use. I just find dealing with IPI in the >> toolflow much clunkier than RTL. But between your work and Adam/Grant's I'm >> sure it shouldn't take too long to get something working. >> I hadn't thought about the XDMA integration -- I don't really have a >> requirement for that but i can think of some handy use cases. Thanks for >> bringing it to my attention. >> >> Cheers >> Jack >> >> On Tue, 5 Oct 2021 at 05:41, Benjamin H Hlophe <hect...@kutleng.co.za> >> wrote: >> >>> Hi Adam, >>> >>> I found its much easier using IP Integrator to use the HBM (It has a lot >>> of easier configuration on IPI). >>> >>> I did a design connecting the HBM to PCIe on the VCU128. >>> >>> Without a single line of HDL code just configuring the IP Integrator and >>> the memory map. >>> >>> It works very well also Xilinx has the PCIe drivers for bridging the HBM >>> to be visible to the XDMA or QDMA. >>> >>> <55237d0c-db3d-4702-8e97-429a8c7e1478.png> >>> >>> On Vivado 2020.1 if you just make these connections and a few >>> configurations on the HBM IP you will get it working. >>> >>> Regards, >>> Benjamin Hlophe >>> <http://www.aerospacetechweek.com/register> >>> <Website Description automatically generated with low confidence.png> >>> <http://www.aerospacetechweek.com/register> >>> >>> >>> >>> On 04 Oct 2021, at 22:55, Adam Isaacson <aisaac...@sarao.ac.za> wrote: >>> >>> >>> Great, I will be in touch :). >>> >>> Kind regards, >>> >>> Adam >>> >>> On Mon, 04 Oct 2021, 10:10 PM Jack Hickish, <jackhick...@gmail.com> >>> wrote: >>> >>>> That would be spectacular! >>>> >>>> Thanks Adam! >>>> >>>> On Mon, 4 Oct 2021, 21:06 Adam Isaacson, <aisaac...@sarao.ac.za> wrote: >>>> >>>>> Hi Jack, >>>>> >>>>> This is exactly what I have been tasked with. I have a meeting with >>>>> Grant Hampson (CSIRO) who has the HBM working in RTL to find out more >>>>> information on the 15th Oct. >>>>> >>>>> Maybe we could work together on this? >>>>> >>>>> Kind regards, >>>>> >>>>> Adam >>>>> >>>>> >>>>> >>>>> On Mon, 04 Oct 2021, 8:59 PM Jack Hickish, <jackhick...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi CASPERites, >>>>>> >>>>>> Hope everyone is keeping well. >>>>>> >>>>>> It looks like I'm imminently going to have to dip my toe (and then >>>>>> probably my entire self) in the world of HBM, in order to make some >>>>>> reasonably large data transposes / packet construction buffers. (For the >>>>>> interested, I'm using a VU37P AlphaData ADM-PCIe-9H7). >>>>>> >>>>>> Ultimately I'm probably going to try and make a yellow block with an >>>>>> interface that looks vaguely like a block ram, or the QDR transpose block >>>>>> of old. >>>>>> >>>>>> Before I start, I thought I'd shout out in case anyone had already >>>>>> looked at making a yellow block like this, and/or felt the urge to share >>>>>> any of their hard-won HBM wisdom. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jack >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "casper@lists.berkeley.edu" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to casper+unsubscr...@lists.berkeley.edu. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3Dy5ey26oR-yUe%2BkVKdCqegRV4q7K1dnzgw1WkiqoXCfQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3Dy5ey26oR-yUe%2BkVKdCqegRV4q7K1dnzgw1WkiqoXCfQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "casper@lists.berkeley.edu" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnE7w%2B_GSms43QW_q6FFsZcxLHaw8X7OGVcFByybSA8APg%40mail.gmail.com >>>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnE7w%2B_GSms43QW_q6FFsZcxLHaw8X7OGVcFByybSA8APg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "casper@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmP7sSp%2BQurWFLPJd3yztLUv5PocWtTi65PZ9ZRyA426Q%40mail.gmail.com >>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmP7sSp%2BQurWFLPJd3yztLUv5PocWtTi65PZ9ZRyA426Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHMaeW593tmCUde4YMdvEpa1UQXdfQ2UmL0jwZZTmCM_w%40mail.gmail.com >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHMaeW593tmCUde4YMdvEpa1UQXdfQ2UmL0jwZZTmCM_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/2999F697-163D-4525-84D4-2336A1ECAAE9%40kutleng.co.za >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/2999F697-163D-4525-84D4-2336A1ECAAE9%40kutleng.co.za?utm_medium=email&utm_source=footer> >>> . >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSn1jnC-dfGVcROiaT%3DJXF-VkXYEtp_YNfNvoguUSKFYhw%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSn1jnC-dfGVcROiaT%3DJXF-VkXYEtp_YNfNvoguUSKFYhw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnFg8UB5ZPn5eq0PcDoLY7ZgNTDSKbaKT7-3G5VzqxFJ5Q%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnFg8UB5ZPn5eq0PcDoLY7ZgNTDSKbaKT7-3G5VzqxFJ5Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/EAE04FEA-5E62-4E6B-BEC0-111E438E4E03%40byu.edu > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/EAE04FEA-5E62-4E6B-BEC0-111E438E4E03%40byu.edu?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHORQBTSGAd1GYbmetso-WNx%3DUJgMsNHFsty%2B_TSpAN6A%40mail.gmail.com.
