cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
15,691 Views
Registered: ‎02-20-2014

3 visible types match here

Hi,

 

I have been using Vivado 2013.4 and have now installed 2014.1.

 

On my port map I had the following:

 

i_bit2_err                     => '0'   

 

When I started to synthesie, I got the following error:

 

[Synth 8-2396] near character '0' ; 3 visible types match here ["C:/Sembarc/PlasticSCM/VHDL/Generic_modules/host_interface/host_interface.vhd":388]

 

I had a theory that something had changed to prevent the driving of the ports with a value directly so I created a constant:

 

CONSTANT BIT_0                         : STD_LOGIC:= '0';

 

I assigned that to the port map instead, thus:

 

i_bit2_err                     => BIT_0

 

The error went away.

 

Is this restriction a restriction imposed by the latest supported IEEE VHDL standard, or is this something that Xilinx have added to the latest design tools.

 

If it is the standard, which one is it? I can not find any information via the gui to which standard is being used for the compilation, or how to change it if possible.

 

I will have to change all my code to use Constants for the Port Map which will take a long time, and make the size of the file even more larger and annoying to debug.

 

I cannot see the realtional from removing this feature. VHDL, unlike Verilog, requires a Component declaration, so why can't the compiler get the information from that it it is confused by what '0' is?

 

Kind Regards

 

Phill

0 Kudos
10 Replies
Highlighted
Xilinx Employee
Xilinx Employee
15,682 Views
Registered: ‎05-14-2008

Re: 3 visible types match here

How do you instantiate this component?

 

my_inst : entity work.inst_ent

 

or 

 

my_inst : inst_ent

 

-Vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Visitor
Visitor
15,679 Views
Registered: ‎02-20-2014

Re: 3 visible types match here

Hi,

 

host_spi_slave_inst : host_spi_slave

 

where host_spi_slave is the component/entity name.

 

P.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,670 Views
Registered: ‎05-14-2008

Re: 3 visible types match here

What library is this host_spi_slave compiled to?

 

-Vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,657 Views
Registered: ‎11-28-2007

Re: 3 visible types match here

Hi Phill,

 

I think I know what is at hand here: Vivado Synthesis 2014.1 has become more strict in applying the LRM rules for VHDL libraries.

 

In the past, our default library was "work" but "work" also has a 2nd meaning: "current" library in other words, the library in which the calling VHDL file (host_interface.vhd) is compiled into.

The new default library is xil_defaultlib to prevent any conflicts between the physical "work" library and the "current" library.

 

In addition, Vivado will not search for the component (host_spi_slave) in libraries that are not referenced in the calling file (host_interface.vhd)

 

In your case, "host_spi_slave" should be in the same library as "host_interface.vhd" or in any of the libraries that are referenced in the header of "host_interface.vhd".

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
Highlighted
15,607 Views
Registered: ‎01-25-2012

Re: 3 visible types match here

I'm seeing the same thing (Vivado 2014.2) when I try to add components from the template.

 

I'm afraid Dries answer doesn't help to explain how to get rid of the error. Should I go back to using work as the default library? Do I need to somehow add the contents of UNISIM into my library?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,603 Views
Registered: ‎11-28-2007

Re: 3 visible types match here

Hi pspear,

 

we are more strict, so you need to correctly apply and use VHDL libraries and components.

Vivado should not search in unreferenced libraries anymore.

 

In your case:

what are the errors? What is the related code? What libraries do you compile your VHDL file in? In what library is the component that you are calling? How do you instantiate your component?

Make sure that you reference the library of your component in your VHDL file that gives the error.

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
Highlighted
15,595 Views
Registered: ‎01-25-2012

Re: 3 visible types match here

I was trying to add a PLL to the clock module in the aurora_8b10b example design to reduce init_clk from 200MHz to 100MHz. In the end I worked around the problem by just using a divide by 2 flip-flop. I would still like to understand what I need to do now to add a Xilinx HDL Language Template part to my design.The UNISIM library and use statements are there but I haven't got a component statement for the PLL. I never had to add those before but maybe that is what must be done now. If that is the case I sure hope there is a plan to add the component declarations to the templates.

 

 

Attached is my modified file that gives the error.

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,588 Views
Registered: ‎05-14-2008

Re: 3 visible types match here

You're using the Xilinx HDL primitive correctly. The only problem is that you put the library declaration and use statement within translate_off/translate_on pair, which makes them transparent to Synthesis.

 

-- synthesis translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- synthesis translate_on

 

Putting them out of the translate_off/translate_on resolves the error.

 

-Vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
15,580 Views
Registered: ‎01-25-2012

Re: 3 visible types match here

Thanks Vivan,

 

Only one minor quibble, I didn't add the translate_off/translate_on, that is how they appear in the example design. Any idea why they do that?

 

Regards

Peter

0 Kudos
Highlighted
Historian
Historian
8,017 Views
Registered: ‎02-25-2008

Re: 3 visible types match here


@pspear@dwavesys.com wrote:

 

Only one minor quibble, I didn't add the translate_off/translate_on, that is how they appear in the example design. Any idea why they do that?

 


Those pragmas are a vestige of very ancient and obsolete synthesis tools. The library name "unisim" is a similar vestige. Originally, the crappy synthesis tools couldn't/wouldn't/didn't deal with the unisim library, so the workaround was to simply not include it at all. so the --synthesis_on/_off was used around the stuff you didn't want the synthesizer to use.

 

History lesson. Back in the day: the unisim library held all of the simulation models for the various Xilinx primitives. These models weren't synthesizable, so when Synopsys' truly awful FPGA Express synthesizer went to work, it would barf on the models. So the --synthesis_on/_off pragmas were used to tell the synthesizer "ignore this code." Implicit in all of this was an assumption that the synthesis tool magically knew about the primitives, or at least their component declarations, and was able to use the primitives as black boxes.

 

In this ever-changing world in which we're living today, things have somewhat changed. unisim is still the name of the Xilinx primitives simulation library. Its vcomponents package holds the models; the package declaration (not the package body) holds all of the component declarations for those primitives.  You need those component declarations to satisfy the VHDL compiler (unless you include each component declaration in the declarative part of your entity architecture, which you don't want to do, because that's why we have packages).

 

So in simulation world, the vcomponents package holds the simulation models of the various primitives. In synthesis world, the package holds the primitives which are usually just blackboxed (for things like DCMs, BRAMs, global buffers, direct instantiations of LUTs, etc).

 

Which all means that in modern code intended to be used with modern tools (both synthesis and simulation), you cannot comment-out the unisim library use declaration if you're including any Xilinx primitives.

 

Got it?

 

PS: FPGA Express' inability to deal with single-process state machine code descriptions is the reason why Xilinx documentation STILL recommends that obsolete and dangerous paradigm.

----------------------------Yes, I do this for a living.