• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Logic Design
  3. RTL Compiler : Giving 1'b0 in synthesized netlist

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 63
  • Views 3421
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RTL Compiler : Giving 1'b0 in synthesized netlist

deeps4
deeps4 over 14 years ago

Hi all,

 I have application  where I have to use a set-reset D flip flop and I need to connect the D input to set port of the flop. 

I have written the RTL code for the same as a single bit flop and instatiated the flop as a 256 bit wide register as shown below

====================================

set_reset_dff  u_shell_output_cap_dff[255:0]
(
  .d          (q_int[255:0]),
  .set        (q_int[255:0]),
  .reset      (RST),
  .clk        (clk),
  .q          (Q[255:0])
);

====================================

However after  synthesis in the netlist I see following code with 1'b0 on the D input and where ever the flop is instantiated there also I see 1'b0 on D input. Basically RTL compiler is not connecting the set and D input of the flop. Any ideas what could be the reason? Is there a way to force it to short set and D input. I have also used "generate" to instatiate flop iso the code snippet above but see same result...

=============================================

module set_reset_dff(d, set, reset, clk, q);
  input d, set, reset, clk;
  output q;
  wire d, set, reset, clk;
  wire q;
  wire n_0, n_1;
  df3qx2pdv q_reg(.CD (n_1), .SD (n_0), .CP (clk), .D (1'b0), .Q (q));
  ivpdv g19(.A (reset), .Z (n_1));
  ivpdv g20(.A (set), .Z (n_0));
endmodule
 ==================================================

 Thanks,

-DN

 

  • Cancel
  • deeps4
    deeps4 over 14 years ago

     Hi,

    Preserving the set_reset_dff module  to dont touch worked for the above issue.

    -DN

     

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • grasshopper
    grasshopper over 14 years ago

    Hi DN,

    in all likelyhood, the implementation you described is functionally equivalent and likely more efficient. That being said, if your design has a strict requirement of keeping the topology you instantiated, the correct approach is to do exactly what you did and

    set_attr preserve true <seq instances list of interest>

    hope this helps,

    gh-

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • deeps4
    deeps4 over 14 years ago

     Hi gh,

     Apart from the above I had a general question. Using generate is better or the way it is instantiated above is better. I presume generate may take slightly more time to compile, both the methods synthesize to same logic. So was wondering if one is better over other...

    -DN

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • grasshopper
    grasshopper over 14 years ago

    Hi DN,

     I believe either one should work. In theory the impact should not be significantly any different. I would say the main reason to use generate statements or not would be if the naming convention of the generate statement has any impact in your flow.

     gh-

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • deeps4
    deeps4 over 14 years ago

    Thanks gh.

    -DN

     

     

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information