[libre-riscv-dev] daily kan-ban update 08mar2020

[libre-riscv-dev] daily kan-ban update 08mar2020

[Luke Kenneth Casson Leighton]

yesterday we had a discussion with Tim from Raptor CS about interfaces.  if
we have LPC which is the old ISA Memory Bus protocol over only 6 pins then
because it is an actual memory interface we can even boot directly from
it.  start the PC at an address that triggers memory requests that get
fulfilled by an external LPC chip.

if we have that as one of the interfaces (and can run a linux kernel) we
basically have our first customer (and business partner).

i managed to get ST working on the LDSTCompUnit.  LD i should have today.

also i will talk with MarketNext today about the magazine article.

also wrote the page for discussion of "minimum viable ASIC"
https://libre-soc.org/180nm_Oct2020/

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 08mar2020

[Luke Kenneth Casson Leighton]

writing on behalf of these two people:

Staf is doing a 180nm tapeout for the next few days.

Rudi from ASICS.ws has offered to do all the interfaces (connected to
wishbone).  we need someone to define them for him.




-- 
---
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 08mar2020

[Yehowshua]

OK. Lemme have a go at this.
So I know we need LPC. Discussions with Raptor would have us use LPC to grab the boot loader externally I believe.

Here is some sample code for having the LCP sit as a wishbone slave.

Is Rudi on the mailing list yet?

https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga/blob/master/lpc_interface.v#L1162 <https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga/blob/master/lpc_interface.v#L1162>

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] daily kan-ban update 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 2:52 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> OK. Lemme have a go at this.

bugreport.  link to the interfaces page
https://libre-soc.org/180nm_Oct2020/interfaces/

> So I know we need LPC. Discussions with Raptor would have us use LPC to grab the boot loader externally I believe.

it's far more trivial even than that.  you literally set the Program
Counter to an address that is mapped to the LPC's memory-mapped
address.  that's it.  the Instruction Q fetch makes a request for an
instruction, that request goes over wishbone, wishbone directs it to
the LPC's memory-mapped peripheral, the LPC translates it into a "LPC
style memory request", the data comes back at that address.

it's so ridiculously not complicated it's actually "difficult to
understand why it's not more complicated".


> Here is some sample code for having the LCP sit as a wishbone slave.

ahh goooood.  perfect!

> Is Rudi on the mailing list yet?

no and i'm going to recommend he not be distracted by it.  define the
task, give him the task, and trust him to do it.  he's done massive
ASICs for some really large companies, multi-million-dollar work,
gigabit SERDES and last time i talked to him he was looking at doing a
USD $20m ASIC.

> https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga/blob/master/lpc_interface.v#L1162 <https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga/blob/master/lpc_interface.v#L1162>

_______________________________________________
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 08mar2020

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 257 bytes --]

Luke Kenneth Casson Leighton schreef op vr 08-05-2020 om 11:59 [+0100]:
> writing on behalf of these two people:
> 
> Staf is doing a 180nm tapeout for the next few days.

Staf is doing the 180nm NLNet test vehicle tape-out for the next few days :)


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
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 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 6:25 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> Luke Kenneth Casson Leighton schreef op vr 08-05-2020 om 11:59 [+0100]:
> > writing on behalf of these two people:
> >
> > Staf is doing a 180nm tapeout for the next few days.
>
> Staf is doing the 180nm NLNet test vehicle tape-out for the next few days :)

oh right!  i thought that was for March, not May :)

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 08mar2020

[Michael Nolan]

Now that I have branches working in the simulator, I was thinking of 
starting work on the integer ALU. Taking a look at alu_hier.py, I think 
I'll keep the interface but replace the implementation with a pipelined 
one.

--Michael


_______________________________________________
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 08mar2020

[Michael N]

> On May 8, 2020, at 9:28 AM, Michael Nolan <mtnolan2640@gmail.com> wrote:
> 
> Now that I have branches working in the simulator, I was thinking of starting work on the integer ALU. Taking a look at alu_hier.py, I think I'll keep the interface but replace the implementation with a pipelined one.
> 
> --Michael
> 
I noticed alu_hier was nicely broken up into different function units (adder, branch unit, multiplier, etc.). Is there a nice way you know of to do that with the nmutil pipeline stages? Like a way to merge stage 1 of the adder pipe with stage one of the branch pipe to get the stage 1 of the alu?

—Michael
_______________________________________________
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 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 3:03 PM Michael N <mtnolan2640@gmail.com> wrote:

> > On May 8, 2020, at 9:28 AM, Michael Nolan <mtnolan2640@gmail.com> wrote:
> >
> > Now that I have branches working in the simulator, I was thinking of starting work on the integer ALU. Taking a look at alu_hier.py, I think I'll keep the interface but replace the implementation with a pipelined one.
> >
> > --Michael
> >
> I noticed alu_hier was nicely broken up into different function units (adder, branch unit, multiplier, etc.).

yes, with an "op" - which in our case will basically be "decoder.InternalOp"

> Is there a nice way you know of to do that with the nmutil pipeline stages?

yyyess.... except it's too complicated to explain right just this
minute.  raise the question in the bugreport.

> Like a way to merge stage 1 of the adder pipe with stage one of the branch pipe to get the stage 1 of the alu?

ok if you are talking about *outside* of ReservationStations, you are
mixing "purposes".  the Branch pipeline *does not* interact - at all -
with the ALU pipeline.

can you look again at Mitch's ScoreBoard Mechanics1.pdf

damnit this needs to be on the bugreport, i haven't got time, 10m until meeting

see page 8, diagram at the top.

Those 4 batches of Function Units are *completely separate*.  they do
*NOT* interact.

basically, the first ALU, do it entirely as combinatorial just as in
alu_hier.py and assume only one clock cycle.  leave out MUL and DIV
because those i believe need to be minimum 2 stages for MUL and a
*lot* for DIV.

actually you know what, screw it: make separate ones for MUL and DIV,
pretty much exactly like in that diagram on p8.  we're doing a
radically different design as a proof-of-concept.

* add sub neg compare logical shift all go in their own
Reservation-Station-style FunctionUnit
* MUL in its own separate RS/FU
* DIV likewise

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 08mar2020

[Michael Nolan]

On 5/8/20 11:25 AM, Luke Kenneth Casson Leighton wrote:
> On Fri, May 8, 2020 at 3:03 PM Michael N <mtnolan2640@gmail.com> wrote:
>
>>> On May 8, 2020, at 9:28 AM, Michael Nolan <mtnolan2640@gmail.com> wrote:
>>>
>>> Now that I have branches working in the simulator, I was thinking of starting work on the integer ALU. Taking a look at alu_hier.py, I think I'll keep the interface but replace the implementation with a pipelined one.

I think I made some decent progress on this. I implemented a couple 
instructions in the ALU, and wrote both formal proofs for what I expect 
the ALU stages to do, as well as a test that compares the output of the 
alu from the output of the power_pseudo simulator.

--Michael


_______________________________________________
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 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 9:47 PM Michael Nolan <mtnolan2640@gmail.com> wrote:

> I think I made some decent progress on this. I implemented a couple
> instructions in the ALU, and wrote both formal proofs for what I expect
> the ALU stages to do, as well as a test that compares the output of the
> alu from the output of the power_pseudo simulator.

nice.

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 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 2:28 PM Michael Nolan <mtnolan2640@gmail.com> wrote:
>
> Now that I have branches working in the simulator, I was thinking of
> starting work on the integer ALU. Taking a look at alu_hier.py, I think
> I'll keep the interface but replace the implementation with a pipelined
> one.

yes please.  please raise a bugreport about it, assign it to yourself,
and make certain to use the ReservationStations base class and test
infrastructure (runfp) exactly as i described in here:

https://bugs.libre-soc.org/show_bug.cgi?id=208#c55

*all* ALUs need to have that common interface (multiple
inputs-outputs).  if you can, use runfp - if there's any assumptions
about the format being FP numbers, add an extra parameter which does
debug printing as hexadecimal.  i *think* it should do that anyway
because i used the same runfp test code for FP-to-INT and INT-to-FP

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 08mar2020

[Michael Nolan]

On 5/8/20 11:10 AM, Luke Kenneth Casson Leighton wrote:
> yes please.  please raise a bugreport about it, assign it to yourself,
> and make certain to use the ReservationStations base class and test
> infrastructure (runfp) exactly as i described in here:
>
> https://bugs.libre-soc.org/show_bug.cgi?id=208#c55
>
> *all* ALUs need to have that common interface (multiple
> inputs-outputs).  if you can, use runfp - if there's any assumptions
> about the format being FP numbers, add an extra parameter which does
> debug printing as hexadecimal.  i *think* it should do that anyway
> because i used the same runfp test code for FP-to-INT and INT-to-FP
>
Since runfp and ReservationStations use FPPipeContext, should it be 
moved to nmutil?

--Michael


_______________________________________________
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 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 4:22 PM Michael Nolan <mtnolan2640@gmail.com> wrote:

> Since runfp and ReservationStations use FPPipeContext, should it be
> moved to nmutil?

tck, tck... *thinks*... not now.  too much code involved (grep for how
many places the RS class is used, that's how many unit tests you'd
have to re-run)

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 08mar2020

[Yehowshua]

Today I worked on legal things.
Also put a rough sketch together for the minimum number of interfaces we need to support.

I put USB and ethernet at second priority. I talked with Florent from EnjoyDigital, and while LiteX supports USB, it may require some non-trivial modification on our part if we didn’t want to go with (FTDI or Cypress) chips which I think max out at 200MB/s.

He pointed me to some alternatives in both Migen and nMigen:
- https://github.com/im-tomu/valentyusb <https://github.com/im-tomu/valentyusb>
- https://github.com/lambdaconcept/lambdaUSB <https://github.com/lambdaconcept/lambdaUSB>
- https://github.com/greatscottgadgets/luna <https://github.com/greatscottgadgets/luna>

I’ll pop them on the Wiki.

Litex also support ethernet which would require a $20 PHY, not great for a low cost SBC. We could also do ethernet over USB - this would render the boot loader slightly more complex if we wished to use ethernet during the boatloader.

Again, ethernet is not **essential for a minimum viable ASIC.

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] daily kan-ban update 08mar2020

[Jacob Lifshay]

On Fri, May 8, 2020, 13:27 Yehowshua <yimmanuel3@gatech.edu> wrote:

> Litex also support ethernet which would require a $20 PHY, not great for a
> low cost SBC.


There are some inexpensive GbE PHYs using the GMII interface (what I think
is what we are planning on using), mouser sells some for less than $2 each:
https://www.mouser.com/ProductDetail/Intel/PEF7072HLV16-S-LLHN?qs=d5w0Orft5TofEDXuIkwIvA==

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 08may2020

[Jacob Lifshay]

(Fixed the title, it's may not march.)

still working on load/store unit, though likely won't progress that far
since Fridays are more like 1/2 a work day for me due to religious reasons
(sabbath going from sundown every friday to sundown every saturday) as well
as me starting the day a little later than I probably should.

yehowshua, I noticed you like math, if you have some free time you might
find some of the algorithms in the algebraics library I wrote interesting
since it's a lot of number theory and modular arithmetic. Yay for factoring
polynomials over modular integers!! (glad I don't have to figure that out
again)

https://docs.rs/algebraics/0.2.0/algebraics/polynomial/struct.Polynomial.html#method.factor

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 08may2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 11:34 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> (Fixed the title, it's may not march.)

doh.  well spotted.

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 08may2020

[Yehowshua]

> On May 8, 2020, at 6:34 PM, Jacob Lifshay <programmerjake@gmail.com> wrote:
> 
> yehowshua, I noticed you like math, if you have some free time you might
> find some of the algorithms in the algebraics library I wrote interesting
> since it's a lot of number theory and modular arithmetic. Yay for factoring
> polynomials over modular integers!! (glad I don't have to figure that out
> again)
> 
> https://docs.rs/algebraics/0.2.0/algebraics/polynomial/struct.Polynomial.html#method.factor <https://docs.rs/algebraics/0.2.0/algebraics/polynomial/struct.Polynomial.html#method.factor>

Thanks, yeah…

I was recently(a month or so ago) working through some Lissajous curves.
If Libre-SOC and my thesis wasn’t burning all my time, I would probably go back to working on solving Greene’s condition for why photons undergo point-source like dispersion when they meet a non-contiguous boundary.

But alas - priorities.

Haven’t done much with number theory in a while - I pop it onto my todo list :)

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] daily kan-ban update 08may2020

[Luke Kenneth Casson Leighton]

On Sat, May 9, 2020 at 1:31 AM Yehowshua <yimmanuel3@gatech.edu> wrote:

> I was recently(a month or so ago) working through some Lissajous curves.
> If Libre-SOC and my thesis wasn’t burning all my time, I would probably go back to working on solving Greene’s condition for why photons undergo point-source like dispersion when they meet a non-contiguous boundary.

this one? https://en.wikipedia.org/wiki/Green%27s_theorem

ooo can you do superposition of spherical harmonics?

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 08may2020

[Yehowshua]

> 
> this one? https://en.wikipedia.org/wiki/Green%27s_theorem
> 
> ooo can you do superposition of spherical harmonics?
> 

https://indico.fnal.gov/event/15645/contributions/32829/attachments/20492/25589/vg_phot_diffuse_dppdmeet.pdf <https://indico.fnal.gov/event/15645/contributions/32829/attachments/20492/25589/vg_phot_diffuse_dppdmeet.pdf>

This one - page 6. When you impose a non-contiguous boundary condition,
you get re-emission in the form of point sources.

Its the analytical interpretation of the physical phenomenon that occurs
when you shine light through a tiny slit onto a wall and observe a sinusoidal
wave pattern illumination instead of just seeing a very narrow beam on the 
opposing  wall.

> l.

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] daily kan-ban update 08mar2020

[Luke Kenneth Casson Leighton]

On Fri, May 8, 2020 at 10:39 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Fri, May 8, 2020, 13:27 Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> > Litex also support ethernet which would require a $20 PHY, not great for a
> > low cost SBC.
>
>
> There are some inexpensive GbE PHYs using the GMII interface (what I think
> is what we are planning on using),

RGMII.  GMII is 8-bit TX, 8-bit RX (so around 26 pins total) where
RGMII is DDR and half the TX and RX pins.  you can see here
https://libre-soc.org/shakti/m_class/pinouts/


> mouser sells some for less than $2 each:
> https://www.mouser.com/ProductDetail/Intel/PEF7072HLV16-S-LLHN?qs=d5w0Orft5TofEDXuIkwIvA==

which  means in China it's well under $1

RT8192.

an alternative is an MCU Bus (AT/XT/ISA) and to use the DM9000.

https://libre-soc.org/shakti/m_class/peripheralschematics/

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 08mar2020

[Luke Kenneth Casson Leighton]

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

On Fri, May 8, 2020 at 9:27 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> Today I worked on legal things.
> Also put a rough sketch together for the minimum number of interfaces we need to support.
>
> I put USB and ethernet at second priority.

good.

> I talked with Florent from EnjoyDigital, and while LiteX supports USB, it may require some non-trivial modification on our part if we didn’t want to go with (FTDI or Cypress) chips which I think max out at 200MB/s.
>
> He pointed me to some alternatives in both Migen and nMigen:
> - https://github.com/im-tomu/valentyusb <https://github.com/im-tomu/valentyusb>
> - https://github.com/lambdaconcept/lambdaUSB <https://github.com/lambdaconcept/lambdaUSB>

right.  this one is ULPI (not USB)
https://github.com/lambdaconcept/lambdaUSB/blob/master/lambdausb/phy/ulpi.py

this one (and the corresponding rx.py) i'm not quite understanding the context
https://github.com/lambdaconcept/lambdaUSB/blob/master/lambdausb/phy/usb/tx.py


> - https://github.com/greatscottgadgets/luna <https://github.com/greatscottgadgets/luna>
>
> I’ll pop them on the Wiki.

use this:
https://libre-soc.org/shakti/m_class/USB2

or this as appropriate, depending on whether they're *actual* USB2
(which is unlikely given that it needs to be analog) or whether they
are UMTI / ULPI.
https://libre-soc.org/shakti/m_class/ULPI/ is the "parallel bus"
version - it does however need cross-referencing to the USB2 page.

i suspect that they're all ULPI... i *hope* they're not ohhh right,
FTDI.  that's almost certainly a "serial bus" (like the FT232 only a
bit faster).

basically UMTI is great (but a lot of pins), ULPI is better (needs
DDR), but *actual* USB2 (D+ and D-) requires a complex analog design.



> Litex also support ethernet which would require a $20 PHY, not great for a low cost SBC.

oink.  the RTL8192 RGMII PHY is under USD $1.  what the hell are they
doing picking a $20 PHY??

there's plenty of RGMII opencores / open cores out there, and the
litex eth looks like it supports a range:
https://github.com/enjoy-digital/liteeth/tree/master/liteeth/phy

GMII, MII, RMII but interestingly not RGMII (reduced gigabit MII).
RGMII is double-data-rate and half the bits (4 per tx, 4 per rx)

ok https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/ecp5rgmii.py




> We could also do ethernet over USB - this would render the boot loader slightly more complex if we wished to use ethernet during the boatloader.

no, definitely not.  far too complex (booting over ethernet) and
having to initialise the USB controller as well?  no.  see dan
gisselquist's code and how much work was involved.

the typical ROM size is 8k to 16k.  that's *it*.

if you *really* have a need to boot over ethernet or over USB, it
should be done as a 2nd-stage boot chain.


> Again, ethernet is not **essential for a minimum viable ASIC.

nope it's not.

l.

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