Generic Mapping of 19-bits over an 8-bit

xtcx · Mar 20, 2012

Hi friends, I need a clarity in generic mapping in VHDL. I have a situation where the top file writes 19-bits into the entity named RND where the generic delcaration in entity is only 8-bits

This RNDcomponent file is instantiated two times in a Top file, as like this

Code:

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

Now the actual RND file has generic declaration like this

Code:

entity RND is

Generic ( g_tap1 => "00000000",                                     -- 8-bits
          g_tap2 => "0000000000000000000");                    -- 19-bits

port ( .......);

end RND;

This code was given to us by stating it was a working code compiled sometime back with ISE7.0 version in 2005. Now we are to re-design this. Now I'm getting error "stating generic size mismatch error while mapping g_tap1 of 19-bits in mod2:RND for 8-bits.

My doubt :
What happens if we pass slv of 19-bit width at the top file generic map into the sub component which has only 8-bit delcaration or vice versa. Will the 19-bit value resize to 8-bit before assigning?.

Or Does the sub-component generic declared signal g_tap1 (in my eg) also adjust based on the bit-width specified in top file or what?.

Actual error : Line 235: Expression has 19 elements ; expected 8

Please clarify me. Thanks.

TrickyDicky · Mar 20, 2012

Can you post the code for the RND component (and why are you using components - why cant you use direct instantiation)?

xtcx · Mar 20, 2012

Thanks and sure, in the code, you will find an slv generic declaration "g_Seed1" which is assigned 8-bits only. But the top file which instantiates this file drives 19-bit value at generic map. For which I'm getting errors.... Please check and help me

Code:

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);

---------- Post added at 14:46 ---------- Previous post was at 14:45 ----------

I also got errors for gtap usage

Code:

[B]g_Seed2  : STD_LOGIC_VECTOR(g_Tap2-g_Tap1 downto 1) [/B]

Later which I changed this subtraction to a constant value, I did not get error. I am using xilinx 13.2 version.

TrickyDicky · Mar 20, 2012

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.

xtcx · Mar 20, 2012

TrickyDicky said:
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.

Yes I understood, but my question is, if the top file which instantiates this file, tries to drive 8-bits for g_seed1(whereas it is actually 19-bits) and for g_seed2 as 19-bits (which is 8-bits width), what will be the problem?. I am getting error for such assignment when synthesize. G_seed is the parameter which provides initial value to the RDN module from which the count has to start from.

I hope you understood my problem\doubt

Thanks

FvM · Mar 20, 2012

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.

In case of doubt, you should supply all 4 generics with actual values of the right type and suitable value.

xtcx · Mar 20, 2012

FvM said:
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.

What do you mean as "Bit vectors" where is the declaration of bit vector?. It has always been integer only.

See, I think I have not posted my question clearly. Please consider this example.

You have an xxx module which has

Code:

entity xxx is

generic ( size : std_logic_vector(3 downto 0):="0000")
port (.....)
end xxx

Now if I instantiate this xxx module in another VHD file and pass the generic value as

Code:

generic map ( size => "00000001");
port map (.....)

Is such declarations in VHDL allowed?.....that is driving of generic with slv size bigger than it is defined in component file.

In the xxx example, I am driving 8-bit value to "size" which is actually declared as 4-bit only in xxx module. What happens in such case?.

a) Will Size reg in generic of "xxx" be resized to 8-bit or will it just trim 4-bits and still be 4-bit for xxx module?....
b) I am getting error with recent xilinx versions, but it was a matured project before 6-years.

Any idea?. Have I made myself clear?.
Thanks....

TrickyDicky · Mar 20, 2012

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.

xtcx · Mar 20, 2012

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.

TrickyDicky · Mar 20, 2012

xtcx said:
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.

As it should. Because the vectors are the wrong size.

xtcx · Mar 20, 2012

TrickyDicky said:
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.

Thanks for the piece of info. I just want to learn this part, since this type of incorrect size map with generics value is 1st time that I'm facing.
Here it is (3 downto 0) which is a defined bus right?..

generic ( size : std_logic_vector(3 downto 0) :="0000")

So I should not practice different slv sizes when driving generics from top file....

But to my wonder, the tool should atleast take this case "when driving 8-bits value to a 19-bit (as declared in comp file)". I thought the tool would do something like this when I drive an 8-bit value at the top file whereas it is actually declared as 19-bits. Some kind of resize.

g_seed1(19 downto 12) <= g_seed1(8 downto 1);

But it even throws error for this case too. Vice versa.

FvM · Mar 20, 2012

Is such declarations in VHDL allowed?.....that is driving of generic with slv size bigger than it is defined in component file.

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).

In post #1, you are supplying bit strings where you should put integer numbers. That's why I asked, if the code actually belongs to the same component. You can however supply any intger values for g_tap1 and g_tap2, as long g_tap2 > g_tap1 along with seeds of the same length.

The types of the component definition must also comply with respective entity code.

E.g.

Code:

generic map (g_tap <= 3,
g_tap2 <= 5,
g_Seed1  <= "010",
g_Seed2  <= "01110")

xtcx · Mar 20, 2012

I'm receiving same error in this case too....

FvM · Mar 20, 2012

I'm receiving same error in this case too....

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")

xtcx · Mar 20, 2012

FvM said:
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).

Hi FVM, the problem actually is this generic declaration statement.

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.

I completely agree your point.

But the compiler generates error....what could be done in this case?....
If I change this with some integer, then the tools compiles well. But this creates the problem of SLV width issue which TRICKYDICKY was pointing to....

Is such add\sub in generic declarations not allowed or what?

---------- Post added at 16:04 ---------- Previous post was at 16:02 ----------

FvM said:
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")

Your example is correct, but I wonder whether it will synthesize. Because g_tap2-g_tap1 is not allowed and throwing error in this part :-(

I'm using Xilinx ISE 13.2, VHDL 200x.

TrickyDicky · Mar 20, 2012

xtcx said:
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.

Actually, this is an interesting point.
It is illegal to use generics inside other generics in the same region in VHDL 87, 93 and 2002, but appears to be legal in VHDL 2008 (compiles with modelsim for 2008, but not 93 and 2002). So that is probably what the error is.

So how the origional code compiled I have no idea (I only assume a poor VHDL compiler)

xtcx · Mar 20, 2012

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....

FvM · Mar 20, 2012

O.K. Now I understand the problem. I was misleaded somehow by the first post.

I think, the problem can be solved by omitting the size specification in the generic.

Code:

g_Seed1  : STD_LOGIC_VECTOR := "00000000";
 g_Seed2  : STD_LOGIC_VECTOR := "0000000000000000000"

TrickyDicky · Mar 20, 2012

xtcx said:
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.

xtcx · Mar 20, 2012

TrickyDicky said:
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.

Okay, thanks a lot guys. This is a great idea to solve the problem. But

The actual code (if you see my post-3), the generic value of g_seed1 is used to feed a counter.

Code:

if ( Load = '1' ) then
LfsrPart1 <= g_Seed1;

This signal LfsrPart1 is

Code:

signal   LfsrPart1            : STD_LOGIC_VECTOR(g_Tap1   downto 1)

So, now comes the new problem. std_logic_vector is not compatible with std_logic_vector(x downto 1) right?.

In such cases, I think your suggestion might not work, correct me if wrong.

Thanks

Welcome to EDAboard.com

Generic Mapping of 19-bits over an 8-bit

Advanced Member level 1

Advanced Member level 7

Advanced Member level 1

Advanced Member level 7

Advanced Member level 1

Super Moderator

Advanced Member level 1

Advanced Member level 7

Advanced Member level 1

Advanced Member level 7

Advanced Member level 1

Super Moderator

Advanced Member level 1

Super Moderator

Advanced Member level 1

Advanced Member level 7

Advanced Member level 1

Super Moderator

Advanced Member level 7

Advanced Member level 1

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor