[libre-riscv-dev] Contributing to the Libre-Soc Project

[libre-riscv-dev] Contributing to the Libre-Soc Project

[Sanjay Menon]

Hi,

I am a budding VLSI enthusiast and open-source developer. I would love to
work with the team in your goal to achieve a completely open source project.

I believe that as a beginner in this area, I would be able to learn more
from you guys as I contribute to this wonderful project.

I thank Yehowshua Immanuel for introducing me to this project. Can't wait
to start already. Hoping to hear from you soon.

To know more about me do checkout my LinkedIn
<http://www.linkedin.com/in/sanjay-menon-91791815a> profile.

Thanks and regards,
Sanjay A Menon
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Contributing to the Libre-Soc Project

[Yehowshua]

> On Jun 6, 2020, at 6:29 PM, Sanjay Menon <sanjayamenon.mec@gmail.com> wrote:
> 
> Hi,
> 
> I am a budding VLSI enthusiast and open-source developer. I would love to
> work with the team in your goal to achieve a completely open source project.
> 

My response will be quick as I spend my weekends writing my Master’s
Thesis.
Hi. And fantastic. We have a charter, that you should review here:
https://libre-soc.org/charter/ <https://libre-soc.org/charter/>

> I believe that as a beginner in this area, I would be able to learn more
> from you guys as I contribute to this wonderful project.

Sure. Would probably start by learning nMigen as it seems you’re coming
from a verilog background.

https://github.com/RobertBaruch/nmigen-tutorial <https://github.com/RobertBaruch/nmigen-tutorial>
http://blog.lambdaconcept.com/doku.php?id=nmigen:tutorial <http://blog.lambdaconcept.com/doku.php?id=nmigen:tutorial>


At the moment, we’re prepping for the Oct/Nov 2020 Tapeout.
Most of the work is going into hooking up the scoreboard to
our functional units right now.

We also make extensive use of formal verification.
Which reminds me, we need to separate FHDLTestCase class
into the nmutils repo since it's no longer officially maintained.

That’s a pretty simple task - maybe something you could handle.
You’ll know what I mean once you start playing with nMigen.

We also should start putting test we want to in `__init__.py` in the soc/tests
folder - so that `setup.py test` works.

So much to do, the aforementioned tasks are pretty beginner level.

> 
> I thank Yehowshua Immanuel for introducing me to this project. Can't wait
> to start already. Hoping to hear from you soon.
> 
> To know more about me do checkout my LinkedIn
> <http://www.linkedin.com/in/sanjay-menon-91791815a> profile.
> 
> Thanks and regards,
> Sanjay A Menon

Welcome,
	Yehowshua

> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Contributing to the Libre-Soc Project

[Luke Kenneth Casson Leighton]

(hi everyone please do cc sanjay as i've just manually approved this
message and he is not yet subscribed to the list, so would not see
replies unless explicitly cc'd.  sanjay, do subscribe to the list via
the interface at
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev)

On Sat, Jun 6, 2020 at 11:47 PM Sanjay Menon <sanjayamenon.mec@gmail.com> wrote:
>
> Hi,
>
> I am a budding VLSI enthusiast and open-source developer. I would love to
> work with the team in your goal to achieve a completely open source project.

good to hear from you.

one key thing to appreciate: this is a libre project, not an "open
source" one.  the distinction is not immediately apparent or
well-known to people, and it comes down to this: a Libre project says
"no" when it comes to unethical practices, whereas an "open" one makes
no such declaration.  "open source" projects *might* have people
contributing to it with the very best of intentions, however none of
them will have *actively* declared not to cross an ethical line.

> I believe that as a beginner in this area, I would be able to learn more
> from you guys as I contribute to this wonderful project.

well, one thing i love telling people the story is of how Cole Poirier
has gone from zero hardware knowledge to writing his own nmigen
modules.  so there is room for everyone with all levels of experience.

> I thank Yehowshua Immanuel for introducing me to this project. Can't wait
> to start already. Hoping to hear from you soon.

so, congratulations on the first step - getting in touch (*tick*) :)
just go through the list on the "how can i help as a developer", in
your own time - https://libre-soc.org/

in particular you'll find the development workflow advice here:
https://libre-soc.org/HDL_workflow/

this is a combined page of best practices for collaboration, as well
as containing developer-style "getting started" instructions.


> To know more about me do checkout my LinkedIn
> <http://www.linkedin.com/in/sanjay-menon-91791815a> profile.

nice, i see you've done actual VLSI layout - we're using coriolis2,
this involves actually writing the layout *entirely as a python
program*:
https://bugs.libre-soc.org/buglist.cgi?quicksearch=coriolis2&list_id=826

if you'd like to do that, you're more than welcome (and can receive
donations from NLNet for doing so).  there's plenty of other tasks as
well.

you have some cool projects on there, including implementing SHA256 in
hardware: did you do that at gate-level or in an HDL?

best,

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] FHDLTestCase

[Luke Kenneth Casson Leighton]

On Sun, Jun 7, 2020 at 12:03 AM Yehowshua <yimmanuel3@gatech.edu> wrote:

> Which reminds me, we need to separate FHDLTestCase class
> into the nmutils repo since it's no longer officially maintained.

(i've done that already.  we also need to take a copy of the
nmigen._tools.py code.  could you ask whitequark if she expects that
to also happen, that we create multiple copies of more and more code
from nmigen?)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] FHDLTestCase

[Yehowshua]

> 
>> Which reminds me, we need to separate FHDLTestCase class
>> into the nmutils repo since it's no longer officially maintained.
> 
> (i've done that already.  we also need to take a copy of the
> nmigen._tools.py code.  could you ask whitequark if she expects that
> to also happen, that we create multiple copies of more and more code
> from nmigen?)
> 

Just now seeing this. Glad you did that!
I’ll ask.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] FHDLTestCase

[Yehowshua]

But from what she told me, anything with `_` prefix 
has not guarantees of maintaining a stable interface.

So if we’ve been importing from `_`, that’s on us.

Other than that, we should be fine.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] FHDLTestCase

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Jun 7, 2020 at 12:22 AM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> >> Which reminds me, we need to separate FHDLTestCase class
> >> into the nmutils repo since it's no longer officially maintained.
> >
> > (i've done that already.  we also need to take a copy of the
> > nmigen._tools.py code.  could you ask whitequark if she expects that
> > to also happen, that we create multiple copies of more and more code
> > from nmigen?)
> >
>
> Just now seeing this. Glad you did that!

from nmigen._toolchain import require_tool

https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/formaltest.py;hb=HEAD


> I’ll ask.

basically, without coming out and actually saying "this is completely
ridiculous, it leads down a rabbithole of copying more and more of
nmigen into a separate repository, which everyone else will likewise
have to do", we need to slowly and diplomatically educate her in the
python collaborative practices that she's missing.

nmigen is extremely unusual in that it is a "root" project (zero
external dependencies).  it's self-contained, is whitequark's first
experience with python, and consequently she has *zero* experience of
python collaborative development practices that have taken 20 years to
establish.

given that nmigen may well be the very first time that some HDL
engineers ever *use* python extensively (Staf, for example i believe
may fall into this category), there is a huge responsibility that
falls on whitequark's shoulders to learn and then make sure to use
best collaborative python practices.  and it is a huge responsibility.

unfortunately, my efforts to communicate with her about this did not
go well.  when i spoke with her about the extremely damaging practice
of using wildcard imports, rather than go "ah: i understand how this
is extremely detrimental to collaborative development, i will give it
some thought", her response was, "the python programming language
should not be broken.  it is not my responsibility: it is the
responsibility of the python developers.  they should never have added
the feature".

to her credit she *is* responding on some things.  usually it takes
more than one person to communicate with her about a given issue.
over time, she'll get it, i am sure, as she is extremely intelligent.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] FHDLTestCase

[Yehowshua]

nMigen is in active development. 

At somepoint, we may have to make nMigen a 
submodule frozen at a particular commit anyways.

We do have tests, so we’ll know when things start breaking.
We’ll take it one thing at a time.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] FHDLTestCase

[Luke Kenneth Casson Leighton]

On Sun, Jun 7, 2020 at 12:28 AM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> But from what she told me, anything with `_` prefix
> has not guarantees of maintaining a stable interface.

correct.  and therefore the implications are: we must take a copy of
that code in order for it to be "maintained as a stable interface".

> So if we’ve been importing from `_`, that’s on us.

uh-huh.  and we just had to quotes take a copy of FHDLTestCase quotes.

and, because FHDLTestCase - which she wrote - uses nmigen._toolchain,
we must now quotes take a copy of _toolchain.py quotes.

... you see where that leads?

absolutely every single python nmigen developer must quotes take
copies of code quotes in order to guarantee that they have a stable
API to work with.

now, it *might* be the case that somebody notices that we have quotes
taken a copy of FHDLTestCase quotes and also quotes taken a copy of
_toolchain.py quotes.

they *might* use nmutil because of that, and thus avoid code-duplication.

however the much more likely scenario is that they will likewise take
copies of that code, maintain completely separate copies (effectively
hard forks).

the bottom line is that this, slowly, will demonstrate to whitequark
what the *actual* role and responsibility of being an open
collaborative software development maintainer is.  it's *not* to say
"this is not my responsibility, *i* declare - end of discussion - that
this is outside of scope of *my* project: if you try to use what *I
DECLARE* is private, that is YOUR problem", it's to be the gateway of
a *two-way* conversation.

i fully get that she is concerned about changing the API, and wants
the freedom and flexibility to change the internals.  python
unfortunately doesn't work that way.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] FHDLTestCase

[Luke Kenneth Casson Leighton]

On Sun, Jun 7, 2020 at 12:45 AM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> nMigen is in active development.

yehyeh.

> At somepoint, we may have to make nMigen a
> submodule frozen at a particular commit anyways.

when the ASIC layout is being done, this will be a hard requirement.
Jean-Paul explained that it is Industry Standard Practice to have full
reproducible builds, fully automated in all respects.  not even the
username / login changes (nobody has separate usernames in the
repro-build scripts: even the username is exactly the same, added as
part of the OS clone/install script).

> We do have tests, so we’ll know when things start breaking.

yehyeh.

> We’ll take it one thing at a time.

:)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev