01-30-2018 05:59 AM
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.
01-30-2018 07:40 AM
01-30-2018 06:13 AM
01-30-2018 06:54 AM
01-30-2018 07:16 AM
01-30-2018 07:32 AM - edited 01-30-2018 07:42 AM
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'
01-30-2018 07:40 AM
01-30-2018 07:44 AM - edited 01-30-2018 07:45 AM
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)
01-30-2018 08:26 AM
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!