Classification: UK OFFICIAL
Hey,
I had seen these ARs when trying to look up the problem, but I'm pretty sure they aren't related.
The pins in question are outputs of a MIG that go directly to an FPGA output pin, so I don't think I need to manually constrain them?
The MIG core should do that.
I'm relatively confident that this is an OCPI bug.
When you leave pins unconnected in an empty container, they are treated differently depending on what they are.
>From my synthesized opt stage schematic:
* 1. Input pins are left unconnected.
* 2. Bidirectional pins that aren't driven are left unconnected.
* 3. Output pins that aren't driven, are connected to ground through an OBUF.
This third one causes a problem with differential signals.
In the synthesized schematic (from opt stage) the _n and _p sides of my differential signal are separately driven from OBUF primitives connected to ground, when they should be driven from the paired outputs of an OBUFDS connected to ground.
As such, both sides of the differential pair are grounded when one of them should instead be high.
I believe this is caused by the same lines of code that James patched at the start of this thread.
One side of the differential pair should be tied high instead of low.
I believe the patch should instead be:
--- 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 =>
'1')" : "'1'");
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;
This corrects the first bug in this thread that James fixed, and this one.
It sets the _p side to be high, and the _n side low. I'm testing this possible solution now, I'll update when it finishes.
Thanks for your help,
D. Walters
-----Original Message-----
From: discuss <discuss-bounces_at_lists.opencpi.org> On Behalf Of Davis Hoover
Sent: 18 December 2019 20:08
To: discuss_at_lists.opencpi.org
Subject: [Discuss OpenCPI] [UK OFFICIAL] Possible bug in OCPI assembly code gen caused by unassigned differential signals
This might fix your issue:
https://scanmail.trustwave.com/?c=7369&d=6Yf63dd-MiuKGnl0TQ4ig56ORSCEZck_9rkPtUagLg&u=https%3a%2f%2fwww%2exilinx%2ecom%2fsupport%2fanswers%2f57109%2ehtml
Also related:
https://scanmail.trustwave.com/?c=7369&d=6Yf63dd-MiuKGnl0TQ4ig56ORSCEZck_9r0IvRWkeA&u=https%3a%2f%2fforums%2exilinx%2ecom%2ft5%2fWelcome-Join%2fSystemclockP-is-a-Single-ended-but-iostandard-is-LVDS-25-which%2ftd-p%2f557165
---------- 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
> http://scanmail.trustwave.com/?c=7369&d=6Yf63dd-MiuKGnl0TQ4ig56ORSCEZc
> k_9ugOskaifw&u=http%3a%2f%2fss%255flists%252eopencpi%252eorg%252fattac
> hments%252f20191217%252fe077209a%252fattac
> 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
> %http://scanmail.trustwave.com/?c=7369&d=6Yf63dd-MiuKGnl0TQ4ig56ORSCEZ
> ck_9uoItUagLg&u=http%3a%2f%2f2fdiscuss%255flists%252eopencpi%252eorg
"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://scanmail.trustwave.com/?c=7369&d=6Yf63dd-MiuKGnl0TQ4ig56ORSCEZck_9u9Ythukfw&u=http%3a%2f%2flists%2eopencpi%2eorg%2fmailman%2flistinfo%2fdiscuss%5flists%2eopencpi%2eorg
Received on Thu Dec 19 2019 - 11:20:09 CST