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: 
Highlighted
Visitor rnelsonee1
Visitor
1,271 Views
Registered: ‎03-30-2017

LUT usage all over the place with one-line changes

Jump to solution

Vivado 2016.3, Artix-7

 

I was getting LUT usage (slice) of around 100%. I removed one simple counter variable and it went to 67%. I removed a similar counter and it went back up to 90%

 

I also found an if where I look for a sync word - if (a) then X else Y end if. I got it so I don't need the if statement, so I have 

 

 

if path1='X' then
  -- one comment line, nothing else
else
  <code>
end if

 

 

This gives LUT of 3%. Awesome! So, I change it to this, or remove the if, else, and end if lines:

 

if path1 /= path1 then
  -- one comment line, nothing else
else
  <code>
end if

And it goes to 90% LUT usage!

 

Any ideas? I'm looking to add more code, and I'm worried it's going to jump to 100% if I write just one line in a way the synthesizer/implementer doesn't like. Using default settings/profiles.

0 Kudos
1 Solution

Accepted Solutions
Scholar richardhead
Scholar
1,871 Views
Registered: ‎08-01-2012

Re: LUT usage all over the place with one-line changes

Jump to solution
@rnelsonee1 Is this a synchronous bit of code? I assume it is otherwise you'd have latches all over.

""&path1 is a bit of a hack, but hacks that lead to more readable code are perfectly acceptable. The reason here is because of the strong typing in VHDL. This hack forces the conversion from a single std_logic type to an array of std_logic. Because of the context, it works out its an unsigned (rather than slv or signed).

Having had another think, I would be careful with the if path1 = 'X'. It is likely being treated by the synthesisor as dont care, so synth may be thinking it can take that branch whatever, and because there is no logic there, it removes the else case, which is removing your logic. Have you tried it in real hardware, or looked at the RTL diagram to ensure your logic is still there?

0 Kudos
7 Replies
Scholar hbucher
Scholar
1,263 Views
Registered: ‎03-22-2016

Re: LUT usage all over the place with one-line changes

Jump to solution

@rnelsonee1 Sure you are not looking for the inequality operator != rather than \=? 

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Scholar richardhead
Scholar
1,256 Views
Registered: ‎08-01-2012

Re: LUT usage all over the place with one-line changes

Jump to solution
@hbucher in vhdl, /= is the inequality operator. != means nothing.

@rnelsonee1 Its difficult to comment without any real code. Comments on what you have posted:
if path = 'X' then
if path /= path then

In both cases these if statements will be synthesised away as they can never be true on real hardware.

LUT usage really depends on coal. If you modified the code and resource usage reduced, there is probably something at issue in your code. The synthesis will do lots of logic reductions, and its probably unable to do logic reduction and merging when you have high resource usage.
0 Kudos
Scholar hbucher
Scholar
1,245 Views
Registered: ‎03-22-2016

Re: LUT usage all over the place with one-line changes

Jump to solution

@richardhead Ouch thought it was verilog...

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Visitor rnelsonee1
Visitor
1,236 Views
Registered: ‎03-30-2017

Re: LUT usage all over the place with one-line changes

Jump to solution

Thank you for your response! Yeah, I had figured the path1/=path1 would get removed - I didn't know about path1='X' getting synthesized out, but that's good to know. Although that adds even more to the mystery :)

 

I can post my code, but I don't expect anyone to be able to use it to resolve the issue as there may be code outside this loop that is fundamentally at the root of the problem. But I'll post it for completion. What I'm doing is adding a std_logic, path1, to bit_buffer. If the bit_buffer equals sync_pattern, I set synced to '1'.

 

I will say, it would also be nice to add a std_logic to an unsigned - I found a trick by adding ""&path1 but that seems hacky. So I just used that long if condition instead. Now that I type this out, I realized bit_buffer really doesn't need to be unsigned. Maybe I'll see what happens when I change that. *edit*: It was because of the shift left function. I don't know a better way to have a running buffer other than shift left, so that required something other than std_logic_vector.

 

signal sync_pattern : unsigned(79 downto 0) :=x"00000000000000000001";
signal bit_buffer : unsigned(79 downto 0) :=x"aaaaaaaaaaaaaaaaaaaa";

-- Ed note: sync_counter is integer that goes 0->255 then wraps.
-- We expect a sync word every 255 bits (path1).
-- So it's at a don't-care value when we match sync pattern first time. IF it's say, 123
-- then we just make sure that it equals 123 for syncs_reqd number of matches.

if path1 = 'X' then -- we need to keep this here for some silly reason to avoid LUT's going up else if ((shift_left(bit_buffer, 1) = sync_pattern) and (path1='0')) or ((shift_left(bit_buffer, 1)+1 = sync_pattern) and (path1='1')) then if successive_syncs = 0 then last_sync_cntr <= sync_counter; successive_syncs <= 1; elsif last_sync_cntr = sync_counter then successive_syncs <= successive_syncs + 1; if successive_syncs >=syncs_rqd then -- We do this inside of the loop to go right into sync on next bit synced <= '1'; -- We are synced sync_counter <= 0; -- Re-purpose sync_counter to match with sync so we know to ignore first 80 bits end if; else successive_syncs <= 0; last_sync_cntr <= 300; end if; end if;
if (path1='0') then bit_buffer <= shift_left(bit_buffer, 1); else bit_buffer <= shift_left(bit_buffer, 1)+1; end if; end if; -- if path1 != 'X'

  

0 Kudos
Scholar richardhead
Scholar
1,872 Views
Registered: ‎08-01-2012

Re: LUT usage all over the place with one-line changes

Jump to solution
@rnelsonee1 Is this a synchronous bit of code? I assume it is otherwise you'd have latches all over.

""&path1 is a bit of a hack, but hacks that lead to more readable code are perfectly acceptable. The reason here is because of the strong typing in VHDL. This hack forces the conversion from a single std_logic type to an array of std_logic. Because of the context, it works out its an unsigned (rather than slv or signed).

Having had another think, I would be careful with the if path1 = 'X'. It is likely being treated by the synthesisor as dont care, so synth may be thinking it can take that branch whatever, and because there is no logic there, it removes the else case, which is removing your logic. Have you tried it in real hardware, or looked at the RTL diagram to ensure your logic is still there?

0 Kudos
Visitor rnelsonee1
Visitor
1,225 Views
Registered: ‎03-30-2017

Re: LUT usage all over the place with one-line changes

Jump to solution

Oh, that's a good idea. I've only checked this via sim. I'm not sure how to check with an RTL diagram but I'll try now!

 

 

And I think it's synchronous (it's in an if rising_edge(clk) block) 

0 Kudos
Visitor rnelsonee1
Visitor
1,198 Views
Registered: ‎03-30-2017

Re: LUT usage all over the place with one-line changes

Jump to solution

I don't quite have a handle on using the RTL schematic (the one variable used in that loop exclusively doesn't appear in any schematic, but it is just the syncs_reqd input... how would you verify if a variable is getting set to '1'?) but your explanation makes sense. My code reads in data and builds up UDP packets byte by byte, probably 1000 lines of code. It makes no sense to go all the way to 3% usage unless that code was blocked out. And since that is the only code to set synced to '1', if we never sync, we never need to do anything else in this code!

 

It worries me now that removing a simple counter made it go from 87% or so to 67% or so - maybe something else was just removed wholesale... but then again I had all this tested with Rev 1 a few months ago and it worked, so maybe that counter just introduced a lot of 'fluff'.

 

So, marking as solved, as I'm at least closer to understanding how it works! Thank you!

0 Kudos