Bug 50 - nmigen pinmux
Summary: nmigen pinmux
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
Depends on:
Blocks: 8 191
  Show dependency treegraph
Reported: 2019-03-21 11:28 GMT by Luke Kenneth Casson Leighton
Modified: 2021-10-06 14:21 BST (History)
2 users (show)

See Also:
NLnet milestone: NLnet.2019.02
total budget (EUR) for completion of task and all subtasks: 10000
budget (EUR) for this task, excluding subtasks' budget: 10000
parent task for budget allocation: 191
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2019-03-21 11:28:46 GMT

* peripheral multiplexing
* SoC-to-peripheral interconnect auto-generation
* auto-creation of peripheral memory-address locations and suitable linux header
* auto-creation of linux kernel header files for GPIO pinmux layout
* auto-creation of IO ring corona for ASICs
* auto-generation and allocation of IRQs and IRQ connectivity
* auto-generation of Technical Reference Manual sections
Comment 1 Luke Kenneth Casson Leighton 2019-04-26 12:01:57 BST

On Fri, Apr 26, 2019 at 11:25 AM Rishabh Jain <rishucoding@gmail.com> wrote:
> hi luke,
> i am having difficulty in understanding nmigen Record (hdl/rec.py)
> i am able to  follow some part of hdl/rec.py like Direction, fields,
> __init__ in class Layout checking
> for valid field, are the elements of field valid, avoiding duplication of
> names.
> but, i am not able to understand the full picture :(

 in some ways, you don't actually need to read all the code, just know
 the function names and read the docstrings.  except (*sigh*) Record
 and Layout don't *have* any docstrings... *sigh*...

> can you give me some pointers over what is layout, shape?

 Layout is just a list of signal-width plus signal-Direction.
 (or signal-width plus signed/unsigned plus Direction).

 shape is a tuple of signal-width plus if the signal is signed or unsigned.

> from our diagram of GPIO  (https://libre-riscv.org/shakti/m_class/pinmux/)
> the i/o pad is a PHYSICAL PIN of processor which connects it to
> peripherals, memory, etc, right?
> so, we  mux (select one of many) inputs of processor coming to i/o pad from
> various peripherals and mux outputs of
> processor coming to i/o pad going to peripherals.
> I am not able to relate FAN_OUT  and FAN_IN with this diagram :(

FAN_OUT and FAN_IN are actually Muxers, nothing to do with Record/Layout...
there is an example somewhere of a multi-selection Mux...


ah, it's not quite the same.  actually, FAN_IN and FAN_OUT would be:

 with m.Switch(mux):
    with m.Case(0):
       m.d.comb += self.o.eq(self.a)
    with m.Case(1):
       m.d.comb += self.o.eq(self.b)

that would be one of them and the other would be:

 with m.Switch(mux):
    with m.Case(0):
       m.d.comb += self.a.eq(self.o)
    with m.Case(1):
       m.d.comb += self.b.eq(self.o)

you'll have to work out which is which :)

actually it turns out that doing this is not necessary, you can use an Array:

signals = [self.a, self.b, self.c, self.d]
array = Array(signals)

m.d.comb += self.o.eq(array[self.muxselector])

or for the other one:

m.d.comb += array[self.muxselector].eq(self.o)

so instead of a massive list of Switch/Case statements, just use Array.
Comment 2 Luke Kenneth Casson Leighton 2021-10-06 14:21:32 BST

nmigen-boards and nmigen-soc has the resources needed.