Mail Archives: geda-user/2015/09/05/00:58:07
--001a113deb38e0431f051ef8dbcd
Content-Type: text/plain; charset=UTF-8
It's never open source vs. commercial.
It's free vs. commercial, and
it's open source vs. proprietary.
With open source, you can have commercial development. You just can't act
like you own it. You have to do your commerce in services around the open
source parts.
Now, there's no way we're going to wean the chip vendors off PDFs. What we
need to do instead is provide them with tools (like they're using now)
which can generate PDFs AND which can generate machine-readable specs. That
means two things:
o Somebody has to define the specifications. Pin numbers, voltage ranges,
current consumption, frequency responses, etc.
o Once those specifications have been defined, the software has to be
written which can take that input data, and write out a PDF that looks
mostly like what they're sending out now, and generate the machine-readable
spec file.
Can't cross the river in one jump. Need a stone in the middle which keeps
creating the PDFs everybody expect.
On Fri, Sep 4, 2015 at 1:08 AM, Ouabache Designworks (z3qmtr45 AT gmail DOT com)
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>
> On Thu, Sep 3, 2015 at 9:00 PM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>>
>>
>> On Thu, 3 Sep 2015, Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via
>> geda-user AT delorie DOT com] wrote:
>>
>>
>>>
>>> https://medium.com/@zakhomuth/disrupting-electronic-design-automation-8988f
>>> 72299e3
>>>
>>
>> Btw, somewhat off-topic, the part not covered by geda-user discussions
>> usually: pdf datasheets. I really like his rant on how useless distributing
>> data in pdf is.
>>
>> I face that problem from time to time. Last december I had it with an arm
>> cortex. I wanted to extract the register names, bit names and magic values
>> (e.g. this bit in this register always has to be 1). C source and other
>> stuff comes with an EULA that doesn't let me do what I want. Datasheet is
>> in pdf. Most of the relevant data are in almost uniform tables.
>>
>> I thought I'd just convert the pdf to html and extract <table> nodes... I
>> laugh at this idea in retrospect. I tried with various tools and various
>> settings. Never got a <table>. Turned out the pdf just draws the borders
>> and draws the text separately. The render looks like if it was a table. The
>> html some tools produce look the same as the pdf. In practice, it's not a
>> table in those htmls, just a big background bitmap with the lines and the
>> text printed onto it at pixel coords.
>>
>> I ended up with a "table mapping" script that takes the bitmap, scans
>> lines and columns to map cell coordinates then reads all the text from the
>> html and determine which cell they are in.
>>
>> And this is only the first step to convert the data of a datasheet to a
>> machine readable form on the lowest level... Upper levels in separate
>> scripts took the table map and tried to read the header and convert the
>> info into a register description.
>>
>> I agree with the upverter guy. In the age of thousand page datasheets,
>> non-machine-readable format is a bug that needs to be fixed. On the other
>> hand I'm highly sceptic about vendors being cooperative on this.
>>
>> Regards,
>>
>> Igor2
>>
>
> In the old days I would keep a printed copy of all the IC's that I was
> working on in a binder on my shelves. But as chips grew that became
> impossible. A single chip today could easiy take up hundreds of feet of
> shelf space
> and searching it is impossible. Upverter is a commercial vendor so I
> understand that they do have to make a buck but Zak does bring up an
> interesting point. It is not open source vs commercial that we are dealing
> with. It is
> Big EDA vs everybody. We have to start talking with each other and come up
> with usable standards that do not lock us into big eda tools.
>
>
> John Eaton
>
>
>
>
--001a113deb38e0431f051ef8dbcd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div>It's never open sou=
rce vs. commercial.<br></div>It's free vs. commercial, and<br></div>it&=
#39;s open source vs. proprietary.<br><br></div>With open source, you can h=
ave commercial development. You just can't act like you own it. You hav=
e to do your commerce in services around the open source parts.<br><br></di=
v>Now, there's no way we're going to wean the chip vendors off PDFs=
. What we need to do instead is provide them with tools (like they're u=
sing now) which can generate PDFs AND which can generate machine-readable s=
pecs. That means two things:<br></div>=C2=A0 o Somebody has to define the s=
pecifications. Pin numbers, voltage ranges, current consumption, frequency =
responses, etc.<br></div>=C2=A0 o Once those specifications have been defin=
ed, the software has to be written which can take that input data, and writ=
e out a PDF that looks mostly like what they're sending out now, and ge=
nerate the machine-readable spec file.<br><br></div>Can't cross the riv=
er in one jump. Need a stone in the middle which keeps creating the PDFs ev=
erybody expect.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Fri, Sep 4, 2015 at 1:08 AM, Ouabache Designworks (<a href=3D"ma=
ilto:z3qmtr45 AT gmail DOT com">z3qmtr45 AT gmail DOT com</a>) [via <a href=3D"mailto:ged=
a-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a hre=
f=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On Thu, Sep 3, 2015 at 9:00 PM, <span dir=3D"ltr"><<a href=3D"m=
ailto:gedau AT igor2 DOT repo DOT hu" target=3D"_blank">gedau AT igor2 DOT repo DOT hu</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Thu, 3 Sep 2015, Ouabache Designworks (<a href=3D"mailto:z3qmtr45 AT gmail.=
com" target=3D"_blank">z3qmtr45 AT gmail DOT com</a>) [via <a href=3D"mailto:geda-=
user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
<a href=3D"https://medium.com/@zakhomuth/disrupting-electronic-design-autom=
ation-8988f" rel=3D"noreferrer" target=3D"_blank">https://medium.com/@zakho=
muth/disrupting-electronic-design-automation-8988f</a><br>
72299e3<br>
</blockquote>
<br>
Btw, somewhat off-topic, the part not covered by geda-user discussions usua=
lly: pdf datasheets. I really like his rant on how useless distributing dat=
a in pdf is.<br>
<br>
I face that problem from time to time. Last december I had it with an arm c=
ortex. I wanted to extract the register names, bit names and magic values (=
e.g. this bit in this register always has to be 1). C source and other stuf=
f comes with an EULA that doesn't let me do what I want. Datasheet is i=
n pdf. Most of the relevant data are in almost uniform tables.<br>
<br>
I thought I'd just convert the pdf to html and extract <table> no=
des... I laugh at this idea in retrospect. I tried with various tools and v=
arious settings. Never got a <table>. Turned out the pdf just draws t=
he borders and draws the text separately. The render looks like if it was a=
table. The html some tools produce look the same as the pdf. In practice, =
it's not a table in those htmls, just a big background bitmap with the =
lines and the text printed onto it at pixel coords.<br>
<br>
I ended up with a "table mapping" script that takes the bitmap, s=
cans lines and columns to map cell coordinates then reads all the text from=
the html and determine which cell they are in.<br>
<br>
And this is only the first step to convert the data of a datasheet to a mac=
hine readable form on the lowest level... Upper levels in separate scripts =
took the table map and tried to read the header and convert the info into a=
register description.<br>
<br>
I agree with the upverter guy. In the age of thousand page datasheets, non-=
machine-readable format is a bug that needs to be fixed. On the other hand =
I'm highly sceptic about vendors being cooperative on this.<br>
<br>
Regards,<br>
<br>
Igor2<br></blockquote><div><br></div></div></div><div>In the old days I wou=
ld keep a printed copy of all the IC's that I was working on in a binde=
r on my shelves. But as chips grew that became impossible. A single chip to=
day could easiy take up hundreds of feet=C2=A0 of shelf space<br></div><div=
>and searching it is impossible. Upverter is a commercial vendor so I under=
stand that they do have to make a buck but Zak does bring up an interesting=
point. It is not open source vs commercial that we are dealing with. It is=
<br></div><div>Big EDA vs everybody. We have to start talking with each oth=
er and come up with usable standards that do not lock us into big eda tools=
.<br><br><br></div><div>John Eaton<br><br><br></div></div><br></div></div>
</blockquote></div><br></div>
--001a113deb38e0431f051ef8dbcd--
- Raw text -