[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] orderings

From: Felix Salfelder
Subject: Re: [Gnucap-devel] orderings
Date: Sun, 11 Nov 2018 02:35:37 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Nov 09, 2018 at 06:33:49PM -0500, al davis wrote:
> Even that should be done before expansion.
> Suppose we have a degree array for a block something like this:
>       21432.33  ... 5 internal nodes, two connection nodes.
> The two connection nodes cannot be moved, but the internal nodes can
> be.  The ideal order would have a degree array:  12234.33.
> So, if the numbers were 12345.67, the updated order would be 21543.67.
> I think this is as ideal as you can get.

I figured out ordering before expansion. conceptually, this is working.
just after declaring a subcircuit there is enough structure available to
do some ordering. the code for this could go into a DEV_SUBCKT plugin,
e.g. virtual void BASE_SUBCKT::finish(). i don't know where to hook it,
so i used a hack in CARD_LIST::push_back for testing.

similarly, i managed to reorder the top level nodes.  unlike subcircuit
instances the top level cardlist does not go through new_subckt, the
reindexing could possibly be done through _sim->_nm instead. (i used a
hack, for now). it is much less obvious to me, where to put pluggable
code for the top level node ordering. i guess this is important.

I copied in the cmk ordering code, with some adaptions to connection
nodes. it's not magic, but it deals with randomly ordered netlists well
enough to be useful. it does not break eq3.fg2 as the global rcmk did.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]