kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/06/2010 02:55 PM, Brian F. G. Bidulock wrote:
> Vesa,
>
> On Fri, 06 Aug 2010, Vesa Solonen wrote:
>   
>> I'm waiting eagerly to test your improvements on PCBnew, also the EM 
>> fied modeling is very interesting. Do you know Qucs? Qucs project may be 
>> of value for sharing the implementation and ideas. IIRC Qucs-KiCad 
>> cooperation was discussed on the list a while ago.
>>     
> The modelling uses the approximate equations that everone says
> don't rely on.  I just wanted to have the program perform the
> approximate calculations (differential impedance, delay, bussing
> NEXT and FEXT, etc.) to make it so that one does not have to
> bounce back and forth from a FEM modeller.  I have tried to
> capture sufficient information that one could write an export
> to qucs or some of the freely available FEM tools that can do
> 2.5 or even 3D EM.  I'm pushing 2.5Gbps in my current board
> design and would like to bounce up to 10Gbps and 40Gpbs in my
> next two.
>
> I'm trying to get power consuption and distribution as well as
> some thermal modelling in as well.
>
> Unfortunately most of this is not best handled from PCBNEW alone
> but I'm having a time biting PCBNEW off without tackling EESCHEMA.
> It would be good it the component library in EESCHEMA could assign
> maximum current sink into a power pin.  Assigning junction
> conductivity to footprints with, say, cvpcb would be nice too.
> Otherwise all of this stuff needs to be plugged into PCBNEW
> separately (as with netclasses).
>
> --brian
>   

I have an idea that can keep you working in PCBNEW by fabricating some
extra data for now by hand and adding it to the "netlist" file coming to
you from EESCHEMA.  I would like to switch the netlist over to an
S-record file, and can get the parser and exporter done in a day I
think.  Then you could add the data you need to it by hand with a text
editor, and step for step incrementally enrich the parser/importer which
I would have started for you in PCBNEW, and keep working over there. 
Later we can settle the score back into EESCHEMA and see how that
additional data that you add, can get into the new fancy netlist file. 
Somehow somewhere that data can be injected into the new fancy netlist
file, and technically it can be any utility, not just EESCHEMA.

I have a very simple idea that I want to explore, probably tomorrow. 
The idea is to use the XML document tree that I am already creating for
the generic netlist export, and have it spit out the S-record file from
EESCHEMA.  We just have to derive from the bare wxXmlNode and add the
Format() functions to that derived class.  This way the same tree can
generate XML or S-records.  Parsing the S-record stuff is fairly easy,
recursively.  And I would do the initial pass at that tomorrow probably
(well today actually, its late).

Loosely speaking, see the attached for the basic idea.  What I like
about this is that we are building the tree up front to be compatible
with XML in ram.  This leads to a cleaner S-record data file, and
significantly less code in the export realm anyway.


Dick



class XATTR : public wxXmlAttribute
{
public:
    XATTR() :
        wxXmlAttribute()

    XATTR( const wxString& name, const wxString& value ) :
        wxXmlAttribute( name, value )
    {
    }

    // well whatever I did for the specctra export here:
    virtual int FormatContents( )
    {
        for( XNODE*
    }


    virtual int Format()
    {
    }
};


class XNODE : public wxXmlNode
{
public:
    XNODE() :
        wxXmlNode()
    {
    }

    }

    XNODE( XNODE* aParent, wxXmlNodeType type,
              const wxString& name,
              const wxString& content = wxEmptyString ) :
        wxXmlNode( aParent, type, name, content )
    {
    }


    // well whatever I did for the specctra export here:
    virtual int FormatContents( )
    {
        // output attributes first if they exist

        // output children if they exist.

        // output "contents" if it exists.  Use quote need checker to wrap contents if needed.

        // A good XML element will not have both children AND contents, usually one or the other.
        // children != attributes in the above statement.

        for( XNODE*...
    }


    virtual int Format()
    {
    }
};