[libre-riscv-dev] daily kan-ban update 03jun2020

[libre-riscv-dev] daily kan-ban update 03jun2020

[Luke Kenneth Casson Leighton]

yesterday:

* fixed MultiCompUnit FSM for case when there are no registers to
write (branch conditional)
* worked with Michael on Branch, deciding where to put the incoming
SPR registers (port1, port2)
* sorted out regspecs, in particular the "fast" regfile (CTR, MSR, CIA, TAR, LR)
* created a special strategic function that encodes the relationship
between regspecs, PowerDecode2, and the Function Units
* reorganised the */test_pipe_caller.py and test_*_compunit.py unit
tests to share common functions for setting up input
* worked with Cole on TRAP pipeline.
* moved RS to pipeline input position 1, in MTSPR and MTMSR.

morning:

* more pipeline / compunit test reorganisation
* dynamic enable/disable carry-in and XER flags (and test it's ok)
* remove pipe_data.py rdflags() and use strategic function
regspec_decode() instead

today:

* continue helping Cole with TRAP pipeline
* slowly work towards linking pipelines to regfiles, now that
regspec_decode can express the port read/write characteristics, purely
from pipeline specifications (pipe_data.py)

l.

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

_______________________________________________
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] daily kan-ban update 03jun2020

[Tobias Platen]

today:
  formal verification of the data merger class.

_______________________________________________
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] daily kan-ban update 03jun2020

[Cole Poirier]

On Jun 3 2020, at 5:50 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote: 
> today:
> 
> * continue helping Cole with TRAP pipeline

Thanks Luke, I had a great time working with you on all the TODOs
yesterday, and I feel just a little bit more confident in my handle on
the concepts at play today than I did yesterday.

Today:

continue working on TRAP pipeline fixing the TODOs luke has provided for me

Cole

_______________________________________________
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] daily kan-ban update 03jun2020

[Luke Kenneth Casson Leighton]

On Thu, Jun 4, 2020 at 12:58 AM Cole Poirier <colepoirier@gmail.com> wrote:
>
> On Jun 3 2020, at 5:50 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
> > today:
> >
> > * continue helping Cole with TRAP pipeline
>
> Thanks Luke, I had a great time working with you on all the TODOs
> yesterday, and I feel just a little bit more confident in my handle on
> the concepts at play today than I did yesterday.

:)

> Today:
>
> continue working on TRAP pipeline fixing the TODOs luke has provided for me

cool.  remember also to include the comments - don't delete them.  the
VHDL comments ( "--" VHDL translated to "#" python) are just as
important to do line-by-line.  you'll need to go over the microwatt
execute1.vhdl and the bugreport because i noticed you deleted some of
the python docstrings containing the VHDL, without translating the
VHDL comment strings.

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] daily kan-ban update 03jun2020

[Cole Poirier]

On Jun 3 2020, at 5:03 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> cool.  remember also to include the comments - don't delete them.  the
> VHDL comments ( "--" VHDL translated to "#" python) are just as
> important to do line-by-line.  you'll need to go over the microwatt
> execute1.vhdl and the bugreport because i noticed you deleted some of
> the python docstrings containing the VHDL, without translating the
> VHDL comment strings.
> 
> l.

Yes sorry about that, part was intentional, which I see now was clearly
a silly thing to do, the other part was that I managed to really mess up
the 'resolution' of merge conflicts. I was following the same guide I've
used previously (successfully) for git mergetool vimdiff, and for some
reason my attempt to accept the remote changes in favour of my own did
the opposite... and then some, like deleting a bunch of lines near the
top of the file that I did't touch. This all would not have been a
problem had I done a second review of the changes before pushing them
like I was supposed to. Lesson learned.

Cole

_______________________________________________
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] daily kan-ban update 03jun2020

[Luke Kenneth Casson Leighton]

On Thu, Jun 4, 2020 at 1:09 AM Cole Poirier <colepoirier@gmail.com> wrote:

> Yes sorry about that, part was intentional, which I see now was clearly
> a silly thing to do, the other part was that I managed to really mess up
> the 'resolution' of merge conflicts.

your responsibility to sort out :)

welcome to working on the same file.

suggestion: do regular "git pulls".  this doesn't work with rebase, so
you have to use "git stash" followed by "git pull" followed by "git
stash apply" and then work it out from there.

or you can use "git stash show -p {0}" (after doing "git stash list"
to find the right one) prior to "git stash apply" and that will give
you the diff before applying it.

which.... if you want, you can pipe that diff into a file, then use
"patch", which has the advantage of putting rejected patches into
".rej" files, which you can then manually sort out.

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] daily kan-ban update 03jun2020

[Jacob Lifshay]

continuing working on the div and mul pipelines

Jacob

_______________________________________________
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] daily kan-ban update 03jun2020

[Cole Poirier]

On Jun 3 2020, at 5:32 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> On Thu, Jun 4, 2020 at 1:09 AM Cole Poirier <colepoirier@gmail.com> wrote:
> 
>> Yes sorry about that, part was intentional, which I see now was clearly
>> a silly thing to do, the other part was that I managed to really mess up
>> the 'resolution' of merge conflicts.
> 
> your responsibility to sort out :)

I think I have, but we shall see...
 
> welcome to working on the same file.
> 
> suggestion: do regular "git pulls".  this doesn't work with rebase, so
> you have to use "git stash" followed by "git pull" followed by "git
> stash apply" and then work it out from there.
> 
> or you can use "git stash show -p {0}" (after doing "git stash list"
> to find the right one) prior to "git stash apply" and that will give
> you the diff before applying it.
> 
> which.... if you want, you can pipe that diff into a file, then use
> "patch", which has the advantage of putting rejected patches into
> ".rej" files, which you can then manually sort out.
> 
> l.

Ooooh, this is very cool, will be 'bookmarking' this for future use.

Cole

_______________________________________________
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] daily kan-ban update 03jun2020

[Luke Kenneth Casson Leighton]

On Thu, Jun 4, 2020 at 4:46 AM Cole Poirier <colepoirier@gmail.com> wrote:
>
> On Jun 3 2020, at 5:32 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > On Thu, Jun 4, 2020 at 1:09 AM Cole Poirier <colepoirier@gmail.com> wrote:
> >
> >> Yes sorry about that, part was intentional, which I see now was clearly
> >> a silly thing to do, the other part was that I managed to really mess up
> >> the 'resolution' of merge conflicts.
> >
> > your responsibility to sort out :)
>
> I think I have, but we shall see...
>
> > welcome to working on the same file.

btw, another thing: if you're constantly running into commit
conflicts, it means that you're "panicking and omg omg i can't
possibly commit this i need to leave it a few days because i'm not
confident omg it might not work might damage something omg omg argh
argh"

do a small change, commit it immediately, push it immediately.

do another small change, commit it immediately, push it immediately.

if you were working last night, and committed something without
pushing it, you'll now find that you have another conflict to resolve,
because i've replaced all of the long signal names with the
convenience variables.

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] daily kan-ban update 03jun2020

[Cole Poirier]

On Jun 4 2020, at 4:02 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> On Thu, Jun 4, 2020 at 4:46 AM Cole Poirier <colepoirier@gmail.com> wrote:
>> 
>> On Jun 3 2020, at 5:32 pm, Luke Kenneth Casson Leighton
>> <lkcl@lkcl.net> wrote:
>> > On Thu, Jun 4, 2020 at 1:09 AM Cole Poirier <colepoirier@gmail.com> wrote:
>> >
>> >> Yes sorry about that, part was intentional, which I see now was clearly
>> >> a silly thing to do, the other part was that I managed to really
>> mess up
>> >> the 'resolution' of merge conflicts.
>> >
>> > your responsibility to sort out :)
>> 
>> I think I have, but we shall see...
>> 
>> > welcome to working on the same file.
> 
> btw, another thing: if you're constantly running into commit
> conflicts, it means that you're "panicking and omg omg i can't
> possibly commit this i need to leave it a few days because i'm not
> confident omg it might not work might damage something omg omg argh
> argh"
> 
> do a small change, commit it immediately, push it immediately.
> 
> do another small change, commit it immediately, push it immediately.
> 
> if you were working last night, and committed something without
> pushing it, you'll now find that you have another conflict to resolve,
> because i've replaced all of the long signal names with the
> convenience variables.
> 
> l.

Not to worry, you helped me break the bad habit of not committing
immediately a few weeks ago :) Was just that we were working on the same
file within 15 min of each other.

Cole

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