Actions
Forum Thread Details
  • Replies 6 replies
  • Subscribers 188 subscribers
  • Views 754 views
  • Users 0 members are here
Related

Feature request for physical design reuse capability in the board editor

rachaelp

Hi All,

 

I mentioned this briefly as part of another thread a little while back but I don't think it's been raised as an actual feature request in its own right before.

 

So when using PADS there is a really useful feature called physical design reuse. What it allows you to do is as follows:

 

1) Take a design which has a lot of repeated circuitry within the design (whether within a schematic sheet or across hierarchy, it's not fussy!)

2) Place and route a single "channel" of the identical circuit blocks.

3) Create a script which encapsulates the details of the placement and routing.

4) Apply that script to subsequent channels to place and route the remaining identical blocks.

 

This would be really useful of many different things, here are just a few examples:

 

1) Audio input / output circuitry of multi-channel audio gear, e.g. Pro audio gear I have worked on has up to 16 identical input and output channels

2) Multi channel motor drive circuits, e.g. 3D Printer or CNC machine control circuits.

3) DDR memory channel placement and breakout, e.g. TI's DM8168 has two DDR3 controllers, copying one placement and the majority of routing to the other would be a huge time saver.

4) DC-DC converters, e.g. I often find I have several identical circuits for different voltages on large boards.

 

There are a few examples on youtube of how this is implemented in PADS which are worth taking a look at which I will link below. When I mentioned this on another thread previously it was suggested that this would best be done as part of the hierarchy feature but I actually think it would be best to be kept absolutely separate from that as it's not dependant on hierarchy at all. Linking this feature to using hierarchy would severely limit it's potential usefulness I think.

 

Here are the youtube examples:

 

https://www.youtube.com/watch?v=mG8MhuUKC6c

https://www.youtube.com/watch?v=9OyAlInoIT0

 

Many thanks,

 

Rachael

Parents

  • On 14.04.2016 12:36, rachaelp wrote:

     

    I want to support this suggestion, but I'd like it to be done this

    specific way.

     

    A sub-project should be instanciated as a library component. This should

    of course also make it possible to update the instance, like you with

    libraries like would do if you change a package.

    It must allow an extended "smash", so values can be replaced or parts

    can be moved slightly off the master sub-design.

     

    Some examples of circuits I would reuse are:

    -SMPS (switch mode power supply) design (IC,inductor,capacitors,..)

    -Video (plug+,equalizer,IC,..)

    -Ethernet (plug,magnetics,phy,..)

    -FPGA's (chips,decoupling caps (lots!),configuration memory,..)

     

    It is important to support update of all the instanciations, cause I may

    very design for 10 video ports and 5 SMPS, and I really don't like to

    manually modify each one.

     

     

    This could maybe be handled nicely by the existing module structure, but

    I think the modules would work better if they were broken out as a

    separate project.

     

    I also think it's time to implement proper page connectors

    so that the IO can be defined in a much nicer way, both internally in

    projects, and between them in a subproject case. I think (hope) they can

    exist without damaging the existing structure.

     

     

     

  • in reply to autodeskguest

    Morten wrote:

     

    I want to support this suggestion, but I'd like it to be done this

    specific way.

     

    A sub-project should be instanciated as a library component. This should

    of course also make it possible to update the instance, like you with

    libraries like would do if you change a package.

    It must allow an extended "smash", so values can be replaced or parts

    can be moved slightly off the master sub-design.

     

    Some examples of circuits I would reuse are:

    -SMPS (switch mode power supply) design (IC,inductor,capacitors,..)

    -Video (plug+,equalizer,IC,..)

    -Ethernet (plug,magnetics,phy,..)

    -FPGA's (chips,decoupling caps (lots!),configuration memory,..)

     

    It is important to support update of all the instanciations, cause I may

    very design for 10 video ports and 5 SMPS, and I really don't like to

    manually modify each one.

    I think it could be done the way you suggest and if this were the only option available to me I would probably still find it useful but I think it's probably also more restrictive than the very generic way Mentor Graphics approach this in PADS. There are advantages and disadvantages to both ways I think. For my usage I would prefer having it so you could save a script file which encapsulated the placement and routing information (the Mentor way) to be subsequently re-applied to other circuit blocks and this is the approach I am going to take when I try and implement this in a ULP. I think I could incorporate some of your requirements, specifically to enable instances of a reuse block to be updated easily and of course by the nature of how this way works, any block can be altered once the reuse block information had been applied so variations based on that block are easily accommodated.

    Morten wrote:

     

    This could maybe be handled nicely by the existing module structure, but

    I think the modules would work better if they were broken out as a

    separate project.

    I specifically wouldn't want it as part of the module structure as I think this is far too restrictive and as the module functionality isn't a fully capable and polished feature at this point anyway it's not the most stable starting point.

    Morten wrote:

     

    I also think it's time to implement proper page connectors

    so that the IO can be defined in a much nicer way, both internally in

    projects, and between them in a subproject case. I think (hope) they can

    exist without damaging the existing structure.

    Yes I 100% agree with this!

Reply
  • in reply to autodeskguest

    Morten wrote:

     

    I want to support this suggestion, but I'd like it to be done this

    specific way.

     

    A sub-project should be instanciated as a library component. This should

    of course also make it possible to update the instance, like you with

    libraries like would do if you change a package.

    It must allow an extended "smash", so values can be replaced or parts

    can be moved slightly off the master sub-design.

     

    Some examples of circuits I would reuse are:

    -SMPS (switch mode power supply) design (IC,inductor,capacitors,..)

    -Video (plug+,equalizer,IC,..)

    -Ethernet (plug,magnetics,phy,..)

    -FPGA's (chips,decoupling caps (lots!),configuration memory,..)

     

    It is important to support update of all the instanciations, cause I may

    very design for 10 video ports and 5 SMPS, and I really don't like to

    manually modify each one.

    I think it could be done the way you suggest and if this were the only option available to me I would probably still find it useful but I think it's probably also more restrictive than the very generic way Mentor Graphics approach this in PADS. There are advantages and disadvantages to both ways I think. For my usage I would prefer having it so you could save a script file which encapsulated the placement and routing information (the Mentor way) to be subsequently re-applied to other circuit blocks and this is the approach I am going to take when I try and implement this in a ULP. I think I could incorporate some of your requirements, specifically to enable instances of a reuse block to be updated easily and of course by the nature of how this way works, any block can be altered once the reuse block information had been applied so variations based on that block are easily accommodated.

    Morten wrote:

     

    This could maybe be handled nicely by the existing module structure, but

    I think the modules would work better if they were broken out as a

    separate project.

    I specifically wouldn't want it as part of the module structure as I think this is far too restrictive and as the module functionality isn't a fully capable and polished feature at this point anyway it's not the most stable starting point.

    Morten wrote:

     

    I also think it's time to implement proper page connectors

    so that the IO can be defined in a much nicer way, both internally in

    projects, and between them in a subproject case. I think (hope) they can

    exist without damaging the existing structure.

    Yes I 100% agree with this!

Children
No Data