[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such
John Doty wrote:
> On Dec 6, 2007, at 11:43 PM, Steve Meier wrote:
>
>
>> John,
>>
>> Well veralog or vhdl as an internal data structure format? Maybe but I
>> am not going to worry about it or attempt it.
>>
>
> But that is what Al is proposing.
>
>
I don't think so. At least he isn't at this time. If he were wouldn't
that be how gnucap internal data is structured? I might need to look at
that code as well.
>> But I am curios enough
>> that I might look at icarus' data structures. Perhaps what Al is
>> suggesting is that vhdl has all the elements needed for
>> constructing an
>> internal data structure? again maybe, but it seems that geda has a
>> pretty good selection as well and if libgeda is missing something then
>> extending libgeda at this point might be easier or in my opinion at
>> least my non-stock library. As I start to dig into the capabilities of
>> these languages it might become apperent that an extension is
>> desirable.
>> Whats that old saying something about if you want to understand a
>> language learn a few?
>>
>> As I recall John you have consistently argued for a spice output
>> for at
>> least modeling purposes if not as a netlist format for chip and
>> perhaps
>> even board layout?
>>
>
> More than that: I've been using it with great success for modeling
> and chip layout. But that's not the issue here. SPICE is very useful
> as an *export* format, and sometimes as an *import* format. I use the
> designs at http://research.kek.jp/people/ikeda/openIP/ quite a bit.
> And I had dinner with Professor Ikeda Tuesday night. He likes what
> I've done with gEDA a lot!
>
>
>> So yes your help on spice syntax would be
>> appreciated.
>>
>
> What problems do you see in spice-sdb? Have you looked at my
> Mathematica netlister (for symbolic circuit analysis)?
>
>
I am particularily interested in being able to output netlists for
simulation wich support hierarchical references.
I am not an expert at spice and advice, test cases, expected results
will only make my work in that direction more likely to be successfull.
But if there isn't open willing support I probably should re-prioritize
my efforts.
>> Also as part of this process I am striving to create a well
>> documented scheme interface into the library review of that interface
>> and suggestions on what is needed to achieve the desired spice, vhdl,
>> verilog output files would also be apreciated. If you really feal like
>> it then once the scheme interface is deffined you could take a shot a
>> writting/modifying the spice output format macro.
>>
>
> The issue at hand is how the databases that drive this should work.
> Various people have various visions. I have no strong preference as
> long as the result retains gEDA's flexibility. But I don't know how
> to evaluate Al's suggestion, as it's just "wave the magic Verilog
> wand, and all will be well".
>
>
No the database is built into the strucure of the library. verilog, vhdl
and spice are just reflections of that internal database.
>> Later on today I will send out the latest scheme interface document it
>> still mostly (almost exclusively) is about getting data into the
>> library
>> structures but I am about to turn my attention towards basic netlist
>> generation control (page level and as specific command to flatten the
>> page nets/buses into a single page as a specific command) and
>> schematic,
>> symbol, bom and netlist exporting functions. Actual netlist generation
>> both page and flattening functions already exists in the library as
>> does
>> the scheme interface at least for the flat netlist but these scheme
>> functions havn't made it into my document yet.
>>
>
> I know well that right now you just have to experiment with modifying
> other netlisters.
>
>
Actualy two points one I got so wrapped up I forgot to publish my latest
scheme interface doc and two I think what I have doen is rewrite an
existing netlister... since I have built a board that has two channels
of a flat bandwidth of 4Khz to 450 Mhz feeding into a system of a/d
converters sampling at 500 Msamples sper sec and then into some fpga's
which then process the data and then hook into an existing piece of
equipment. Board built, fpga's programed embeded linux running, real
time processors running array processors taking over more and more of
the signal processing... I think we are past experimenting.
>> Then with an eye towards the future I am starting to think about
>> how one
>> could embbed files other then schematics into symbols. As well as
>> spice
>> models these could include hardware description languages such as
>> verilog and vhdl and???
>>
>
> Why embed? References are good things. Directories are good
> containers. File utilities are handy for reshuffling the pieces.
> Files are good publishable objects. People who don't know what to do
> with a .sch often can handle a SPICE netlist...
>
Is a schematic which is referenced via a source= attribute embedded?
That is what I ment. Similarily to have an attribute which reads vhdl=
or verilog= or spice= and then pulling the code or a reference to the
code and includding that into the final netlist embedded or just
refferenced...
Thanks,
Steve Meier
>
>> Thanks,
>>
>> Steve Meier
>>
>>
>> John Doty wrote:
>>
>>> On Dec 6, 2007, at 3:13 PM, Steve Meier wrote:
>>>
>>>
>>>
>>>> John,
>>>>
>>>> The beauty of geda and its scheme capabilities is that any file
>>>> format
>>>> that is reasonably well deffined can be supported.
>>>>
>>>>
>>> Indeed. Give me a well defined format with a clear use, I might even
>>> help.
>>>
>>>
>>>
>>>> Instead of railing at at Al start helping to nail doen the
>>>> deffinitions
>>>> on the formats your prefer.
>>>>
>>>> As I have said my short term goals are to provide output support for
>>>> verilog, vhdl and spice.
>>>>
>>>>
>>> But that can mean many things. Al keeps talking about Verilog as an
>>> internal format, not an export format. But it's impossible to
>>> understand what he means by that.
>>>
>>>
>>>
>>
>> _______________________________________________
>> geda-user mailing list
>> geda-user@xxxxxxxxxxxxxx
>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>>
>
> John Doty Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd@xxxxxxxxx
>
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user