[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Heavy Symbols and such
Dave,
Well the netlister needs to be able to read in the schematic files and
eco file and then modify the schematic files. I have a version of a
netlister that generates a netlist the traditional flat netlist way and
then reads in an eco file which it uses to modify the netlist. It isn't
100% so I have had to do some hand modifications but it looks promissing
and has helped me reduce mistakes. Ohh the board was layed out using a
modern version of pads.
I have been thinking that the way to do back annotation is to add a
schematic level attribute that is attached to a symbol. Something like
C 8500 9600 1 180 0 big_fpga-1.sym
{
T 8300 9100 5 10 1 1 180 0 1
refdes=U1
T -100 -100 5 10 1 1 180 0 1
pinswap=a12,g13
}
This could then be used when viewing the schematic or generating a
netlist to swap the two pins.
Steve Meier
On Wed, 2007-12-05 at 10:13 -0800, Dave N6NZ wrote:
>
> 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
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user