[UK OFFICIAL] Multiple Constraints files for a HdlConfig

WD
Walters Dominic A
Mon, Jan 27, 2020 2:45 PM

Classification: UK OFFICIAL

Hello again,

Is it possible for a HdlConfig file to specify multiple constraints files to be used?
I have a platform atm that has grown to 4 possible configurations, each requiring a complete Constraints file.
These configs are largely very similar (GPIO and RAM pins and iostandards are identical, clocks are set up the same way) with a section of FMC related iostandard constraints and associated input delays that differ.

Currently my HdlConfig looks like this:

<hdlconfig constraints="<file-name>">

......
</hdlconfig>

I tried a comma separated list of constraint files, but that doesn't seem to be supported and I struggled to find the section of ocpigen that parses this.
The way I've gotten around this at the moment is by editing vivado-impl.tcl:

@ -52,7 +54,7 @@link_design -mode $mode -part $part
puts "Loading XDC: $constraints"

  • read_xdc $constraints
  • read_xdc -unmanaged $constraints
    }

This allows the constraints file to be read as pure .tcl, so the .xdc file itself is then allowed use the whole syntax of .tcl, such as:

Ø  read_xdc <second_constraints_file>.xdc

Without this change vivado complains, saying that "read_xdc can't be used in a .xdc file".
Is adding "-unmanaged" here okay?
You turn off managed design flows in vivado-synth.tcl, although I'm not sure if that is related to this -unmanaged flag.

Thanks,
Dominic Walters

"This e-mail and any attachment(s) is intended for the recipient only.  Its unauthorised use,
disclosure, storage or copying is not permitted.  Communications with Dstl are monitored and/or
recorded for system efficiency and other lawful purposes, including business intelligence, business
metrics and training.  Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy."

"If you are not the intended recipient, please remove it from your system and notify the author of
the email and centralenq@dstl.gov.uk"

Classification: UK OFFICIAL Hello again, Is it possible for a HdlConfig file to specify multiple constraints files to be used? I have a platform atm that has grown to 4 possible configurations, each requiring a complete Constraints file. These configs are largely very similar (GPIO and RAM pins and iostandards are identical, clocks are set up the same way) with a section of FMC related iostandard constraints and associated input delays that differ. Currently my HdlConfig looks like this: <hdlconfig constraints="<file-name>"> ...... </hdlconfig> I tried a comma separated list of constraint files, but that doesn't seem to be supported and I struggled to find the section of ocpigen that parses this. The way I've gotten around this at the moment is by editing vivado-impl.tcl: @ -52,7 +54,7 @@link_design -mode $mode -part $part puts "Loading XDC: $constraints" - read_xdc $constraints + read_xdc -unmanaged $constraints } This allows the constraints file to be read as pure .tcl, so the .xdc file itself is then allowed use the whole syntax of .tcl, such as: Ø read_xdc <second_constraints_file>.xdc Without this change vivado complains, saying that "read_xdc can't be used in a .xdc file". Is adding "-unmanaged" here okay? You turn off managed design flows in vivado-synth.tcl, although I'm not sure if that is related to this -unmanaged flag. Thanks, Dominic Walters "This e-mail and any attachment(s) is intended for the recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. Communications with Dstl are monitored and/or recorded for system efficiency and other lawful purposes, including business intelligence, business metrics and training. Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy." "If you are not the intended recipient, please remove it from your system and notify the author of the email and centralenq@dstl.gov.uk"
DH
Davis Hoover
Mon, Jan 27, 2020 3:34 PM

We have only ever supported one constraints file per platform config. For
future framework improvements, your edits do provide improvement that we
might like to take advantage of.

---------- Forwarded message ---------
From: Walters Dominic A via discuss discuss@lists.opencpi.org
Date: Mon, Jan 27, 2020 at 9:46 AM
Subject: [Discuss OpenCPI] [UK OFFICIAL] Multiple Constraints files for a
HdlConfig
To: discuss@lists.opencpi.org discuss@lists.opencpi.org

Classification: UK OFFICIAL

Hello again,

Is it possible for a HdlConfig file to specify multiple constraints files
to be used?
I have a platform atm that has grown to 4 possible configurations, each
requiring a complete Constraints file.
These configs are largely very similar (GPIO and RAM pins and iostandards
are identical, clocks are set up the same way) with a section of FMC
related iostandard constraints and associated input delays that differ.

Currently my HdlConfig looks like this:

<hdlconfig constraints="<file-name>">

......
</hdlconfig>

I tried a comma separated list of constraint files, but that doesn't seem
to be supported and I struggled to find the section of ocpigen that parses
this.
The way I've gotten around this at the moment is by editing vivado-impl.tcl:

@ -52,7 +54,7 @@link_design -mode $mode -part $part
puts "Loading XDC: $constraints"

  • read_xdc $constraints
  • read_xdc -unmanaged $constraints
    }

This allows the constraints file to be read as pure .tcl, so the .xdc file
itself is then allowed use the whole syntax of .tcl, such as:

Ø  read_xdc <second_constraints_file>.xdc

Without this change vivado complains, saying that "read_xdc can't be used
in a .xdc file".
Is adding "-unmanaged" here okay?
You turn off managed design flows in vivado-synth.tcl, although I'm not
sure if that is related to this -unmanaged flag.

Thanks,
Dominic Walters

"This e-mail and any attachment(s) is intended for the recipient only.
Its unauthorised use,
disclosure, storage or copying is not permitted.  Communications with Dstl
are monitored and/or
recorded for system efficiency and other lawful purposes, including
business intelligence, business
metrics and training.  Any views or opinions expressed in this e-mail do
not necessarily reflect Dstl policy."

"If you are not the intended recipient, please remove it from your system
and notify the author of
the email and centralenq@dstl.gov.uk"

We have only ever supported one constraints file per platform config. For future framework improvements, your edits do provide improvement that we might like to take advantage of. ---------- Forwarded message --------- From: Walters Dominic A via discuss <discuss@lists.opencpi.org> Date: Mon, Jan 27, 2020 at 9:46 AM Subject: [Discuss OpenCPI] [UK OFFICIAL] Multiple Constraints files for a HdlConfig To: discuss@lists.opencpi.org <discuss@lists.opencpi.org> Classification: UK OFFICIAL Hello again, Is it possible for a HdlConfig file to specify multiple constraints files to be used? I have a platform atm that has grown to 4 possible configurations, each requiring a complete Constraints file. These configs are largely very similar (GPIO and RAM pins and iostandards are identical, clocks are set up the same way) with a section of FMC related iostandard constraints and associated input delays that differ. Currently my HdlConfig looks like this: <hdlconfig constraints="<file-name>"> ...... </hdlconfig> I tried a comma separated list of constraint files, but that doesn't seem to be supported and I struggled to find the section of ocpigen that parses this. The way I've gotten around this at the moment is by editing vivado-impl.tcl: @ -52,7 +54,7 @@link_design -mode $mode -part $part puts "Loading XDC: $constraints" - read_xdc $constraints + read_xdc -unmanaged $constraints } This allows the constraints file to be read as pure .tcl, so the .xdc file itself is then allowed use the whole syntax of .tcl, such as: Ø read_xdc <second_constraints_file>.xdc Without this change vivado complains, saying that "read_xdc can't be used in a .xdc file". Is adding "-unmanaged" here okay? You turn off managed design flows in vivado-synth.tcl, although I'm not sure if that is related to this -unmanaged flag. Thanks, Dominic Walters "This e-mail and any attachment(s) is intended for the recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. Communications with Dstl are monitored and/or recorded for system efficiency and other lawful purposes, including business intelligence, business metrics and training. Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy." "If you are not the intended recipient, please remove it from your system and notify the author of the email and centralenq@dstl.gov.uk"
WD
Walters Dominic A
Mon, Jan 27, 2020 3:49 PM

Classification: UK OFFICIAL

A disadvantage with this change that I can't see a way around atm is that when the top .xdc file is read, vivado is in the target-<platform> folder for the assembly container it is processing.
So to get to a second .xdc file that is marked in the "ExportFiles" parameter of a platform makefile, you have to write something like this in the main .xdc file:

read_xdc ../../../../../imports/<pkg-pref>.<pkg-name>/hdl/platforms/<platform>/lib/<file-name>.xdc

Pretty disgusting, especially given the file with this written in it is inside the specific platforms directory, so this line makes little sense to someone who comes across it out of context.
Also in some situations I can imagine the depth of the container won't always be 5 below the project top.

-----Original Message-----
From: discuss discuss-bounces@lists.opencpi.org On Behalf Of Davis Hoover
Sent: 27 January 2020 15:35
To: discuss@lists.opencpi.org
Subject: [Discuss OpenCPI] [UK OFFICIAL] Multiple Constraints files for a HdlConfig

We have only ever supported one constraints file per platform config. For future framework improvements, your edits do provide improvement that we might like to take advantage of.

---------- Forwarded message ---------
From: Walters Dominic A via discuss discuss@lists.opencpi.org
Date: Mon, Jan 27, 2020 at 9:46 AM
Subject: [Discuss OpenCPI] [UK OFFICIAL] Multiple Constraints files for a HdlConfig
To: discuss@lists.opencpi.org discuss@lists.opencpi.org

Classification: UK OFFICIAL

Hello again,

Is it possible for a HdlConfig file to specify multiple constraints files to be used?
I have a platform atm that has grown to 4 possible configurations, each requiring a complete Constraints file.
These configs are largely very similar (GPIO and RAM pins and iostandards are identical, clocks are set up the same way) with a section of FMC related iostandard constraints and associated input delays that differ.

Currently my HdlConfig looks like this:

<hdlconfig constraints="<file-name>"> ......
</hdlconfig>

I tried a comma separated list of constraint files, but that doesn't seem to be supported and I struggled to find the section of ocpigen that parses this.
The way I've gotten around this at the moment is by editing vivado-impl.tcl:

@ -52,7 +54,7 @@link_design -mode $mode -part $part
puts "Loading XDC: $constraints"

  • read_xdc $constraints
  • read_xdc -unmanaged $constraints
    }

This allows the constraints file to be read as pure .tcl, so the .xdc file itself is then allowed use the whole syntax of .tcl, such as:

Ø  read_xdc <second_constraints_file>.xdc

Without this change vivado complains, saying that "read_xdc can't be used in a .xdc file".
Is adding "-unmanaged" here okay?
You turn off managed design flows in vivado-synth.tcl, although I'm not sure if that is related to this -unmanaged flag.

Thanks,
Dominic Walters

"This e-mail and any attachment(s) is intended for the recipient only.
Its unauthorised use,
disclosure, storage or copying is not permitted.  Communications with Dstl are monitored and/or recorded for system efficiency and other lawful purposes, including business intelligence, business metrics and training.  Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy."

"If you are not the intended recipient, please remove it from your system and notify the author of the email and centralenq@dstl.gov.uk"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZROz4W4oceCg&u=http%3a%2f%2flists%2eopencpi%2eorg%2fpipermail%2fdiscuss%5flists%2eopencpi%2eorg%2fattachments%2f20200127%2f988e5fd0%2fattachment%2ehtml


discuss mailing list
discuss@lists.opencpi.org
http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZRO28WtY9JXw&u=http%3a%2f%2flists%2eopencpi%2eorg%2fmailman%2flistinfo%2fdiscuss%5flists%2eopencpi%2eorg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZRO2xFtdJLDA&u=http%3a%2f%2flists%2eopencpi%2eorg%2fpipermail%2fdiscuss%5flists%2eopencpi%2eorg%2fattachments%2f20200127%2f1af11dfb%2fattachment%2ehtml


discuss mailing list
discuss@lists.opencpi.org
http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZRO28WtY9JXw&u=http%3a%2f%2flists%2eopencpi%2eorg%2fmailman%2flistinfo%2fdiscuss%5flists%2eopencpi%2eorg

"This e-mail and any attachment(s) is intended for the recipient only.  Its unauthorised use,
disclosure, storage or copying is not permitted.  Communications with Dstl are monitored and/or
recorded for system efficiency and other lawful purposes, including business intelligence, business
metrics and training.  Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy."

"If you are not the intended recipient, please remove it from your system and notify the author of
the email and centralenq@dstl.gov.uk"

Classification: UK OFFICIAL A disadvantage with this change that I can't see a way around atm is that when the top .xdc file is read, vivado is in the target-<platform> folder for the assembly container it is processing. So to get to a second .xdc file that is marked in the "ExportFiles" parameter of a platform makefile, you have to write something like this in the main .xdc file: > read_xdc ../../../../../imports/<pkg-pref>.<pkg-name>/hdl/platforms/<platform>/lib/<file-name>.xdc Pretty disgusting, especially given the file with this written in it is inside the specific platforms directory, so this line makes little sense to someone who comes across it out of context. Also in some situations I can imagine the depth of the container won't always be 5 below the project top. -----Original Message----- From: discuss <discuss-bounces@lists.opencpi.org> On Behalf Of Davis Hoover Sent: 27 January 2020 15:35 To: discuss@lists.opencpi.org Subject: [Discuss OpenCPI] [UK OFFICIAL] Multiple Constraints files for a HdlConfig We have only ever supported one constraints file per platform config. For future framework improvements, your edits do provide improvement that we might like to take advantage of. ---------- Forwarded message --------- From: Walters Dominic A via discuss <discuss@lists.opencpi.org> Date: Mon, Jan 27, 2020 at 9:46 AM Subject: [Discuss OpenCPI] [UK OFFICIAL] Multiple Constraints files for a HdlConfig To: discuss@lists.opencpi.org <discuss@lists.opencpi.org> Classification: UK OFFICIAL Hello again, Is it possible for a HdlConfig file to specify multiple constraints files to be used? I have a platform atm that has grown to 4 possible configurations, each requiring a complete Constraints file. These configs are largely very similar (GPIO and RAM pins and iostandards are identical, clocks are set up the same way) with a section of FMC related iostandard constraints and associated input delays that differ. Currently my HdlConfig looks like this: <hdlconfig constraints="<file-name>"> ...... </hdlconfig> I tried a comma separated list of constraint files, but that doesn't seem to be supported and I struggled to find the section of ocpigen that parses this. The way I've gotten around this at the moment is by editing vivado-impl.tcl: @ -52,7 +54,7 @@link_design -mode $mode -part $part puts "Loading XDC: $constraints" - read_xdc $constraints + read_xdc -unmanaged $constraints } This allows the constraints file to be read as pure .tcl, so the .xdc file itself is then allowed use the whole syntax of .tcl, such as: Ø read_xdc <second_constraints_file>.xdc Without this change vivado complains, saying that "read_xdc can't be used in a .xdc file". Is adding "-unmanaged" here okay? You turn off managed design flows in vivado-synth.tcl, although I'm not sure if that is related to this -unmanaged flag. Thanks, Dominic Walters "This e-mail and any attachment(s) is intended for the recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. Communications with Dstl are monitored and/or recorded for system efficiency and other lawful purposes, including business intelligence, business metrics and training. Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy." "If you are not the intended recipient, please remove it from your system and notify the author of the email and centralenq@dstl.gov.uk" -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZROz4W4oceCg&u=http%3a%2f%2flists%2eopencpi%2eorg%2fpipermail%2fdiscuss%5flists%2eopencpi%2eorg%2fattachments%2f20200127%2f988e5fd0%2fattachment%2ehtml > _______________________________________________ discuss mailing list discuss@lists.opencpi.org http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZRO28WtY9JXw&u=http%3a%2f%2flists%2eopencpi%2eorg%2fmailman%2flistinfo%2fdiscuss%5flists%2eopencpi%2eorg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZRO2xFtdJLDA&u=http%3a%2f%2flists%2eopencpi%2eorg%2fpipermail%2fdiscuss%5flists%2eopencpi%2eorg%2fattachments%2f20200127%2f1af11dfb%2fattachment%2ehtml> _______________________________________________ discuss mailing list discuss@lists.opencpi.org http://scanmail.trustwave.com/?c=7369&d=x4Ov3lW7G-h0YNhMykOaR7s7akBxC3ZRO28WtY9JXw&u=http%3a%2f%2flists%2eopencpi%2eorg%2fmailman%2flistinfo%2fdiscuss%5flists%2eopencpi%2eorg "This e-mail and any attachment(s) is intended for the recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. Communications with Dstl are monitored and/or recorded for system efficiency and other lawful purposes, including business intelligence, business metrics and training. Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy." "If you are not the intended recipient, please remove it from your system and notify the author of the email and centralenq@dstl.gov.uk"