UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
1,324 Views
Registered: ‎05-12-2011

Vivado Trimming Top Bits of Unsigned?

Jump to solution

Hiya, I'm wondering if I'm doing something wrong or if this is how it's supposed to work and I just haven't figured out how to get what I want.  I have the following test case:

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Test is
    port(
        u12    : in  unsigned(11 downto 0);
        u10_1  : in  unsigned(9 downto 0);
        u10_2  : in  unsigned(9 downto 0);
        u10_out: out unsigned(9 downto 0)
    );
end Test;

architecture Behavioral of Test is
begin

    process( u12, u10_1, u10_2 )
        variable u: unsigned(11 downto 0);
    begin
u := u12 - u10_1 - u10_2; u10_out <= u(9 downto 0); end process; end architecture Behavioral;

When I run it through Synthesis in Vivado 18.1 with default settings (in project mode), I get the following 4 warnings:

 

[Synth 8-3331] design Test has unconnected port u12[11]
[Synth 8-3331] design Test has unconnected port u12[10]
[Synth 8-3331] design Test has unconnected port u12[11]
[Synth 8-3331] design Test has unconnected port u12[10]

I don't think it's unreasonable to expect the larger value to be used in its entirety as a base for subtracting the two smaller values from, even if the final result is truncated by two bits from the larger size.  But it appears Vivado is just ditching the top two bits as "unused and therefore irrelevant".  Is this how it's supposed to be?  If that's not how I want it to be, then would I apply a "save" attribute to u12 to cut out the undesired behavior?

 

Cheers,

-Doug

0 Kudos
1 Solution

Accepted Solutions
Scholar u4223374
Scholar
1,669 Views
Registered: ‎04-26-2015

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

Can you post an example where the top two bits would make any difference in the result? I'm curious about how what effect you expect from "forcing" Vivado to use them.

 

The Vivado/ISE logic trimming is very good. It's not going to cut out hardware unless it's certain that there will be no effect on the result.

View solution in original post

7 Replies
Highlighted
Explorer
Explorer
1,315 Views
Registered: ‎05-12-2011

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

Applying a DONT_TOUCH attribute to u12 eliminates the warning, however the schematic shows that only u12(9 downto 0) are used in the subtraction.  So the only impact of the attribute is to obscure the fact that the upper bits of u12 are being ignored.  UG912 says you can't apply DONT_TOUCH to the port of a module or entity, but it looks like you can.  I also tried flatten_hierarchy = none and that didn't have the desired impact either.

 

While I'm at it, why do I occasionally but not always get the warning "[IP_Flow 19-3899] Cannot get the environment domain name variable for the component vendor name. Setting the vendor name to 'user.org'." when synthesizing?  I can't pin down exactly when it shows up, but it seems like it appears after some amount of doing stuff in Vivado (in project mode).  Is it important or can I ignore it and masquerade as 'user.org' whatever that might entail?  I did set the board for this test project to Nexys Video just because...  Perhaps it's something in the Digilent setup?

Any ideas on the refusing to use all 12 bits thing?

 

Cheers,

-Doug

 

 

0 Kudos
Scholar u4223374
Scholar
1,670 Views
Registered: ‎04-26-2015

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

Can you post an example where the top two bits would make any difference in the result? I'm curious about how what effect you expect from "forcing" Vivado to use them.

 

The Vivado/ISE logic trimming is very good. It's not going to cut out hardware unless it's certain that there will be no effect on the result.

View solution in original post

1,257 Views
Registered: ‎01-22-2015

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution
Doug,

I agree with u4223374 that Vivado/ISE logic trimming is very good.

If the VHDL component you have shown us is the top level of your project then make sure all bits of u12 are connected to an FPGA pin in the constraints (xdc) file.

If the VHDL component is instantiated inside another VHDL component then look at the assignment (inside the other component) for u12 and make sure this assignment is not limiting the size of u12 to 10 bits.

Mark
Explorer
Explorer
1,192 Views
Registered: ‎05-12-2011

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

Ya know, I had to really stop and think about it.  I bumped into the trimming while working on a project, and it just seemed wrong to throw away the upper bits of a number before even doing the subtraction.  But it doesn't matter because the result is forced into 10 bits anyway.  So the upper 2 bits of the result may have differed but since they're not retained it's irrelevant and regardless of what was in the upper 2 bits to begin with, the lower 10 will be the same due to the implicit unsigned borrow feature.  So you're right, I don't know what result I was expecting that would be different because I didn't think it all the way through before bothering humanity about it.

 

My apologies for wasting your time.  I should have spent more of mine on it than I did.

 

And Mark this was just a test case to see if it was something in my project.  The original issue came up as I was weeding out the incessant trimming of pretty much everything (due to really small logic errors in really big new code, the waterfall effect is impressive!) calculating a video back porch from a total blanking period less front porch less sync pulse width using field sizes from the EDID spec.  Makes me wonder if it's not indicative of me presuming the calculated back porch number really should be the same size as the front and sync pulse fields.  I think I'll bump it up, better safe than sorry :-)

 

Thanks for the feedback guys, I appreciate your taking the time to straighten me out and in such a professional manner as well.

 

Cheers,

-Doug

 

0 Kudos
Scholar u4223374
Scholar
1,182 Views
Registered: ‎04-26-2015

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

@dchavir On the other hand, you've probably saved time for all the future people who have the same problem as you. Unless the question is seriously trivial (I recall someone who posted multiple threads asking whether a Zynq was a Virtex, followed by asking why a Zynq was not a Virtex) there is no harm in adding to the forum general knowledge.

 

 

For what it's worth, I've never managed to catch ISE or Vivado cutting out logic in a way that would affect the final design (Vivado HLS is another story...). The "find a counterexample" method is very useful for trying to resolve any questionable optimizations; when you sit down and try to find a scenario that will break the optimizations it generally becomes clear that no such scenario can exist.

 

The aggressive logic trimming is both impressive and annoying a times - all too often you cut out one wire (especially one I/O pin) and suddenly half your design disappears into "trimming unconnected signal" messages.

0 Kudos
Explorer
Explorer
1,175 Views
Registered: ‎05-12-2011

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

I have a love-hate relationship with the aggressive trimming.  Usually when things get trimmed on me, it means I made some really inane oversight so whatever logic I thought was being employed, was never used and therefore deleted.  That part I love.  I have one more such trimming incident where half of an 8-bit register is being trimmed, despite it being assigned to inputs of numerous sub-modules conveying full 8-bit data.  The trimming goes away if I don't flatten the hierarchy, it also goes away if I merely reference all 8 bits by changing a 4-bit lookup to a needlessly wide 8-bit lookup padded with zero bits, and I can't find where I've done anything wrong as it simulates properly either way.  As far as I'm concerned, I've got a bug in there somewhere and I just haven't found it yet.  And half of the register gone?  But I still see full 8-bit data going to the modules.  That part I hate, the only thing I know is the tools say the top half is unused so it's gone now, and I'm left to wonder how 8-bit data will move around in 4-bit registers.  If some other 8-bit register from another module was merged with the one in question, then why are the lower four bits needed at all - shouldn't the whole register disappear?  If I just define the register as 4 bits to begin with I'm sure it wouldn't do what I originally wanted.

 

I'm pretty sure my consternation arises from my lack of in-depth understanding.  It's just not easy to sneak up on that understanding from the terse warnings interspersed throughout oceans of text.  The more I do learn, my respect increases exponentially for those of you who are really, really good at this stuff. :-)

 

Cheers,

-Doug

 

0 Kudos
1,150 Views
Registered: ‎01-22-2015

Re: Vivado Trimming Top Bits of Unsigned?

Jump to solution

@dchavir

 

               ...due to the implicit unsigned borrow feature.

 

It has been a long time since I've thought about that feature.   Thanks for the re-learning experience.  -and thanks for your very appreciative replies.

 

Mark

0 Kudos