Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] NLNet018TV documentation
Date: Fri, 5 Jun 2020 19:08:45 +0100
Message-ID: <CAPweEDw01z6gyM+7pZkg58Si17VzH5Z6NR7Rfgmqftah=wWQ6A@mail.gmail.com> (raw)
In-Reply-To: <ec78ac1658e971e716ae8a819f001f7f8fed72dd.camel@fibraservi.eu>

On Fri, Jun 5, 2020 at 5:45 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> Goodday all,
>
> I did tape-out the TSMC 0.18µm test chip around a week ago

fantastic!

> and am now
> hard at work in documenting was is on the chip. I just pushed first
> version of the documentation and can be found in the designs/NLNet018TV
>  directory on my SnowWhite repo on gitlab. Currently it only discusses
> what is on the design; not why these structures are there with this
> design. This is planned for later. Next step is to add a test plan and
> then blog about it.
>
> Most significant change is that I did not put a full SRAM block on the
> design but single SRAM cells only. This was both due the limited
> availability of IO pins and the time pressure of the tape-out deadline.
> Instead more focus was put on the design of the IO cells which is
> actually the main reason of this test chip.

sounds very sensible.

> I did currently have three different drive strengths for the source and
> sink drivers next to the pull-up/pull-down functionality.
> The highest drive strength of 230mA is meant for driving resistive
> loads like for example LEDS.

zowee that's a lot.

> The real current will most of the time be
> limited by an external resistor in order to limit the heating of the
> chip. This is one the things that will be measured during testing.
> These test chips are wirebonded semi-manually and to ease it a pitch of
> 90µm between the IO cells is used. The 230mA driver strength is the
> result of filling up the total width of the IO cell with drivers.
> Depending on the number of outputs for the prototype we may negotiate a
> smaller pitch but this will also reduce the drive strength of this big
> driver or alternatively the IO cell may need to be made higher.
> The two lower drive strength are meant to drive capacitive loads. They
> can be either used alone or combined giving possibility of having 10mA,
> 20mA or 30mA (e.g. 10mA + 20mA) drivers. It allows to configure them as
> having the driver sink or source current or both. Reason I choose these
> drive strengths is that the 10mA corresponds with one transistor needed
> to fulfill the ESD design rules and in simulation I did see acceptable
> output over/undershoot even with minimal capacitive load. From
> simulation a 40mA driver gave significant overshoot/undershoot and
> oscillation even with high capacitive loads.

interesting.

40mA was what i saw in Allwinner SoCs: it was intended for very high
speed interfaces (120mhz range).

STM32 and Atmel only have three options: low medium and high.  to have
4 options: 10mA, 20mA, 30mA and 230mA, that's fantastic.


> The design of the IO cell is quite flexible and can still be adapted if
> there would be special needs for the prototype. So I am interested to
> know what changes you think are needed for the prototype.

i found the bugreport with the requirements that i tracked down from
how industry-standard GPIO pads are done:

https://bugs.libre-soc.org/show_bug.cgi?id=55

the level / edge-detection in hardware, in combination with the
schmidt trigger, rather than software is for situations where you get
significant key-bounce from an external switch, button or toggle.

also, software might miss the level event, particularly if it was a
very fast press that went low immediately, where hardware would not.

l.

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

  reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-05 16:44 Staf Verhaegen
2020-06-05 18:08 ` Luke Kenneth Casson Leighton [this message]
2020-06-05 18:30   ` Jacob Lifshay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPweEDw01z6gyM+7pZkg58Si17VzH5Z6NR7Rfgmqftah=wWQ6A@mail.gmail.com' \
    --to=lkcl@lkcl.net \
    --cc=libre-riscv-dev@lists.libre-riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git