This might fix your issue:
https://www.xilinx.com/support/answers/57109.html
Also related:
https://forums.xilinx.com/t5/Welcome-Join/SystemclockP-is-a-Single-ended-but-iostandard-is-LVDS-25-which/td-p/557165
---------- Forwarded message ---------
From: Walters Dominic A via discuss <discuss_at_lists.opencpi.org>
Date: Wed, Dec 18, 2019 at 10:32 AM
Subject: Re: [Discuss OpenCPI] [UK OFFICIAL] Possible bug in OCPI assembly
code gen caused by unassigned differential signals
To: James Kulp <jek_at_parera.com>, discuss_at_lists.opencpi.org <
discuss_at_lists.opencpi.org>
Classification: UK OFFICIAL
Hi again,
I'm having another (possibly related) problem during bitstream generation.
Same build as last email (trying to make an empty container for an fmcomms
card with a device worker available in the BSP but unused).
Vivado is returning the following error:
[DRC IOSTDTYPE-1] IOStandard Type: I/O port <device_worker_name>_ddr4_ck_c
is Single-Ended but has IOStandard of DIFF_SSTL12 which can only support
Differential.
[DRC IOSTDTYPE-1] IOStandard Type: I/O port <device_worker_name>_ddr4_ck_t
is Single-Ended but has IOStandard of DIFF_SSTL12 which can only support
Differential.
This error propagates from the opt stage, which had the above error as a
critical warning (becoming an error during bitstream generation).
The signal in question "<device_worker_name>_ddr4_ck" is defined as
differential in my device worker .xml with the appropriate "pos" and "neg"
formatting strings:
* <signal output='ddr4_ck' differential='1' pos='%s_t' neg='%s_c' />
The IOStandard of DIFF_SSTL12 is correct. My container .xdc has two lines
for each side of the differential (one set_property to designate the pin
its attached to, and another for its IOStandard)
I tried changing the names to the more standard "_n" and "_p" in case it
was a parsing error, but that didn't work.
Again, this error occurs only on a differential output signal. A
bidirectional differential signal of width 2 in the same device worker
isn't having a problem (although it does use a different IOStandard:
DIFF_POD12).
In the synthesised schematic in the .xpr file, both of these pins are
present and are each being driven from ground through an OBUF.
Seems like this is more likely to be caused by something I've written,
rather than being an OCPI bug, as this is the first time that the device
worker is being put through the full vivado build process.
Have I missed out a constraint that I need to apply to the pin (not really
an OCPI question anymore :D)?
Does the signal tag in the xml need a "pin='1'"?
Thanks,
D. Walters
-----Original Message-----
From: James Kulp <jek_at_parera.com>
Sent: 17 December 2019 17:08
To: Walters Dominic A <dawalters_at_dstl.gov.uk>; discuss_at_lists.opencpi.org
Subject: Re: [Discuss OpenCPI] [UK OFFICIAL] Possible bug in OCPI assembly
code gen caused by unassigned differential signals
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"
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://scanmail.trustwave.com/?c=7369&d=kI353W7H6BuxfeBY9FCIHepnNwyd0
> 7-FwO_Pc5avAg&u=http%3a%2f%2flists%2eopencpi%2eorg%2fpipermail%2fdiscu
> ss%5flists%2eopencpi%2eorg%2fattachments%2f20191217%2fe077209a%2fattac
> hment%2ehtml> _______________________________________________
> discuss mailing list
> discuss_at_lists.opencpi.org
> http://scanmail.trustwave.com/?c=7369&d=kI353W7H6BuxfeBY9FCIHepnNwyd07
> -FwLqcJ5qsAw&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_at_dstl.gov.uk"
_______________________________________________
discuss mailing list
discuss_at_lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
Received on Wed Dec 18 2019 - 20:08:12 CST