Re: [Discuss OpenCPI] [UK OFFICIAL] Possible bug in OCPI assembly code gen caused by unassigned differential signals

From: James Kulp <jek_at_parera.com>
Date: Tue, 17 Dec 19 12:08:17 -0500

Congratulations on stepping on a latent silly bug.
I haven't searched our (soon to be public) bug database for this. 
Clearly none of the devices we currently use or test have hit this
differential tieoff issue before.

If you are building from source code and want a quick patch you can try
this (untested) change.
It has been made in our development version.

--- a/tools/ocpigen/src/hdl-container.cxx
+++ b/tools/ocpigen/src/hdl-container.cxx
_at_@ -1075,9 +1075,9 @@ emitTieoffSignals(FILE *f) {
          "  -- Output signal \"%s\" is not connected to any
instance.\n", s.cname());
      if (s.m_differential) {
        OU::format(name, s.m_pos.c_str(), s.cname());
-      fprintf(f, "  %s => %s,\n", name.c_str(), s.m_width ? "(others =>
'0')" : "'0'");
+      fprintf(f, "  %s <= %s;\n", name.c_str(), s.m_width ? "(others =>
'0')" : "'0'");
        OU::format(name, s.m_neg.c_str(), s.cname());
-      fprintf(f, "  %s => %s,\n", name.c_str(), s.m_width ? "(others =>
'0')" : "'0'");
+      fprintf(f, "  %s <= %s;\n", name.c_str(), s.m_width ? "(others =>
'0')" : "'0'");
      } else
        fprintf(f, "  %s <= %s;\n", s.cname(), s.m_width ? "(others =>
'0')" : "'0'");
      break;

Did you use any of the older MIG code in OpenCPI or did you start from
scratch?

Thanks.



On 12/17/19 11:34 AM, Walters Dominic A via discuss wrote:
> 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 - 17:08:17 CST