More width issues in Synplify Pro 8.8

[filmil]

I get the following error while trying to instantiate GTP_DUAL for a
Virtex 5 in Synplify Pro 8.8:

CD395 Constant width 28 does not match context width 27. There are a
couple of such messages, so I'll focus on one.

Within unisim.vhd, line 8216:
PMA_CDR_SCAN_0 : bit_vector := X"6c08040";

Which, in effect says that the attribute is 28 bit, since hexadecimal
addressing is used.

However, from V5 User Guide: http://direct.xilinx.com/bvdocs/userguides/ug196.pdf,
table 7-10 on page 137:

PMA_CDR_SCAN_0 This *27-bit* attribute...

So, there seems to be a mismatch with the inferred width of the
attribute (28) and the actual width (27), and to me it seems to be a
bug. How can I report this somewhere? At least I hope some synplify
people are reading this.

f

 

[Mike Treseler]

filmil wrote:

CD395 Constant width 28 does not match context width 27. There are a
couple of such messages, so I'll focus on one.

Within unisim.vhd, line 8216:
PMA_CDR_SCAN_0 : bit_vector := X"6c08040";

Note that x"6c08040" has a leading zero for 28 bits while
b"110" & x"c08040" is 27 bits.

How can I report this somewhere?
http://www.synplicity.com/support/

At least I hope some synplify
people are reading this.

They would certainly read a bug report.
Did your simulator compile and elaborate
this code without warnings?

-- Mike Treseler

 

[Filip Miletic]

Mike Treseler wrote:

Note that x"6c08040" has a leading zero for 28 bits while
b"110" & x"c08040" is 27 bits.

It is very clear what you mean.

I also remember reading that with the "hex" notation one cannot specify
a vector whose length in bits is not a multiple of 4.

Why is it then that the authors of unisims.vhd chose for this option ---
It even does not compile in Synplify Pro, of which the said file is part.

Did your simulator compile and elaborate
this code without warnings?

Yes, ModelSim had no trouble with the code. This is why I only
discovered it when I tried synthesis.

Next stop: Synplify support.

10xf

 

[Brian Drummond]

On Fri, 29 Jun 2007 21:45:45 +0200, Filip Miletic <filmil@gmTRIPail.com>
wrote:

Mike Treseler wrote:
Note that x"6c08040" has a leading zero for 28 bits while
b"110" & x"c08040" is 27 bits.

It is very clear what you mean.

I also remember reading that with the "hex" notation one cannot specify
a vector whose length in bits is not a multiple of 4.

Why is it then that the authors of unisims.vhd chose for this option ---
It even does not compile in Synplify Pro, of which the said file is part.

Did your simulator compile and elaborate
this code without warnings?

Yes, ModelSim had no trouble with the code. This is why I only
discovered it when I tried synthesis.

Should the process of instantiating GTP_DUAL involve trying to
synthesise the simulation models?

Anything in unisims.vhd was (I thought) intended for simulation only, to
replace a Xilinx primitive, intended to be treated as a black box by the
simulation tools, or possibly a core supplied in a compiled (.ngc)
format and therefore also black-boxed?

So what is different about the flow with GTP transceivers? Or am I
missing something?

- Brian

 

[Filip Miletic]

Brian Drummond wrote:

Should the process of instantiating GTP_DUAL involve trying to
synthesise the simulation models?

Anything in unisims.vhd was (I thought) intended for simulation only, to
replace a Xilinx primitive, intended to be treated as a black box by the

Of course not.

Unisims from Synplify Pro apparently contain only the declarations and a
blackbox attribute definition for the each. They therefore do not
contain a behavioral model of the circuit, in contrast to the unisims
intended for simulation.

The file is also not a part of my design, but was pulled in by Synplify
Pro itself during synthesis.

So what is different about the flow with GTP transceivers? Or am I
missing something?

Nothing is different in the flow. Just that the entity declaration for
the black box is written in a way Synplify Pro does not accept.

f