Feature request for physical design reuse capability in the board editor

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!

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.

Jorge Garcia wrote:

 

It can actually be a little better than that. You see you can import a

schematic into itself (INCEPTION!). So the number of copies grow 2^n for

8 channels you would only have to import 3 times, for 16 four and for 32

five imports.

 

Yes I see this does save some imports so quicker than I thought but I still think the physical design reuse method is the cleaner and right way to do it for the future if I can sort this as a ULP. I'll let you know if I manage to get a proof of concept working.

Jorge Garcia wrote:

 

I believe the BOM-EX ulp is setup for something like this, just wanted

to let you know to avoid reinventing the wheel.

I have looked at BOM-EX, and it's a useful ULP for managing components and BOM's within some limitations but it doesn't cover all my component management requirements unfortunately. The database I am using is a relational database which tracks one or more manufacturers part numbers for each of my in house part numbers and for each manufacturers part number it tracks the status of the part and possible suppliers as well as holding all of the pertinent parameters for population into attributes in the schematic. It also allows me to put say a generic part into my schematics, lets say a particular capacitor with a number of specific parameters and then I can right click on it and from my new 'Update part' option from my ULP it pulls all the parameters from the database like the corresponding internal part number, the datasheet reference etc (would be a lot more for other types of parts). Now if I do this for all my parts then I have a design with completely populated parameter attributes and internal part numbers. I can then generate a BOM based on my part numbers and from that get the list of full manufacturers part numbers and suppliers by querying my database. I've seen other solutions for this where people try to hook into Octopart with their API's but I generally find that to be slow and not reliable and not everything is in Octopart anyway. So EAGLE doesn't support ODBC which is a shame which means my database access took a little more legwork to get working but I found a good way to get it to work and it's largely there, I just need to finish off a few bits of the script and finish creating and populating some tables in my database.

Best Regards,

Rachael

On 4/15/2016 4:46 AM, rachaelp wrote:

Hi Jorge,

 

Thanks for your reply, and I agree your suggestions do enable a similar

effect to an extent but there are limitations. For example if we take

the the import EAGLE drawing way, I can do this but if I have a small

piece of circuitry which I can normally fit say 8 channels per page, to

have the schematics with 8/16/32 channels I would have to import this

8/16/32 times and then go about restructuring the schematics to get

everything where I need it to be. It's definitely a time saver on the

layout but a lot of it I think will be mitigated by the extra work of

re-structuring the schematics. It's something that is likely of benefit

where there are a smaller number of reasonably sized identical blocks

that need reusing though so this is definitely going to be helpful.

Hi Rachael,

It can actually be a little better than that. You see you can import a

schematic into itself (INCEPTION!). So the number of copies grow 2^n for

8 channels you would only have to import 3 times, for 16 four and for 32

five imports.

  I'm currently in the middle of finishing off the ULP

which links my back end components database to EAGLE for better

component management, once I have finished that off I will take a look

at this.

I believe the BOM-EX ulp is setup for something like this, just wanted

to let you know to avoid reinventing the wheel.

hth,

Jorge Garcia

Hi Jorge,

Thanks for your reply, and I agree your suggestions do enable a similar effect to an extent but there are limitations. For example if we take the the import EAGLE drawing way, I can do this but if I have a small piece of circuitry which I can normally fit say 8 channels per page, to have the schematics with 8/16/32 channels I would have to import this 8/16/32 times and then go about restructuring the schematics to get everything where I need it to be. It's definitely a time saver on the layout but a lot of it I think will be mitigated by the extra work of re-structuring the schematics. It's something that is likely of benefit where there are a smaller number of reasonably sized identical blocks that need reusing though so this is definitely going to be helpful.

I actually think I have an idea how it may be done using ULP, I have the concept in my head of how I might do it but I need to do a bit more research first and then I will have a go and see if I can get a proof of concept working. I'm currently in the middle of finishing off the ULP which links my back end components database to EAGLE for better component management, once I have finished that off I will take a look at this.

Best Regards,

Rachael

On 4/14/2016 6:36 AM, rachaelp wrote:

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.

There is kind of a way to do this already using File > Import > EAGLE

drawing. The methodology would go something like this:

1. Draw one channel as a consistent brd/schematic pair.

2. Open the schematic in which you want to reuse this design.

3. Go File > Import > EAGLE Drawing.

4. Select the schematic to import (the board will come with it).

5. A dialog will pop up showing any naming conflicts with existing

signals. Make sure everything looks good then click OK.

6. You will now see the channel imported as additional schematic sheets

and the layout is perfectly preserved on the board, along with consistency.

It's not the same as what you have suggested, but it's a means to

achieve a similar effect. It's also completely isolated from hierarchy.

 

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.

Within the framework of hierarchy, the mod-duplicate ULP can almost

achieve the script like behaviour, however it has issues with global nets.

hth,

Jorge Garcia