xtcx
Advanced Member level 1
- Joined
- Dec 22, 2007
- Messages
- 493
- Helped
- 65
- Reputation
- 130
- Reaction score
- 58
- Trophy points
- 1,308
- Location
- Bangalore, India
- Activity points
- 5,003
mod1 : RND
Generic map ( g_tap1 => "0000000000000000000", -- 19-bits
g_tap2 => "00000000") -- 8-bits
port map (.........) -- some mapping, so leave it
mod2 : RND
Generic map ( g_tap1 => "00", -- 2-bits
g_tap2 => "0000000000000000000") -- 19-bits
entity RND is
Generic ( g_tap1 => "00000000", -- 8-bits
g_tap2 => "0000000000000000000"); -- 19-bits
port ( .......);
end RND;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Rnd is
-- Generic Default values
generic(g_Tap1 : INTEGER := 8; -- tap to be Xored into Bit 0 of shift register
g_Tap2 : INTEGER := 27; -- last tap to be Xored into Bit 0 of shift register
-- 05/04/2006 - RA - Added ability to load an initial seed value in the LFSR
g_Seed1 : STD_LOGIC_VECTOR(g_Tap1 downto 1) := "00000000";
g_Seed2 : STD_LOGIC_VECTOR(g_Tap2-g_Tap1 downto 1) := "0000000000000000000");
port (
Clock : in STD_LOGIC;
Enable : in STD_LOGIC;
Load : in STD_LOGIC; -- 05/04/2006 - RA - Added ability to load an initial seed value in the LFSR
RndOut : out STD_LOGIC
);
end entity Rnd;
------------------------------------------------------------------------------------------------
-- : There is an implicit assumption that g_Tap2 is the end of the LFSR
-- v2.1 : Changed vectors to allow taking g_Tap1 and g_Tap2 values directly from
-- : xilinx xapp210
-- : NB g_Tap2 > g_Tap1 > 1
--
-- The two tap length vectors do not have a reset, this permits Leonardo to optimise the
-- vectors into SRL's (which Leo can do for fixed length shift register with an Enable and no reset)
-- using SRL's means the xilinx resouce usage is ((vector_length mod 16) + 1) LUT's per vector
--------------------------------------------------------------------------------
architecture RTL of Rnd is
constant EndTap : INTEGER := g_Tap2 - g_Tap1;
signal LfsrPart1 : STD_LOGIC_VECTOR(g_Tap1 downto 1) := (others =>'0'); -- others for simulation
signal LfsrPart2 : STD_LOGIC_VECTOR(EndTap downto 1) := (others =>'0');
signal FeedBack : STD_LOGIC;
begin
-- Use continuous assign for not Xor so spectrum won't be confused
FeedBack <= LfsrPart2(EndTap) xnor LfsrPart1(g_Tap1);
-- This process will instantiate at most g_Tap1/16 + 1 SRL16E's
ps_LfsrTap1 : process(Clock,Enable)
begin
if ( rising_edge(Clock) ) then
-- 05/04/2006 - RA - Added ability to load an initial seed value in the LFSR
if ( Load = '1' ) then
LfsrPart1 <= g_Seed1;
-- 05/04/2006 - RA - Added ability to load an initial seed value in the LFSR
elsif (Enable = '1' ) then
LfsrPart1 <= LfsrPart1(g_Tap1-1 downto 1) & FeedBack;
end if;
end if;
end process ps_LfsrTap1;
-- This process will instantiate at most (g_Tap2-g_Tap1)/16 + 1 SRL16E's
ps_LfsrTap2 : process(Clock,Enable)
begin
if ( rising_edge(Clock) ) then
-- 05/04/2006 - RA - Added ability to load an initial seed value in the LFSR
if ( Load = '1' ) then
LfsrPart2 <= g_Seed2;
-- 05/04/2006 - RA - Added ability to load an initial seed value in the LFSR
elsif (Enable = '1') then
LfsrPart2 <= LfsrPart2(EndTap-1 downto 1) & LfsrPart1(g_Tap1);
end if;
end if;
end process ps_LfsrTap2;
RndOut <= LfsrPart2(EndTap);
[B]g_Seed2 : STD_LOGIC_VECTOR(g_Tap2-g_Tap1 downto 1) [/B]
It will depend on the generic values G_Tap1 and G_tap2. In the code you posted, g_seed1 will always be 8 bits, and g_seed2 will always be 19 bits, because you have not changed the tap sizes. So they always have to be 8 and 19 bits (unless you change the tap sizes.
Nevertheless, I don't think that both posted codes will fit each other, because g_tap1/2 are bit_vectors in one and integers in the other.
The parameter requirements of the component itself are pretty clear, also that g_tap2 > g_tap1 (for the integer value, not the bit_string) is necessary.
entity xxx is
generic ( size : std_logic_vector(3 downto 0):="0000")
port (.....)
end xxx
generic map ( size => "00000001");
port map (.....)
entity xxx is
generic ( size : std_logic_vector :="0000")
port (.....)
end xxx
Also I am getting the error for g_seed1 and g_seed2 only. The xilinx tool clearly in the error state that there is a size mismatch at generic mapping. With integers this is not a problem. ONly the problem is with SLV.
No, its not allowed, because size is fixed at 4 bits, and it cannot be any more or any less. So a good VHDL parser would throw an error.
The only way I can see the origional code getting through, is if the VHDL parser was a bit lax, and set any unconnected bits to 'U'.
But if this was the case:
Code:entity xxx is generic ( size : std_logic_vector :="0000") port (.....) end xxx
Then you could connect "size" to any size std_logic_vector you liked. 4 bits is just the default if its left unconnected.
Of cause it's not.Is such declarations in VHDL allowed?.....that is driving of generic with slv size bigger than it is defined in component file.
generic map (g_tap <= 3,
g_tap2 <= 5,
g_Seed1 <= "010",
g_Seed2 <= "01110")
In which case? Is your component definition correct, too? Are you sure about the actually imported entity Rnd?I'm receiving same error in this case too....
generic map (g_tap <= 3,
g_tap2 <= 5,
g_Seed1 <= "010",
g_Seed2 <= "01")
Of cause it's not.
A I said, the requirements for the generics that fit the definition in post #3 are pretty clear. It expects integer values for the length of both seeds and the seeds itself as bit strings fitting the respective std_logic_vectors (which I called a bit vectors in my previous post).
g_Seed2 : STD_LOGIC_VECTOR(g_Tap2-g_Tap1 downto 1) := "0000000000000000000");
In which case? Is your component definition correct, too? Are you sure about the actually imported entity Rnd?
P.S.: I didn't look sharp. The expected length of seed2 is only g_tap2-g_tap1, just 2 bits in my example.
It needs to be like:
Code:generic map (g_tap <= 3, g_tap2 <= 5, g_Seed1 <= "010", g_Seed2 <= "01")
Code:g_Seed2 : STD_LOGIC_VECTOR(g_Tap2-g_Tap1 downto 1) := "0000000000000000000");
Xilinx latest tool 13.2 is throwing error at this line saying some illegal declaration. IF this statement is accepted by the tool, then the G_tap1 and G_tap2 which is driven from the top file will definitly adjust the SLV size of the g_seed1 and g_seed2 and then there will not be any error.
g_Seed1 : STD_LOGIC_VECTOR := "00000000";
g_Seed2 : STD_LOGIC_VECTOR := "0000000000000000000"
Thanks Dude....
Then I've got a long way to edit...and re-design
How did you get this piece of info?, you knew or is it shared somewhere on internet?.
Thanks again....
I made a demo bit of code and tried to compile it on modelsim. The 93 switch failed but 2008 compiled fine.
But yes, I suggest dropping the integers completly, and let the unbound std_logic_vectors set the length required, like FvM suggested.
if ( Load = '1' ) then
LfsrPart1 <= g_Seed1;
signal LfsrPart1 : STD_LOGIC_VECTOR(g_Tap1 downto 1)
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?