<_whitenotifier-d>
[nmigen] hansfbaier commented on pull request #627: cli: add new show backend which shows a diagram of the generated RTL - https://git.io/JEGDE
<_whitenotifier-d>
[nmigen] hansfbaier closed pull request #627: cli: add new show backend which shows a diagram of the generated RTL - https://git.io/J0tVg
<lkcl>
agg: good point. it's been a while since i looked at this code, we had to move on (and it's now "just part of the furniture" if you know what i mean)
<agg>
yea, i understand
<agg>
how do you interpret lgpl3 for that code, out of interest? that's a big reason i see that none of it could be integrated in nmigen (and incidentally why i'm not looking at/can't use it), but I don't really know how to interpret lgpl in the context of gateware generators
<lkcl>
the LGPLv3+ was designed specifically with hardware in mind.
<agg>
with embedded devices in mind, maybe, but with software that generates hdl?
<agg>
not saying you shouldn't have used lgpl or anything, just curious about how it applies here
<lkcl>
at 3mdeb's event a few months ago Dr Stallman turned up, which was a real surprise for everyone
<lkcl>
we asked him, "how does the LGPL apply to hardware because of the 'linking' problem"?
<lkcl>
he immediately picked up on that and corrected us
<agg>
it's not like anyone using an fpga running gateware built by your software could dynamically link a different version of nmutil
<agg>
I suspect i'm about to regret asking, lol
<lkcl>
and explained that the GPL / LGPL was designed around Copyright Law
<lkcl>
:)
<lkcl>
it mentions "aggregate works"
<lkcl>
not "linking"
<lkcl>
thus
<lkcl>
as long as you release modifications to the parts of the *aggregate work* that are covered under the LGPLv3
<lkcl>
you can do basically whatever you like
<lkcl>
use proprietary tools
<lkcl>
create proprietary HDL
<lkcl>
etc.
<lkcl>
etc.
<lkcl>
etc.
<agg>
that definitely doesn't seem clear in this case
<agg>
does distributing a product containing an fpga containing gateware built using this software count as distribution of an aggregate work that includes lgpl3 software?
<lkcl>
i would imagine so, yes.
<agg>
maybe it's the same as distributing a binary compiled from lgpl3 source, but maybe it's more like distributing a binary compiled by a gpl compiler like gcc
<lkcl>
so you'd have the usual conditions: required to include the usual letter offering to provide the source code (or make it available publicly online)
<agg>
anyway not my field to play in, just seems a bit more complicated than usual for generators like this compared to "normal" software libraries
<lkcl>
basically, yes, i believe the parallel of gcc is the same
<lkcl>
gcc is a tool, nmigen is a tool.
<agg>
well that's the opposite of what you said a moment ago
<agg>
if it's more like gcc or bison or other GPL tools that generate binaries that are not then GPL-encumbered, it's totally different from if it's like compiling a GPL library and linking it
<agg>
(bison distributes a bunch of gpl code in its output but has a specific licence exception for it, though)
* lkcl
still thinking it through here myself, how to explain it
<agg>
put another way: if someone sold a commercial closed-source fpga product that used nmigen and nmutil, but provided zero source code or even attribution, would you consider it in violation of your licence?
<lkcl>
yes, because they hadn't provided the written offer to provide the source code of nmutil with the product
<lkcl>
or provided the link to the source code online
<agg>
so it's not like gcc, where of course you can provide executables built using gcc without including a gcc copyright attribution
<agg>
in addition to providing nmutil source, wouldn't they need to provide some way for the user to use their own version of nmutil to rebuild the gateware?
<lkcl>
in the case of the GPLv3 yes
<lkcl>
in the case of the LGPLv3 no
<lkcl>
they just need to provide the tools which allow the user to build *nmutil*, as best i can tell
<agg>
lgplv3 4.d says to distribute a combined work you must either convey the source code in a form suitable for the user to recombine with a modified version of the licensed software, or use a suitable shared library mechanism for linking that will work with a modified version of the licensed software
<agg>
it seems quite explicit that the user must be able to recombine the application with a modified nmutil
<lkcl>
tck, tck, tck....
<agg>
which in nmutil's case would of course require the original nmigen-based source code
<lkcl>
i need to think about that
<lkcl>
agg: appreciate you bringing it up
<agg>
it's probably reasonable to say that nmutil code is "compiled" into the final gateware, rather than "generates" a gateware itself, but it's not super clear to me either way anyway
<agg>
if it was the latter then it seems like the gateware binary would be unencumbered anyway
<lkcl>
we don't use "prev" / "next", at some point i'd shortened it simply to "self.p" and "self.n"
<agg>
if it's a class member only (and not a variable named 'next') then I guess it doesn't override the builtin anyway, but can't beat p and n for brevity lol
<lkcl>
:)
<lkcl>
the input and output names i had to beat my head against a desk repeately for weeks
<lkcl>
we debated them over several months, settled on NextControl.valid_o and ready_i
<lkcl>
and PrevControl.valid_i ready_o
<lkcl>
including the _i and _o suffix to stop us from repeatedly making the mistake of cross-wiring them incorrectly
<lkcl>
oh - also: around the same time we came up with the standard "nmoperator" concept, based on the python "operator" concept except for nmigen
<lkcl>
creating nmoperator.eq, nmoperator.cat etc.
<lkcl>
hoolleeee coww was that a deep rabbithole
<lkcl>
i created a Visitor class which walks objects looking for eq functions, in order to recursively "eq" one object to another, over a Stage Boundary
<lkcl>
so whilst in iocontrol.py PrevControl and NextControl it's just, "m.d.comb += nmoperator.eq(data_o, data_i)"
<lkcl>
which makes the Stage API dead simple to work with
<lkcl>
part of the contract of the API is to provide an eq function, *including* for compound objects (class instances or Record derivatives)
<d1b2>
<dragonmux> nMigen itself tends to prefix - so o_valid, i_ready
<d1b2>
<dragonmux> just FYI
<lkcl>
dragonmux, yeah i don't know why that was chosen - this code was developed almost... 2 years ago now
<lkcl>
shouldn't be a huge deal to turn it round (global search/replace)
<dragonmux>
good question.. figured we'd point out the inconsistency though
<dragonmux>
true
<lkcl>
and, intriguingly, due to the heavy abstraction, no *users* of the StageAPI (libre-soc soc repo) actually have to intrude on the names of the signals between the stages
* lkcl
checking
<lkcl>
oh, ha ha, i use {valid/ready}_{o/i} elsewhere for different purposes
<lkcl>
and Liskov Substitution Principle in one experiment, forgot about that
<dragonmux>
we would weigh in on the LGPLv3+ stuff that.. we suggest giving it a think about whether the result of running a tool (RTLIL and a .debug.v in the case of nMigen) ends up covered by a given license - we suggest that while nMigen is BSD-2-Clause, the result of running it with some given input nMigen DSL source.. is not covered by BSD-2-Clause itself in the same way running GCC on some C and C++ code to produce .S and .o files does
<dragonmux>
not cause those .S and .o files to be GPL'd
<dragonmux>
it's the distinction between the tool and the result of it doings its job
<lkcl>
yeah
* lkcl
checking if a g/s/r ready/valid_o/i works... yes. unit tests good.
<lkcl>
thx dragonmux
<agg>
dragonmux: yea, that's where I struggle, I wonder if it's materially different between nmigen (which seems most akin to GCC in that it processes your own input to produce some output, even if that might include some "stdlib" stuff like fifos) and nmutil, which is explicitly a user level library you can use alongside your own code to feed nmigen
<dragonmux>
we would suggest that makes nmutil affect only the licensing of the projects in which it's used in the same way a C or C++ library would
<agg>
In those library cases it does cause the output to be encumbered though
<dragonmux>
yes, except in the case of LGPLv3+ which doesn't bleed across library boundaries
<agg>
In a practical sense both nmigen and nmutil are just python libraries though
<agg>
It doesn't bleed across library boundaries but it does place restrictions on what you can do with the aggregate application distribution
<dragonmux>
correct
<agg>
(namely that end users need to be able to swap out the LGPL part, which for nmigen designs would seem to require availability of the python source)
<agg>
Question is whether it applies to gateware binaries or just the python application that generates them
<dragonmux>
the LGPL component must be declared, the output must be able to reproduce or contain the license notice (that's a standard *GPL* license term), and you must be able to swap out the LGPL component's impl
<dragonmux>
the license intentionally makes it so you must in all forms be able to swap out the LGPL component
<dragonmux>
this means being able to take the RTLIL and gut the LGPL library parts out, replacing them with something else
<agg>
Yes, I think understand that part, but earlier you were saying the result of running nmigen would not itself be bsd licensed
<agg>
But now you're suggesting that if you used an LGPL library the result would be restricted by that?
<dragonmux>
it would be acceptable in this case to provide the RTLIL for your gateware to satisfy the gateware library license condition
<agg>
Not that that's inconsistent, they're different licenses of course
<agg>
Would it? It's not possible to use the rtlil to change the nmutil version
<dragonmux>
yes, nMigen itself is a tool.. it has a library component and that library component is default BSD-2-Clause.. but the core tool does not affect the resulting license of the RTLIL
<dragonmux>
if you feed it with DSL that's been licensed under, say, CERN OHL-2-Strict.. the resulting RTLIL is also CERN OHL-2-Strict
<agg>
The freedom the LGPL seeks to preserve is for users to swap in a different nmutil, but to do that you need the original python source, not the rtlil
<dragonmux>
it would be hard to do but you could technically swap out the nmutil components at the RTLIL level too so that is a valid path
<agg>
That's like saying you could swap out the LGPL components of a statically linked elf executable
<agg>
Not sure people like that
<agg>
The LGPL test even specifically calls our dynamic linking for that use case
<dragonmux>
source: it's considered sufficient to provide a .a or a set of loose .o files of binary built against an LGPL library so the user can re-link the whole thing after providing their own version of the library
<agg>
In any event it's still not obvious to me that the license doesn't only apply to the application you build using the libraries but not to the gateware that application generates
<dragonmux>
dynamic linking just makes that process easier
<agg>
Yea, some .a and .o files can definitely swap out an LGPL part, but I don't think that's the case for nmutil and rtlil at all
<dragonmux>
we're saying that the license of the libraries fed in does affect the gateware
<dragonmux>
but the tool doing the translation doesn't
<agg>
At that point it's been completely inlined into the application specific code, it's not seperable or delimited
<dragonmux>
you're conflating (in the C++ equivilent) the STL vs g++
<dragonmux>
yes, that's why we said it's tricky..
<agg>
The license of Cairo doesn't affect the license of a pdf I generate from a python program
* lkcl
thinking about that one
<dragonmux>
nMigen itself is equivilent to g++ in the process.. the nMigen.lib equivilent to the STL, and nmutil equivilent to some 3rd party library you choose to use.. the .debug.v has concerns sufficiently seperated you could do a swap
<dragonmux>
it'd suck to do but you can do it
<agg>
Two separate things here, I'm sure you couldn't swap nmutil versions from the rtlil at all, so I don't think that would satisfy the requirements
<dragonmux>
unsure
<agg>
At least in general a python library you use in generating gateware can fully embed inside the resulting gateware
<agg>
E.g. I use scipy to design a FIR filter
<agg>
Does scipy license affect my gateware?
<agg>
At the very least I don't think it's obvious either way
<lkcl>
oo interesting.
<dragonmux>
we would suggest that it affects the license of the source if it were GPL'd, but not necessarily the gateware as it doesn't produce nMigen source and is not itself nMigen source
<dragonmux>
but that is a complicated question
<lkcl>
if nmutil is considered to be "like nmigen" (i.e. a tool) then just because the *tool* (the aggregate work of nmigen+nmutil) is LGPLv3 you would not need to apply the usual license requirements
<lkcl>
but if nmigen is the tool working *on* nmutil (as a library) with other HDL, then it would
<lkcl>
intriguing
<agg>
I think there's an argument that anything you use is just a tool because it all turns into a single python application
<agg>
and that application, when run, can among other things generate a gateware image
<agg>
so distributing the application itself - e.g. glasgow - of course requires observing all the licenses that go into it
<dragonmux>
the reason for our stance being that while Python is source-interpreted (unfortunately, which muddies this), it is split into libraries in the form of modules and you can drop a module out and put another in its place with the same API (see PIL -> Pillow), so we can claim a linking boundary down imports API lines
<agg>
but distributing the output of the application - a gateware binary - not sure?
<lkcl>
okok much as i really appreciate this discussion can i suggest moving it to #libre-soc? :)
<dragonmux>
we guess agg that it does fall under the static linking rules for the most part
* lkcl
concerned about keeping #nmigen channel for nmigen
<dragonmux>
so.. use the static linking model for C++ to guide your interpretation of software licensing as applied to gateware
<agg>
i don't see why it would be different from e.g. using inkscape to create a svg
<lkcl>
i don't mind this being discussed on #libre-soc (it's actually very relevant there)
<dragonmux>
because it's using a tool to feed inkscape with instructions to create an SVG
<dragonmux>
and we're asking if the resulting SVG ends up with the license of the tool that fed inkscape, or qhat
<dragonmux>
*what
<agg>
fine, using libinkscape as part of my own program that generates svgs
<agg>
my program, if I distributed it, would clearly need to be GPL compatible (since inkscape is GPL)
<dragonmux>
we would suggest that if you dynamically link libinkscape, then the normal rules apply, otherwise it's the static linking clauses.. and we're talking static linking here going by your model of RTLIL
<agg>
but I can presumably distribute the SVGs it generates to my heart's content
<agg>
I don't think we're linking nmutil to the output gateware at all, we're just linking it to our python application that generates gatewares
<dragonmux>
yes, that's how nMigen fits into the picture
<dragonmux>
but nmutil feels like, as its translated code ends up in the output, it's static linking
<agg>
if we distribute the python application itself (which is my code + uses nmigen and nmutil libs), then sure it must be compatible with lgpl
<dragonmux>
this is why we like the example of talking of .S and .o output from g++ because it's closer to the model and problem in question
<agg>
you don't feel like the same is true of inkscape going into svgs?
<dragonmux>
the .S and .o output of g++ does not gain g++'s license but it *does* retain the license of the C++ source that went in to produce it
<dragonmux>
nMigen is a DSL and RTLIL is the primary output format from the transpilation process.. this feels like it fits best
<dragonmux>
it'd be interesting to see how C and C++ unity builds impact licencing in the same veign as that's even closer to the RTLIL problem here
<dragonmux>
*vein
<dragonmux>
we hope that line of thought makes some sense
<agg>
yea, I see your point
<agg>
GPL FAQs are not especially enlightening except for a weird insistence that the output is only derived in a copyright sense if it contains literal copies of the copyright inputs https://www.gnu.org/licenses/gpl-faq.en.html#GPLOutput
<agg>
"So the only way you have a say in the use of the output is if substantial parts of the output are copied (more or less) from text in your program."
<agg>
I guess the question really is whether gateware binaries counts as "statically linked" to the python library used to construct them, or if they are merely "outputs" of such a generator program
<agg>
(and yes, I suppose the distinction between the RTLIL and the packed gateware binary generated later using yosys/nextpnr adds more murkiness)
<Sarayan>
afaik compilers don't change copyright
<Sarayan>
copyright-wise source and binary are the same thing
<agg>
sure, no doubt
<Sarayan>
similarly, there's no distinction between the rtlil and the bitstream
<agg>
(well, I'd say in both cases they are derived works rather than the same thing, but the same copyright applies plus potentially extra copyrights from the derivation, but not usually in the case of a compiler)
<Sarayan>
I don't think they're derived works because there's no (human?) creativity in making the bitstream so it's not a new derived work, it's another version of the same work
<Sarayan>
libre-SOC is intriging, would it with on a de10-nano?
<Sarayan>
s/with/fit/
* Sarayan
looks at his fingers funny
<dragonmux>
agg: our point is that by the logic that the RTLIL is a derived work, then so is the .S for some C++ code, or the -flto'd -O3'd binary output of building something like the MXKeyboard firmware.. which is inconsistent with how the licenses are designed to work and be interpreted
<dragonmux>
we think the RTLIL is the gateware equivilent to the assembler for our firmware
<agg>
yea, I think that's fair
<dragonmux>
we would suggest it should be interpreted by persuing a static linking line of enquirery
<agg>
I think you're right and static linking is a good metaphor for this case
<agg>
I think maybe the distinction I was trying to pursue depends on the nature of the library and in the nmutil case, where it's just more gateware, it would count as being linked in in some sense
<agg>
(though I still think the rtlil would not allow changing versions of nmutil and you'd have to distribute the python source for that to work...)
<dragonmux>
aye, we would suggest the same wrt nmutil
<agg>
but I could imagine a different python library that's also used to generate the gateware but not by just being gateware itself
<dragonmux>
yeah, maybe that's so.. the .debug.v would but it'd suck to do it
<agg>
I'm not even sure there
<agg>
because the gateware is parameterisable by the user in a way that's no longer a parameter in the verilog
<agg>
it would be like if g++ inlined and optimised some library code
<dragonmux>
the .debug.v contains the unoptimised blocks so you can drop a block out and replace it
<agg>
you can't replace it without knowing how it was being called
<agg>
it doesn't contain unoptimised blocks because python itself has done most of the optimisation before nmigen even gets to see it
<dragonmux>
that's why we like thinking about unity builds or -flto -O3'd code
<dragonmux>
oh, we see.. where an adjacent library has had impact.. mmm
<dragonmux>
the C++ generator tool problem
<dragonmux>
like uic
<agg>
for example I have a CRC gateware library
<agg>
the python user calls it with a polynomial and other CRC settings
<agg>
it generates (in python) a series of logic statements for nmigen
<agg>
those are what go into the .v
<dragonmux>
it is incredibly tricky
<agg>
if you wanted to replace it with a different version of that CRC library, you need to know what polynomial and other settings I called it with
<agg>
but you can't get that from the generated .v, you must have the python
<dragonmux>
because what we're talking of here is the STL problem.. ie, the template metaprogramming problme
<dragonmux>
*problem
<agg>
it's not even templated though
<agg>
if it was templated I think it's clearer that it's derived
sakirious has quit [Ping timeout: 252 seconds]
<lkcl>
yyeah, in libre-soc we make eexxtensive use of that
<agg>
in this case it's not even clear to me that the logic statements my crc library generates count as copyrighted, right?
<dragonmux>
the CRC library is a metaprogram to the gateware generation
<agg>
it's not like when you link code
<lkcl>
multiple inheritance which is flat-out impossible in verilog
<agg>
basically all nmigen libraries are metaporgram to gateware generation
<agg>
metaprogram*
<agg>
they seem more like libraries that GCC itself is linked to, like GMP, than libraries the "gateware" is linked to
<lkcl>
there's no way you could "derive" the python source from the verilog output: the verilog is effectively assembly-code at that point
<agg>
but it depends a lot on the nature of the library.... some of them will just be 100% gateware, not generators at all
<dragonmux>
uh.. no? if it's a simple Elaboratable.. that's the same deal as a C++ class in a library
<agg>
yea, sorry, I was definitely way too strong
<agg>
lots of nmigen libraries are metaprograms, including lots of nmutil
<agg>
some are clearly not and are just straight up HDL, or anyway just always generate the same HDL
<agg>
like a fixed-function CRC block for computing ethernet CRCs or whatever
<dragonmux>
that's a fair characterisation which is why we were just contemplating the way these licenses interact with C++ templates as that feels like the best model we have for how to handle this
<agg>
and that does have a clear interface in verilog and could be replaced wholesale
<lkcl>
a good (simple) example is for-loops which take a parameter (at python time)
<lkcl>
constructing an AST that results in static creation of assembly-like "loop-unrolled" verilog/RTLIL
<dragonmux>
that's just the -flto -O3 problem
<dragonmux>
a better example is where agg was going with this where gatware generation is entirely driven by metaprogam parameters like the choice of polynomial going into a CRC lirbary
<dragonmux>
something that makes the metaprogram stamp out a different bit of gateware that then ends up in the .debug.v or RTLIL
<d1b2>
<zyp> the CRC example sounds comparable to a tool generating lookup tables for an accelerated software implementation
<agg>
zyp: maybe kind of like a tool generating source code for an accelerated version, since it's not only generating data tables
<d1b2>
<zyp> true
<agg>
though I think it's different to that hxx template because it's not textually included at all, which is a situation where the copyright is much clearer
<agg>
maybe it's effectively the same, I don't know, but it's running different code based on the input instead of placing the input into a template
<dragonmux>
uh, the template in our example ends up on the "wrong" side of the library/API barrier same as your CRC metaprogram example
<agg>
doesn't it effectively end up as source being compiled alongside your code?
<dragonmux>
you end up with library source in *your* program/gateware
<dragonmux>
rather than in the library's .so/.a
<agg>
I think that's effectively true for all nmigen libraries
<agg>
wellllllll
<agg>
yes
<agg>
the output of my crc is still its own "module" in the output verilog
<d1b2>
<zyp> IMO it'd be reasonable for the tool's license to explicitly specify that the output were exempt from the license if that were the case
<agg>
so it's as distinct as any other
<dragonmux>
that's why we were contemplating if you should apply the STL template stuff to this
<agg>
the same as it's its own class in your case
<agg>
zyp: yea, that would definitely clear it up! but if the tool doesn't specify, I wonder where and to what extent it counts
<dragonmux>
there were exceptions drawn up because of these bleed-over problems which is why the GCC STL is GPL w/ linking exception
<d1b2>
<zyp> I think that would depend on whether the included part would be significant enough to be considered copyrightable or not
<dragonmux>
anywhere you have a 'simple' Elaboratable, and therefore a module in the .debug.v, that feels like it obeys the library API boundaries normally.. but when there's metaprogramming going on affecting the generation.. then that possibly leads to the bleed-over problem
<dragonmux>
for context agg, when building MXKeyboard's firmware, the compiler has to chew on a couple of libraries such as dragonUSB to create .a files containing LTO objects.. at that point you can still do a swap, but as soon as you do the linking step.. the resulting binary is too blended to be able to.. and it'd be worse if doing a unity build as that effectively takes all the source files and pastes them one after the other into one
<dragonmux>
giant TU and does compile+link on that in one step
<dragonmux>
(the RTLIL output of nMigen feels like it fits the model of C++ unity builds is where we're going with that)
<dragonmux>
also in our example the firmware has a lot of templates involved, and whenever that happens it causes a crossing of library boundaries to occur, so you can't take the .a/.o files and swap out dragonAVR for example as the flash_t template bleeds really badly into the main firmware source
<agg>
yea
<agg>
so you see why i'm not convinced providing the rtlil would allow swapping out nmutil under the lgpl conditions
<dragonmux>
we do.. we figued that was along your line of thinking
<lkcl>
basically it looks like we need to add a linking exemption.
<dragonmux>
we are suggesting that strongly, yes
<dragonmux>
modeled after the STL linking exception
<agg>
well, depends what you want, lkcl
<agg>
as-is it will effectively ensure projects using nmutil are open-source
<dragonmux>
true
<lkcl>
for people to be able to use nmutil in commercial products
<lkcl>
but not "sponge" off of our efforts
<dragonmux>
(also,lkcl, we felt it was topic-relevant here because we're not sure anyone's actually come up with a workable answer as to how nMigen library licensing works in relation to the otuput, so it's generally applicable to all projects using the tool)
<agg>
how do you imagine that looking in practice?
<lkcl>
by requiring that they contribute modifications back to everyone
<lkcl>
dragonmux: got it
<lkcl>
as in, use nmutil in commercial products (FPGA soft-products as well as ASICs) but without them necessarily having to come to us for re-licensing under a commercial license
<agg>
the LGPL already _is_ a linking exception to the GPL, but with the extra requirement that you must be able to swap out the library, aiui
<agg>
but you could certainly add extra exemptions
<lkcl>
but, if they *modify* or enhance nmutil, they'd have to provide the source
<lkcl>
we'd have to add an exemption that that swap-out not be required
<lkcl>
because in an ASIC you *literally* can't "swap out" (link) a hard-version - but there's another issue at play, there, with ASICs
<agg>
hah indeed
<lkcl>
my understanding there is that whilst Design Rights apply (which in the Silicon Industry ends up being called "Mask Rights")
<lkcl>
there's a fire-break between the HDL and the Masks due to the Masks being circuits (mathematics) which are un-copyrightable
<lkcl>
i had a similar conversation with Bruce Perens (who worked closely with the SFLC) over PCB CAD drawings
<lkcl>
he was quite annoyed when i said i was going to release the PCB CAD layout files under an open source license :)
<lkcl>
because every time you do that it reinforces the [mistaken] belief that schematics - mathematical representations of circuits - are copyrightable
<lkcl>
it's all so confusing! :)
<agg>
the circuits are not copyrightable but I believe the specific schematics are...
<agg>
of course someone can redraw the same circuit and it's not copyright protected, but a pdf of a schematic I create couldn't be freely copied (aiui...)
<dragonmux>
correct agg.. schematics do contain original work by their designer, especially if the novel combination of components into a new product
<lkcl>
ahh yeah, similar to how Standards (ISAs) are not copyrightable because they're facts
<agg>
standards are totally copyrightable, huh?
<agg>
oh, ISAs conceptually, perhaps
<lkcl>
but the document *containing* those facts are copyrightable material
<lkcl>
yes, because the ISA is effectively a formal declaration of a set of "facts"
<agg>
dragonmux: the novel combination of components into a product isn't copyrightable, is it?
<dragonmux>
likewise specific implementations can be copyrightable too
<agg>
like, I could combine the same components into something with the same function and it wouldn't impact copyright (maybe patents)
<dragonmux>
agg: the designs showing your work and calculations and how is.. ergo the schematic..
<agg>
yes, agreed
<agg>
but if I reimplement that schematic in my own hardware and I distribute that hardware
<agg>
that's not an infringement of your schematic or copyright
<agg>
(redistributing your schematic would be, though)
<dragonmux>
the PCB designs too with the specific layout of traces and stackup is also copyright material
<dragonmux>
falls under being a creative work at the very least
<agg>
yea, pcb layout is also copyright
<agg>
just not the concept of the circuit
<lkcl>
dragonmux: that's covered by "Design Rights"
<dragonmux>
depends on the concept.. there are some that could be under certain circumstances.. but you are right that the general case a circuit, generally, isn't
<lkcl>
which is a 4th not-very-well-known completely separate area of Copyright Law
<dragonmux>
lkcl: under copyright the PCB is considered artwork IWRC
<lkcl>
dragonmux: sounds about right
<dragonmux>
can't blindly copy a piece of art without consequences
<dragonmux>
's called forgery
<agg>
so it makes sense to release schematics under something like CERN OHL or even creative commons, and PCB layouts similarly, I think
<dragonmux>
agreed
<agg>
I used to use CC especially as the CERN OHLs were a bit confusing and had a lot of options, afaict CC seems reasonable for schematics in a way it does not for software
<agg>
but probably OHL is a more explicit choice for hardware I guess
<dragonmux>
aye, CC is a popular choice it seems for schematics and similar
<dragonmux>
we use OHL typically for our hardware
<dragonmux>
interestingly, we think with the way BSD-*-Clause is worded, it would be reasonably applicable to hardware too
<agg>
huh, yea
* lkcl
committed a change data_o/data_i to i_data/o_data as well in nmutil StageAPI
cyborg_ar has quit [Ping timeout: 258 seconds]
cyborg_ar has joined #nmigen
emeb_mac has joined #nmigen
vup has quit [*.net *.split]
lkcl has quit [*.net *.split]
lsneff_ has quit [*.net *.split]
mithro has quit [*.net *.split]
sm2n has quit [*.net *.split]
mindw0rk has quit [*.net *.split]
vup has joined #nmigen
lkcl has joined #nmigen
mithro has joined #nmigen
mindw0rk has joined #nmigen
lsneff_ has joined #nmigen
sm2n has joined #nmigen
TD--Linux is now known as TD-Linux
emeb_mac has quit [Quit: Leaving.]
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #nmigen
ktemkin has quit []
ktemkin has joined #nmigen
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #nmigen
<tpw_rules>
has anybody done pcie on nmigen? i know there's litex but that's just regular migen
<tpw_rules>
(i'm not entirely sure how to integrate the tw0
<tpw_rules>
two)
<d1b2>
<zyp> litepcie can generate a standalone core that you can instance from nmigen
<tpw_rules>
ok
<tpw_rules>
i have a nitefury i bought forever ago and i want to do dma type things over the m.2 connector with a host computer
<d1b2>
<zyp> or you can start with a litex base and add nmigen cores if that suits your goal better
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #nmigen
<tpw_rules>
are there linux drivers for the litex pcie core?
<tpw_rules>
yes
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #nmigen
GenTooMan has quit [Ping timeout: 240 seconds]
<lkcl>
zip: unfortunately - bear in mind you'll have to check this - i was told that litepcie relies on a proprietary encrypted binary firmware provided by xilinx tools as part of the build process
<lkcl>
please do double-check that
<lkcl>
if that's not a problem for you then please do ignore the above
gatecat has quit []
gatecat has joined #nmigen
yuriks has quit []
yuriks has joined #nmigen
<d1b2>
<zyp> yes, I can confirm it relies on vendor IP for the lowlevel stuff