cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
titan_amit
Visitor
Visitor
6,597 Views
Registered: ‎04-15-2011

warning while synthesizing for loop

I have written this code for bit stuffing in USB. The purpose of the code is to insert a '0' after every 6 consecutive 1's in the data. I am getting these warnins while synthesizing this code, i dont know why. I think its because of the loop. Can somebody please help me to get a better way to do this?

 

My code.

 

                                                                     



library ieee;
use ieee.std_logic_1164.all;
entity amit_bitstuff is
--generic (n,m : integer);
generic (n : integer :=96 ;m : integer := 112);
port ( din : in std_logic_vector(95 downto 0);
--a2 : out std_logic_vector(n-7 downto 0);
dout : out std_logic_vector(111 downto 0) --:= (others=>'0')

); ----for n is in between 12 to 17
end entity;
architecture arch of amit_bitstuff is
-- signal i : integer := 0;
-- signal j : integer := 0;
-- signal count : integer := 0;
signal A : std_logic_vector(n-7 downto 0);
-- signal flag : std_logic := '0' ;


begin
g0 : for j in 6 to n-1 generate
A(j-6) <= din(j-1) and din(j-2) and din(j-3) and din(j-4) and din(j-5) and din(j-6);
-- a2 <= A;
end generate g0;
-- flag <='1' ;


process(A)
variable i : integer range 0 to 111 := 0;
variable j : integer range 0 to 95 := 0;
variable count : integer := 0;
--variable A : std_logic_vector(n downto 1);



begin

dout(5 downto 0) <= din(5 downto 0);
dout (m-1 downto n) <= (others=>'0');
j := 6;
i := 6;

for j in 6 to n-1 loop
if (A(j-6)='1' and count <= 0) then
dout (i) <= '0';
i := i+1 ;
count := 5;
dout(i) <= din (j) ;
i:= i+1;


else
dout(i) <= din (j) ;
i := i+1;
count := count -1;

end if;
end loop;
end process;
end architecture;

 

 

WARNING:Xst:790 - "C:/Documents and Settings/Administrator/Desktop/sunil&amit/tr1/t1.vhd" line 45: Index value(s) does not match array range, simulation mismatch.
WARNING:Xst:790 - "C:/Documents and Settings/Administrator/Desktop/sunil&amit/tr1/t1.vhd" line 53: Index value(s) does not match array range, simulation mismatch.

WARNING:Xst:737 - Found 1-bit latch for signal <dout_7>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_8>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_9>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_10>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_11>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_12>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_13>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_14>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
WARNING:Xst:737 - Found 1-bit latch for signal <dout_15>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

0 Kudos
8 Replies
mcgett
Xilinx Employee
Xilinx Employee
6,596 Views
Registered: ‎01-03-2008

Loops are for software programs and should be rarely used in HDL.

 

I think that you need to take a step back and reconsider how this insertion of extract data bits will work with the rest of your data flow.

 

 

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
rcingham
Teacher
Teacher
6,592 Views
Registered: ‎09-09-2010

Look ma! No clocks!

------------------------------------------
"If it don't work in simulation, it won't work on the board."
eteam00
Instructor
Instructor
6,587 Views
Registered: ‎07-21-2009

The purpose of the code is to insert a '0' after every 6 consecutive 1's in the data.

Think of the hardware signal processing path as an assembly line.  At every step in the assembly line, parts come in the conveyor belt and parts go out on the conveyor belt at the same rate.  If they didn't come in and go out at the same rate, the whole system would quickly fall apart.

 

If you were to 'insert' a part into the assembly line, you have two choices:

 

1.  Toss a part out to make room for the new part

 

2.  Add controls to the assembly line to cause the 'input' belt to pause, to make room for the new part.  This would, of course, cause the entire 'upstream' assembly line to 'back up' -- which is much easier said than done.

 

This is how real hardware works when processing signals in a sequential (assembly line) system.

 

Perhaps 'insert' is an awkward term for the function you are trying to design.  If not, you should contemplate what happens in your finished hardware design when you 'insert' an extra 'cycle' of data or signal to process.  What happens, at the 'insertion point', to the data bit which would normally have arrived at the time of 'insertion'.

 

Did you intend 'substitution' rather than 'insertion' ?  Substitution (or modification, or replacement) is a simple construct in both assembly lines and hardware signal processing.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
titan_amit
Visitor
Visitor
6,569 Views
Registered: ‎04-15-2011

@ mcgett -- I tried google, but couldn't find a better way. @ rcingham -- I have got clock in my system but this module does require a clock because all the processing has to complete in a single clock. @ Bob Elkind -- Its not substitution, its insertion. Its a protocol of USB which requires a stuffing a '0' to the input stream of data if there are consecutive six '1's in the data stream. Its basically for clock synchronization( since USB doesn't use a clock exclusively). @ All-- Can you atleast tell me why am I getting warnings like Index values does not match array range though I think it matches. The simulation is running perfectly fine. and the other warning "Found 1 bit latch for signal " -- is it because the loop is running only once. Please have a look at the code. thanks in advance.
0 Kudos
eteam00
Instructor
Instructor
6,565 Views
Registered: ‎07-21-2009

@ mcgett -- I tried google, but couldn't find a better way.

You are responding to mcgett's standard 'signature', which is appended automatically to his posts.  The exhortation to 'google' is not directed specifically to you.

@ Bob Elkind -- Its not substitution, its insertion. Its a protocol of USB which requires a stuffing a '0' to the input stream of data if there are consecutive six '1's in the data stream. It's basically for clock synchronization( since USB doesn't use a clock exclusively).

How does the USB interface block interpret the 'dout' vector you are passing to it?  Does it re-scan the array for strings of '1's?  If not, how does it know if the vector has been expanded with the bit-stuff '0's?  My point is this:  'insertion' is a construct which does not lend itself easily to actual data processing hardware.

@ All-- Can you at least tell me why am I getting warnings like Index values does not match array range though I think it matches.

One of the problems with loop code such as yours is this:  it's very difficult for anyone -- except the person who wrote it -- to read and understand the code, even if the code is commented (which your code is not).

The simulation is running perfectly fine. and the other warning "Found 1 bit latch for signal " -- is it because the loop is running only once.

The synthesiser inferred latches because it found incomplete case or if statements.  Your simulation might be running fine, but your source code resulted in latches for the dout vector.  You may disagree with the synthesiser's interpretation of your code, but you are obliged to defer to the synthesiser.  You have two options:  change your code or use a different synthesiser.

Please have a look at the code.

Looked at the code and decided I didn't have enough time and brain cells to parse the code or your intent.  Your use of loops will limit your audience considerably.  Absence of comments limits your audience further.  The fact that much or most of the 'review' activity in these forums is done by unpaid volounteers in their spare time limits your audience further still.  If you are patient, you are likely to see useful responses, but there are no guarantees.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
titan_amit
Visitor
Visitor
6,557 Views
Registered: ‎04-15-2011

How does the USB interface block interpret the 'dout' vector you are passing to it? Does it re-scan the array for strings of '1's? If not, how does it know if the vector has been expanded with the bit-stuff '0's? My point is this: 'insertion' is a construct which does not lend itself easily to actual data processing hardware.

 

The output of this bit_stuff module is transmitted to a tranciever which encodes the data to NRZI format and transmits it to the USB device. Basically the transmitter receives data in packets of 8 bit parallely and converts it to serial D+ and D-(NRZI) which is transmitted to USB device(USB flash drive). In the device side there is another transciever which decodes the NRZI encoded data and transfers it parallely in packets of 8 bit to its memory. The stuffing is done to for clock recovery using PLL(since data is NRZI encoded).

 

 

My code with comments :)

 

library ieee;
use ieee.std_logic_1164.all;
entity amit_bitstuff is
generic (n : integer :=96 ;m : integer := 112);
port ( din : in std_logic_vector(95 downto 0); -- ip data

dout : out std_logic_vector(111 downto 0) --:= (others=>'0') -- op data which can be of max 96 + 96/6 = 112 bits

);
end entity;
architecture arch of amit_bitstuff is
signal A : std_logic_vector(n-7 downto 0);

begin
g0 : for j in 6 to n-1 generate
A(j-6) <= din(j-1) and din(j-2) and din(j-3) and din(j-4) and din(j-5) and din(j-6); ----anding every 6 consecutive bits to check if they are all 1.

end generate g0;


process(A)
variable i : integer range 0 to 111 := 0;
variable j : integer range 0 to 95 := 0;
variable count : integer := 0;

begin

dout(5 downto 0) <= din(5 downto 0); -- copy first 6 bits in ip to op as it is because it doesn't need any stuffing.


dout (m-1 downto n) <= (others=>'0'); -- stuff '0' to bits of o/p if its not used i.e. if all 16 bit of zeroes are not required.

j := 6;
i := 6;

for j in 6 to n-1 loop ---if 6 consecutive '1' are there
if (A(j-6)='1' and count <= 0) then
dout (i) <= '0';
i := i+1 ;
count := 5; -- count to copy next 6 bits as it is again
dout(i) <= din (j) ;
i:= i+1;


else
dout(i) <= din (j) ; -- if no 6 consecutive '1'
i := i+1;
count := count -1;

end if;
end loop;
end process;
end architecture;
0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
6,547 Views
Registered: ‎01-03-2008

> The output of this bit_stuff module is transmitted to a tranciever .... Basically the transmitter receives

> data in packets of 8 bit parallely and converts it to serial

 

As I said originally, you need to rethink the data flow and how this function needs to work.

 

Your module starts with 96 bit din input and outputs a 112 bit dout.   What happens if there are no 6 bit all one lengths in the 96 and no bits need to be inserted?  How does the next module know to only use the first 96 and not the last 16?

 

The latches?  They are coming from errors in your code (very common when using loops).  Does this work in simulation?  I would suggest that you walk through the code by hand to see where the failure is.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
eteam00
Instructor
Instructor
6,544 Views
Registered: ‎07-21-2009

Your thought processes are those of a software designer.  Mine (and - I think - Mcgett's) are those of a hardware designer.  It will not be easy to understand each other, but please understand that we have a valid and useful point to make.  Try to understand our point as we try to understand yours.

dout : out std_logic_vector(111 downto 0) --:= (others=>'0') -- op data which    can be of max 96 + 96/6 = 112 bits
Comment: In the synthesised hardware, dout is always 112 bits. How is the USB block to understand that dout consists of perhaps 96 bits for transmission, or perhaps 112 bits for transmission, or perhaps any number of bits for transmission greater than 96 and less than 112? What value should be assigned to dout[111 downto 96] by the synthesised logic if din[95 downto 0] is not all 1s?
dout(5 downto 0) <= din(5 downto 0)-- copy first 6 bits in ip to op as it is because it doesn't need any stuffing.
Comment: Have you taken care of case where previous din ended with one or more 1s ? Do you need to test din[-1 downto -5] (the equivalent of the previous din[95 downto 91]) for string of 1s?
	j := 6;
i := 6;
Comment: If you need these two lines, then you also need the following line:
count := 0;

 

Your code looks like the beginnings of a sequential state machine design.  After all, its logic is undeniably sequential.  I do not know how the synthesiser is likely to interpret your code to logic.  To a hardware designer, this uncertainty would not be acceptable.  After all, my job is to write code which can be unambiguously understood by both the synthesiser and myself -- anything different should be construed as a design error.  Ambiguity is bad, certainty is good!

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos