[UK OFFICIAL] Compressfile is too large for BRAM.

WD
Walters Dominic A
Fri, Jul 3, 2020 6:43 PM

Classification: UK OFFICIAL

Hi,

I'm having a problem building an assembly for zynq and zynq_ultra.
After the print out stating "Generating UUID, artifact xml file and metadata ROM file..." I get the following error messages:

  •     On Zynq using OSP for zed with the platform project version of the fmcomms_2_3_scdcd card:
    

o  "Exiting for problem: Compressfile is too large for BRAM. Input is 727451, output is 10232."

  •     On Zynq Ultrascale using custom OSP for ZCU102 with the platform project version of the fmcomms_2_3_scdcd card:
    

o  "Exiting for problem: Compressfile is too large for BRAM. Input is 726109, output is 10148."

They both start opt stage but fail complaining about a missing .edf file for the container (I assume because the bit above terminated?).
Building the same thing for xsim succeeds with a 5952 byte metadatarom.dat file.
I'm not familiar with this error message. I assume it's in ocpihdl as that's the only place I could find the word "Compressfile" in the source.
Any suggestions? I feel like I've seen the byte number that gets reported when this stage is successful at values above 10k before.
FYI, I've just ported this assembly and the components it uses from Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd July).

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 Hi, I'm having a problem building an assembly for zynq and zynq_ultra. After the print out stating "Generating UUID, artifact xml file and metadata ROM file..." I get the following error messages: * On Zynq using OSP for zed with the platform project version of the fmcomms_2_3_scdcd card: o "Exiting for problem: Compressfile is too large for BRAM. Input is 727451, output is 10232." * On Zynq Ultrascale using custom OSP for ZCU102 with the platform project version of the fmcomms_2_3_scdcd card: o "Exiting for problem: Compressfile is too large for BRAM. Input is 726109, output is 10148." They both start opt stage but fail complaining about a missing .edf file for the container (I assume because the bit above terminated?). Building the same thing for xsim succeeds with a 5952 byte metadatarom.dat file. I'm not familiar with this error message. I assume it's in ocpihdl as that's the only place I could find the word "Compressfile" in the source. Any suggestions? I feel like I've seen the byte number that gets reported when this stage is successful at values above 10k before. FYI, I've just ported this assembly and the components it uses from Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd July). 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"
JK
James Kulp
Fri, Jul 3, 2020 10:01 PM

Hi Dominic.

The XML for a bitstream goes to two places - one is at the end of the
file in clear text (ignored by bitstream loading),
and the other is in a compressed form into BRAMs that OpenCPI reads out
for various purposes like "ocpihdl get".
The error message is saying that the XML is large (727451 bytes) and can
only be compressed to 10232 bytes, which does not fit into the BRAM for
this purpose (which is 8192).

We have discussed a number of "smart" ways of dealing with this, but
none have been completely implemented yet.  There is not much difficult
about it, but this size has not been exceeded in a few years.

In the mean time, if you have a source release, you can simply change
the two constants for this:
One is in runtime/hdl/include/HdlDevice.h  - the constant ROM_NBYTES
The other is in projects/core/hdl/primitives/platform/metadata_rv.vhd -
the default for the romwords generic

I haven't tried this, but it is likely to work.  Try just doubling the
values.

I'll try to create an issue to track the real automatic fix for this.

Jim

On 7/3/20 2:43 PM, Walters Dominic A via discuss wrote:

Classification: UK OFFICIAL

Hi,

I'm having a problem building an assembly for zynq and zynq_ultra.
After the print out stating "Generating UUID, artifact xml file and metadata ROM file..." I get the following error messages:

  •     On Zynq using OSP for zed with the platform project version of the fmcomms_2_3_scdcd card:
    

o  "Exiting for problem: Compressfile is too large for BRAM. Input is 727451, output is 10232."

  •     On Zynq Ultrascale using custom OSP for ZCU102 with the platform project version of the fmcomms_2_3_scdcd card:
    

o  "Exiting for problem: Compressfile is too large for BRAM. Input is 726109, output is 10148."

They both start opt stage but fail complaining about a missing .edf file for the container (I assume because the bit above terminated?).
Building the same thing for xsim succeeds with a 5952 byte metadatarom.dat file.
I'm not familiar with this error message. I assume it's in ocpihdl as that's the only place I could find the word "Compressfile" in the source.
Any suggestions? I feel like I've seen the byte number that gets reported when this stage is successful at values above 10k before.
FYI, I've just ported this assembly and the components it uses from Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd July).

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"

Hi Dominic. The XML for a bitstream goes to two places - one is at the end of the file in clear text (ignored by bitstream loading), and the other is in a compressed form into BRAMs that OpenCPI reads out for various purposes like "ocpihdl get". The error message is saying that the XML is large (727451 bytes) and can only be compressed to 10232 bytes, which does not fit into the BRAM for this purpose (which is 8192). We have discussed a number of "smart" ways of dealing with this, but none have been completely implemented yet.  There is not much difficult about it, but this size has not been exceeded in a few years. In the mean time, if you have a source release, you can simply change the two constants for this: One is in runtime/hdl/include/HdlDevice.h  - the constant ROM_NBYTES The other is in projects/core/hdl/primitives/platform/metadata_rv.vhd - the default for the romwords generic I haven't tried this, but it is likely to work.  Try just doubling the values. I'll try to create an issue to track the real automatic fix for this. Jim On 7/3/20 2:43 PM, Walters Dominic A via discuss wrote: > Classification: UK OFFICIAL > > > Hi, > > I'm having a problem building an assembly for zynq and zynq_ultra. > After the print out stating "Generating UUID, artifact xml file and metadata ROM file..." I get the following error messages: > > * On Zynq using OSP for zed with the platform project version of the fmcomms_2_3_scdcd card: > > o "Exiting for problem: Compressfile is too large for BRAM. Input is 727451, output is 10232." > > * On Zynq Ultrascale using custom OSP for ZCU102 with the platform project version of the fmcomms_2_3_scdcd card: > > o "Exiting for problem: Compressfile is too large for BRAM. Input is 726109, output is 10148." > > They both start opt stage but fail complaining about a missing .edf file for the container (I assume because the bit above terminated?). > Building the same thing for xsim succeeds with a 5952 byte metadatarom.dat file. > I'm not familiar with this error message. I assume it's in ocpihdl as that's the only place I could find the word "Compressfile" in the source. > Any suggestions? I feel like I've seen the byte number that gets reported when this stage is successful at values above 10k before. > FYI, I've just ported this assembly and the components it uses from Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd July). > > 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" >
JK
James Kulp
Sun, Jul 5, 2020 9:51 PM

This is gitlab issue #1272

On 7/3/20 2:43 PM, Walters Dominic A via discuss wrote:

Classification: UK OFFICIAL

Hi,

I'm having a problem building an assembly for zynq and zynq_ultra.
After the print out stating "Generating UUID, artifact xml file and metadata ROM file..." I get the following error messages:

  •     On Zynq using OSP for zed with the platform project version of the fmcomms_2_3_scdcd card:
    

o  "Exiting for problem: Compressfile is too large for BRAM. Input is 727451, output is 10232."

  •     On Zynq Ultrascale using custom OSP for ZCU102 with the platform project version of the fmcomms_2_3_scdcd card:
    

o  "Exiting for problem: Compressfile is too large for BRAM. Input is 726109, output is 10148."

They both start opt stage but fail complaining about a missing .edf file for the container (I assume because the bit above terminated?).
Building the same thing for xsim succeeds with a 5952 byte metadatarom.dat file.
I'm not familiar with this error message. I assume it's in ocpihdl as that's the only place I could find the word "Compressfile" in the source.
Any suggestions? I feel like I've seen the byte number that gets reported when this stage is successful at values above 10k before.
FYI, I've just ported this assembly and the components it uses from Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd July).

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"

This is gitlab issue #1272 On 7/3/20 2:43 PM, Walters Dominic A via discuss wrote: > Classification: UK OFFICIAL > > > Hi, > > I'm having a problem building an assembly for zynq and zynq_ultra. > After the print out stating "Generating UUID, artifact xml file and metadata ROM file..." I get the following error messages: > > * On Zynq using OSP for zed with the platform project version of the fmcomms_2_3_scdcd card: > > o "Exiting for problem: Compressfile is too large for BRAM. Input is 727451, output is 10232." > > * On Zynq Ultrascale using custom OSP for ZCU102 with the platform project version of the fmcomms_2_3_scdcd card: > > o "Exiting for problem: Compressfile is too large for BRAM. Input is 726109, output is 10148." > > They both start opt stage but fail complaining about a missing .edf file for the container (I assume because the bit above terminated?). > Building the same thing for xsim succeeds with a 5952 byte metadatarom.dat file. > I'm not familiar with this error message. I assume it's in ocpihdl as that's the only place I could find the word "Compressfile" in the source. > Any suggestions? I feel like I've seen the byte number that gets reported when this stage is successful at values above 10k before. > FYI, I've just ported this assembly and the components it uses from Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd July). > > 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" >
JK
James Kulp
Tue, Aug 4, 2020 8:08 PM

The gitlab issue for this is #1328

On 7/3/20 6:01 PM, James Kulp wrote:

Hi Dominic.

The XML for a bitstream goes to two places - one is at the end of the
file in clear text (ignored by bitstream loading),
and the other is in a compressed form into BRAMs that OpenCPI reads
out for various purposes like "ocpihdl get".
The error message is saying that the XML is large (727451 bytes) and
can only be compressed to 10232 bytes, which does not fit into the
BRAM for this purpose (which is 8192).

We have discussed a number of "smart" ways of dealing with this, but
none have been completely implemented yet.  There is not much
difficult about it, but this size has not been exceeded in a few years.

In the mean time, if you have a source release, you can simply change
the two constants for this:
One is in runtime/hdl/include/HdlDevice.h  - the constant ROM_NBYTES
The other is in projects/core/hdl/primitives/platform/metadata_rv.vhd

  • the default for the romwords generic

I haven't tried this, but it is likely to work.  Try just doubling the
values.

I'll try to create an issue to track the real automatic fix for this.

Jim

On 7/3/20 2:43 PM, Walters Dominic A via discuss wrote:

Classification: UK OFFICIAL

Hi,

I'm having a problem building an assembly for zynq and zynq_ultra.
After the print out stating "Generating UUID, artifact xml file and
metadata ROM file..." I get the following error messages:

*         On Zynq using OSP for zed with the platform project version
of the fmcomms_2_3_scdcd card:

o   "Exiting for problem: Compressfile is too large for BRAM. Input
is 727451, output is 10232."

*         On Zynq Ultrascale using custom OSP for ZCU102 with the
platform project version of the fmcomms_2_3_scdcd card:

o   "Exiting for problem: Compressfile is too large for BRAM. Input
is 726109, output is 10148."

They both start opt stage but fail complaining about a missing .edf
file for the container (I assume because the bit above terminated?).
Building the same thing for xsim succeeds with a 5952 byte
metadatarom.dat file.
I'm not familiar with this error message. I assume it's in ocpihdl as
that's the only place I could find the word "Compressfile" in the
source.
Any suggestions? I feel like I've seen the byte number that gets
reported when this stage is successful at values above 10k before.
FYI, I've just ported this assembly and the components it uses from
Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the
1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd
July).

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"

The gitlab issue for this is #1328 On 7/3/20 6:01 PM, James Kulp wrote: > Hi Dominic. > > The XML for a bitstream goes to two places - one is at the end of the > file in clear text (ignored by bitstream loading), > and the other is in a compressed form into BRAMs that OpenCPI reads > out for various purposes like "ocpihdl get". > The error message is saying that the XML is large (727451 bytes) and > can only be compressed to 10232 bytes, which does not fit into the > BRAM for this purpose (which is 8192). > > We have discussed a number of "smart" ways of dealing with this, but > none have been completely implemented yet.  There is not much > difficult about it, but this size has not been exceeded in a few years. > > In the mean time, if you have a source release, you can simply change > the two constants for this: > One is in runtime/hdl/include/HdlDevice.h  - the constant ROM_NBYTES > The other is in projects/core/hdl/primitives/platform/metadata_rv.vhd > - the default for the romwords generic > > I haven't tried this, but it is likely to work.  Try just doubling the > values. > > I'll try to create an issue to track the real automatic fix for this. > > Jim > > > > > On 7/3/20 2:43 PM, Walters Dominic A via discuss wrote: >> Classification: UK OFFICIAL >> >> >> Hi, >> >> I'm having a problem building an assembly for zynq and zynq_ultra. >> After the print out stating "Generating UUID, artifact xml file and >> metadata ROM file..." I get the following error messages: >> >> *         On Zynq using OSP for zed with the platform project version >> of the fmcomms_2_3_scdcd card: >> >> o   "Exiting for problem: Compressfile is too large for BRAM. Input >> is 727451, output is 10232." >> >> *         On Zynq Ultrascale using custom OSP for ZCU102 with the >> platform project version of the fmcomms_2_3_scdcd card: >> >> o   "Exiting for problem: Compressfile is too large for BRAM. Input >> is 726109, output is 10148." >> >> They both start opt stage but fail complaining about a missing .edf >> file for the container (I assume because the bit above terminated?). >> Building the same thing for xsim succeeds with a 5952 byte >> metadatarom.dat file. >> I'm not familiar with this error message. I assume it's in ocpihdl as >> that's the only place I could find the word "Compressfile" in the >> source. >> Any suggestions? I feel like I've seen the byte number that gets >> reported when this stage is successful at values above 10k before. >> FYI, I've just ported this assembly and the components it uses from >> Geontech's OpenCPI 1.4 to current OpenCPI 1.7 (specifically the >> 1078-implement-fmcomms-support-on-zcu104-platform branch as of 2nd >> July). >> >> 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" >>