[libre-riscv-dev] On language choice.

[Samuel Falvo II]

I've found this requires clairvoyance to work effectively.  It also runs
the very high risk of analysis paralysis.  As an engineer, I'm deeply
susceptable to both.

If I just repackaged the same things other people were doing all the time,
I'd never advance in my learning.  At some point, I need to make a decision
and go with it, learn from it, even if it was the wrong decision.

We use Python extensively at work.  It has allowed us to do many great
things on short timescales.  But, longer term analysis shows that it's been
a categorically wrong choice for us overall.  It's utter lack of ability to
be profiled while hot in production has cost us months of debugging effort,
two failed hires, two outages longer than a month (seriously) and now we're
(currently) stuck with an outsource contract which we *hope* will deliver a
better solution "real soon now."  This doesn't count the time wasted on
type-related failures, often missed in QA.  I'm just counting the harder,
more interesting problems, like, "why is our dashboard still taking 2
minutes to load data after a year's worth of debugging effort?"  I've also
learned that debugging from logs is utterly ineffectual at helping to solve
this issue.  What I need is a type-safe Lisp, and unfortunately, that just
doesn't exist.  Haskell, et. al. are not it.

I digress, though.

Similarly with the Wishbone vs. TL issue which spawned this thread.  When I
made the decision to try TL, it was motivated by curiosity, community
outreach, and it's promised technical properties.  I wanted to be a
contributor to the RISC-V ecosystem and community.  I wanted to make a
positive impact.  At the time, TL looked like it was increasing in
popularity, and again, I can't see why it's not.  It's a solid protocol and
I find it easy to work with.  In some cases, even easier than Wishbone!

For example, last night, I realized the IFU's state machine could be
implemented in two fewer states than its corresponding Wishbone interface,
all because the valid/ready handshake doesn't rely on pulses as Wishbone's
strobe/ack protocol does.  That's less code I have to write, test, and
debug, and requires correspondingly fewer formal properties.

Today, I can see that it might have been the wrong choice.  The community
has failed to form around the spec as OpenCores did around Wishbone, so I
might well be wasting my community outreach time.  But, far more
importantly, while it may have some technically superior semantics than
Wishbone, it also uses up to 10% more wires to achieve functional parity
with Wishbone because of it's typed message-based interface.  This latter
issue might be the deal-breaker for me b/c I'm targeting the iCE40HX8K
chip, making the KCP53000B one of the smallest, 64-bit CPUs in its
performance class that complies to the priv-spec on the planet.  (And
you're damn right I'm proud of that!)

I'm not so concerned about other people wanting to reuse ROMA or SIA, for
example.  Or even my CPU.  Although they're easy to reuse in other designs,
they're all made with the Kestrel project in mind.  Some cores, like ROMA,
exist because of the specific dev board I'm using.  UARTs are a
dime-a-dozen, and I'm not going to contribute anything new there.
Memory-mapped serial flash adapters less so, but still common enough.
picorv32 exists already, has been taped out, and has an AXI interface
already.  I'm not sure what value I bring to the table here.  My
contributions just don't seem that interesting.

Yet, here we are, and it happened *despite* my desire to explore the use of
TL.  I'm positively happy to even be *considered* as a viable contributor.
Knowing your project wants an AXI4 interface is exactly why I opened this
dialog with Luke in the first place.  Designing for protocol agility wasn't
*originally* in the cards for the 53000B, but it absolutely is now, and
thanks to nmigen, I pretty much know exactly how to pull it off.  Luke
wants AXI4, and I'm thinking of returning to Wishbone B4.  Both are about
as far apart from each other as they are from TL.  :)

What I'm hoping to contribute is the total system package that is
co-engineered to minimize software and hardware impedance mismatch while
remaining approachable and understandable by one or two (motivated)
individuals.  That's the only way to make a RV64I processor fit on a chip
as small as the HX8K.  Reducing total system complexity is my goal.  If I
wanted a box to just run Linux, I'd use my PC.  But, that's boring, and a
solved problem, monopoly influences notwithstanding, of course.

Thanks for letting me ramble about this.

On Sun, May 5, 2019, 4:10 AM Hendrik Boom <hendrik at topoi.pooq.com> wrote:

> On Sun, May 05, 2019 at 04:31:23AM +0100, Luke Kenneth Casson Leighton
> wrote:
>
>
> > *you* could implement them... however what about the users?  what is
> > the cost *to them*?
> >
> > i always look beyond the immediate "is this easy", thinking of the
> > whole picture.  programming, for me, is actually quite challenging.
> > so i think regularly in terms of "how can i minimise the amount of
> > programming needed, to complete the *whole* picture?"
>
> I agree.  And for programming I always wonder, what's the best way to
> minimize debugging time, since I've found that to be the most
> time-consuming aspet of programming.  Which is why I prefer strong type
> checking ... but the *wrong* type system is worse than none.  And a
> language without good library support isn't going to cut it any more.
>
> > this allows me to avoid some extremely costly design and development
> > decisions, as i cherry-pick from wildly disparate sources and even
> > take into consideration the creation of cross-language conversion
> > tools as a way to bridge between two (or more) seemingly utterly
> > different and otherwise incompatible projects.
>
> Yes.
>
> -- hendrik
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>