Re: [Discuss OpenCPI] Source Code HDL Assemblies
Geon Has already implemented this feature for the Stratix10 for a
customer. We intend for this to be open sourced once it is delivered and
get approval but don't really have a concrete timeline.
As far as we could tell it is not possible to create "EDIF" files for any
block that needs to touch pins using the Quartus Prime tools, so this is
likely a requirement for using any new altera parts. That said what we
developed is probably just a starting point and would need some amount of
work to be implemented across all Build tools and platforms.
On Wed, Jan 8, 2020 at 10:49 PM Brian Padalino <bpadalino_at_gmail.com> wrote:
> On Wed, Jan 8, 2020 at 5:56 PM James Kulp <jek_at_parera.com> wrote:
>
> > Hi Brian,
> >
> > This is a big topic and is not new and is sensible.
> > The current build system was based on the "3rd party IP" or "Incremental
> > compilation" model (as Altera used to call it).
> > It is optimized to avoid rebuilding and resynthesizing lots of pieces
> > that add up to the design.
> > There is some sacrifice in some possible optimizations across synthesis
> > boundaries.
> >
> > It is not optimal in the time it takes for building the whole design
> > from scratch.
> >
> > There has been discussion on adding the option to flip things the other
> > way, and allowing building from all source code in one shot.
> >
> > We do in fact carry the source code through the process behind the
> > scenes, so it is not a giant challenge.
> >
> > Can you describe what drove you to ask and what benefits you were
> > looking for? That will help prioritize this issue.
> >
>
> In an effort to familiarize myself with OpenCPI, I chose to:
> - Add a new RCC for Ubuntu 18.x as a host (done)
> - Add a new RCC for Xilinx Vivado 2017.4 (done)
> - Add a new platform for the ADALM-PLUTO (WIP)
> - Target the OpenCPI FSK application to run on the embedded device (WIP)
>
> There is extensive support for the ad936x based devices, so I figured it
> would be somewhat simple. The ADALM-PLUTO has a device using CMOS, dual
> port, and swapped ports. This was an option based on the parameters for
> the ad9361_data_sub, ad9361_adc_sub, and ad9361_dac_sub devices. When I
> tried to build this platform and assembly, I ran into an issue that the
> ad9361_data_sub was not built for that configuration, and I needed to add
> the configurations to the ad9361_adc_sub and ad9361_dac_sub to get it to be
> recognized as built.
>
> It occurred to me that all the appropriate generics were set, but I had to
> go through the process of generating EDIF netlists for a lot of different
> platforms that I didn't necessarily care about. FPGA synthesis is not a
> fast/easy thing to do and I can see projects becoming somewhat unwieldy
> given the sheer number of parameters for reusable devices which all seem to
> be appropriately controlled via generics.
>
> It occurred to me that if I were just able to get through all the source
> code, it would also feel a bit less obfuscated to me when trying to
> understand the concepts of assemblies, containers, devices, and platforms.
> As of right now, it still feels a little foreign but I think I am getting
> used to it. Though, admittedly, I am pretty freaked out about not defining
> entities or seeing top levels easily.
>
> I hope this helps. Please let me know if you need me to elaborate on
> anything I've stated.
>
> Thanks,
> Brian
>
Received on Thu Jan 09 2020 - 16:55:02 CST
This archive was generated by hypermail 2.3.0
: Fri Jun 05 2026 - 08:45:25 CDT