- Libresilicon-developers - libresilicon.com

LibrePlanet 2019
by Devon Sean McCullough 10 Mar '19

10 Mar '19

The https://LibrePlanet.org/2019 conference at MIT CSAIL building 32 on Saturday-Sunday 23-24 March 2019, two weekends from now. Peace --Devon

1 0

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