| Veera[m] | Hi luke | 04:10 |
|---|---|---|
| Veera[m] | little help with pip | 04:10 |
| Veera[m] | what does it mean by running pip -r requirements.txt | 04:10 |
| Veera[m] | and requirements.txt has a line like: | 04:10 |
| Veera[m] | -e third_party/migen | 04:11 |
| lkcl | it means, "go get those packages named in the requirements.txt file" | 11:32 |
| lkcl | 1 sec... | 11:33 |
| lkcl | man pip3 | 11:33 |
| lkcl | apparently it *uninstalls* those packages (!!) | 11:33 |
| lkcl | ah no | 11:34 |
| lkcl | that's if you use the uninstall command | 11:34 |
| lkcl | https://stackoverflow.com/questions/51010251/what-does-e-in-requirements-txt-do | 11:35 |
| lkcl | sigh | 11:35 |
| Veera[m] | I am using pip3 install -e thirdparty/migen | 11:35 |
| lkcl | it's the equivalent of "python3 setup.py develop" for that specific package | 11:35 |
| Veera[m] | read manual page. it says runs the program from source directory itself. Does not installs into /usr/lib/python?? | 11:36 |
| lkcl | https://pip.pypa.io/en/stable/cli/pip_install/#requirements-file-format | 11:36 |
| lkcl | the way that "python3 setup.py develop" works is: | 11:37 |
| Veera[m] | yep | 11:37 |
| lkcl | 1) there **IS** a "package-indicator" installed into /usr/lib/python | 11:37 |
| lkcl | (or other location) | 11:37 |
| lkcl | (which might be ~/.env/blahblah if you are using venv) | 11:37 |
| lkcl | (which might be /usr/local/lib/pythonN.N/dist-packages) | 11:38 |
| lkcl | but that "indicator" - a .pth file - points ***BACK*** to the ***LOCAL*** actual source code | 11:38 |
| lkcl | **NOT** | 11:38 |
| lkcl | takes-a-duplicate-copy-of-the-source-code-and-drops-it-into-/usr/local/lib/whatever | 11:38 |
| Las[m] | lkcl: Is there any documentation for targeting an FPGA? | 13:40 |
| lkcl | Las[m], it's 2 commands, listed in the README of libresoc-litex. | 15:34 |
| lkcl | 1 builds | 15:34 |
| lkcl | 2 uploads | 15:34 |
| lkcl | 1 sec | 15:34 |
| lkcl | https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=README.txt;hb=HEAD | 15:35 |
| Las[m] | lkcl: Thanks. Can you explain the relation between this repository and the soc repository? | 15:39 |
| Las[m] | So I assume you're supposed to use this repository if you want to target an FPGA? | 15:39 |
| Las[m] | And if it's for real hardware, you use experiments9? | 15:39 |
| lkcl | there's effectively none. or: one uses the output of the other | 15:39 |
| lkcl | experiments9 is purely the "instructions to coriolis2 on what it should do to take the HDL for the ASIC and turn it into GDS-II files for that ASIC" | 15:40 |
| lkcl | the libresoc-litex repository leverages litex to create peripherals and connect them to a core. | 15:41 |
| lkcl | that's litex's "job" | 15:41 |
| lkcl | litex is capable of 3 different "jobs" | 15:42 |
| lkcl | 1) simulations | 15:42 |
| lkcl | 2) creating HDL suitable for uploading to FPGAs | 15:42 |
| lkcl | 3) after a **LOT** of pissing about, creating HDL suitable for use in ASICs | 15:42 |
| Las[m] | Is litex a standard tool or Libre-SoC-specific? | 15:42 |
| lkcl | it's a tool that's created by an individual known as "Florent Kermacc" who has caused us a LOT of headaches, including making unfounded complaints about us to the OpenPOWER Foundation. | 15:43 |
| lkcl | those complaints were terminated with prejudice after we explained the inappropriateness of Florent's complaints | 15:44 |
| lkcl | answering your question: litex is a tool. | 15:44 |
| lkcl | it's not maintained by us. we simply use it. | 15:45 |
| lkcl | and won't be in the future (due to Florent's seriously problematic behaviour) | 15:45 |
| Las[m] | So looking at https://libre-soc.org/HDL_workflow/litex_ls180/, I can see a `.il` file is output, is this what's used in the `libresoc-litex` repository? | 15:45 |
| lkcl | litex only accepts verilog as input | 15:46 |
| lkcl | therefore, we had to undergo a series of conversions | 15:46 |
| lkcl | (which yosys handles... mostly perfectly) | 15:46 |
| lkcl | we found however that the conversion process didn't quite work for SRAM (memory) cells, so converted over to verilog. | 15:47 |
| lkcl | Jean-Paul however very kindly adapted coriolis2 to accept ".il" files, but due to the issues with yosys conversion we stopped using it. | 15:47 |
| lkcl | hence, issuer_verilog.py outputs verilog, not ilang. | 15:48 |
| Las[m] | So ilang is also a HDL? | 15:48 |
| lkcl | it's yosys's "internal" representation | 15:49 |
| lkcl | ILANG aka RTLIL | 15:50 |
| lkcl | it's capable of supporting all concepts of other HDL languages, and consequently is the "intermediary". | 15:50 |
| lkcl | a bit like how Esperanto is often used by automated language translators because it is "simpler" and has a regular grammar | 15:51 |
| lkcl | http://www.clifford.at/yosys/documentation.html | 15:52 |
| lkcl | you'll see there are "read_ilang" and "write_ilang" commands | 15:52 |
| lkcl | as well as "read_verilog" and "write_verilog". | 15:52 |
| Las[m] | So you're saying you stopped using the `.il` files, will you begin using them after you drop litex? | 15:52 |
| lkcl | if you install the yosys-ghdl plugin, you get a "read_vhdl" command as well | 15:52 |
| lkcl | stopped using the il files... as part of the process of converting to GDS-II files, yes. | 15:53 |
| lkcl | stopped using .il files entirely.... no | 15:53 |
| Las[m] | What are the GDS-II files again? | 15:53 |
| Las[m] | I've seen them mentioned before | 15:54 |
| lkcl | GDS-II files are the artwork (bitmap-like) for the layers in an ASIC. | 15:54 |
| Las[m] | It might not be very relevant for what I'm doing so just a quick description might be fine | 15:54 |
| lkcl | you have METAL layers | 15:54 |
| Las[m] | Ah, makes sense | 15:54 |
| lkcl | you have... N-layers | 15:54 |
| lkcl | and etc. etc. | 15:54 |
| lkcl | which are different chemical compounds | 15:54 |
| lkcl | apply them in what is effectively and literally a 3D printing process (literally like 3D printing "slices") and you build up an ASIC | 15:55 |
| Las[m] | What is the file extension for GDS-II files? | 15:55 |
| lkcl | .gd | 15:55 |
| lkcl | s | 15:55 |
| lkcl | -rw-r--r-- 1 lkcl lkcl 22769 Sep 6 21:44 chip_r.spi | 15:55 |
| lkcl | -rw-r--r-- 1 lkcl lkcl 295404 Sep 6 21:44 chip_r.ap | 15:55 |
| lkcl | -rw-r--r-- 1 lkcl lkcl 360803640 Sep 6 21:44 chip_r.gds | 15:55 |
| Las[m] | I noticed you have some prebuilt GDS-II files | 15:56 |
| lkcl | yes, that's accurate, btw: 360 MEGABYTE output | 15:56 |
| Las[m] | like "libresoc_logo.gds" | 15:56 |
| Las[m] | Is this a physical logo, not a circuit, that's meant to be visible on the chip? | 15:56 |
| lkcl | yes, there exist GDS editors and also python programs around that can convert PNGs to GDS-II | 15:56 |
| lkcl | yyyep | 15:56 |
| Las[m] | Thanks, there's honestly quite a lot of build steps I need to understand for this IMO | 15:57 |
| lkcl | https://libre-soc.org/180nm_Oct2020/ls180.svg | 15:57 |
| Las[m] | So is the `libresoc-litex` repository used at all when targeting an ASIC? | 15:57 |
| lkcl | yep, there are. this is just how it is | 15:57 |
| lkcl | yes it is. | 15:57 |
| lkcl | it's triple-purpose | 15:57 |
| lkcl | 1) sim.py - simulations | 15:58 |
| lkcl | 2) versa_ecp5.py - ECP5 FPGA | 15:58 |
| lkcl | 3) ls180.py - ASIC | 15:58 |
| Las[m] | Makes sense, matches the three uses of litex | 15:58 |
| lkcl | bear in mind, litex *doesn't* support ASICs out-of-the-box. | 15:58 |
| lkcl | it's down to the IO pads. | 15:59 |
| Las[m] | Which is why you have libresoc-litex I assume? | 15:59 |
| lkcl | in a simulation, the IO pads are just some code. all great. | 15:59 |
| lkcl | in an FPGA, it's the *FPGA* that handles the IO - and you can have either input, output, or bi-directional | 16:00 |
| lkcl | FPGA input you get one wire | 16:00 |
| lkcl | FPGA output you get one wire (an output) | 16:00 |
| lkcl | FPGA bi-directional you need 3 wires (in, out, output-enable) but they're handled by the FPGA toolchain | 16:00 |
| lkcl | there's classes in litex which take care of that for you | 16:00 |
| lkcl | but for an ASIC, you actually have to output - from your HDL - the *three* signals, explicitly, per IO pad | 16:01 |
| lkcl | given that litex IO peripherals weren't designed to cope with that scenario, i had to cut/paste copy a whole bunch of peripherals and modify them. | 16:01 |
| lkcl | Florent pissed me off by refusing to accept patches except via use of a github account. | 16:02 |
| Las[m] | lol | 16:02 |
| lkcl | there's a lot more to it, but... yeah. | 16:03 |
| Las[m] | I assume it's https://github.com/enjoy-digital/litex ? | 16:03 |
| lkcl | yes | 16:03 |
| lkcl | the code he wrote actually saves a huge amount of time. | 16:04 |
| Las[m] | How does `make -C src/soc/litex/florent ls180` tie into this? | 16:04 |
| lkcl | it's an accumulation of 15 years of expertise. | 16:04 |
| Las[m] | In the `soc` repository, after you've run `issuer_verilog.py` or whatever it was called | 16:04 |
| lkcl | 1 sec | 16:04 |
| lkcl | where did you see that? | 16:05 |
| Las[m] | https://libre-soc.org/HDL_workflow/litex_ls180/ | 16:05 |
| Las[m] | It's also in the Makefile | 16:05 |
| lkcl | i made libresoc-litex a git submodule of soc, for convenience. | 16:05 |
| Las[m] | Ahhh | 16:06 |
| Las[m] | I didn't notice | 16:06 |
| Las[m] | I haven't initialized the submodules | 16:06 |
| lkcl | otherwise they could get out-of-sync | 16:06 |
| lkcl | it should have been the other way round | 16:06 |
| lkcl | or better | 16:06 |
| lkcl | a "top-level-everything" repo with *only* submodules in it | 16:07 |
| Las[m] | If you want to reproducibly link together different versions of software, Nix is the perfect tool for that FYI | 16:07 |
| Las[m] | specifically, specific versions of software | 16:08 |
| lkcl | does nix allow builds to be edited? | 16:09 |
| lkcl | i.e. once installed can they be edited? | 16:09 |
| lkcl | and for development to take place "as usual"... but just with "specific versions"? | 16:09 |
| lkcl | i doubt very much that it does (because it's designed, duh, to deliver specific versions) | 16:10 |
| lkcl | which makes it wholly unsuited for use as an active development tool... | 16:11 |
| lkcl | ... but great for delivering specific versions of tools... *that you use but have no intention of editing* | 16:11 |
| lkcl | we need that combination: specific versions... *and* the ability to work seamlessly with *edited* variants of those specific versions | 16:12 |
| lkcl | aka "python setup.py develop" mode | 16:12 |
| * lkcl afk | 16:13 | |
| Las[m] | Yeah if you're editing them in tandem, submodules are better | 16:14 |
| Las[m] | BTW, what is missing for https://libre-soc.org/180nm_Oct2020/ ? | 16:20 |
| justinrestivo[m] | <lkcl> "and for development to take..." <- this is precisely how I use it at work, now that submodule support has been added. | 19:30 |
| justinrestivo[m] | * at work and personal projects, now | 19:31 |
| justinrestivo[m] | s/at work// | 19:32 |
| justinrestivo[m] | I'm not sure I would describe it as "seamless" yet, but it's worked well enough | 19:34 |
| justinrestivo[m] | Before submodule support was added it was a lot more strained. I would have scripts that repeatedly updated lockfiles before building. Definitely not as nice from a usability standpoint. | 19:35 |
| justinrestivo[m] | s/worked/leaps/, s/well/and/, s/enough/bounds better than before/ | 19:36 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
