| *** tpb has joined #yosys | 00:00 | |
| *** gatin00b has joined #yosys | 00:13 | |
| *** fsasm has quit IRC | 00:16 | |
| *** kraiskil has joined #yosys | 00:23 | |
| *** emeb_mac has quit IRC | 01:53 | |
| *** emeb_mac has joined #yosys | 01:56 | |
| *** PyroPeter has quit IRC | 04:02 | |
| *** kraiskil has quit IRC | 04:15 | |
| *** PyroPeter has joined #yosys | 04:15 | |
| *** kraiskil has joined #yosys | 04:18 | |
| *** _whitelogger has quit IRC | 05:27 | |
| *** _whitelogger has joined #yosys | 05:29 | |
| *** Jybz has joined #yosys | 05:45 | |
| *** citypw has joined #yosys | 05:52 | |
| *** FabM has joined #yosys | 06:41 | |
| *** kraiskil has quit IRC | 06:55 | |
| *** FabM_cave has joined #yosys | 07:02 | |
| *** emeb_mac has quit IRC | 07:07 | |
| *** Jybz has quit IRC | 07:27 | |
| *** citypw has quit IRC | 07:50 | |
| *** citypw has joined #yosys | 07:50 | |
| *** X-Scale` has joined #yosys | 07:58 | |
| *** X-Scale has quit IRC | 07:59 | |
| *** X-Scale` is now known as X-Scale | 07:59 | |
| *** voxadam has quit IRC | 08:37 | |
| *** voxadam has joined #yosys | 08:37 | |
| *** promach has quit IRC | 08:43 | |
| *** philtor has quit IRC | 08:52 | |
| *** FabM has joined #yosys | 08:58 | |
| *** FabM is now known as FabM_vace | 08:59 | |
| *** FabM_vace is now known as FabM_cave | 08:59 | |
| *** X-Scale has quit IRC | 09:19 | |
| *** X-Scale` has joined #yosys | 09:19 | |
| *** X-Scale` is now known as X-Scale | 09:20 | |
| *** kraiskil has joined #yosys | 09:58 | |
| *** citypw has quit IRC | 10:03 | |
| *** kraiskil has quit IRC | 10:15 | |
| *** fsasm has joined #yosys | 10:53 | |
| *** kraiskil has joined #yosys | 11:01 | |
| *** Stary has quit IRC | 11:16 | |
| *** X-Scale has quit IRC | 12:06 | |
| *** X-Scale has joined #yosys | 12:33 | |
| pepijndevos | What's the discerning factor for getting a plugin into yosys-plugins or yosys proper? | 12:33 |
|---|---|---|
| daveshah | I don't think yosys-plugins has much in the way of criterea | 12:34 |
| daveshah | yosys itself would depend more on quality, dependencies, and portability | 12:34 |
| daveshah | One option for features like the protobuf backend and python api is to have them in Yosys but disabled by default in the makefile | 12:35 |
| daveshah | If they add unnecessary dependencies | 12:35 |
| pepijndevos | Right, like verific | 12:35 |
| daveshah | Yeah | 12:35 |
| pepijndevos | I'm looking at CommandHandler, and it seems each subclass is responsible for its own bitstream output, prompting the question if asc files are in any way a well defined and preferred output format, or "whatever the packer takes as input" | 12:37 |
| daveshah | No, asc files are a horrible format | 12:39 |
| daveshah | I would personally use fasm for any new architecture | 12:39 |
| daveshah | https://github.com/SymbiFlow/fasm | 12:39 |
| tpb | Title: GitHub - SymbiFlow/fasm: FPGA Assembly (FASM) Parser and Generator (at github.com) | 12:39 |
| daveshah | (in many ways I don't love it, but it is a standard at least) | 12:39 |
| pepijndevos | Ohhhh fancy | 12:40 |
| pepijndevos | Sounds reasonable | 12:40 |
| pepijndevos | I did a call graph of nextpnr to figure out how stuff fits together, and I noticed a bunch of garbled Python stuff, what is that used for? | 12:41 |
| daveshah | It's used for the Python API | 12:45 |
| daveshah | But you can turn that off in the build if you don't want it complicating things | 12:45 |
| pepijndevos | I don't mind, I was just surprised to see it in a trace when not doing anything special. I suppose it's just setup code then, or is part of the ice40 flow using the Python API? | 12:49 |
| daveshah | No nothing in the actual flow uses the Python API | 12:52 |
| daveshah | it's just initialised at startup as a Python script may be called later on in the flow (with one of the cmdline arguments like --pre-pack etc) | 12:52 |
| pepijndevos | Hmmm, looking at fasm ther reference implementation is in Python. It looks simple enough to just printf though, so maybe what I'll do is just printf fasm in Nextpnr and write the packer in Python. | 12:55 |
| daveshah | Please don't | 12:56 |
| pepijndevos | Which part? | 12:56 |
| daveshah | The Python API is somewhat by necessity a pain to build on certain platforms (windows) | 12:56 |
| daveshah | as a result many of the static builds prefer to exclude the python api | 12:57 |
| daveshah | a few weeks ago I added a way to specify timing constraints without python for this very reason | 12:57 |
| daveshah | Oh wait, you mean C printf | 12:57 |
| daveshah | I thought you meant write parts of the nextpnr flow in Python | 12:57 |
| pepijndevos | Yea, so the Nextpnr side would be all C, the packer in Python. | 12:57 |
| pepijndevos | Unless using Python on Windows *at all* is problematic | 12:58 |
| daveshah | No, it's more linking it that is the problem | 12:58 |
| pepijndevos | IMO... windows in general is just problematic -.- | 12:58 |
| pepijndevos | Alright, sounds good then :) | 12:59 |
| pepijndevos | Does Nextpnr generally support the constraint format supported by the vendor tools, or does it have its own format? Seems ice40 uses pcf while ECP5 uses lpf, not familiar with their respective vendor tools. | 13:32 |
| daveshah | Normally it uses the vendor format | 13:32 |
| pepijndevos | I see, thanks. | 13:32 |
| *** alexhw has quit IRC | 14:03 | |
| mwk | is that something we'd like to change, btw? | 14:04 |
| mwk | it'd be nice to have a unified format | 14:04 |
| daveshah | I would always want vendor constraints as an option | 14:04 |
| mwk | well, definitely | 14:04 |
| daveshah | It mostly depends if maintaining two constraint formats per arch is worth it | 14:05 |
| *** alexhw has joined #yosys | 14:05 | |
| mwk | per arch? | 14:05 |
| daveshah | Well, each arch would have to support the generic and vendor one | 14:06 |
| daveshah | Some of the generic code could be common, but probably not all of it | 14:06 |
| mwk | hmm. | 14:06 |
| mwk | things like setting timing constraints for nets isn't really that backend-dependent, is it? | 14:06 |
| daveshah | No, and that is already generic in the form of the python api | 14:07 |
| mwk | though I suppose I can agree on setting stuff like I/O properties | 14:07 |
| daveshah | It's more IO (moreover IO config) and general chip configuration that I'm thinking of | 14:07 |
| daveshah | I think the long run plan might be a roughly sdc/xdc-like tcl as a generic option easier to integrate than Python | 14:08 |
| mwk | there's also stuff like *sigh* ISE | 14:08 |
| daveshah | This should give us a combination of a generic format and something roughly compatible with several vendor's timing formats | 14:08 |
| mwk | where some options are only settable by bitgen command line options, and not via the UCF constraint file | 14:08 |
| mwk | I have no idea where to even fit that | 14:09 |
| *** fsasm has quit IRC | 14:10 | |
| *** m4ssi has joined #yosys | 14:19 | |
| pepijndevos | What's the purpose of constids.inc? Is that just a list of any type of constant whatsoever? Some seem wire names, but it seems also cell types and parameters. | 14:30 |
| mwk | do you know how IDs work in nextpnr? | 14:31 |
| pepijndevos | Uh no | 14:31 |
| mwk | in yosys? | 14:31 |
| mwk | have you have about interned strings? | 14:32 |
| mwk | the general idea is that there's this big giant global (or in nextpnr's case, per-context) table of all ID strings ever used | 14:32 |
| pepijndevos | Oh, interned strings I know hehe | 14:32 |
| mwk | and the IdString class is just an int that's an index into this array | 14:32 |
| pepijndevos | ahhhhhh | 14:33 |
| mwk | the constids.inc is the initial state of this table | 14:33 |
| mwk | which needs some fixed entries, because there are strings in the binary chip database | 14:33 |
| mwk | and they're also represented as ints in the binary | 14:33 |
| pepijndevos | Oh, so I only need to add the ones that represent a fixed int in the chipdb, the others will be cached automatically? | 14:34 |
| mwk | constids.inc is used (or emitted? I don't remember) by the script that creates the .bba file | 14:34 |
| pepijndevos | .bba file? | 14:34 |
| mwk | so that the indices are in sync between the emitter and nextpnr | 14:34 |
| mwk | binary blob assembler | 14:35 |
| pepijndevos | lol | 14:35 |
| mwk | it's the (custom) tool we use to create the binary databases in nextpnr | 14:35 |
| mwk | it uses a few tricks so that the whole db can just be mmaped straight into memory without needing deserialization | 14:35 |
| mwk | so the general idea is that you have a project that reverses the FPGA, like icestorm or prjtrellis | 14:36 |
| pepijndevos | Okay, I guess I need to learn about the bba. I assume it's a bit more sane and portable than the way Gowin just reads the dat file into a struct? | 14:36 |
| mwk | you install it | 14:36 |
| mwk | then in nextpnr you have some scripts that access prjtrellis/icestorm database at nextpnr build time, and emit the .bba files | 14:36 |
| mwk | which are assembled by the bba tool into binary files | 14:37 |
| mwk | which nextpnr then mmaps, and accesses straight thru C++ classes | 14:37 |
| mwk | pepijndevos: it's... well, a bit saner | 14:37 |
| mwk | as for portability, not really | 14:38 |
| mwk | you need the binary file to be built with the same endianness as nextpnr, for one | 14:38 |
| daveshah | As far as I know that's the only portability issue on any reasonable OS | 14:38 |
| mwk | also, with bba, you don't have one giant struct, you have a sea of structures connected by pointers | 14:38 |
| mwk | which helps the sanity aspect a lot | 14:38 |
| pepijndevos | Okay, so I need to write a Gowin bba script? | 14:39 |
| mwk | (the pointers are encoded as relative pointers in the binary, with a bit of operator overloading on the C++ side to access them easily) | 14:39 |
| daveshah | Of course there's no actual need to use bba at all | 14:39 |
| mwk | yeah, endianness is the only issue | 14:39 |
| daveshah | Its only convention that nextpnr arches use it | 14:40 |
| mwk | but it still means the files are not portable | 14:40 |
| daveshah | The text bba files are, at least | 14:40 |
| mwk | pepijndevos: either that, or roll your own database format | 14:40 |
| daveshah | And they are the time consuming part to generate usually | 14:40 |
| mwk | well, that or hardcode everything into nextpnr C++ code | 14:40 |
| mwk | but I cannot recommend that approach | 14:40 |
| daveshah | From memory that's basically what the very first nextpnr did | 14:41 |
| pepijndevos | Why not? Makes it fun to reverse engineer, with as much C++ sauce as possible... oh wait it's open source. | 14:41 |
| daveshah | There was a Python script that just generated a load of C++ structs | 14:41 |
| daveshah | *struct instances | 14:42 |
| mwk | hah | 14:42 |
| daveshah | But it totally killed g++ trying to build it | 14:42 |
| mwk | well tbh | 14:42 |
| daveshah | Istr memory usage of about 12GB for an iCE40 hx8k | 14:42 |
| mwk | building the .bba file for nextpnr is also... an experience :p | 14:42 |
| daveshah | At least that bit is distributable | 14:42 |
| daveshah | If someone could be bothered to set up the infra for that | 14:43 |
| *** fsasm has joined #yosys | 14:45 | |
| mwk | pepijndevos: and as for output format from nextpnr | 14:46 |
| mwk | well you have several options | 14:46 |
| mwk | which depend on how you want to generate bitstreams | 14:47 |
| mwk | the simplest way (from nextpnr side) is: don't have one at all | 14:47 |
| mwk | these days, nextpnr can dump the current design in json format, which you can read from whatever tool you use to generate bitstreams | 14:48 |
| mwk | particularly convenient if it's some python script anyway | 14:48 |
| pepijndevos | oh, that's neat. | 14:49 |
| daveshah | just use `--write` | 14:49 |
| daveshah | placement and routing is represented using attributes | 14:49 |
| mwk | other options are: emit a bitstream directly (preferably by linking to some separate C/C++ bitstream manipulation library you wrote), or emit some text-based format | 14:49 |
| *** kraiskil has quit IRC | 14:53 | |
| *** emeb has joined #yosys | 14:58 | |
| pepijndevos | I'll have to see how hard it is to generate fasm and how nice the json format is, but either of those options seems fine. | 15:01 |
| *** Jybz has joined #yosys | 15:02 | |
| pepijndevos | In createContext it seems to load the same stuff from the values argument as well as the po::variables_map vm, what's the use of each of those? They seem to duplicate the same settings. | 16:03 |
| daveshah | Probably better off asking micko about that one | 16:03 |
| *** kraiskil has joined #yosys | 16:07 | |
| *** fsasm has quit IRC | 16:14 | |
| *** Stary has joined #yosys | 16:18 | |
| *** kraiskil has quit IRC | 16:32 | |
| *** m4ssi has quit IRC | 16:52 | |
| *** vidbina_ has joined #yosys | 17:12 | |
| *** dys has joined #yosys | 18:15 | |
| *** FabM_cave has quit IRC | 18:17 | |
| *** vidbina_ has quit IRC | 19:08 | |
| *** parport0 has quit IRC | 19:09 | |
| *** parport0 has joined #yosys | 19:11 | |
| *** gorbak25 has joined #yosys | 20:00 | |
| *** emeb_mac has joined #yosys | 20:49 | |
| *** adjtm has quit IRC | 20:54 | |
| *** adjtm has joined #yosys | 21:23 | |
| *** Jybz has quit IRC | 21:52 | |
| *** emeb has quit IRC | 22:59 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!