# port mapping and signals in a loop

Status
Not open for further replies.

#### tj.diego

##### Junior Member level 2
Hello everybody!
i'm here again because i'm very lazy and i want to simplify my life
i'm writing the hdl code of a kogge stone radix2 (dense) at 8 bit, and i was wondering if is possible to define signals and port map in a loop, to avoid to write a lot of code, and also to make the implementation indipendet form the number of bits!

ps i attach the code and the figure i'm using! View attachment koggestone.txt

#### permute

look into for-generate blocks in VHDL, or generate blocks with genvar's in Verilog. note that VHDL does things in a logical manner, while Verilog hacked generates into the language. both can have nested generate blocks in some manner, but Verilog defines all of the genvar's outside of a single block. VHDL just allows generate blocks to be contained within other generate blocks.

in VHDL, you can define signals an constants for internal use as well. processes can also be inside a generate.

Keep in mind that, for FPGA's, fancy adders almost never provide a benefit over the default that you get from just using a+b. This is because the FPGA fabric has very fast routing in place for them, while the fancy adders must use mostly general purpose routing.

#### tj.diego

##### Junior Member level 2
Hello, your nightmare is here again!
. I added the carry in at the 8 bit adder, and modify the structure in this way

Code:
signal carry:std_logic_vector(7 downto 0);
begin
carry(0)<='0';
c: for i IN 0 to 6 generate
c1to6: fa port map (a8(i), b8(i), carry(i), s8(0), carry(i+1));
end generate;

c7: fa port map (a8(7), b8(7), carry(7), s8(7), cout);

but the sum is metastable!

#### mrflibble

If it is metastable maybe you need to register it?

#### tj.diego

##### Junior Member level 2
i really hope that a ripple carry adder doesn't need to be registrered!
btw this is the result of the simulation!

#### mrflibble

i really hope that a ripple carry adder doesn't need to be registrered!
btw this is the result of the simulation!
View attachment 55602

That's not metastable. That's in all probability wrongly generated + setup/hold violations.

notice how the first bit is sometimes an X and sometimes a 0. The X is probably setup/hold violation.

To see the difference ... how about slowing down the clock by a factor of 100 and see if there is a different result. That should change some X's.

#### TrickyDicky

you connect all of the sum from the generate loop to s(0) rather than s(i), hence your problem.

tj.diego

### tj.diego

Points: 2

#### mrflibble

in all probability wrongly generated. check.