Re: [Discuss OpenCPI] Platform Mapping HDL Pins

From: Brian Padalino <bpadalino_at_gmail.com>
Date: Wed, 08 Jan 20 14:39:40 -0500

On Wed, Jan 8, 2020 at 2:29 PM Davis Hoover <dhoover_at_geontech.com> wrote:

> Some more background info if it helps:
>
> When you build from a hdl/platform/<foo> directory, it builds the platform
> worker and all platform configs. For Vivado the worker and configs are
> built as .edfs. A platform config can (and should, if device workers are
> instantiated, in order to keep the device worker and its constraints
> "together") reference a constraints file.
>

I am trying to use the matchstiq_z1 as a reference in the github repo here:


https://github.com/opencpi/opencpi/tree/master/projects/assets/hdl/platforms/matchstiq_z1

And I am failing to see if the XDC files are associated with any of the
platform configs there? I don't think I see it?

How can I explicitly have an HdlConfig reference the constraints?


>
> Then you build from a hdl/assemblies/<my_assembly> directory. An assembly
> is built, again as an .edf if Vivado is used. Then a container is built,
> which is synonymous with the top-level HDL design. Unless the assembly
> makefile overrides the default, a default container is built which uses the
> base config. A custom container can also be built, which can instantiate
> device workers directly, and/or it can reference a platform config. A
> container can also have a constraints file (or it can simply point to a
> platform config which may already have its own constraints file)
>
> So the FSK assembly uses custom containers, each of which follow the
> platform-config-containing-constraints-and-device-workers paradigm. For
> Vivado this yields a hierarchy of:
> * container/bitstream
> * assembly .edf
> * application worker .edf
> * application worker .edf
> * ...
> * platform config .edf (w/ constraints file)
> * device worker .edf
> * device worker .edf
> * ...
>
>
This is exactly what I needed to see. Thank you!

Also, just to be sure, leaving the platform='' should get rid of the signal
in the top level, correct?

Thanks,
Brian


Received on Wed Jan 08 2020 - 19:39:40 CST

This archive was generated by hypermail 2.3.0 : Fri Jun 05 2026 - 08:45:25 CDT