- Libresilicon-developers - libresilicon.com

Analog Try-out "triple-5"
by Hagen SANKOWSKI 04 Mar '19

04 Mar '19

Hello List. Today in our weekly Mumble Session we talked about a smaller chip, which could be realized before the Northpoint. The Reason is mostly, that the Northpoint (as an small MCU) - beside the Standard Cells - also has some challenging Analog Stuff (like the ADC, Pad-Cells) which set the hurdle a little bit high. We need some physical haptic fancy / shiny silicon before which gives us also a realistic way to verify our simulation after model measurement we do with PearlRiver. Something we could hand over to other people and which blinks.. Well, we came across the well-known "triple-5 chip". The original NE555 [0] was developed by the Swiss electronics engineer Hans Camenzind [1] and get cloned by nearly all silicon firms on the market in this era. Great starting points for our CMOS-based clone are the wikipedia site and the free eBook [2] of the original author. I strongly recommend everybody to read this great book! Mostly the 555 chips are in the -55 to +125 C temperature range - the same we assume for our technology. And the voltage supply goes up to +18 Volt, I already saw 555 which worked with higher voltage. If we like, we could using our BiCMOS feature for the output driver - driving the same current with less power consumption. The 555 chip has a legendary status between electronic engineers, radio amateurs and tinkers. And some of them writing obeisance on hackaday.com still in 2018 [3]. Many variations of the chip are still in production. Short - the 555 would be a great try-out for LibreSilicon! And I am proud to announce that Ferenc will be our Lead for the "LS 555" (LibreSilicon triple-5). Thanks Ferenc for your commitment! Regards, Hagen. [0] https://en.wikipedia.org/wiki/555_timer_IC [1] https://en.wikipedia.org/wiki/Hans_Camenzind [2] http://www.designinganalogchips.com/ [3] https://hackaday.com/2018/10/10/the-555-and-how-it-got-that-way/

3 5

ADC for Northpoint
by Hagen SANKOWSKI 26 Feb '19

26 Feb '19

Hello List, Hello Tatzelbrumm. Regarding the current status of the PearlRiver, I like to look ahead to the Analog-Digital Converter (ADC). Which stuff do we still need? Literature? Patent-free concepts? Any other stuff missing? Regards, Hagen.

5 8

ALF parser
by David Lanzendörfer 25 Feb '19

25 Feb '19

Hi I've now removed most of the ambiguities within the ANTLR4/IEEE spec: https://github.com/leviathanch/alf_parser/commit/a806a865f443c55128a9aad2d8… It's still very very slow however (around 4 seconds) Tomorrow I'll be busy setting up the CMP machine together with Henry (who was busy today with the chemical waste) and Victor. Wish us luck. When the results turn out to be acceptable, I will put picture on Twitter :-) Cheers David

1 0

Reminder - next Mumble Session on Sunday (February 24, 2019) 13:00 UTC
by Hagen SANKOWSKI 24 Feb '19

24 Feb '19

Hello List! Just a small reminder for our next Mumble Sessions on this Sunday, February 24 at 9 p.m. Hong Kong Time - this is 13:00 UTC. Please join us as usual at our Mumble Server with IP 109.109.202.102 at Port 64738, the Channel is IC. On the agenda are (at least) this topics - back from Chinese New Year - test wafer status - other stuff around Happy to hear from you! Hagen

2 1

Re: [Libre-silicon-devel] [Librecores Discussion] IEEE754 FPU in nmigen
by Luke Kenneth Casson Leighton 19 Feb '19

19 Feb '19

Rudi wrote: > Curious: What is the cycle time of the generated code versus > native verilog code ? hi rudi, nice to see you around, i haven't forgotten you :) it's exactly the same, as it's clk-based. the layout however with nmigen is... well... it's auto-generated in nmigen via yosys, where migen has its own built-in back-end, and goes to some lengths to generate verilog that looks reasonably similar to the migen it came from: that's gone in nmigen. so, in nmigen, each signal that is assigned is separated out into its own auto-generated code-section (migen keeps them all together). resetting is auto-generated and need not be added manually. declaring a signal "resetless" may be done if it is definitely known that it requires no reset; the value of the reset may be over-ridden at declaration time: x = Signal(32, reset=0xf00baa) in nmigen, all tests, subexpressions and consequently most assignments are done with combinatorial auto-generated wires / registers (of the correct / required / calculated / auto-calculated width), with the original python line number and file name inserted as a comment next to the expression assignment "\$483 = x[1:0] // foo.py:135" in nmigen, all if elif elif elif statements are translated to casez statements comprising a concatenated sequence of tests (derived from the if part of every single if-elif-elif-elif statement), followed by case 0b1zzzzzz case 0bz1zzzzzz case 0bzz1zzzzz and so on. three quirks which are down to python: * n/migen works through operator overloading of python syntax. assignment of python variables does *not* have an operator over-ride, so, annoyingly, an "eq" function had to be provided. "m.d.sync += x.eq(y)" instead of "x = y", because "x = y" would make the *PYTHON* variable x equal to y. * operator-overloading of the "not", "and" and "or" operators unfortunately returns a boolean rather than an object. however the "&" and "|" bit-wise operators, when overloaded, *do* actually return the objects that are returned from the overload-function. consequently, you *have* to do tests as "m.If((modulus[0:31] == 0x0) & (exponent == -127))" of course including the brackets because & and | operators take higher precedence. * python slices go from *LSB* on the left to *MSB PLUS ONE* on the right, where verilog goes from MSB (inclusive) *down* to LSB (inclusive). this so that you can do consecutive slices without needing to subtract one: "x = x[y:] + x[:y]" is a barrel-shifter for example. note the lack of use of "y-1". so... it's... quirky. however, the prevalence and huge adoption of python, the advantages of OO, the fact that to generate online documentation i can use a single command from a 20-year-old tried-and-tested program named "epydoc" (or any of its maaaany Not-Invented-Here quotes replacements quotes), these for me *far* outweigh the quirks and inconveniences. on a separate note: multiply was added yesterday, along with the original unit test process that jon dawson developed (which hilariously was as python programs). i cut out the use of a c++ program and replaced it with sfpy (berkeley softfloat 3 python bindings). so, that's *all* of add, add64, div, div64, mul and mul64, all done, all converted to nmigen, and all unit tests passing. i've run up to 250,000 add and add64 random-input unit tests. the reason for using sfpy is to avoid having to call out to a subprocess (nmigen contains its own simulator), and also, sfpy supports setting of different overflow modes, which is one of the next things to add. also, now we can add FP16, which is supported by sfpy, *without* dependence on a particular feature of a c / c++ compiler (not all c / c++ compilers *have* an FP16 type). adding FP16 is literally a matter of adding a few lines in the base class to tell it what to do when FPAdd(16) is instantiated. l.

2 1

IEEE754 FPU in nmigen
by Luke Kenneth Casson Leighton 17 Feb '19

17 Feb '19

hi, just so people know: obviously for a GPU and a modern CPU, an IEEE754 floating-point unit is essential. however, as you also know, verilog is an old language that would require macro-expansion of some form to modernise it with something approximating OO programming. for the libre riscv CPU/GPU we've chosen nmigen, instead, as it outputs verilog and still allows modern OO programming techniques to be used. despite the fact that the IEEE754 FP unit is needed *for* the libre riscv CPU/GPU, it is important to note that the work is being done in a completely separate repo, to ensure that it is absolutely clear that this work is for *general* wider use. we've started from jon dawson's excellent verilog IEEE754 FP code and have begun a process of conversion to nmigen, with a successful initial conversion of the adder, here: https://git.libre-riscv.org/?p=ieee754fpu.git;a=tree;f=src/add the similarity between the various modules of jon dawson's code - not just 32-bit compared to 64-bit, also how the add is done vs multiply or divide - are striking, meaning that there is *significant* code duplication. we will be removing *all* of the code-duplication with python OO programming techniques. base classes sharing the common functionality between all modules. class parameterisation so that FP16, FP32 and FP64 all share the exact same code. in addition we'll be making sure that the code is properly documented (not excessively so), and, crucially, will be converting it to a pipeline architecture. to achieve this pipeline conversion process, a python class that, fascinatingly, originally came from a PyRTL example, has been adapted for use with nmigen. the current design - jon's original work - is a state machine with variable completion time. it's quite compact in that there are no single-cycle variable-length shifts used: instead, a single 1-bit shift is deployed with a variable-clock-cycle detection on when to end shifting. obviously that cannot be preserved for a pipeline architecture, however it would be particularly interesting to try to preserve both designs within the same codebase. if anyone would like to assist with this work you are most welcome: please do join the libre-riscv-dev mailing list http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev otherwise i am happy to answer questions on either of these lists. l.

2 2

Using 3D Printers to create our own photomasks
by Mohammad Amin Nili 12 Feb '19

12 Feb '19

Hello list, I’d like to know if it is feasible/suitable to use 3D printers “like" the following (something with better resolution) to create our own photomasks? http://www.microlight.fr/bioprinters.html

4 6

Test
by Rick C. Hodgin 09 Feb '19

09 Feb '19

Test email to list.

3 3

sea of gates and open analog
by Luke Kenneth Casson Leighton 08 Feb '19

08 Feb '19

Hi best place to ask, Have forgotten the name of a company that has a sea of gates high end ASIC, you get to do only the one mask, the via layer. Does anyone know the company? It is apparently supported by libre design tools. Second, somewhere in this talk https://youtu.be/zXwy65d_tu8 is mentioned an open analog design project, does anyone know what that project is? Many thanks. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

6 7

Fwd: Tools for VLSI Design - LibreSilicon flavored Live-DVD
by ludwig jaffe 03 Feb '19

03 Feb '19

---------- Forwarded message ---------- From: ludwig jaffe <ludwig.jaffe(a)gmail.com> Date: Saturday, February 2, 2019 Subject: Tools for VLSI Design - LibreSilicon flavored Live-DVD To: Staf Verhaegen <staf(a)fibraservi.eu> Debian based is enough imho. Also openSuSE is not so much used for development. Fedora and especially centos/rhel has a much smaller package wealth compared to debian or ubuntu which is based on debian. People with rpm distros could try to use the alien tool. But I will support debian and ubuntu as these are preffered by me. Cheers Ludwig On Saturday, February 2, 2019, Staf Verhaegen <staf(a)fibraservi.eu> wrote: > ludwig jaffe schreef op za 02-02-2019 om 18:40 [+0100]: > > Toolchain: > Hi I could maintain a repository to be added to /etc/apt/sources.list > /etc/apt/sources.list.d/libresilicon > > Alternatively maybe repos can be maintained for a few selected OSes on openSUSE build Service. I do think for example some academic environments are still based on Centos or derivatives like Scientific Linux. > greets, > Staf. > > so apt will find the packages > this should work for debian and ubuntu and one could try to statically link the tools if they need old stuff like motif or even older stuff that could create dependency problems as every distro is a bit different. > But the first step is to maintain a dynamically linked version of the tools for debian stable and ubuntu lts. > This should be not too much work. > No need fir a life cd. > Just a howto for adding our repo to the distribution. > > Regarding electric: how to host a 600M tarball of html code docunentation. > Github accepts only 100M blobs. So splitting up the docu part of electric did not help much. > If you want to code with electric git clone levush/electric > read the readme on compiling and have gixygen and graphviz installed to make the docu. > There is still a path problem in the Doxyfile as relative paths sonehow are not working correctly. > If someone knows better please look at the different Versions of Doxyfile in the project and improve it. > The code base is quite huge so one would need to surf the code to understand it. Doxygen is a cool tool for analysis of code written by others. > > If we want to develop with electric we need to find what should be improved and try to understand the code to the extend needed fir this task. > Otherwhise electric sits there beeing rescued from beeing depublished in favor of the shity java version but thats it. > > > Cheers > > Ludwig > > > > > On Saturday, February 2, 2019, Hagen SANKOWSKI <hsank@po > > steo.de> wrote: >> Hello Ludwig, Hello List. >> >> Thanks Ludwig for your Effort to compile some tools! >> >> I came across the fact, that the Debian family of Distributions has >> already compiled packages for qflow, which also includes yosys and magic.. >> >> IMHO we should have a working tool flow, which allows us to work on our >> project and others to follow us. >> >> Ludwig, do you like to setup and maintain a (Debian/Mint clone) Live-DVD >> with all tools already installed tools? >> >> I would vote (at least) for >> - qflow >> - yosys >> - magic >> - klayout >> - electric >> - (lua)latex (while with easier UTF-8 usage!) >> >> all in the latest and greatest version. Plus all stuff we are developing >> here, like >> - lsc >> - popcorn >> - melmac >> - ... etc. >> >> Additional (in later versions) I can think about distributing nice >> documentations not only about the process, but also how-to, cookery >> books of how to make chips. > > -- Send from mobile phone with autocorrection / autofill. Blame my phone for typos. -- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.

4 7

2024

2023

2022

2021

2020

2019

2018

Libresilicon-developers