Resources

Posted by admin on August 2, 2016

 

AutoRoute IC bypass CAPs

Cost and Tax

Eagle Net Classes

Electra under WINE

 

 

    Go Gridless

    Grid map v.s. Shape Based

    How it works

    Iterative Recornering

 

 

      Necking down to thin pads

      Running ELECTRA on MAC with Parrallels 

      Signal & Power/Gnd layers

      Single layer routing with jumpers

          


 

Single layer routing with jumpers

If you want to have straight jumpers on let’s say top layer, you can follow a strategy like this:

bus diagonal
fanout 5 (direction out)
cost layer bottom low
cost via high
cost layer top high (type length)
cost layer top forbidden (type way)
route 10

clean 2
route 10 16
clean 2
filter 5
recorner diagonal
status_file

Using the GUI instead:

layer_cost.jpg



ELECTRA under Wine

Customers are using succesfully paid version of Wine sold by Crossover and can enjoy using ELECTRA on a MAC platform.

wine.jpg



Running ELECTRA on MAC with Parallels

We have users successfully using Electra under Parallels 5-0-9308 on Macbook Pro running OS
Mac OS 10.6.2. They can even access the .dsn mac files from Electra.

Here are some user notes:

The configuration I use is that Parallels share the VM with the bootcamp
disk (a dual boot partion installed via the bootcamp wizard in
Applications/Utilities - but I don't use the dual boot)
I don't think this is needed to get Electra to work under Parallels.

I guess the important setting for the other mac user is, like I did to set
the mac address in the paralles desktop Virtual_Machine Configure to the
same Mac address as his  en0 network card
found in the applemenu (top left conrner of the screen) about this mac/More
info/Network/Ethernet or but entering the unix command "ifconfig -a" in the
terminal prompt (terminal is an application in the utilities folder in the
applications folder)



Go gridless

To go gridless, you must specify very small values for the grids, but not zero. For example:

unit mil
grid wire 1
grid via 1

Using the GUI instead:
gridless.jpg 



Necking down to thin pad 

set pad_wire_necking 1

It tells the router, when it attempts to route to a SMD pad with a fat wire, to instead use the SMD pad width on the last segment to the target pad.



Iterative Recornering

Regarding the recorner command, here is some more information that should help understand how it works and improve your results. Recorner command is performed on 90 degrees wire corners exiting pins and vias, as well as bend and slant (successive bends) wire configuration.

Pin_setback, slant_setback and bend_setback options can be used to control which corner type is changed and you can override the default setback values as well:

Below are pictures that illustrate the 3 configurations.

A short version of the command:

recorner diagonal

Successive calls should give better results, for example:

unit inch
recorner diagonal 1 1 1
recorner diagonal .5 .5 .5
recorner diagonal .25 .25 .25
recorner diagonal .2 .2 .2
recorner diagonal .1 .1 .1

recorner.jpg

 

Cost and Tax

The “cost” command is used to fix a constant cost value, but the “tax” command is a cost multiplier that is applied to the internally calculated cost.

The router uses internal costing that varies based on the routing pass, so I recommend NOT to change all cost parameters that are directly related to routing, such as “squeeze” and “cross”, for the other parameters such as cost “via”,  “way”, “off_center” or “side_exit” that is OK to change upfront. 

I recommend using the tax command instead, this way the router still follows it’s internal cost schedule, which is key to converge to a solution. 

For example: 

tax squeeze .5
tax cross 1.3
cost way 50
cost via 8
cost off_center 2
cost side_exit 2
route 20
clean 2

If you are routing a 2 layer board and looking at minimizing the # of vias, don’t hesitate to run hundred of passes: 

cost way low
cost via 70
route 20
clean 2
route 50 16
clean 2
route 100 16
clean 2
route 200 16
clean 2
route 300 16
clean 2

Using the GUI instead:

cost_way.jpg


 

Control fanout min/max distance 

This is how you can control the minimum fanout distance:

The fanout pass defines a max length (to keep shorter), and a minimum length by indirectly using the spacing rule.. For example: 

rule pcb (clearance 25 (type smd_via_same_net))

Fanouts are typically better if kept to a max length (short), but items like pad shorts to vias, ease of manufacturing, ease of rework are better with longer fanouts.

 Using GUI instead:

clear_smd_via.jpg

 

Autoroute connections between IC's and their bypass CAPs 

select net GND
select net VCC
limit via 0
route
limit via -1
unselect all

And then continue with remaining nets:

fanout 5 (pin_type signal)

If some power pins can be fanned out (non clocks etc...), you can use this:

fanout 5 (pin_type power) (via_share off) (pin_share off)


Using GUI:

fanout.jpg

Eagle Net Classes

In Eagle layout, the net class definition is a 2 step process.
First, create a class from the menu “Edit/Net Classes” and assign width/clearance values.

eagle_class1.jpg

Then define the nets that belongs to the power net class:

eagle_class2.jpg

 

Signal & Power/Ground layers 

There are various ELECTRA configurations (2L, 4L, etc...) tailored to the max number of signal layers required. There is no restriction in the number of power/ground layers.

A signal layer is defined as being of type signal or mixed, with its direction not being turned OFF. 

Autorouting with full planes and split planes is supported. In case of a full plane, there is no need to specify a polygonal region,  the board outline is used as limiting region.

In presence of split planes on same layer, polygonal areas need to be defined along with the associated use_net, the router understands the presence of those polygonal areas and will assume connectivity just by plugging the proper via within the allowed area:


How ELECTRA autorouter works

The router uses an adaptive algorithm and looks at the evolution of the parameters between the routing passes and adjust its internal costs.

More explicitly, the routing solution is dependant on the net ordering and so the algorithm goal is to find a solution to the problem that minimizes the number of unroutes. The router allows conflicts (crossing + spacing violations) and initially routes all connections with conflicts. The goal is to untangle the nets and get rid of the conflicts and find the solution with the minimal number of unroutes and hopefully zero unroute. In order to find the best minimum and not get stuck in what is called a "local" minimum I am using a multipass approach with a special cost function that allows "free" conflicts at the beginning and as the passes evolves the costs for conflicts evolves in a controlled fashion. So the pass number is a key element used as index into the costing tables. This is why there is a control into the initial pass number used when re-invoking the router. For example after a route 25, it is not a good idea to run another route 1 for the remaining unroutes, as this would provide a low cost for generating conflicts on those remaining nets.

>How to continue autorouting after high 90% completion has been found so that a "better" solution?

>Why should the start pass be specified as (n+1) or 16 in the route command.  What is special about the first 15 passes that prompts guideline?

To continue you should add the second argument to the route command, if you specify a initial pass of 16, that is fine as after 16 passes the conflicts are getting very high anyways.

> If the 'bestsave' feature is enabled for a command file sequence, does the route command automatically read in the 'bestsave.rte' file before the autoroute is executed? 

If several route commands are given in a command file, then each route command will continue from where the previous route command left off.  
With bestsave turned on, the router compares the results at the end of each routing passes and saves the best one to a file called bestsave.rte. That's it, it is up to the user to decide to take the result by explicitly reading the wire file.



ELECTRA Shape-based v.s. Grid-based routers

Grid-based routers (Eagle, etc...), model the PCB by using grid maps. Their weaknesses are excessive memory requirements, long search time and inability to handle placement of components with mix units having pads off grid. ELECTRA Shape-based representation model requires memory for storing shapes only AND not a 2D map of grid points. Grid-mapped system require much larger storage to store a shape mapped to grid points, as opposed to storing the required shapes only. 
Another advantage of Shape-based technology is the natural support of complex design rules. Each shape on each layer inherits its own unique set of design rules. This way ELECTRA can handle the most complicated design requirements.