[Libre-soc-dev] daily kan-ban update 12oct2020

[Cole Poirier]

On Mon, Oct 12, 2020 at 2:45 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> On Mon, Oct 12, 2020 at 8:46 PM Cole Poirier <colepoirier at gmail.com> wrote:
> >
> > Today:
> >
> > created litex/florent/ulx3s85f.py based on
> > lites/florent/versa_ecp5.py, successfully completes when run as
> > `./ulx3s85f.py`, `./ulx3s85f.py --build`, and loads to my 85K LUT
>
> if the differences are not significant i would have preferred it be
> called just "ecp5.py" and given a runtime option to select the
> platform, but hey.  you worked it out.

Actually there is a weird significant difference in the ordering of
positional arguments between versa_ecp5.py and ulx3s.py, that's why I
was getting that cryptic error about 'multiple values for device in
init', where:
```versa_ecp5.py
BaseSoC.__init__(self, sys_clk_freq,
```

```ulx3s85f.py
BaseSoC.__init__(self, device="LFE5U-85F", sys_clk_freq=sys_clk_freq,
```

... looking at it now I'm seeing that I can probably just specify both
as keywords in versa_ecp5.py... though it seems that ecp5.py would be
a more accurate file name given that we are using both versa_ecp5 and
the model of the chip in my ulx3s is LFE5U-85F. Worthwhile for me to
make this change `versa_ecp5.py -> ecp5.py` and grep for references to
versa_ecp5.py and test that it still works?

> > What should I do now? Try sending commands over JTAG, openocd, gdb?
>
> gdb will not work because there is absolutely zero support in gdb or
> openocd for PowerISA processors, believe it or not.

F*** :) I assume we will need this at some point. Should this be done
through OPF, or is there money in the budget for this to be
implemented by a to-be-found developer?

> however see the litex/florent/README.txt you *MIGHT* be able to adapt
> that to "direct" contact with the HDL running on the FPGA.

Will add this to my list, will update my wiki page later today once
I've created bug reports to reference.

> the thing is: where are you connecting that JTAG to?  if you send JTAG
> commands to the *FPGA* why would you expect the *FPGA* to know about
> the TAP HDL in the processor core running *on* that FPGA?
[snip]
> similar to these four lines:
> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=4279effcffe2fbf15f877e9b2a1b76beab248dac;hb=HEAD#l460

Ahhh understood. Thank you for the very thorough and helpful explanation.

> but instead doing something like... err....
> gpio0_pads = platform.reqiest("gpio", 0) # because back in ulx3s.py
> there's gpio 0, 1, and 2
[snip]
> if they are, then great! these are what you wire up the STLINKv2 to,
> according to what you decided to connect to just above.

Gotcha. Should be a 'fun' process ;)

> but for god's sake do not get this wrong, such as driving an input as
> an output or vice-versa, or wiring up 5.0V to GND with those
> jumper-cables.

I probably checked that oh i dont know... 150 times when I was setting
it up hehe.

> do *NOT* randomly upload and power up the ulx3s until this has been
> THOROUGHLY triple-checked.  or, you are entirely free to not bother
> and to end up learning the hard way by destroying the FPGA.

YUP!! Definitely been very cautious so far, and that's just been with
trying to upload known-working stuff... I may even quintuple check ;)

> > Now, going to work on adding getopt to all of the currently hard-coded
> > options in simple/issuer_verilog.py etc, making sure to test that it
> > still works with this augmentation.
>
> excellent.

Ok started this, wanted to make sure tests were up to date as well,
just commited some fixes for import errors, seems like there is one
real error though:
```
============================= test session starts ==============================
platform linux -- Python 3.7.3, pytest-6.1.1, py-1.9.0, pluggy-0.13.1
rootdir: /home/colepoirier/src/soc
collected 223 items / 1 error / 222 selected

==================================== ERRORS ====================================
________ ERROR collecting src/soc/bus/test/test_sram_wb_downconvert.py _________
bus/test/test_sram_wb_downconvert.py:132: in <module>
    sim.run()
[snip]
../../../../workspace/nmigen/nmigen/sim/core.py:90: in wrapper
    yield from process()
bus/test/test_sram_wb_downconvert.py:120: in process
    assert data == test_data, "data != %x %16x" % (test_data, data)
E   AssertionError: data != deadbeef12345678 1234567812345678
E   assert 1311768465173141112 == 16045690981402826360
------------------------------- Captured stdout --------------------------------
wb downconvert from to ratio 64 32 2
sel 0 from 0 to 2
sel 1 from 2 to 4
(sig cvtbus__adr) = 0
(sig cvtbus__dat_r) = 0x0
data 0x1234567812345678
(sig cvtbus__adr) = 4
(sig cvtbus__dat_r) = 0x1234567812345678
```

Are you already aware of this test failure?

... actually just nosetests3 as is specified in the Makefile and I get
totally different results... strange.. actually it looks like it's
either stuck or running a *very* intensive test because it's been
running displaying the same output for at least 5 min. I guess I
should stick to using nosetests3 instead of pytest? although I do have
to say I find the pytest reporting really clean and wonderful...
Sorry, first time really interacting with our tests... any comments
for me?

```nosetest3 output as of right now
colepoirier at cherrytree:~/src/soc/src/soc$ nosetests3
F....EEESEEEEEEEEEEEEEEEEEEEEFFFFFFFFFFFFF..E/home/colepoirier/src/soc/src/soc/experiment/test/test_compalu_multi.py:457:
UnusedElaboratable: <soc.experiment.alu_fsm.Shifter object at
0x7f1e52a16a58> created but never used
  alu = Shifter(8)
[snipped 10 or so 'created but never used warnings]
/home/colepoirier/src/soc/src/soc/experiment/compalu_multi.py:182:
UnusedElaboratable: <nmutil.latch.SRLatch object at 0x7f1e52bfc828>
created but never used
  m.submodules.rok_l = rok_l = SRLatch(sync=False, name="rdok")
UnusedElaboratable: Enable tracemalloc to get the object allocation traceback
..E..
```

Additional questions/comments:

Has Alain made the necessary change to the libre-soc.org server that
will enable us to make use of .gitlab-ci.yaml that tobias just did
work on? If not, what is the purpose of his updating this file? Does
he have his own gitlab instance? Apologies for the ignorant questions,
I am confused.

Cole