qucs parser

[Fabian Vallon]

Hi

I'm trying to implement a language module for qucs.

However, it appears, that the bm module parses the argument list for a device, using obsolete_callback(). Does this mean, I have to modify the bm module as well? Where would be the right place to implement this part?

In which way is obsolete_callback() obsolete ? I don't see a way around it yet.

All the best,
Fabian


--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone

_______________________________________________
Gnucap-devel mailing list
Gnucap-devel@...
https://lists.gnu.org/mailman/listinfo/gnucap-devel

[al davis-13]

On Tuesday 17 January 2012, Fabian Vallon wrote:
> I'm trying to implement a language module for qucs.

Thank you!!!!

I was just starting to look into doing  that myself, but if you
can do it I can do something else.  Enabling gnucap to work in
the qucs environment will be very valuable.

> However, it appears, that the bm module parses the argument
> list for a device, using obsolete_callback(). Does this
> mean, I have to modify the bm module as well? Where would be
> the right place to implement this part?

You shouldn't need to.

obsolete_callback() is a throwback to old code, made before I
had thought of the concept of language plugins.  Back then, all
parsing was done in the device modules, or in things like the
"bm" modules, which modify the behavior of a parent device.

As of now, everything except the "bm" modules has been moved
away from it.  Eventually, it will be removed completely, but
that can't be done yet.

The missing pieces are the functions set_param_by_index,
set_param_by_name, param_is_printable, param_name, param_value.  
They need to be added to the bm modules.  They will be
eventually.  Some of the bm modules have arrays of parameters,
which are not yet accomodated by the new system.




>
> In which way is obsolete_callback() obsolete ? I don't see a
> way around it yet.


_______________________________________________
Gnucap-devel mailing list
Gnucap-devel@...
https://lists.gnu.org/mailman/listinfo/gnucap-devel

[Felix Salfelder]

On Tue, Jan 17, 2012 at 09:50:15PM -0500, al davis wrote:

> [..]
>
> As of now, everything except the "bm" modules has been moved
> away from it.  Eventually, it will be removed completely, but
> that can't be done yet.
>
> The missing pieces are the functions set_param_by_index,
> set_param_by_name, param_is_printable, param_name, param_value.
> They need to be added to the bm modules.  They will be
> eventually.  Some of the bm modules have arrays of parameters,
> which are not yet accomodated by the new system.
>

Hello Al, Hello list.

We have mostly figured out the parser and the parameter passing. it
works in some examples. others should work after completing the
corresponding set_param* functions.

what remains (on gnucap side) is the probes. qucs does not issue .print
commands, but has {i,v} probe devices, which add themselves to the
printlist. we had no trouble to implement an ELEMENT doing, what the
qucs-style probes do and hacked a simple hook in the backend, which
makes these probes register the corresponding probes.

there seem to be hardly any more options (we don't want to change qucs
for that matter), and i like the idea of having devices add probes.
would you give a hint on how to implement this functionality without
breaking other things? i'd like to add this functionality, but i'm not
feeling creative...

thanks
felix

PS: i sent this mail some time in february, but our institutes mail server
seems to have eaten it. apologies if you get a second copy later this century.

_______________________________________________
Gnucap-devel mailing list
Gnucap-devel@...
https://lists.gnu.org/mailman/listinfo/gnucap-devel

[al davis-13]

On Thursday 15 March 2012, Felix Salfelder wrote:
> We have mostly figured out the parser and the parameter
> passing. it works in some examples. others should work after
> completing the corresponding set_param* functions.

Good .. I think the qucs people will like it too.

> what remains (on gnucap side) is the probes. qucs does not
> issue .print commands, but has {i,v} probe devices, which
> add themselves to the printlist. we had no trouble to
> implement an ELEMENT doing, what the qucs-style probes do
> and hacked a simple hook in the backend, which makes these
> probes register the corresponding probes.

In a way, I like the qucs approach that everything, including
probes, is a netlist element.  A while back, I implemented a
"meter" device that provides some new probes like "gain".

If all you can look at is voltage and current, the idea of all
probes are elements is a good one.  But there is a lot more to
probe than voltage and current.  .. things like gm or ft of a
transistor, instantaneous capacitance of a diode used as a
variable capacitor ....

One thought is to make a "wire" or "net" a first class object.  
A wire could be perfect, and give you a bunch of probes, or it
could have electrical characteristics like resistance or delay.  
I think this is needed anyway, for schematic and layout interface.

> there seem to be hardly any more options (we don't want to
> change qucs for that matter), and i like the idea of having
> devices add probes. would you give a hint on how to
> implement this functionality without breaking other things?
> i'd like to add this functionality, but i'm not feeling
> creative...

Here's the code for a "meter" device.  It adds a "gain" probe,
and inherits all of the probes than an ELEMENT has.


/*$Id$ -*- C++ -*-
 * Copyright (C) 2010 Albert Davis
 * Author: Albert Davis <aldavis@...>
 *
 * This file is part of "Gnucap", the Gnu Circuit Analysis Package
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 * 02110-1301, USA.
 *------------------------------------------------------------------
 * 2-port "meter" device
 * does nothing to the circuit, but has probes
 */
#include "globals.h"
#include "e_elemnt.h"
#include "u_xprobe.h"
/*--------------------------------------------------------------------------*/
namespace {
/*--------------------------------------------------------------------------*/
class DEV : public ELEMENT {
private:
  explicit DEV(const DEV& p) :ELEMENT(p) {}
public:
  explicit DEV() :ELEMENT() {}
private: // override virtual
  char   id_letter()const {return '\0';}
  std::string value_name()const {return "";}
  std::string dev_type()const {return "meter";}
  int   max_nodes()const {return 4;}
  int   min_nodes()const {return 4;}
  int   matrix_nodes()const {return 4;}
  int   net_nodes()const {return 4;}
  CARD*   clone()const {return new DEV(*this);}
  void   tr_iwant_matrix() {}
  void   ac_iwant_matrix() {}
  void     precalc_last();
  double   tr_involts()const {return dn_diff(_n[IN1].v0(), _n[IN2].v0());}
  double   tr_involts_limited()const {return tr_involts();}
  COMPLEX  ac_involts()const {return _n[IN1]->vac() - _n[IN2]->vac();}
  double   tr_probe_num(const std::string&)const;
  XPROBE   ac_probe_ext(const std::string&)const;

  std::string port_name(int i)const {
    assert(i >= 0);
    assert(i < 4);
    static std::string names[] = {"outp", "outn", "inp", "inn"};
    return names[i];
  }
};
/*--------------------------------------------------------------------------*/
/*--------------------------------------------------------------------------*/
void DEV::precalc_last()
{
  ELEMENT::precalc_last();
  set_constant(true);
  set_converged();
}
/*--------------------------------------------------------------------------*/
double DEV::tr_probe_num(const std::string& x)const
{
  if (Umatch(x, "gain ")) {
    return tr_outvolts() / tr_involts();
  }else{
    return ELEMENT::tr_probe_num(x);
  }
}
/*--------------------------------------------------------------------------*/
XPROBE DEV::ac_probe_ext(const std::string& x)const
{
  if (Umatch(x, "gain ")) {
    return XPROBE(ac_outvolts() / ac_involts());
  }else{
    return ELEMENT::ac_probe_ext(x);
  }
}
/*--------------------------------------------------------------------------*/
/*--------------------------------------------------------------------------*/
DEV p1;
DISPATCHER<CARD>::INSTALL d1(&device_dispatcher, "meter", &p1);
}
/*--------------------------------------------------------------------------*/
/*--------------------------------------------------------------------------*/

_______________________________________________
Gnucap-devel mailing list
Gnucap-devel@...
https://lists.gnu.org/mailman/listinfo/gnucap-devel

[Felix Salfelder]

On Fri, Mar 16, 2012 at 12:38:53AM -0400, al davis wrote:
> In a way, I like the qucs approach that everything, including
> probes, is a netlist element.  A while back, I implemented a
> "meter" device that provides some new probes like "gain".

if a probe is a netlist element, would that make printlists obsolete in
the end? (thats fine with me, i'm just curious)

> > what remains (on gnucap side) is the probes. qucs does not
> > issue .print commands, but has {i,v} probe devices, which
> > add themselves to the printlist. we had no trouble to
> > implement an ELEMENT doing, what the qucs-style probes do
> > and hacked a simple hook in the backend, which makes these
> > probes register the corresponding probes.
>
> Here's the code for a "meter" device.  It adds a "gain" probe,
> and inherits all of the probes than an ELEMENT has.

thanks. this meter device is similar to what our probes do. in a similar
manner i've also implemented frequency and duty-cycle probes. how do you
suggest it to add itself to the printlist (and when?). or rather: what
would be a considerable change in the backend allowing components to add
probes?

currently its not possible for the qucs parser to issue a 'print tran
v(myself)' simply because the device does not yet exist.
what would work out of the box is having qucs issue print statements,
but i dont like that idea...

thank you
felix

_______________________________________________
Gnucap-devel mailing list
Gnucap-devel@...
https://lists.gnu.org/mailman/listinfo/gnucap-devel