Re: gEDA-user: Heavy Symbols and such

[Dave N6NZ <n6nz@xxxxxxxx>]

Steve Meier wrote:
> Eventually, I would also like to see being able to define the logic
> level for a group of pins, can the pins be used differentialy? if so
> which pins are paired? Can we swap pins if so which ones? 
The pin swapping question brings up another of my pet peeves -- when the 
same part comes in packages with different pin outs, it needs different 
symbols.  Although -- last night it occurred to me that I could use 
slots to fake that out.  Even if the part isn't slotted, I could define 
a slot for each package pin out.

But it really points out the fact that there is a level of abstraction 
missing in the current symbol definition, and that interacts with back 
annotation from what ever PCB layout tool you are using.  Maybe the 
netlister needs to be enhanced to be a more interactive tool instead of 
a one-way translator to make all the work well.

-dave


What are the
> power requirements (max and min) use this for drc checking. How about an
> attribute that tells if a pin must be connected to a net?
> 
> I also agree that flat files really arn't a good way to capture a lot of
> relevent information. I shudder thinking about a library of 10 million
> resistors one for each manufacturor each package, each value etc.
> 
> So a real database that can make symbols heavier at run time is a really
> good idea.
> 
> Steve Meier
> 
> 
> On Tue, 2007-12-04 at 21:25 -0700, Andy Peters wrote:
>> On Dec 4, 2007, at 8:23 PM, Steve Meier wrote:
>>
>>> What is the deffinition of a heavy symbol? And secondly why put a data
>>> base behind one? I have been pondering this from several levels.
>> To me, a "heavy symbol" (or, in the parlance of other EDA packages, a  
>> "component") is one that includes footprint information and either a  
>> vendor part number or a company-internal one (which gets mapped to a  
>> vendor part number for ordering). A heavy symbol may also contain a  
>> pointer to a Spice library but I don't use that.
>>
>> Why is this good?
>>
>> Simply put: the schematic becomes the master drawing. From the  
>> schematic, one can generate a netlist including package information  
>> for layout and a BOM for parts ordering.
>>
>> The former is very important. We've seen examples of different flavors  
>> of transistors with different TO-92 pinouts. Things like opamps can  
>> have different pinouts when in different packages.
>>
>> So one can avoid all sorts of confusion by placing an AD8138ARZ on my  
>> schematic, knowing that it will automatically pull in the expected  
>> footprint (SOIC) and populate the BOM with a valid orderable part  
>> number. We have added the AD8138ARM to the library because we need the  
>> smaller footprint, and this part also has a different internal part  
>> number.
>>
>>> One level is about how heavy large components have become and the  
>>> tasks
>>> that are used in building a working programed printed circuit board.
>>>
>>> Take a large fpga that has a large number of io pins that can have  
>>> many
>>> different functions. these are typically broken up into groups other
>>> wise called banks.
>>>
>>> On a bank by bank basis it is possible to sellect the following logic
>>> families
>>>
>>> 3.3-V LVTTL/LVCMOS
>>> 2.5-V LVTTL/LVCMOS
>>> 1.8-V LVTTL/LVCMOS
>>> 1.5-V LVCMOS
>>> 3.3-V PCI
>>> 3.3-V PCI-X mode 1
>>> LVDS
>>> LVPECL
>>> Differential 1.5-V HSTL Class I and II
>>> Differential 1.8-V HSTL Class I and II
>>> Differential SSTL-18 Class I and II
>>> Differential SSTL-2 Class I and II
>>>
>>> Within a bank a pair of io pins can be used differentialy or as single
>>> ended inputs. At lay out time pin swapping to detangle the netlist
>>> becomes very attractive. Which pins can be swapped?
>> It's even worse than that, as (certainly with Xilinx) there are plenty  
>> of limitations to pin placement. Some pins are inputs only. You need  
>> to make sure you get your differential polarity correct. You need to  
>> specify particular clock input pins. Differential inputs on Spartan 3E  
>> don't have built-in terminations (but differential I/O does). You need  
>> to avoid using the configuration control pins for most general I/O.
>>
>> But this, in my estimation, doesn't have anything to do with the heavy  
>> vs light symbol debate. We like to break up FPGA symbols into banks.  
>> For example, XC3S250E-FT256 has four banks so our "symbol" is really  
>> five parts, one for configuration connections and core power and  
>> ground, and four symbols, one for each bank which include VCCIO  
>> connectors for that bank. Pin names are as noted in the Xilinx data  
>> sheet. This allows for some reasonable options for pin swapping.
>>
>> The other FPGA school-of-thought involves making a logic symbol (or  
>> set of symbols) for each design (which of course includes footprint  
>> and part number info) with particular FPGA design pins on the correct  
>> location in each symbol. By "logical symbol" I mean that you have,  
>> say, one symbol for CPU interface, another for DDR SDRAM interface, a  
>> third for Ethernet PHY, a fourth with config/power, etc. The downside  
>> of this is pretty obvious: make a change that requires adding pins and  
>> it gets ugly.
>>
>>> On a second level, even a resistor has limitations. For a given
>>> manufacturor of a given product line there exists only a finite number
>>> of resistance values? To support manufacturing I would like to know  
>>> what
>>> are the options for a particular package? Can I expect the package to
>>> survive the expected power levels?
>> The obvious solution to this is to have heavy symbols for each and  
>> every resistor value, package size and tolerance. Of course your  
>> resistor library can grow quite large in a hurry, although creating a  
>> new symbol is a simple as copying an older one and changing the  
>> relevant fields.
>>
>>> On a third level, I would like to tie models and/or code (verilog,  
>>> vhdl,
>>> spice) to a symbol and have the ability to generate simulatable  
>>> netlists.
>> The problem with having schematics that support simulation (either HDL  
>> or Spice) and layout is that there are things on a layout that don't  
>> have models (connectors etc) and Spice-specific things don't translate  
>> to layout.
>>
>> -a
>>
>>
>> _______________________________________________
>> 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
> 
> 


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user