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"
Received on Wed Dec 18 2019 - 16:31:57 CST