[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Introduction and some questions/thoughts on gEDA/gaf...
From: Ales Hvezda <ahvezda@xxxxxxxx>
Subject: Re: gEDA-user: Introduction and some questions/thoughts on gEDA/gaf...
Date: Sun, 11 Sep 2005 21:19:07 -0400
Message-ID: <20050912011907.1CF341408269@xxxxxxxxxxxxxx>
> Hi Dan and all,
Ales,
Magnus (the trouble-maker) here...
> [snip]
> >Breaking of numerous netlisters at once is a concern. I've actualy been
> >thinking that you'd call some function or set some flag early in the
> >netlister backend to tell gnetlist to enter into hierarchical mode.
> >Hopefully that would not break all the netlisters at once...
> >
> >It has been a few years since doing a design for an FPGA in verilog, but
> >it was certainly hierarchical.
>
> Yeah, that is a concern. Basically all the netlist backends would
> have to be updated to be able to output a hierarchical netlist. Also, I'm
> not really convinced that trying to "fix" gnetlist is the right answer.
> There is a lot of cruft and rather poor design decisions within that would
> I really don't want to continue. I've been dreaming of writing a brand
> new netlister (based heavily on the good pieces of gnetlist), but without
> all the warts. The three things which really need to be implemented are:
> hierarchical buses (the most requested feature), hierarchical netlist
> output, and the ability to maintain the coupling between netlist and
> schematic (to facilitate back annotation and other nifty manipulations).
Hurray! Now, what warts (except non-support for the three features above) where
you thinking of? Would you care to spell (spit???) it out?
> [snip]
> >One of my big complaints about Skill is I wish cadence would have made
> >up their minds about "is it scheme/lisp or isn't it". It's pretty gross
> >that you can write
> >
>
> There has been some interesting discussions about scripting here
> on geda-user, but I'll get to those later. Right now, I'm once again
> considering what to do about guile (in context of a new netlister).
> As much as I like guile, it suffers from three issues (IMHO):
>
> 1) It takes over the program. I like how tcl/tk's interperter is more
> contained and encapsulated.
>
> 2) It isn't particularly portable and is the cause of a lot of porting
> problems. The maintainers of guile don't seem to care.
>
> 3) What is the future of guile? There hasn't been a release or news in
> 1/2 year now from the development group.
>
> Of course the problem is that gnetlist has a rather large number
> of scheme backends which work rather well and I would hate to lose them.
> Whatever I end up doing will have to take this into account (read: I will
> probably stick with scheme but use a different portable interpreter).
What I would consider as an alternative strategy is to phase out guile as the
basis for gnetlist backends (and please note, I am *only* speaking about
gnetlist backends) and do them in C instead. What is good with the gnetlist
environment is that it is pretty isolated from the internals, so let's keep
that. Maybe the backends in deep shit of need to have hierarchial stuff is
game to be ported into the new environment. Those backends which still uses
guile (or whatever) can do that, without necessarilly creating a limit for
those in other need. I am not sure that scripting languague is the name of the
game here. A good structured C (or C++ for that matter) environment may be the
best in the end of the day.
> PS. Please don't respond with your favorite pet scripting language as
> we have had that discussion on geda-* N times already. :-)
Didn't you know that C is my pet scripting languague? ;O)
Cheers,
Magnus