RFDC needs to be on top-level of Simulink diagram

[jack-h]

The RFDC mask uses the sysgen block to determine hardware-specific capabilities. The original RFDC mask searched for the sysgen block from the same level in the model as the RFDC yellow block. This fails if the RFDC is in a subsystem.

I "fixed" this with realtimeradio/mlib_devel@6c67275

However, it turns out that unless the RFDC is on the top-level of the design, the RFDC .dtsi file never gets created. It's not really clear to me how this file gets generated, and whether the top-level requirement is fundamental or can be relaxed with a simple script change (maybe name to fullname in some generation script somewhere?).
If the latter, it would be good to implement this.

[jack-h]

@mitchburnett -- happy to implement this if you can point me in the right direction. (Or happy to close if you tell me this is harder to fix than it looks)

[mitchburnett]

The thinking was that yellow blocks supporting use of a device tree implement gen_dt_node(). Then in VitisBackend it would inherit from Toolflow and keep the frontend parsed information and iterate over the list of periph_objs and if that name is in the mmap it will call gen_dt_node() for the periph_obj. https://github.com/casper-astro/mlib_devel/blob/m2021a/jasper_library/toolflow.py#L1600

@jack-h, I am not super familiar with how simulink subsystem hierarchy works and gets tracked in the frontend and what information is available for reconciling that. You would know that better than me. But you are right, allowing the rfdc to be in a subsystem should be allowed. Thanks for getting this started with the mask updates!

If the change from name to fullname on that check is enough to match what is placed in the mmap this would be enough to get the dtsi fragment to generate. Short of testing it to see what explodes, I cannot think of any issues this will raise because the formatted string in the include directive where name is used to identify the fragment file is just a convention. All that matters is that whatver the name of the fragment file is, that it is included by that name in the top-level jasper.dtsi. That way when the device tree compiler runs it can include the fragments.

I would say give it this a shot at and if it doesn't work we should keep looking at this.

The underlying information that is placed in the device tree fragment and used to actually do any work by the rfdc driver is contained in the implementation of gen_rfdc_dt and not dependent on this name. The only thing the node generation should need is the information in the memory map. If this requirement will be true in general for anything wanting to support/use a device tree I was not sure. I do not know enough to really say. Which is a bit why I made any needed name string separate (e.g., compatible keyword required by the driver). I was not sure how the requirements for such functionality could grow.

The rfdc is certainly the odd ball YB here in that it is the only one right now that uses any of this. But I do believe there is potential in general for broader support and reuse of software/drivers that an IP provides.

[jack-h]

Thanks Mitch. I think I need to do a bit more digging, but your pointer is helpful. It looks like the memory map name (which I think is regname in https://github.com/realtimeradio/mlib_devel/blob/8fdbb7499f01f09cb411a8b490547468b2336d53/jasper_library/yellow_blocks/rfdc.py#L381) doesn't contain block hierarchy (unlike, eg, software register mmap names) so possibly this is related to this issue. From what you say, the limitation doesn't sound like it is fundamental, which was my main concern. I'll see if I can figure out a patch. Re. the DT generation infrastructure in general -- I have a need to build some ADI DT entries so might hit you up for more information about all this works in the future :)

…

On Mon, 16 Jan 2023 at 16:44, Mitch Burnett ***@***.***> wrote: The thinking was that yellow blocks supporting use of a device tree implement gen_dt_node(). Then in VitisBackend it would inherit from Toolflow and keep the frontend parsed information to iterates over the list of periph_objs and if that name is in the mmap it will call gen_dt_node() for the periph_obj. https://github.com/casper-astro/mlib_devel/blob/m2021a/jasper_library/toolflow.py#L1600 @jack-h <https://github.com/jack-h>, I am not super familiar with how hierarchy works and what information is available for reconciling that. You would know that better than me. But you are right, allowing the rfdc to be in a subsystem should be allowed. If the change from name to fullname on that check is enough to match what is placed in the mmap this would be enough to get the dtsi fragment to generate. Short of testing it to see what explodes, I cannot think of any issues this will raise because the formatted string in the include directive where name is used to identify the fragment file is just a convention. All that matters is that whatver the name of the fragment file is, that it is included by that name intop-level jasper.dtsi. That way when the device tree compiler runs it can include the fragments. I would say give it this a shot at and if it doesn't work we should keep looking at this. The underlying information that is placed in the device tree fragment and used to actually do any work by the rfdc driver is contained in the implementation of gen_rfdc_dt and not dependent on this name. The only thing the node generation should need is the information in the memory map. If this requirement will be true in general for anything wanting to support/use a device tree I was not sure. I do not know enough to really say. Which is a bit why I made any needed name string (e.g., compatible keyword required by the driver) separate. I was not sure how the requirements for such functionality could grow. The rfdc is certainly the odd ball YB here in that it is the only one right now that uses any of this. But I do believe there is potential in general for broader support and reuse of software/drivers. — Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKWM7BVLDNY6BSSG57SC6TWSV3F3ANCNFSM6AAAAAAT34FZDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>