On Jun 1, 2011, at 2:05 AM, DJ Delorie wrote:
Why have a core at all? One of the issues with the current gnetlist
is that it cannot be ported to a different Scheme implementation,
because the core is Guile-specific. Why not start from Scheme
functions for reading/writing .sch format?
I
Why have a core at all? One of the issues with the current gnetlist
is that it cannot be ported to a different Scheme implementation,
because the core is Guile-specific. Why not start from Scheme
functions for reading/writing .sch format?
I never said the core had to be C, but given we
On 05/30/2011 01:50 AM, John Doty wrote:
But who's volunteering?
On 05/30/2011 01:50 AM, John Doty wrote:
So, one way or another, we're looking at a new tool, I think. Maybe we keep
the old gnetlist around and feed it modified/annotated schematics.
There will always be people who don't
One thought I had for gnetlist backends, is to recode gnetlist as a
set of libraries. The Core would only load the design files
(schematics, spreadsheets, databases, back-annotation info, etc) as
raw data; the backend would be required to call at least one library
function that said I want data
On May 31, 2011, at 1:55 AM, DJ Delorie wrote:
One thought I had for gnetlist backends, is to recode gnetlist as a
set of libraries.
Now you're talking.
The Core would only load the design files
(schematics, spreadsheets, databases, back-annotation info, etc) as
raw data; the backend
I was thinking of how to represent all of the connections and relationships.
Then thought of sqlite3, as a database of connections.
a table of symbols,
a table of pins
This table maps the pins to a net and a symbol.
a table of nets
This is a rather simple database, of connections.
To
6 matches
Mail list logo
