| *** tpb has joined #yosys | 00:00 | |
| *** gnufan_home has quit IRC | 00:03 | |
| *** m4ssi has quit IRC | 00:15 | |
| *** emeb_mac has joined #yosys | 00:17 | |
| *** gsi__ has joined #yosys | 01:01 | |
| *** gsi_ has quit IRC | 01:04 | |
| *** trmm has quit IRC | 01:26 | |
| *** blunaxela has quit IRC | 02:19 | |
| *** PyroPeter has quit IRC | 02:50 | |
| *** blunaxela has joined #yosys | 03:02 | |
| *** PyroPeter has joined #yosys | 03:04 | |
| *** jevinskie has joined #yosys | 03:35 | |
| *** dys has quit IRC | 04:39 | |
| *** dys has joined #yosys | 04:44 | |
| *** proteusguy has quit IRC | 05:24 | |
| *** jevinskie has quit IRC | 05:31 | |
| *** proteusguy has joined #yosys | 05:37 | |
| *** proteusguy has quit IRC | 05:38 | |
| *** rohitksingh has joined #yosys | 06:07 | |
| *** _whitelogger has quit IRC | 06:47 | |
| *** _whitelogger has joined #yosys | 06:49 | |
| pepijndevos | ZirconiumX, currently the muxes are defined in both the library and as a techmap. Can one of them go? | 07:12 |
|---|---|---|
| pepijndevos | ../74_models.v:12: Module 74AC151_1x1MUX8 was already declared here: 74series.v:141 | 07:12 |
| *** emeb_mac has quit IRC | 07:17 | |
| *** dys has quit IRC | 07:23 | |
| pepijndevos | Awesome, I got my synthesized 74xx counter to simulate | 07:23 |
| pepijndevos | Now trying to hunt down where ZirconiumX got these benchmark files and see if they have easy to add testbenches. | 07:30 |
| *** dys has joined #yosys | 07:32 | |
| ZirconiumX | pepijndevos: no; techmap needs them to map large muxes, and ABC can synthesise functions out of muxes, too | 07:36 |
| ZirconiumX | Oh, you generated a model from the liberty file | 07:37 |
| pepijndevos | Exactly, so the generated model is conflicting with the techmap | 07:37 |
| ZirconiumX | So remove the generated model :P | 07:37 |
| pepijndevos | But I need all the other ones. | 07:38 |
| ZirconiumX | Do you? | 07:38 |
| pepijndevos | What I think is more sane is to load the liberty file in the script and remove them from models. | 07:39 |
| ZirconiumX | One question is whether the liberty models are black boxes or not | 07:39 |
| pepijndevos | depends how you load them. read_liberty -lib makes black boxes | 07:39 |
| pepijndevos | So these can then be omited from 74_models.v | 07:40 |
| ZirconiumX | Okay, I'll try to make a model for things like the 74283 | 07:41 |
| pepijndevos | Huh? | 07:41 |
| pepijndevos | Hold on... I'll try if this works and send a pr so you can see what I'm doing | 07:41 |
| pepijndevos | no need to rewrite all the things just yet. | 07:41 |
| pepijndevos | Huh, I just plainly deleted the models from 74_models.v and it does not even complain. | 07:45 |
| pepijndevos | I don't think it's using those muxes | 07:47 |
| ZirconiumX | It is, as far as I can tell | 07:48 |
| ZirconiumX | But presumably it's synthesising the model from the liberty file | 07:49 |
| pepijndevos | Yea, but I think the mux techmap is not generating any. If I completely omit the models.v it complains it's missing the adder, but if I removet the verilog mux def it's still happy. | 07:50 |
| pepijndevos | Anyway, pushing changes | 07:51 |
| *** mms has joined #yosys | 07:52 | |
| pepijndevos | ZirconiumX, do you want my simulation stuff too? (possibly in a new branch/pr) | 07:54 |
| ZirconiumX | Sure, I'll take a look | 07:54 |
| pepijndevos | https://github.com/ZirconiumX/74xx-liberty/pull/2 thats just the liberty stuff | 07:55 |
| tpb | Title: Remove duplicate models by loading the liberty ones by pepijndevos · Pull Request #2 · ZirconiumX/74xx-liberty · GitHub (at github.com) | 07:55 |
| pepijndevos | I only have a very simple simulation now, trying to find something more interesting and elaborate. | 07:56 |
| *** _whitelogger has quit IRC | 08:05 | |
| *** _whitelogger has joined #yosys | 08:07 | |
| *** proteusguy has joined #yosys | 08:56 | |
| pepijndevos | Hrm, the bram doesn't have a verilog model either obviously... | 09:07 |
| pepijndevos | Commenting out that pass, I can run the picorv32 testbench, but it's not working correctly. | 09:07 |
| pepijndevos | ZirconiumX, I've been staring at gtkwave to find the difference between the original simulation and the synthesized one and... I have no clue what is going on. Things seem to be not initialised and spread XXXXX like wildfire. | 09:33 |
| ZirconiumX | Esh | 09:33 |
| ZirconiumX | I've just been trying to synthesize things, but apparently I didn't test it properly too. | 09:34 |
| ZirconiumX | Hmm. | 09:34 |
| *** fsasm has joined #yosys | 09:46 | |
| pepijndevos | This seems a reasonable observation ;) | 09:49 |
| pepijndevos | Glad this came to light before you order PCB's for your 1k chips riscv CPU ;) | 09:50 |
| pepijndevos | Honestly, it might be a better idea to write some tests than try to debug picorv32. | 09:53 |
| pepijndevos | IIRC there are various types of DFF with reset and initial values and stuff. Maybe one of those is broken. | 09:53 |
| pepijndevos | I'm going to add more stuff from yosys-bench that has verilog testbenches, which are a whole 4 tests. | 10:01 |
| *** gsi__ is now known as gsi_ | 10:12 | |
| pepijndevos | ZirconiumX, I've added a bunch more simple benchmarks, which should help pin down the problem. | 10:24 |
| *** nengel has quit IRC | 10:24 | |
| pepijndevos | In particular cic5 is pretty simple and also turns into XXXX pretty quickly. | 10:24 |
| *** attie has joined #yosys | 10:24 | |
| pepijndevos | dspmac also produces xxxx | 10:26 |
| ZirconiumX | Hmm... | 10:31 |
| ZirconiumX | pepijndevos: file an issue, please | 10:31 |
| pepijndevos | Sure. I'll spend a bit more time trying to figure out what is going on, and make a nice issue. So far I've just been piling commits onto the PR. | 10:33 |
| ZirconiumX | I'll review them when I get back from the shop | 10:35 |
| pepijndevos | yay | 10:36 |
| pepijndevos | At this point I'd be really happy if Icarus could treat an X value as an error and tell me where it happened. | 10:42 |
| ZirconiumX | The most boring approach is to go through the Yosys script one command at a time and write_verilog | 10:49 |
| pepijndevos | This might be a very good idea, because the end result is... not okay. | 10:52 |
| pepijndevos | Basicallly there is nothing left except the output DFF. | 10:52 |
| pepijndevos | Such optimize, many efficient, wow | 10:53 |
| pepijndevos | The final opt pass deletes everything :/ | 11:06 |
| pepijndevos | Ahhh... I think I know... it is totally my own fault... maybe | 11:12 |
| pepijndevos | YAY it works... at least I'm getting *something" | 11:30 |
| pepijndevos | Yea, it's definitely not correct yet. But... it does stuff, so that's an improvement. | 11:32 |
| *** fsasm_ has joined #yosys | 12:02 | |
| *** fsasm has quit IRC | 12:04 | |
| pepijndevos | welp... I'm not convinced I got the order of the mux pors right... | 12:45 |
| pepijndevos | yea... my muxes are still broken. | 12:46 |
| *** rohitksingh has quit IRC | 12:47 | |
| pepijndevos | Basically $_MUX4_ has a different idea of what things mean than 74AC153, and I know neither... | 12:51 |
| *** cr1901_modern has quit IRC | 12:57 | |
| *** voxadam has quit IRC | 13:01 | |
| pepijndevos | ZirconiumX, unless I'm being thick, your S0-S2 seem reversed from the datasheet? | 13:01 |
| *** voxadam has joined #yosys | 13:02 | |
| ZirconiumX | Ah, possibly? | 13:03 |
| pepijndevos | Ok, dspmac works now | 13:06 |
| pepijndevos | But that's not using mux8 | 13:06 |
| pepijndevos | YESSSSSSS!!! | 13:06 |
| pepijndevos | PicoRV32 works!!! | 13:07 |
| ZirconiumX | Woo | 13:10 |
| ZirconiumX | How many chips? | 13:10 |
| pepijndevos | Oh, not sure. Will check. | 13:10 |
| pepijndevos | Didn't change that part though. | 13:10 |
| *** cr1901_modern has joined #yosys | 13:11 | |
| pepijndevos | Oh, I disabled bram though, because it doesn't have a verilog model, so that's going to be lots of extra memory chips I guess | 13:11 |
| pepijndevos | 859?? | 13:12 |
| pepijndevos | If I reenable the pass it makes IDT7132: 8 | 13:14 |
| ZirconiumX | Yep | 13:15 |
| ZirconiumX | BRAM is a pretty major optimisation | 13:15 |
| *** mms has quit IRC | 13:16 | |
| pepijndevos | As in... to-be-optimised? Pretty minor difference in chip count at least in the picorv32 | 13:16 |
| *** proteusguy has quit IRC | 13:16 | |
| *** emeb has joined #yosys | 13:16 | |
| pepijndevos | huh... I'm confused | 13:17 |
| pepijndevos | it seems to add the IDT chips, but does not remove and others | 13:17 |
| pepijndevos | Like... if I comment out "memory_bram -rules ../bram.rules" I get 8 *less* chips. | 13:19 |
| pepijndevos | That seems broken... | 13:19 |
| *** proteusguy has joined #yosys | 13:25 | |
| *** pie_ has quit IRC | 13:40 | |
| *** cr1901_modern has quit IRC | 14:00 | |
| *** trmm has joined #yosys | 14:34 | |
| trmm | Is there a way to enable pullups on a ECP5 bidirectional pin with the TRELLIS_IO? | 14:37 |
| trmm | ecp5/cells_sim.v doesn't have a pullup parameter, and I'm not sure where else to look. | 14:37 |
| daveshah | Use the PULLMODE attribute either on the TRELLIS_IO or in the LPF | 14:37 |
| daveshah | `(* PULLMODE="UP" *)` or `(* PULLMODE="DOWN" *)` as an attribute | 14:38 |
| *** rohitksingh has joined #yosys | 14:41 | |
| trmm | Ah, I had seen that used in non-LPF programs to assign pins. Is that a long-term feature or a transitional one? | 14:49 |
| daveshah | Everything should really be LPF now | 14:59 |
| daveshah | the attributes were a hack before I got round to writing a LPF parser | 15:00 |
| *** pie_ has joined #yosys | 15:10 | |
| trmm | It would be nice to have pullups selectable in the verilog so that the LPF can be shared between projects that might have different pullup requirements. | 15:17 |
| *** cr1901_modern has joined #yosys | 16:15 | |
| *** indy has quit IRC | 17:05 | |
| *** pie_ has quit IRC | 17:29 | |
| *** pie_ has joined #yosys | 17:32 | |
| pepijndevos | ZirconiumX, any prefs what I write the KiCad stuff in? Since it's s-expr based, I'm thinking about Clojure(Script), but if you prefer Python(already used) or something else, no problem. | 17:42 |
| ZirconiumX | I can't speak s-expr, sadly | 17:47 |
| ZirconiumX | Not for lack of trying | 17:47 |
| ZirconiumX | I'd prefer Python | 17:47 |
| pepijndevos | Alright | 17:55 |
| *** rohitksingh has quit IRC | 18:08 | |
| *** rohitksingh has joined #yosys | 18:12 | |
| *** indy has joined #yosys | 19:21 | |
| *** dys has quit IRC | 19:23 | |
| *** dys has joined #yosys | 19:58 | |
| *** rohitksingh has quit IRC | 20:08 | |
| *** cr1901_modern has quit IRC | 22:00 | |
| ZirconiumX | I'm having issues getting Yosys to infer a (6-port) block RAM | 22:30 |
| ZirconiumX | It handles 3-port just fine | 22:31 |
| ZirconiumX | But I need 6 | 22:31 |
| mwk | what... what kind of hardware actually has a 6-port block RAM? | 22:33 |
| ZirconiumX | Well, I need two pairs of two read/one write ports | 22:34 |
| ZirconiumX | https://pastebin.com/BdejFNiL | 22:34 |
| tpb | Title: [VeriLog] module sh4a_regfile( input clk, input reset, output [31:0] prog - Pastebin.com (at pastebin.com) | 22:34 |
| ZirconiumX | (it's a superscalar core) | 22:34 |
| edwinbalani | A Super-H SH4 one, by any chance? :-) | 22:35 |
| ZirconiumX | edwinbalani: Yep | 22:35 |
| ZirconiumX | Strictly an SH4a which has a few extra instructions and a longer pipeline | 22:35 |
| ZirconiumX | It's a little painful when Yosys can't infer the RAM though; it's 300 cells for the 3-port and 9,000 cells for the 6-port | 22:37 |
| ZirconiumX | (ECP5) | 22:38 |
| daveshah | There's no way that can map to ECP5 hardware | 22:39 |
| daveshah | ECP5 BRAM has a max of two write ports, and they have to be shared read write ports in that case and Yosys doesn't even support that | 22:39 |
| ZirconiumX | Mmm... | 22:40 |
| ZirconiumX | Vague target is a Xilinx chip rather than an ECP5 (though the latter appears to be a bit easier to obtain?) | 22:41 |
| daveshah | Xilinx have similar constraints, two write ports are only possible in the form of shared read/ write ports | 22:41 |
| ZirconiumX | Anyway, what are my options here, then? Two copies of the register file? | 22:41 |
| ZirconiumX | Synchronising them would be painful though | 22:41 |
| daveshah | That allows you to gain read ports but not write ports | 22:42 |
| daveshah | Yosys will do that transformation already | 22:42 |
| daveshah | But obviously not for write ports where it would not match the design | 22:42 |
| ZirconiumX | So I have to accept the major gate loss for this? | 22:43 |
| ZirconiumX | (I'm being paid for writing this, at least) | 22:44 |
| mwk | you could try to bump the clock rate for memory ×2 and double-pump a port | 22:44 |
| mwk | not exactly pretty, but then implementing a three-port memory out of simple flops doesn't end well either | 22:45 |
| ZirconiumX | I have no idea if the DRAM/BRAM/whatever can run fast enough | 22:46 |
| sorear | there’s a XOR trick for synthesizing write ports | 22:46 |
| ZirconiumX | SH4 ran at 200MHz, so this register file would need to be 400MHz | 22:46 |
| sorear | poke azonenberg, he did this | 22:47 |
| ZirconiumX | So, my options are pretty limited here | 22:49 |
| ZirconiumX | I'm presuming building a RAM out of DFFs is going to be fairly slow | 22:49 |
| sorear | http://www.eecg.toronto.edu/~steffan/papers/laforest_xor_fpga12.pdf | 22:49 |
| *** azonenberg has joined #yosys | 22:51 | |
| * azonenberg appears in a puff of smoke | 22:52 | |
| azonenberg | Did someone say multiport register file? | 22:52 |
| ZirconiumX | azonenberg: I'm the one sorear summoned you for | 22:53 |
| ZirconiumX | (hello!) | 22:53 |
| ZirconiumX | I've been commissioned to make a SuperH SH4a core for emulation purposes | 22:54 |
| ZirconiumX | However, the SH4a is two-way superscalar | 22:54 |
| ZirconiumX | Which means I need multiple write ports | 22:55 |
| azonenberg | So, multiple read ports is obviously an easy problem | 22:57 |
| azonenberg | just replicate the array | 22:57 |
| ZirconiumX | sorear linked an interesting paper, and said you could help | 22:57 |
| ZirconiumX | Yosys can do that already | 22:57 |
| azonenberg | Yeah so as far as multiple write ports, the method i've preferred most is probably the paper sorear linked | 23:00 |
| azonenberg | laforest's paper on XOR based multiport memory? | 23:00 |
| ZirconiumX | Yep | 23:00 |
| azonenberg | if not, that's the method i suggest | 23:00 |
| azonenberg | Area scaling is O(W(W+R)) | 23:00 |
| azonenberg | or O(W^2 + WR) | 23:01 |
| azonenberg | So write ports are expensive and read ports comparatively cheap | 23:01 |
| ZirconiumX | I hopefully only need two of them right now | 23:01 |
| daveshah | Given this is only 32 deep, I do wonder if LVT would be more efficient here | 23:05 |
| azonenberg | Possible | 23:05 |
| azonenberg | in my case i was going with a multithreaded design | 23:06 |
| azonenberg | so i had 32 regs * 32 threads | 23:06 |
| ZirconiumX | There are more registers in SH4, but I haven't figured out where I wanted to put them | 23:06 |
| azonenberg | i used a full block ram for each bank of reigsters | 23:06 |
| daveshah | At 32x32 it's marginal whether DRAM or BRAM would be the better choice | 23:07 |
| azonenberg | Yeah | 23:08 |
| azonenberg | I have not done a superscalar processor that was not also multithreaded so i can't suggest much there | 23:08 |
| *** trmm has quit IRC | 23:16 | |
| sorear | ZirconiumX: so how complete is this supposed to be, does it target cycle accuracy, will it be public, and language of choice? | 23:30 |
| ZirconiumX | Yes, yes (license yet to be determined, but open source), Verilog | 23:31 |
| ZirconiumX | Not very for the completeness at the moment | 23:32 |
| sorear | ZirconiumX: I’m wondering if you just bit off a project larger than the multi person multi year j-core.org (architecturally sh2 compatible but slower, single issue) | 23:32 |
| ZirconiumX | I'm not being paid to finish this, I'm being paid to start it :P | 23:33 |
| ZirconiumX | And yes, I'm aware of the J2 | 23:33 |
| ZirconiumX | But byuu managed to perfectly emulate the SNES | 23:36 |
| ZirconiumX | A CPU is a bit less complicated than a game console, even if it is more recent | 23:37 |
| ZirconiumX | I'm reading LaForest's paper and slides, but I still don't think I quite get how the LVT itself is made | 23:42 |
| sorear | haha. good luck with that, honestly | 23:44 |
| daveshah | aiui, the LVT is small enough that a bit blasted dual write port RAM would be fine | 23:45 |
| daveshah | It is only 32 entries | 23:45 |
| daveshah | 1 bit each | 23:45 |
| ZirconiumX | Ah, I think I just grokked it | 23:45 |
| ZirconiumX | Though I'm not smart enough to figure out how to synthesise a PLL or whatever for the double clocking | 23:46 |
| ZirconiumX | I think I can figure out how to divide a clock through a counter, but not multiply it | 23:47 |
| sorear | maybe you’ll have a MMU public before them | 23:47 |
| ZirconiumX | Well, the j-core website appears to be down, so I'm in no rush | 23:48 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!