Stats

  • Locked Locked
  • Replies 2
  • Subscribers 92
  • Views 14638
  • 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

CPF style with analog hard macro

GabrielB

Dear all,

hopefully I'm not writing in the wrong forum - but I saw most CPF related posts are here.

I'm designing a mixed signal ASIC with digital-on-top methodology. I have only one big analog custom hard block, for which I generated the abstract view and wrote by hand a liberty file. My problems arise, since this block needs 6 power supply voltages and 4 grounds. All this voltages together with all analog signals are directly connected to pads. All the digital ports of the block belongs to a single 3.3V power domain.


I'm writing in CPF 2.0 so I can use the set_analog_ports command and the set_macro_model with set_instance -model.

Now: should I define 6 different power domains for my macro and therefore also in my top design?

I tried defining only one 3.3V power domain, but then what about all the power and ground ports?


Thanks in advance

Gabriel

PS: I'm working with conformal 14.10.220, RC 14.11.000 and EDI 14.13

Parents

  • Hi Shawn!

    Thank you very much for your reply! I noticed, that I forgot to mention (really sorry about that!), that my analog hard block is both connected to a big 1.8V digital core and some small 3.3V modules: the hard block has more than 1300 pins, some of which then need level shifting - and I didn't want to instantiate explicitly the level shifter, that's why I'm working with the CPF.

    What you wrote, is exactly what I get confused with, since it is to me not very clear how to treat the (explicit) power ports of my macro.

    I managed in the meanwhile to get a working flow, but I still have doubts, here one of them for example:

    1) the analog hard block has power ports h_VDD33D, h_VDD18D and a common ground for both h_VSSD.

    2) the top level (chip) has top_VDD33D, top_VDD18D and top_VSSD, which connect directly to h_VDD33D, h_VDD18D and h_VSSD.

    3) the digital core has two power domains (PD18 and PD33), also powered by top_VDD18D and top_VSSD, and top_VDD33D and top_VSSD respectively - this information is correctly defined in the CPF.

    4) since the hard block is connected to both top_VDD33D and top_VDD18D I defined inside set_macro_model also two power domains for the macro.

    Now, in the macro definition: what about the ports h_VDD33D, h_VDD18D and h_VSSD?

    If I associate them to a power domain, for example like this:

    create_power_domain -name h_PD33 -boundary_ports {h_VDD33D....}

    create_power_domain -name h_PD18 -boundary_ports {h_VDD18D}

    I don't know where to put the h_VSSD, since it "belongs" both power domains. I tried to put h_VSSD in one of them and I get level shifters between top_VDD18D and h_VDD33D!!

    If I don't say anything about h_VDD33D, h_VDD18D, h_VSSD in the macro definition I get a CLP error since every port has to be either boundary port, feedthrough, analog or floating.

    So the stable solution I found, which gives no errors, but does not look very elegant is to define all the power and ground ports (pins) of my hard block as floating and set them as -primary_power and -primary_ground of the respective power domain: what do you think about it?

    Thanks,

    Gabriel

Reply

  • Hi Shawn!

    Thank you very much for your reply! I noticed, that I forgot to mention (really sorry about that!), that my analog hard block is both connected to a big 1.8V digital core and some small 3.3V modules: the hard block has more than 1300 pins, some of which then need level shifting - and I didn't want to instantiate explicitly the level shifter, that's why I'm working with the CPF.

    What you wrote, is exactly what I get confused with, since it is to me not very clear how to treat the (explicit) power ports of my macro.

    I managed in the meanwhile to get a working flow, but I still have doubts, here one of them for example:

    1) the analog hard block has power ports h_VDD33D, h_VDD18D and a common ground for both h_VSSD.

    2) the top level (chip) has top_VDD33D, top_VDD18D and top_VSSD, which connect directly to h_VDD33D, h_VDD18D and h_VSSD.

    3) the digital core has two power domains (PD18 and PD33), also powered by top_VDD18D and top_VSSD, and top_VDD33D and top_VSSD respectively - this information is correctly defined in the CPF.

    4) since the hard block is connected to both top_VDD33D and top_VDD18D I defined inside set_macro_model also two power domains for the macro.

    Now, in the macro definition: what about the ports h_VDD33D, h_VDD18D and h_VSSD?

    If I associate them to a power domain, for example like this:

    create_power_domain -name h_PD33 -boundary_ports {h_VDD33D....}

    create_power_domain -name h_PD18 -boundary_ports {h_VDD18D}

    I don't know where to put the h_VSSD, since it "belongs" both power domains. I tried to put h_VSSD in one of them and I get level shifters between top_VDD18D and h_VDD33D!!

    If I don't say anything about h_VDD33D, h_VDD18D, h_VSSD in the macro definition I get a CLP error since every port has to be either boundary port, feedthrough, analog or floating.

    So the stable solution I found, which gives no errors, but does not look very elegant is to define all the power and ground ports (pins) of my hard block as floating and set them as -primary_power and -primary_ground of the respective power domain: what do you think about it?

    Thanks,

    Gabriel

Children
No Data

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.