Source Code HDL Assemblies
Is it possible, or on the roadmap, to produce final assemblies which are
not based on EDIF netlists but are simply projects with reference to the
source code and instantiations with appropriate generics?
Thanks,
Brian
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.
Jim
On 1/8/20 4:58 PM, Brian Padalino wrote:
Is it possible, or on the roadmap, to produce final assemblies which are
not based on EDIF netlists but are simply projects with reference to the
source code and instantiations with appropriate generics?
Thanks,
Brian
On Wed, Jan 8, 2020 at 5:56 PM James Kulp jek@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
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@gmail.com wrote:
On Wed, Jan 8, 2020 at 5:56 PM James Kulp jek@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
An HTML attachment was scrubbed...
URL: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20200109/0f5720e2/attachment.html
Very clear. Thanks. Two main takeaways: (not new but well stated).
- Build what you care about without building things you don't need.
- Make it easy to see/find/navigate the entire hierarchy of source code.
On 1/8/20 10:48 PM, Brian Padalino wrote:
On Wed, Jan 8, 2020 at 5:56 PM James Kulp <jek@parera.com
mailto:jek@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