proposed SoC pinouts / pinmux
by Luke Kenneth Casson Leighton
[question at end: feel free to skip to that. rest of message is background]
hi folks, i've been keeping track of lowrisc for some time, and like
the approach you're taking as the CIC framework provides for a really
good way to honour ethical commitments.
i noticed on the irc channel on oftc.net that the question was raised
about the faq entry that an SoC would be crowd-source-started within
2017. after taking a quick peek at the discussion on the list i get
the distinct impression that you're spending significant resources
fighting git merges, and it's sucking valuable time, unfortunately
narrowing the focus.
i first mentioned this yesterday on irc and, after my irc client
disconnected (and stayed down) i realised it would be better sent to
this list anyway.
as you probably know i've spent five to six years working with
literally dozens of different SoCs, so i have a really, *really* clear
understanding of how pinmuxes are done, and i also took a course (and
still remember it) at university on how to "target" a processor design
at a specific application. you're also no doubt aware (as i was from
my mentor with 30 years experience in VLSI and the mass-volume silicon
industry) that by the time you get to 800, 900, 1000+ pins, the damage
done by the gold bond-wiring process hammering the die and the PCB
that the die is on causes cracks (and failures of the IC), such that
the high pin-count ICs are SERIOUSLY disproportionately low-yield...
and thus incredibly, incredibly expensive. you would also most likely
wish to ensure that the lowRISC SoC is as financially successful
(covers several different markets) as possible.
it's therefore critical to get the pincount down as low as possible,
whilst at the same time being critically important to target as many
markets as possible with the same IC (not quite the same as "the same
die", because you can always make a die that has some pads internally
left unconnected to actual IC package pins).
the "minioncores" concept is an extremely good one for basically
turning general-purpose I/O into actual functions, with the
significant advantage over standard hard-coded macros that there is no
need to have the "mux" part of a "pinmux", greatly simplifying the IC
and routing. aside from the main technical disadvantage that
bit-banging without hardware-assist has a maximum speed threshold
related to the minioncore's maximum clock rate, the only thing to
still watch out for is that, as demonstrated and emphasised in the
links below (particularly peripheralschematics page) level-shifting
*really must* be included on-chip (even if it's a multi-chip module).
one freescale IC iMX made the severe mistake of having something
bizarre like a 2.6v GPIO VREF. absolutely every single deployment of
that SoC required absolutely every single GPIO to be routed via level
shifters. that's hundreds of pins and massive amounts of board space
consumed PLUS a hugely disproportionate increase in the BOM, for even
a basic application: bear in mind that for each GPIO you need an IC
with *double* the number of pins on the (external) level-shifter.
... by this point you may be getting the sinking feeling that the task
of actually developing the pinouts for a SoC is an extremely
specialist and comprehensive area requiring just as much expertise and
attention as the equally-important task that you're presently
primarily and actually focussed on: the development of the lowriscv
core. this is something that i can help you with.... so that you
don't have to spend the time, or heavily change focus.
below are the links to an analysis, based on the requirements of the
M-Class Shakti Core, which covers the industrial, mobile, smartphone
and netbook/laptop market *without requiring any mixed analog/digital
circuits of any kind* on the actual SoC itself.
http://rhombus-tech.net/riscv/shakti/m_class/
http://rhombus-tech.net/riscv/shakti/m_class/pinouts/
http://rhombus-tech.net/riscv/shakti/m_class/pinouts.py
http://rhombus-tech.net/riscv/shakti/m_class/peripheralschematics/
also to save a heck of a lot of effort (and from making SoC design
mistakes due to lack of analysis and planning), peripheral schematics
are also included, not just so that when it comes to making a
particular design a set of Reference ICs to use is readily available,
but also included is the pinouts of each IC, which in turn are
incorporated into the list of pin-mux coverage for the applications /
target markets, thus ensuring that the SoC *can* actually cover,
successfully, all the markets in question.
the coverage was done programmatically, with the stand-alone python
program "pinouts.py". a first "finger-in-the-air" set of pinouts was
added, followed by a first target market, then progressively more
targets added and the pinouts adjusted accordingly, by hand, to ensure
that 100% coverage was guaranteed.
the first attempt i made at this type of pinmux was 5 years ago. it
was done entirely by hand, by (stupidly as it turned out) trying to
fight KiCAD (and several absolutely critical bugs and severe design
flaws which the developers actively failed to comprehend, despite many
many people attempting to explain it to them) - consequently the task
took MONTHS.
learning from that experience, the development of this particular
pinmux was completed in *three days*, with later target market
reference designs taking under an hour to add.
question: would you be interested to make use of my expertise to
create the pinmux for the SoC that's part of the proposed
crowd-sourcing? and, if so, would you be prepared to ensure that
either in an ethical way i financially benefit directly from doing so,
or that there is sufficient overlap such that the [libre and ethical]
goals that i seek to "have completed" are met in some indirect way?
tia,
l.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
5 years, 9 months
Default branch
by Olof Kindgren
I'm wondering a bit about the branching strategy. I'm currently stockpiling
a bunch of small patches and I wonder if those should be submitted against
master, minion-v0.4 or ethernet-v0.5.
//Olof
5 years, 10 months
BRAM logic in chip_top.sv
by Olof Kindgren
One of the things I would like to do with LowRISC is a clean separation of
structural and behavioural logic to eventually use IP-XACT or other
configuration formats to easier build modular designs
In chip_top.sv I found a big chunk of logic that seems to be related to
creating an boot memory.
Could someone please enlighten me what this code is supposed to do? I can't
really figure out from looking at the source, and the elaborated design
doesn't provide any addtional clues.
//Olof
5 years, 10 months
Introducing myself
by Olof Kindgren
Hi all,
I'm Olof Kindgren and has been involved with Open Source Silicon for quite
a while. I have been working on many project over the years, but right now
my two main time thieves are working on FuseSoC (
https://github.com/olofk/fusesoc) and running the FOSSi Foundation (
https://fossi-foundation.org/)
I've finally found some time to look at LowRISC in detail after planning to
do so for about three years. Right now I'm digging through the RTL and have
found some things that I would need some help to understand.
So my first question is, is the mailing list the best forum to discuss RTL
stuff, or is there another preferred communication method?
Cheers,
Olof
5 years, 10 months
Running Java on lowrisc
by Jawad Haj-Yahya
Hello,
Could you pleas help us with instructions on how to run Java 8 bytecode on
the latest lowrisc (0.4) on top on linux ?
Best,
Jawad Haj-Yahya
5 years, 10 months
Re: Floating Point Unit Research Query
by Christopher Celio
>
> I hope you won't mind me now completely moving to the second part of my
> initial query. Can you tell me about the relation between the hardfloat
> submodule and the FPU.scala file?
>
> If all of the FPU is generated based on the HDL code of the hardfloat
> submodule, what does FPU.scala actually do?
>
> Thanks a lot,
>
> Aleksandar
hardfloat is where the parameterized blocks that execute FP operations reside. They do the "math" stuff, if you will. Blocks like MulAddRecFN.scala (multiply-add in a recoded format for some set-at-instantiation-time N-bit floating point number).
Rocket's FPU.scala is where you instantiate these units, set their values (say, to get a double-precision FMA unit), and do all of the yucky plumbing into and out of the unit. FPU.scala contains the FP register file, it manages the packing and unpacking into and out of the the recoded format, it manages the condition flags, and more.
-Chris
5 years, 10 months
Floating Point Unit Research Query
by Aleksandar Pajkanovic
Hello, thank you, dr Kimmitt, thank you very much for taking the time to
look into my quesetion.
For some reason, your reply did not end up in my inbox, so I have no
possibility on choosing Reply-to-All, so I hope this way the message
will end up on the corresponding thread.
Thank you for elaborating on the possibilities to characterize the
performance of the FPU. To conclude, basically, we need to generate the
whole thing, be it LowRISC chip or anything else, and only from there we
could make a claim about FPU's performance (in the context of speed,
area and power consumption).
I hope you won't mind me now completely moving to the second part of my
initial query. Can you tell me about the relation between the hardfloat
submodule and the FPU.scala file?
If all of the FPU is generated based on the HDL code of the hardfloat
submodule, what does FPU.scala actually do?
Thanks a lot,
Aleksandar
5 years, 10 months
Floating Point Unit Research Query
by Aleksandar Pajkanovic
Hello,
my name is Aleksandar Pajkanovic and I write to express interest in the
floating-point unit implementation within the LowRISC project.
I am learning on the topic, so for starters I would like to be able to
test FPU's performance.
Does the whole chip need to be generated in order to testbench the FPU?
In either case, what would be the simplest way to have it up and running
within the testbench?
While going through the repo, I first thought that the hardfloat
submodule represents the FPU, but later on I found fpu.scala within the
rocket submodule - I am a bit confused what is the relation between
these two. Seemengly, they have nothing to do which other - and I am
saying this with great fear, I truly don't know, I am only not seeing
the connection. Would you, please, provide some context on the
development of the FPU?
Finally, as I am still trying to bend my mind around the RISC-V, Chisel,
Scala, chip generators and chip... please forgive possible redundancy. I
did try searching the list and found no discussions of FPU.
Best regards,
Aleksandar
p.s. Guys, thank you for all the effort you are putting into the
development of open hardware.
5 years, 10 months
Re: lowRISC Rocket Core and other submodules update
by Christopher Celio
> Getting git workflow right isn't easy indeed, UCB Boom project opted for a
> slightly obvious strategy which is forking rocket-chip into a branch of
> their own in which they include their git repo as a sub-module.
> https://github.com/ucb-bar/riscv-boom
For BOOM, I'm experimenting with a new code/repo organization which is based off of Berkeley's "project-template":
https://github.com/ccelio/boom-template
An other example system that follow this organization is the SiFive Freedom platform (https://github.com/sifive/freedom).
The idea is that boom-template provides an "Example BOOM chip" with an example TestHarness and example BoomCoreplex.
The BOOM source code is a submodule of this boom-template. More interesting, the master branch of rocket-chip is also a submodule of boom-template, which is now treated as a library of components. Anything that needs to be modified for BOOM's is pulled into the BOOM repo. Going forward, BOOM will no longer be a fork within rocket-chip. That was too painful to manage.
There is still going to be some growing pains (hopefully this new setup will be less painful than the hard fork), and I am still learning how best to interface my stuff to upstream rocket-chip and the broader OSHW community.
I also realize that my changes/differences relative to rocket do not compare to the wider, sweeping changes of lowRISC's efforts. =(
-Chris
5 years, 10 months
