translate2geda handles bsdl files, but things get a bit c= razy with large fpga devices

<= a href=3D"https://github.com/erichVK5/translate2geda">https://github.com/er= ichVK5/translate2geda

= Regards,

Erich

On Mon, 26 Apr 2021 03:47 Nicklas SB Karlsson (nk AT nksb DOT online) [via geda-user AT delorie DOT com], <geda-user AT delorie DOT com> wrote:
<= /div>

It's a good appreciated effort. As = manufacturers make available BSDL
files for components I however think it's a good idea to mention
something about them.

Syntax is different from yours but they are text files. Looking into one or a few: there is pin label similar to your last column, pin type
similar to your second last column, there is a pin map string and there are also other information probably not usable in symbols.

Nicklas Karlsson

Den 2021-04-25 kl. 13:43, skrev karl AT aspodata DOT se [via
geda-user AT delorie DOT com]:
>=C2=A0 =C2=A0In http://aspodata.se/= git/openhw/pdftosym/pintosym.pl
>=C2=A0 =C2=A0I have a program that generates symbols.
>
>=C2=A0 =C2=A0It takes lists of pinnumber vs pinlabels like:
>
> LQFP100 LQFP64 TFBGA64 LQFP48
> ...
>=C2=A0 =C2=A0 6=C2=A0 =C2=A01=C2=A0 B2=C2=A0 =C2=A01 pwr VBAT
>=C2=A0 =C2=A0 7=C2=A0 =C2=A02=C2=A0 A2=C2=A0 =C2=A02 io=C2=A0 PC13 TAMP= ER_RTC
>=C2=A0 =C2=A0 8=C2=A0 =C2=A03=C2=A0 A1=C2=A0 =C2=A03 pas PC14 OSC32_IN<= br> >=C2=A0 =C2=A0 9=C2=A0 =C2=A04=C2=A0 B1=C2=A0 =C2=A04 pas PC15 OSC32_OUT=
>=C2=A0 =C2=A010=C2=A0 =C2=A0-=C2=A0 =C2=A0-=C2=A0 =C2=A0- pwr VSS_5
>=C2=A0 =C2=A011=C2=A0 =C2=A0-=C2=A0 =C2=A0-=C2=A0 =C2=A0- pwr VDD_5
>=C2=A0 =C2=A012=C2=A0 =C2=A05=C2=A0 C1=C2=A0 =C2=A05 pas OSC_IN
>=C2=A0 =C2=A013=C2=A0 =C2=A06=C2=A0 D1=C2=A0 =C2=A06 pas OSC_OUT
> ...
>
>=C2=A0 =C2=A0where a function is on different pins for different packag= es.
>=C2=A0 =C2=A0I.e. VBAT is a pwr pin, which is pin 1 in the LQFP48 packa= ge,
>=C2=A0 =C2=A0and B2 in the bga package.
>
>=C2=A0 =C2=A0That works quite nice, and for e.g. the power pins I can m= ake them
>=C2=A0 =C2=A0line up as in:
> http://= aspodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.LQFP100.sym<= br> > http://a= spodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.LQFP48.sym > http://a= spodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.LQFP64.sym > http://= aspodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.TFBGA64.sym<= br> >=C2=A0 =C2=A0so for theese symbols Vdd_3 is in the same position regard= less of
>=C2=A0 =C2=A0package type, so I can swap the symbol, and all things tha= t were
>=C2=A0 =C2=A0connected to Vdd_3 will still be. Compare theese two for e= xample:
> http://aspodata.se/git/openhw/share/gschem/_sub_page/stm32f100lm.power.LQF= P48_10u.sch
> http://aspodata.se/git/openhw/share/gschem/_sub_page/stm32f100lm.power.LQ= FP100_10u.sch
>=C2=A0 =C2=A0they depends on symbols in directories:
> http://aspodata.se/git/openhw/= share/gschem/_graphical/
> http://aspodata.se/git/openhw/= share/gschem/_discrete/
>=C2=A0 =C2=A0and the above stm32f1xxx.sym's.
>
>=C2=A0 =C2=A0So that works just nice if the pin label stays the same. >
> ///
>
>=C2=A0 =C2=A0But now I'm looking at the smarc standard:
> https://sget.org/standards/smarc/
>
>=C2=A0 =C2=A0There you have the same pin, but differnt names/functions = depending on
>=C2=A0 =C2=A0which generation, also later generations might add alterna= te functions.
>
>=C2=A0 =C2=A0A) same function but the name is changed
>=C2=A0 =C2=A0E.g. for pin P26, in Embedian T335X (smarc v1p0?) it is na= med EthRX-,
>=C2=A0 =C2=A0in sget standard for v1p0 and v1p1 it is named GBE_MDI1-, = and lastly
>=C2=A0 =C2=A0in v2p0,v2p1,v2p1.1 it is named GBE0_MDI1-. I.e. Eth ->= GBE -> GEB0
>=C2=A0 =C2=A0is the same thing under different names.
>
>=C2=A0 =C2=A0B) alternate functions dropped or added
>=C2=A0 =C2=A0Se e.g.
>=C2=A0 =C2=A0http:= //aspodata.se/git/openhw/share/gschem/_module/smarc_pinout.txt
>=C2=A0 =C2=A0https://sget.o= rg/wp-content/uploads/2020/05/SMARC_V211.pdf p.96..
>
>=C2=A0 =C2=A0Take pin S32, between v1p1 - v2p0 there is a function chan= ge, and
>=C2=A0 =C2=A0between v2p0 - v2p1 an alt.func. was added.
> $ head -1=C2=A0 smarc_pinout.txt ; grep 'S32' smarc_pinout.txt=
> pin=C2=A0 | SMARC v1.0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SMARC= v1.1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SMARC v2.0=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = SMARC v2.1 (and 2.1.1)
> S32=C2=A0 | SDMMC_D6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = SDMMC_D6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| PCIE_D_RX+=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| PCIE_D_RX+ SERDES_0_RX+
>
>=C2=A0 =C2=A0Pin P77 was dropped in v2p0, and oops, readded in v2p1. > $ head -1=C2=A0 smarc_pinout.txt ; grep 'P77' smarc_pinout.txt=
> pin=C2=A0 | SMARC v1.0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SMARC= v1.1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SMARC v2.0=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = SMARC v2.1 (and 2.1.1)
> P77=C2=A0 | PCIE_B_CKREQ#=C2=A0 =C2=A0 =C2=A0 =C2=A0 | PCIE_B_CKREQ#= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | RSVD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| PCI= E_B_CKREQ#
>
>=C2=A0 =C2=A0What is a good way to handle that ?
>
> Regards,
> /Karl Hammar
>
>

--0000000000006765dd05c0d2445f--