How to generate a design with 100 Flip-Flop fanouts connected to one node?

ads-ee said:

Something like this perhaps...

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
signal clk : std_logic;
signal din : std_logic;
signal ffs : std_logic_vector(99 downto 0); -- one hundred FFs
attribute syn_preserve : boolean;
attribute syn_preserve of ffs : signal is true;
 
process (clk)
begin
  if rising_edge(clk) then
    for i in 0 to 99 loop
      ffs(i) <= din;
    end loop;
  end if;
end process;

---

Note: this has not been checked, but should be approximately correct.

The syn_preserve attribute might have to be changed to whatever is appropriate for the synthesis tool you are using. This should ensure that the flip-flops are all kept and not merged into a single flop with 100 loads.

Click to expand...

Thank you @ads-ee for your kind reply. I did test the code but the synthesis report returns nothing ! it means that no RTL is assigned to it. it seems weird !

Click to expand...

ads-ee said:

You connected the signals to top level entity ports, right? Otherwise the code as is would just be deleted if dropped into a entity/architecture.

If this is not the problem post the synthesis log file.

Click to expand...

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.ALL;
library UNISIM;
use UNISIM.Vcomponents.ALL;



entity flipflops is
			port(
						clk       :in  std_logic;                       -- Clock input
						din       :in  std_logic;                       -- Reset lfsr
						ffs       :out  std_logic_vector(99 downto 0));
end flipflops;


architecture Behavioral of flipflops is



attribute syn_preserve : boolean;
attribute syn_preserve of ffs : signal is true;
 
 
 begin
 
 
process (clk)
begin
  if rising_edge(clk) then
    for i in 0 to 99 loop
      ffs(i) <= din;
    end loop;
  end if;
end process;




end Behavioral;

I have no idea if you can apply the attribute to an entity port, hence I used a signal. Besides I'm lazy and didn't want to type all the extra "overehad" associated with the entity and architecture stuff.

Click to expand...

My objective is that to connect D input of 100 flip flops to a specific net in my design and then remove them one-by-one and verify the fanout impact. Could you please help me by that?

Click to expand...

process (clk) -- I hope I understand what you want to achieve
begin
  if rising_edge(clk) then
    for i in 0 to 99 loop
      if i /= the_net_number_i_want_to_drop then
         ffs(i) <= din;
      else
         ffs(i) <= '0';
      end if ;
    end loop;
  end if;
end process;

shaiko said:

Verilogger in da house
I'm pretty sure attributes cam be assigned to ports.
But the interesting question to msdarvishi is - why would you want to do that ?
High fanout nets something you want to avoid (not just in logic design). The poor transistor that drives your 100 FFs screaming "help me" - and this usually means that your Fmax will be less then optimal.

Click to expand...

TrickyDicky said:

fewer lines of code:

ffs <= (others => din);

Click to expand...

msdarvishi said:

Dear @shaiko,

to answer to your question, my objective is to connect 100 flip-flops to one net of my design and see the percentage of the net delay that changes while the fanouts are increased??

Click to expand...

shaiko said:

Code:

process (clk) -- I hope I understand what you want to achieve
begin
  if rising_edge(clk) then
    for i in 0 to 99 loop
      if i /= the_net_number_i_want_to_drop then
         ffs(i) <= din;
      else
         ffs(i) <= '0';
      end if ;
    end loop;
  end if;
end process;

Click to expand...

ads-ee said:

:-D why didn't you chime in before! You know I'm a VHDL hammer and everything looks like a nail to me ;-).

- - - Updated - - -



Just changing how a signal is routed can affect the net delay. If you manage to route a signal on the same metal track that goes to multiple FFs located on a similar branch of routing you may not see any delay changes when adding or removing FFs (been there when hand routing stuff to match delays)

Click to expand...

msdarvishi said:

I agree, but if we put each flipflop in a different location in floorplan (by setting the UCF configuration) then the routing to each flip flop won't be on the same metal track and the delay will vary !

Click to expand...

ads-ee said:

Awesome you've actually done some homework on this project. That would definitely ensure differing delays especially if they are all kept further away than the hop distance of the routing fabric (which is something like 2-3 slices).

Click to expand...

msdarvishi said:

Dear @ads-ee,

what do you mean by homework?! The implementation does not seem to be straightforward ! Do you have any idea for its implementation?

Thanks,

Click to expand...

As you see, in the FPGA Editor, all the input of flip flops are a bus, and if I want to delete only the net associated with D input of the first flip flop, all other D inputs of other flip flops will be deleted as well !!

Click to expand...

ads-ee said:

I meant you've actually put some effort in understanding what you are trying to do and have made an effort to do the work as opposed to many of the posters here that want someone to do every thing for them in the guise of an "example".

Write the code either as a tricky suggest or using the generate, add placement constraints for each FF in the UCF file, I would suggest placing them approximately evenly distributed in a 10x10 grid across the part.


Don't delete the connection like you posted in this quote, delete the FF in the editor, this will leave the rest of the routing alone. Optionally you can tell the tools to unroute an object, though now the design will have unrouted nets that will be reported.

Click to expand...

msdarvishi said:

First, I think you've got a wrong impression of my diagram posted ! I never asked anybody to do everything for me !! I know you as a colleague that we are sharing posts for some years.... ! It was weird to me to hear it from you !

Click to expand...