Announcement

Collapse
No announcement yet.

Libre-SOC Test ASIC Going To Fabrication, Using TSMC 180nm Process

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Libre-SOC Test ASIC Going To Fabrication, Using TSMC 180nm Process

    Phoronix: Libre-SOC Test ASIC Going To Fabrication, Using TSMC 180nm Process

    Libre-SOC that started out as Libre RISC-V in aspiring to be an open-source software/hardware Vulkan accelerator but then renamed to Libre-SOC after changing over to the OpenPOWER architecture is now seeing test fabrication done using TSMC's 180nm process...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    As no IO is listed I assume this is a test run.

    Comment


    • #3
      This concept is one that has really interested me since the V extension came around. I think if you combine this with heterogeneous scheduling and some hardware graphics features, you could have a winner.

      Comment


      • #4
        Originally posted by elatllat View Post
        As no IO is listed I assume this is a test run.
        Yup, iirc we have JTAG and a few other simple I/O devices (@lkcl knows the whole list), thanks to LiteX. The device is programmed and debugged through JTAG.

        Comment


        • #5
          It's been said before, but I guess Michael needs it repeated. This chip will have a real, actual *Vulkan driver*, not a software rendering implementation.

          The only difference is that the Vulkan driver is a completely userspace driver, as all of the GPU instructions built into the vector hardware are accessible from userspace. That means that the driver mostly looks like just a MESA userspace library, as there isn't much of a kernel backend for it to plug into.

          AFAIK, there will be no OpenGL driver. It's expected (and designed) to be Vulkan-only, which is reasonable given the number of translation layers available for other APIs.
          Last edited by Developer12; 08 July 2021, 05:28 PM.

          Comment


          • #6
            Originally posted by elatllat View Post
            As no IO is listed I assume this is a test run.
            yes, ah good point, err where did i put it... here we go: https://libre-soc.org/180nm_Oct2020/ls180/

            so it's not a test run, or it is, it's a test run *of an actual ASIC*. we'll get about 100 samples of a 0.5mm QFP-128 back.

            the most important one there is JTAG. Staf created c4m-jtag which *actually* implements a JTAG TAP interface including boundary scanning (re-routing I/O into JTAG registers), normally if you're used to FPGAs you get a JTAG interface "for free" and don't have to think about it.

            behind that JTAG interface is also a DMI interface (Debug Memory Interface) which can read the PC, MSR, GPRs, CRs, SPRs, just like you would expect to be done with gdb... except the last time someone added JTAG to a Power ISA system was *fifteen* years ago (you can find the patch set to openocd if you look reaallly hard), IBM normally supports FSI because it's way faster. this being an SoC, we went with JTAG, and there's a way to read/write to the Wishbone Memory Bus.

            so we'll be putting the ASIC into "stop" mode, then write programs to it word-by-word over the JTAG/DMI interface, then let it continue. there's no on-board ROM: JTAG is the *only* way we'll be testing this. so of course that was simulated to ad nauseam, and also tested on a VERSA_ECP5 FPGA, which was fun, very confusing connecting _two_ JTAG USB interfaces to an FPGA

            i've a mock-up which has to go to TSMC for the packaging... that SVG was entirely
            auto-generated from the same pinmux program that created the pinouts used in the ASIC

            TSMC need to know which way up to put the die, and also which pads to connect, and the package is *not* square, it's i think 26 on EAST-WEST and 38 on NORTH-SOUTH, which made for a bundle of fun in the SVG creation, deep joy there https://git.libre-soc.org/?p=pinmux....int.py;hb=HEAD


            https://libre-soc.org/180nm_Oct2020/ls180.svg
            Last edited by lkcl; 08 July 2021, 06:37 PM.

            Comment


            • #7
              Originally posted by Developer12 View Post
              This chip will have a real, actual *Vulkan driver*, not a software rendering implementation.
              a future version will, yes. this is like... if we reach 300 mhz in 180nm we'll be deeply overjoyed.

              The only difference is that the Vulkan driver is a completely userspace driver, as all of the GPU instructions built into the vector hardware are accessible from userspace. That means that the driver mostly looks like just a MESA userspace library, as there isn't much of a kernel backend for it to plug into.
              yehyeh, there's actually someone working on the MESA Driver, it's sort-of like SwiftShader (only not done by google), sort-of like all the other userspace 3D MESA drivers except the focus is on keeping the parallel (vector) intrinsics clear and clean (i.e. not completely destroying them then going "err oh dear, now we have to run massively expensive LLVM autovectorisation passes to get back the parallel Vector information we just absolutely trashed")





              AFAIK, there will be no OpenGL driver. It's expected (and designed) to be Vulkan-only, which is reasonable given the number of translation layers available for other APIs.
              yes, there's another one cropped up somewhere, forget its name, it's another vulkan-to-OpenGL, we can focus on making Vulkan drivers then finally down the line somewhere look at optimisations for OpenGL.

              Comment


              • #8
                Originally posted by lkcl View Post
                yes, there's another one cropped up somewhere, forget its name, it's another vulkan-to-OpenGL, we can focus on making Vulkan drivers then finally down the line somewhere look at optimisations for OpenGL.
                To be honest, I'm skeptical OpenGL will even be needed. It seems to be the default first-go when you're bringing up a new driver (all the way back to the days of SGI), but more and more everything in the Linux world seems to be going Vulkan.

                Comment


                • #9
                  Originally posted by Developer12 View Post

                  To be honest, I'm skeptical OpenGL will even be needed. It seems to be the default first-go when you're bringing up a new driver (all the way back to the days of SGI), but more and more everything in the Linux world seems to be going Vulkan.
                  There's plenty of software that will need OpenGL, such as Minetest, SuperTux, Blender, etc. Luckily Zink is turning out to be a pretty good translation layer with support for OpenGL 4.6 iirc.

                  Comment


                  • #10
                    Big is beautiful. I'ma gonna get me two of these silicones.

                    Comment

                    Working...
                    X