Re: gEDA-user: spNet v0.9.2 released

["John P. Doty" <jpd@xxxxxxxxx>]

Anthony Shanks wrote:
> Yes I know exactly what you mean now and I have seen (and have used)
> that kind of hierarchy control present in very high end tools (like
> cadence) but it is usually at the schematic capture level like you
> stated rather at the netlister level. gschem would have to drastically
> change to support that level of hierarchical maniuplation.
>   

Not in the makefile approach. Define suitable attributes, process with a 
script, use the results to build the netlist from the pieces. Use the 
toolkit, don't fight it.

> Theoretically I can add some netlisting directive object at the top
> level schematic/testbench to handle this in spNet, but I'd have to
> look into how much work that would take. It would definately be a
> great feature though I agree with you.
>
> On Tue, Jun 30, 2009 at 4:06 PM, r<nbs.public@xxxxxxxxx> wrote:
>   
>> On Tue, Jun 30, 2009 at 11:10 PM, Anthony Shanks<yamazakir2@xxxxxxxxx> wrote:
>>     
>>>> - hierarchy configuration from top-level schematic,
>>>>         
>>> What do you mean by this?
>>>       
>> Say, you want to modify a subcircuit somewhere deep down the hierarchy
>> or use an extracted netlist for some of sub-blocks. If there is no
>> hierarchy configuration, you would have to modify all cells in the
>> design starting from the swapped one up to the top level. With
>> hierarchy configuration, you can specify that the sub-cell should be
>> mapped to a particular "cell view/architecture" (e.g. "extracted" or
>> "schematic_for_openloop_gain_simulation").
>>
>> If this could be integrated with gschem, so that it knew which
>> schematic it should descend to, that would be perfect. Unfortunately,
>> AFAIK gschem has neither the notion of "cell view" nor the hierarchy
>> configuration.
>>
>> One idea would be to add a text-like "component" on the top level
>> schematic, say "hierarchyConfiguration", where the user could write
>> something like this:
>>
>> -----
>> # original_file_name file_name_to_be_used
>> preamp.sch preamp_for_openloop_sim.sch
>> analoglatch.sch analoglatch_extracted.sp
>> # path_to_instance file_name
>> /X5/X1/something something_else.sch
>> -----
>>
>> IMHO, having this information present and displayed on the top level
>> schematic (testbench) is very convenient from the design management
>> point of view. If it was to be added in a GUI or in makefile the
>> information would have to be stored and handled separately.
>>
>> Regards,
>> -r.
>>
>>
>> _______________________________________________
>> 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