Classification: UK OFFICIAL
Hi,
Potentially this might be a bug report.
I've been using the empty assembly from the assets project to build containers for an fmcomms card on a ZCU102.
This has been working until I added an always enabled device worker to the platform .xml for my ZCU102 (the worker in question deals with a DDR4 chip on the board).
This caused OCPI to generate two lines of invalid VHDL when rebuilding the empty assembly. A clean build caused the same problem.
Specifically in the file with the name "empty_<platform_name>_<cfg_name>_<cnt_name>-assy.vhd" that generates inside the folder "container-empty_<platform_name>_<cfg_name>_<cnt_name>/gen" within the empty directory.
At the bottom of this file, a selection of output signals that aren't used in the container are bound to '0' or (others => '0').
In my case these signals were from the interface to my unused device worker (signals looking like <device_worker_name>_ddr4_addr for example).
There were also comments indicating a selection of input signals that hadn't been bound to anything (FMC_HPC_...).
Most of these zeroing assignments were fine, looking like:
* <device_worker_name>_<signal_name> <= '0';
o OR
* <device_worker_name>_<signal_name> <= (others => '0');
Except for two of them which looked like:
* <device_worker_name>_<signal_name> => '0',
o AND
* <device_worker_name>_<signal_name> => (others => '0'),
Both of the signals that this happened to were differential (specifically, they were the only two differential signals that were unused).
In this case the ck_t and ck_c pins on a DDR4 RAM MIG. Every other signal that was treated correctly wasn't differential.
I manually edited this file to correct the VHDL to the former format, and it built the container core correctly and has gotten to routing as I type this.
Any idea what has happened here? Unfortunately I can't provide the source code that causes this to happen at this time.
Thanks for any input,
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_at_dstl.gov.uk"
Received on Tue Dec 17 2019 - 16:34:23 CST