1
\$\begingroup\$

I have a straightforward quest about HDL and FPGA design.

If I seperate my code to a lot of modules, by modules I mean verilog files which do specifig things instead of writing close to the top module, does it affect clk timing?

Ill try to illustrate my question: the first option the I write most of my code in 1 file (not a top file, I know I shouldnt write logic on the top): enter image description here

the second option that I going deep with my modules, instead of write lot of code in 1 file, I will have seperate hdl files that does some functionality and bring back upstair the answers, something like this: enter image description here

does it affect timings of the clock/reset etc? does it good design to write lot of modules and going deep with the modules or I should stay close the the top?

In my opinion, I using Lattice FPGA and I "Share Resources" option in the syntesis, and than, its doesnt matter.

\$\endgroup\$

3 Answers 3

3
\$\begingroup\$

No, it doesn't affect the timing or final netlist. If you take a signal from the top level and assign it to successive modules, the compiler will recognise this is the same signal. Modules are there to allow you to:

  1. Group functionality into logical blocks.
  2. Reuse common designs.
  3. Keep design elements at a size you, as a human, can keep track of.

I try to have only assignments and very simple logic (e.g. ORing the output of two modules) at the top level. This keeps the namespace clean, and allows easy traversal of the hierarchy in the simulator.

\$\endgroup\$
3
  • \$\begingroup\$ If you have repeated instances of modules, it can probably affect the physical design, right? Just picturing a very complicated large design, won't the design compiler probably try use signal/module proximity at least as a heuristic for first pass cell placement? \$\endgroup\$
    – Justin
    Commented Apr 28, 2020 at 13:49
  • \$\begingroup\$ @Justin - potentially, it would be dependent on the compiler/synthesis/placement tools. I wouldn't expect the outputs from a single big file to be absolutely identical to that of a modular design as the compiler might miss some optimisations perhaps, but to a first order at least, they shouldn't diverge significantly. I can clarify the answer on that, but I think this would be a case of premature optimisation. \$\endgroup\$
    – awjlogan
    Commented Apr 28, 2020 at 13:58
  • \$\begingroup\$ @Justin- you can control how the tools do their job. For instance, I've had designs where the tools optimize out something that I need in my design. You can add tags to your HDL so the tool won't optimize a particular section of your design. \$\endgroup\$
    – David
    Commented Jul 29, 2020 at 12:16
1
\$\begingroup\$

I don't know about Lattice tools but my experience with Synopsys was that changing the module hierarchy could affect the timing results. The important issue was whether or not the compiler would completely flatten the design before starting optimization.

If the design is completely flattened then the tools will optimize across module boundaries, so that each instance of every module is optimized for the specific case of how it is connected to other modules.

If the design is not flattened then the lower level modules can only be optimized internally, without knowledge of how they are used, which can be less effective.

\$\endgroup\$
0
\$\begingroup\$

I'm not familiar with FPGA. But it will really worsen timing if we did bad design partition when designing ASICs. Too many hierarchies without care will possibily lead to a situation where a cloud of combinational gates is splitted into different modules, or feedthough happens. If we now synthesize this design without flattening, the tool will not optimize across module boundaries, and hence lower operating frequency. I agree with @Elliot Alderson.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.