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 forma
> 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 al
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 compe
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 back
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 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
6 matches
Mail list logo
