Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such

[John Doty <jpd@xxxxxxxxxxxxx>]

On Dec 7, 2007, at 12:40 PM, Steve Meier wrote:
>
> I am particularily interested in being able to  output netlists for
> simulation wich support hierarchical references.

Right now, the big problem is that gnetlist will insist on expanding  
all references via source= itself, so you wind up with a monstrous  
and very repetitive file. It's not what the layout folks want to see.  
The way I deal with that is to avoid using source= (which means Hd  
doesn't work, but it's easy enough to open the source schematic  
manually as needed). I assemble the complete SPICE netlists by  
concatenating the subcircuit netlists with "cat".

>
> 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.

That's your vision. But Al wants "the structural subset" of Verilog  
to be the 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's not our terminology. "Embedded" means present as a complete  
object in the schematic file.

> 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...

We have file= for SPICE already. But it would make more sense to have  
a SPICE-specific attribute. Also, pinseq= is confusing.

>
>
> 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

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