From: Gopala K. <kri...@gm...> - 2007-07-14 13:02:37
|
Hi guys, I am almost done with my exams(just one more to go). Hurray!! Now i can peacefully get back to porting qucs. Some food for thought: I wanted to know how many of you have tried/looked at geda(http://www.geda.seul.org/) ? Probably we can use some of their ideas. We may also try to be part of them (left to admins to decide). There are lots of tools there. Though the user interface doesn't look intutive(my opinion) they seem to powerful with nice scripting support and intergration to all kinds of tools. -- Cheers, Gopala Krishna A |
From: roucaries b. <rou...@gm...> - 2007-07-14 13:50:27
|
On 7/14/07, Gopala Krishna <kri...@gm...> wrote: > Hi guys, > I am almost done with my exams(just one more to go). Hurray!! > Now i can peacefully get back to porting qucs. > > Some food for thought: > I wanted to know how many of you have tried/looked at > geda(http://www.geda.seul.org/) ? we could also try a merge with kicad http://www.lis.inpg.fr/realise_au_lis/kicad/ Their layout tool is quite impressive... > Probably we can use some of their ideas. We may also try to be part of > them (left to admins to decide). There are lots of tools there. Though > the user interface doesn't look intutive(my opinion) they seem to > powerful with nice scripting support and intergration to all kinds of > tools. > I have one day week ago a chat with vincent about filter tool. And we talk about python scripting. In fact scriptiong seems quite simple with something like boost (http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/libs/python/doc/tutorial/doc/exposing_classes.html) or simpler swig (www.swig.org/). Moreover python seems to be a good choice because they are a lot of binding for library like umfpack, and python is a standard tool is the research community. Ragards bastien > Cheers, > Gopala Krishna A > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Lisandro
<per...@gm...> - 2007-07-14 21:05:29
|
El S=E1bado 14 Julio 2007, roucaries bastien escribi=F3: > On 7/14/07, Gopala Krishna <kri...@gm...> wrote: > > Hi guys, > > I am almost done with my exams(just one more to go). Hurray!! > > Now i can peacefully get back to porting qucs. > > > > Some food for thought: > > I wanted to know how many of you have tried/looked at > > geda(http://www.geda.seul.org/) ? > > we could also try a merge with kicad > http://www.lis.inpg.fr/realise_au_lis/kicad/ > Their layout tool is quite impressive... IMHO the best thing would bee to do all schematics/simulations in qucs and = the=20 rest in kicad.=20 Of course, I guess we would all benefy if the two groups make soft that are= =20 compatible between them. Regards, Lisandro. =2D-=20 Un viejo proverbio de El.Machi dice que la memoria es como las papas fritas... =A1nunca sobran! Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ #bblug irc.freenode.net |
From: Gopala K. <kri...@gm...> - 2007-07-14 15:25:27
|
> we could also try a merge with kicad > http://www.lis.inpg.fr/realise_au_lis/kicad/ > Their layout tool is quite impressive... Yup! But unfotunately all these tools are written using other toolkits(other than qt). So we have to make our own layout tool. Anyway noone will prevent us from looking at their code and using them as required ;) (GPL *v2*) > I have one day week ago a chat with vincent about filter tool. And we > talk about python scripting. In fact scriptiong seems quite simple > with something like boost > (http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/libs/python/doc/tutorial/doc/exposing_classes.html) > or simpler swig (www.swig.org/). > > Moreover python seems to be a good choice because they are a lot of > binding for library like umfpack, and python is a standard tool is the > research community. Great! I too love python :) If you have some insights of introducing scripting even to schematic editor can you give some usecases. I'd like to know what kind of api need to be exposed. Is it possible to create a dummy exposable class that delegates all the required scriptable calls to internally used class and then just expose this class. This way we may easily be able to add scripting support. -- Cheers, Gopala Krishna A -- Cheers, Gopala Krishna A |
From: roucaries b. <rou...@gm...> - 2007-07-14 16:24:08
|
On 7/14/07, Gopala Krishna <kri...@gm...> wrote: > > (http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/libs/python/doc/tutorial/doc/exposing_classes.html) > > Awesome! Thanks for the link :) Personnally I prefer swig but it is a matter of taste (moreover swig allow to export binding in perl, ruby etc) A good tutorial is http://www.geocities.com/foetsch/python/extending_python.htm Regards bastien > -- > Cheers, > Gopala Krishna A > |
From: Svenn A. B. <sve...@go...> - 2007-07-15 11:24:31
|
On 7/14/07, Gopala Krishna <kri...@gm...> wrote: > Hi guys, > I am almost done with my exams(just one more to go). Hurray!! > Now i can peacefully get back to porting qucs. > > Some food for thought: > I wanted to know how many of you have tried/looked at > geda(http://www.geda.seul.org/) ? > Probably we can use some of their ideas. We may also try to be part of > them (left to admins to decide). There are lots of tools there. Though > the user interface doesn't look intutive(my opinion) they seem to > powerful with nice scripting support and intergration to all kinds of > tools. Don't use the idea of using guile as the embedded scripting language. They have a lot of problems with the language living its own life and dependencies in distributions make life hard for users. They also have problem supporting the windows platform since they are using Gtk. Not that Gtk is not possible to support on windows, but it is so hard that noone have stepped up to take care of it. Mac is only supported under X11. The user interface is not intuitive, but it is fast for frequent users, just like Cadence. If you want to take Qucs into the integrated circuit design, you have to have extencive keyboard short-cut possibilities, black background instead of white (IC-designers sit the whole day in front of their screen) and the naming of the nets in Qucs must change or add to have the net name tied to the net withouth that funny looking rubber band added to it. If the rubber band is made possible to turn off it would be good as designers from time to time want to know which labels are tied to which wires. The simulator must be made pluggable. Just like Cadence, it should be irrelevant to the GUI which simulator is providing the data. You will need some real good infrastructure to make this happen at an acceptable speed. When that is done, Qucs is a real alternative to million dollar EDA tools. gEDA solves this by having a separate netlist generator which currently doesn't support hierarchies very well. -- Svenn |
From: Gopala K. <kri...@gm...> - 2007-07-15 22:54:26
|
Dear list, Thanks Svenn for your thoughtful insights. I've a dilemma. Here goes .. How this basic idea originated ? Recently i had few converstions(mail) with ktechlab people. The project admin had a flair idea of merging qucs-ktechlab when they port ktechlab to kde4. He also asked my help. Due to exams i couldn't answer him appropriately. I got some random thoughts about merging/reusing several available gpl-eda or simulator tools. I explored geda a bit and i found their goal motivating. Result: I looked at qucs.sf.net again and the main goals listed here state qucs is aimed to be circuit simulator. Immediately a doubt struck me whether to stick on to this ? The answer might sound obvious(expansion of qucs) but last year before starting to think about the port, we had ideas of doing pcb support for qucs. My State: Now i am confused on how to proceed the qucs-qt4 port. If we think of any mergers or additionals like these , i feel it would be wise to incorporate proper infrastructure from now on. But they have to be planned and requires some hands and *proper guidance*. That is the reason i asked these questions. Well looking at Svenn's reply it seems too tough at the moment without sufficient hands. What are your views on this ? What should future qucs be ? -- Cheers, Gopala Krishna A |
From: roucaries b. <rou...@gm...> - 2007-07-16 10:08:35
|
aOn 7/16/07, Gopala Krishna <kri...@gm...> wrote: > Dear list, > > Thanks Svenn for your thoughtful insights. > I've a dilemma. Here goes .. > > How this basic idea originated ? > Recently i had few converstions(mail) with ktechlab people. The > project admin had a flair idea of merging qucs-ktechlab when they port > ktechlab to kde4. He also asked my help. Due to exams i couldn't > answer him appropriately. I got some random thoughts about > merging/reusing several available gpl-eda or simulator tools. I > explored geda a bit and i found their goal motivating. Geda goals is motivating. Create a true eda is also motivating. However, please do not commit the same mistake than cadence spice (ie graphic interface must be always used), or geda (a really hard to understand and ugly interface). Please clearly separate the core functionnality (as today) and the graphical layer. And like Sven I do not think scheme is a good scripting language. I have no objection for merging ktechlab if and only if it is modular. For processor simulation it is quite simple because basically processor is a state machine, therefore you need only to create a generic class for state machine. But you need to carefull in order to avoid slowing the simulation. Basically if the state machine is synchrone you need to refresh simulation every rising or falling clock signal (ie you could save a lot of computation by caching), but a lot of processor have asynchronous input, and this asynchronous input could change by changing internal configuration :-( Morevover, you MUST simulate fannout and delay on processor pin. This is really important and sometimes not really well documented in datasheet. Last but not least, I believe ktechlab is only a transationnal option because industrial standard for this kind of simulation is VHDL-AMS. > Result: > I looked at qucs.sf.net again and the main goals listed here state > qucs is aimed to be circuit simulator. Immediately a doubt struck me > whether to stick on to this ? The answer might sound obvious(expansion > of qucs) but last year before starting to think about the port, we had > ideas of doing pcb support for qucs. > > > My State: > Now i am confused on how to proceed the qucs-qt4 port. If we think of > any mergers or additionals like these , i feel it would be wise to > incorporate proper infrastructure from now on. But they have to be > planned and requires some hands and *proper guidance*. > > That is the reason i asked these questions. Well looking at Svenn's > reply it seems too tough at the moment without sufficient hands. > > What are your views on this ? What should future qucs be ? For me the priority is a layer tool, a method of moment simulator (I know some fortran code), a fem full-wave simulator (based on http://home.gna.org/getfem/ or ,http://www.csc.fi/english/pages/elmer/). or fdtd (http://carsten.welcomes-you.com/radarfdtd/). Regards Bastien > -- > Cheers, > Gopala Krishna A > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Svenn A. B. <sve...@go...> - 2007-07-18 17:47:39
|
On 7/16/07, roucaries bastien <rou...@gm...> wrote: > aOn 7/16/07, Gopala Krishna <kri...@gm...> wrote: > > Dear list, > > > > Thanks Svenn for your thoughtful insights. > > I've a dilemma. Here goes .. > > > > How this basic idea originated ? > > Recently i had few converstions(mail) with ktechlab people. The > > project admin had a flair idea of merging qucs-ktechlab when they port > > ktechlab to kde4. He also asked my help. Due to exams i couldn't > > answer him appropriately. I got some random thoughts about > > merging/reusing several available gpl-eda or simulator tools. I > > explored geda a bit and i found their goal motivating. The goal is motivating, indeed. The problem gEDA has is simply its rigidness vs. becoming really useful for chip design in an enterprise environment. What do I mean by that? If I want to have a working version of gEDA I have to compile it myself. Some of the dependencies are really tricky. Guile is the most tricky one and mostly the killer. There are developers who have made chips with gEDA, but I only know one. That is too few for a program that has a 10 year lifetime. The idea of having a separate netlister with plug-ins for the netlisting formats are really a good one. Problem is that the netlister does not support hierarchies very good, and you have to learn a new, difficult programming language to get a new back-end. (Difficult is not only because lisp is a bit different, but guile development is mostly ignoring backwards compatibility at all...) > > Geda goals is motivating. Create a true eda is also motivating. Yes it is, but on the other side the user base is so small that real EDA is still a domain for multi-million companies. Open source community does have a lot of alternatives, but they are all scattered applications. There must be some glue to tie the all together. Find that glue. > However, please do not commit the same mistake than cadence > spice (ie graphic interface must be always used), or geda (a really > hard to understand and ugly interface). Please clearly separate the > core functionnality (as today) and the graphical layer. Actually, newer versions of Cadence have really separated graphical layer and simulator. With an extra license you get all the docs you need to write the interface for a new simulator in to cadence. But don't forget that Cadence sell their own simulator, Spectre, which is really expencive and thus Cadence is not so eager that users should integrate the qucs or the gnucap or the ng-spice simulators into it. Spectre is a horror. It has a decent list of simulation features, but it has horrible data processing features. Most Hspice users are fairly used to do things from the command line with schematic capture from cadence composer, but when these guys have to transfer to Spectre, there is at first an uproar and then they learn about ocean. Ocean is the Cadence scripting language that make the cadence SKILL programming language a bit easier for EE's. It is a horrible mix of C and lisp syntax and the stand alone interpreter is slow, but the simulations are reproducable and things may even run over-night without a simple mouse-click. Problem is still that the waveform viewers from Cadence are horror stories and the native storage format for analog simulations are proprietary. >And like Sven I do not think scheme is a good scripting language. Tcl is the only scripting language that you really should evaluate for such operations. It is not the newest language, but it was made with EDA automation in mind by somebody who had experience with EDA. (John Ousterhout) it is stable, it is well documented and it used to be the GUI scripting language of choice until Python occured. Tkinter in modern Python is still the Tk part of Tcl/Tk. But I think it is more important to take small successful steps than to have too great ideas and never reach the goal. -- Svenn |
From: Gopala K. <kri...@gm...> - 2007-07-18 18:43:06
|
Well thanks people for your active participation in this thread :) Now i am clear with the things. Actually to be frank i'm not an electronics/electrical person. Infact i'm doing engineering in Information Science. Yet i am always keen to learn about electronics too and when i learnt programming for the first time, i wanted to do my own circuit simulator with good gui. I realised soon that it wasn't possible with my limited knowledge. Then i played (novice level assignments) with ngspice, gnucap, ktechlab,geda and finally qucs. Since i knew qt i started with qucs with small patch for gui improvements. Finally i got hooked up with job of porting to qt4. So please do excuse me for random distracting thoughts. These kinds of goals are too tough to realize without proper planning, people and right knowledge. Also i'm trying to think about very distant future which is pointless at the moment. I really feel Svenn is right with this sentance > But I think it is more important to take small successful steps than > to have too great ideas and never reach the goal. Thanks once again for your thoughts :) -- Cheers, Gopala Krishna A |
From: roucaries b. <rou...@gm...> - 2007-07-18 19:03:13
|
On 7/18/07, Svenn Are Bjerkem <sve...@go...> wrote: > On 7/16/07, roucaries bastien <rou...@gm...> wrote: > > aOn 7/16/07, Gopala Krishna <kri...@gm...> wrote: > > > Dear list, > > > How this basic idea originated ? > > > Recently i had few converstions(mail) with ktechlab people. The > > > project admin had a flair idea of merging qucs-ktechlab when they port > > > ktechlab to kde4. He also asked my help. Due to exams i couldn't > > > answer him appropriately. I got some random thoughts about > > > merging/reusing several available gpl-eda or simulator tools. I > > > explored geda a bit and i found their goal motivating. > > The goal is motivating, indeed. The problem gEDA has is simply its > rigidness vs. becoming really useful for chip design in an enterprise > environment. What do I mean by that? If I want to have a working > version of gEDA I have to compile it myself. Some of the dependencies > are really tricky. Guile is the most tricky one and mostly the killer. > There are developers who have made chips with gEDA, but I only know > one. That is too few for a program that has a 10 year lifetime. Dependencies are tricky but sometimes you need to have dependencies. For instance I do not want to write my own optimized umfpack function, because it is really really tricky > The idea of having a separate netlister with plug-ins for the > netlisting formats are really a good one. Problem is that the > netlister does not support hierarchies very good, and you have to > learn a new, difficult programming language to get a new back-end. > (Difficult is not only because lisp is a bit different, but guile > development is mostly ignoring backwards compatibility at all...) I agree that netlist plugger is a really good idea. And we could do this with qucs using text to xml transform. > > Geda goals is motivating. Create a true eda is also motivating. > > Yes it is, but on the other side the user base is so small that real > EDA is still a domain for multi-million companies. Open source > community does have a lot of alternatives, but they are all scattered > applications. There must be some glue to tie the all together. Find > that glue. Glue is simple, merge all the possible stuff in the main tree. Morevover we could allow to create new component using pipe command or a lot of thing. > > However, please do not commit the same mistake than cadence > > spice (ie graphic interface must be always used), or geda (a really > > hard to understand and ugly interface). Please clearly separate the > > core functionnality (as today) and the graphical layer. > > Actually, newer versions of Cadence have really separated graphical > layer and simulator. With an extra license you get all the docs you > need to write the interface for a new simulator in to cadence. But > don't forget that Cadence sell their own simulator, Spectre, which is > really expencive and thus Cadence is not so eager that users should > integrate the qucs or the gnucap or the ng-spice simulators into it. I do not know that this possibility exist, perhaps my uni version does not include the whole cadence eda. But using qucs on cadence is not really useful. Let the two world not overlap > Spectre is a horror. It has a decent list of simulation features, but > it has horrible data processing features. Most Hspice users are fairly > used to do things from the command line with schematic capture from > cadence composer, but when these guys have to transfer to Spectre, > there is at first an uproar and then they learn about ocean. Ocean is > the Cadence scripting language that make the cadence SKILL programming > language a bit easier for EE's. It is a horrible mix of C and lisp > syntax and the stand alone interpreter is slow, but the simulations > are reproducable and things may even run over-night without a simple > mouse-click. Problem is still that the waveform viewers from Cadence > are horror stories and the native storage format for analog > simulations are proprietary. I do not understand why proprietary softaware reinvent the weel :-) And I totally agree with you about cadence waveform viewer. > >And like Sven I do not think scheme is a good scripting language. > > Tcl is the only scripting language that you really should evaluate for > such operations. It is not the newest language, but it was made with > EDA automation in mind by somebody who had experience with EDA. (John > Ousterhout) it is stable, it is well documented and it used to be the > GUI scripting language of choice until Python occured. Tkinter in > modern Python is still the Tk part of Tcl/Tk. What do you think? I do not follow you, you say that the only language of choise is TCL. I do not agree, because you could have tcl, python and perl for free :-) With swig you create your export in three language (and moreover lips if you want). Nice isn't? See http://www.swig.org/compat.html#SupportedLanguages That will be really useful is to create matlab hook but it is not really high in the priority list (they exist a outdated port of swig to matlab http://search.cpan.org/src/DBEAZLEY/swig1.1p5/Examples/MATLAB/) > But I think it is more important to take small successful steps than > to have too great ideas and never reach the goal. I agree, therefore the first step I think to do a big brainstorming on the type and the function we want to export as programable. Next step will to create a good data viewer (or allow gtkwave to read data), etc... Regards Bastien |