| *** tpb has joined #yosys | 00:00 | |
| *** vidbina_ has quit IRC | 00:05 | |
| *** Degi_ has joined #yosys | 00:24 | |
| *** Degi has quit IRC | 00:27 | |
| *** Degi_ is now known as Degi | 00:27 | |
| *** X-Scale has quit IRC | 00:58 | |
| *** [X-Scale] has joined #yosys | 00:59 | |
| *** [X-Scale] is now known as X-Scale | 00:59 | |
| *** futarisIRCcloud has joined #yosys | 02:05 | |
| *** citypw has joined #yosys | 02:22 | |
| *** Cerpin has quit IRC | 03:53 | |
| *** Cerpin has joined #yosys | 03:54 | |
| *** az0re has joined #yosys | 03:55 | |
| *** _whitelogger has quit IRC | 04:33 | |
| *** _whitelogger has joined #yosys | 04:35 | |
| *** elfGamal has quit IRC | 05:33 | |
| *** elGamal has joined #yosys | 05:37 | |
| *** rohitksingh has quit IRC | 06:15 | |
| *** emeb_mac has quit IRC | 06:33 | |
| *** Vinalon has quit IRC | 06:34 | |
| *** npe has quit IRC | 06:40 | |
| *** dys has joined #yosys | 07:21 | |
| *** jakobwenzel has joined #yosys | 08:02 | |
| *** anuejn_ is now known as anuejn | 08:22 | |
| *** jakobwenzel1 has joined #yosys | 09:13 | |
| *** jakobwenzel has quit IRC | 09:15 | |
| *** jakobwenzel1 is now known as jakobwenzel | 09:15 | |
| *** hexagon5un has quit IRC | 09:16 | |
| *** hexagon5un has joined #yosys | 09:17 | |
| *** rohitksingh has joined #yosys | 09:21 | |
| *** az0re has quit IRC | 09:25 | |
| *** vidbina_ has joined #yosys | 09:48 | |
| ZirconiumX | I've been going through a MiSTer core and trying to fix the various bits of SystemVerilog that have creeped into the codebase | 10:46 |
|---|---|---|
| ZirconiumX | But there's a Yosys error that confuses me | 10:47 |
| ZirconiumX | https://github.com/MiSTer-devel/Minimig-AGA_MiSTer/blob/MiSTer/sys/hps_io.v#L600 | 10:47 |
| tpb | Title: Minimig-AGA_MiSTer/hps_io.v at MiSTer · MiSTer-devel/Minimig-AGA_MiSTer · GitHub (at github.com) | 10:47 |
| ZirconiumX | (pretend the always block has a name like it should in Verilog-2005) | 10:48 |
| ZirconiumX | sys/hps_io.v:600: ERROR: Failed to detect width for identifier \clk_sys.cmd! | 10:48 |
| daveshah | This is a terrible error | 10:48 |
| ZirconiumX | But the width is defined within the block (`reg [15:0] cmd`) | 10:48 |
| daveshah | but in non-system Verilog signals can only be declared in named blocks | 10:48 |
| daveshah | try begin: foo here | 10:48 |
| daveshah | https://github.com/MiSTer-devel/Minimig-AGA_MiSTer/blob/MiSTer/sys/hps_io.v#L585 | 10:48 |
| tpb | Title: Minimig-AGA_MiSTer/hps_io.v at MiSTer · MiSTer-devel/Minimig-AGA_MiSTer · GitHub (at github.com) | 10:48 |
| ZirconiumX | <ZirconiumX> (pretend the always block has a name like it should in Verilog-2005) | 10:48 |
| ZirconiumX | I gave it the name `clk_sys` | 10:49 |
| daveshah | Oh, I didn't see that | 10:49 |
| ZirconiumX | Which appears in the error | 10:49 |
| daveshah | Then this is a bug | 10:49 |
| daveshah | at a guess it is because of nesting of begin/end blocks | 10:49 |
| ZirconiumX | Well, using *just* that always block as a minimal testcase parses fine | 10:56 |
| ZirconiumX | Ugh | 10:56 |
| ZirconiumX | :q | 11:03 |
| ZirconiumX | ... | 11:03 |
| ZirconiumX | I really hate how difficult it is to see if a window is in focus sometimes | 11:03 |
| ZirconiumX | Oh, I see where the bug is | 11:06 |
| ZirconiumX | daveshah: I have two always blocks named the same thing and they contain a register which is named the same thing | 11:07 |
| daveshah | ah | 11:07 |
| ZirconiumX | So I'm wondering if Yosys isn't properly resolving the names | 11:07 |
| daveshah | Yes, although maybe that should be an error? | 11:07 |
| ZirconiumX | I don't know what the LRM thinks here. | 11:07 |
| daveshah | idk if two always blocks named the same are allowed | 11:07 |
| ZirconiumX | Verilator rejects it | 11:10 |
| ZirconiumX | As does Icarus | 11:10 |
| ZirconiumX | So I guess it's technically invalid. | 11:10 |
| ZirconiumX | daveshah: https://github.com/YosysHQ/yosys/issues/1940 | 11:13 |
| tpb | Title: Poor error message with two always blocks named the same · Issue #1940 · YosysHQ/yosys · GitHub (at github.com) | 11:13 |
| ZirconiumX | While I'm here, the code uses register initialisation inside always blocks | 11:25 |
| ZirconiumX | e.g. reg [3:0] state = 0; | 11:25 |
| ZirconiumX | How should I replace that? | 11:25 |
| *** ebb has quit IRC | 11:27 | |
| *** ebb has joined #yosys | 11:27 | |
| *** Ultrasauce has quit IRC | 11:27 | |
| *** Ultrasauce has joined #yosys | 11:29 | |
| *** kuldeep has quit IRC | 11:42 | |
| *** kuldeep has joined #yosys | 11:48 | |
| *** kuldeep has quit IRC | 11:51 | |
| *** kuldeep has joined #yosys | 11:51 | |
| ZirconiumX | daveshah: Could you send me a firmware.hex for attosoc? I want to try using attosoc with synth_intel_alm and Quartus and see how far I get | 12:16 |
| daveshah | https://www.irccloud.com/pastebin/g07RwjBr/firmware.hex | 12:17 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 12:17 |
| ZirconiumX | Thank you | 12:17 |
| ZirconiumX | I still think the most cursed code I've ever seen has to be the Altera mif2hex.v, which does all its parsing in Verilog | 12:20 |
| ZirconiumX | I'm sure mwk would love to read it | 12:23 |
| *** FFY00 has quit IRC | 12:51 | |
| *** FFY00 has joined #yosys | 12:52 | |
| *** FFY00 has quit IRC | 13:04 | |
| *** FFY00 has joined #yosys | 13:05 | |
| ZirconiumX | Holy fucking shit | 13:08 |
| ZirconiumX | synth_intel_alm works on real hardware with only minor changes | 13:08 |
| daveshah | nice! | 13:08 |
| ZirconiumX | Yeah, attosoc boots | 13:09 |
| ZirconiumX | And I think that's a pretty good example of a fairly complex program | 13:09 |
| daveshah | Well, complex gateware but a simple program | 13:09 |
| ZirconiumX | A good enough tech demo, though, right? | 13:10 |
| daveshah | Definitely | 13:10 |
| daveshah | It's found the vast majority of problems with simple logic, ime | 13:10 |
| daveshah | May or may not use any BRAM depending on how it is implemented | 13:10 |
| ZirconiumX | It does use BRAM for the register file, but not for the firmware ROM | 13:11 |
| ZirconiumX | (because I don't currently have initialisable BRAM) | 13:11 |
| daveshah | Meanwhile, I'm trying to get the MiST SNES core working with GHDL and cxxrtl (then ECP5) | 13:16 |
| daveshah | It's proving an interesting test, found a few ghdl bugs but all fixed by tristan very quickly | 13:16 |
| * ZirconiumX points to MiSTer being even worse | 13:17 | |
| daveshah | Now deep in 65C816 assembly trying to figure out some subtle bug somewhere | 13:17 |
| daveshah | FPGA dev really can be interesting | 13:17 |
| ZirconiumX | You know how people write "portable code" that only actually compiles with GCC? | 13:17 |
| ZirconiumX | MiSTer is that but with Quartus | 13:17 |
| ZirconiumX | Because all the "Verilog" files are actually SystemVerilog with extensions Yosys can't handle | 13:18 |
| ZirconiumX | And the dev seems to think that's a Yosys problem | 13:18 |
| mwk | what exactly is missing? | 13:18 |
| mwk | oh wait, extensions *to* SystemVerilog | 13:18 |
| mwk | ugh | 13:18 |
| ZirconiumX | mwk: The main things that come to mind are declarations in anonymous always blocks, and initialisations inside always blocks | 13:19 |
| ZirconiumX | With those, I think Yosys will be able to build the Minimig MiSTer core (with the help of ghdlsynth) | 13:20 |
| ZirconiumX | mwk: not "extensions to SystemVerilog" but "SystemVerilog extensions to Verilog" | 13:20 |
| mwk | ah, then it is a yosys problem | 13:27 |
| ZirconiumX | mwk: depends if you count .v files as systemverilog or not | 13:28 |
| *** jfcaron has joined #yosys | 13:44 | |
| *** vidbina_ has quit IRC | 13:58 | |
| *** dys has quit IRC | 14:03 | |
| *** emeb has joined #yosys | 14:38 | |
| Sarayan | ZX: I'm working on integrating slang into yosys | 14:42 |
| ZirconiumX | That ought to work :P | 14:42 |
| Sarayan | It's not a trivial endeavour though, in large part because I don't talk verilog | 14:45 |
| Sarayan | oh, btw, is there a good rtlil documentation, or is all there is to it is in the yosys manual? | 14:46 |
| ZirconiumX | whitequark would probably know more there | 14:50 |
| Sarayan | Yeah, hopefully she'll answer the question when she's around | 14:50 |
| whitequark | i'm here | 14:50 |
| whitequark | everything i know about rtlil is in the manual | 14:51 |
| whitequark | (either i learned it from the manual, or i put it into the manual) | 14:51 |
| Sarayan | Hmm damn | 14:53 |
| Sarayan | okay then | 14:53 |
| whitequark | you can also ask here | 14:53 |
| Sarayan | I guess I shall. Can rtlil do 01XZ? | 14:54 |
| whitequark | yes | 14:54 |
| whitequark | and only those, in fact | 14:54 |
| ZirconiumX | S0/S1/Sx/Sz right? | 14:54 |
| whitequark | ok, not quite | 14:54 |
| ZirconiumX | And I think Sa/Sm | 14:54 |
| whitequark | there's also -, but not in values | 14:55 |
| Sarayan | I mean opposite to 0/1 | 14:55 |
| whitequark | m should never appear in RTLIL you see anywhere | 14:55 |
| ZirconiumX | But it *is* there, and should be mentioned for that | 14:55 |
| whitequark | Sarayan: yep, it is 4-valued | 14:55 |
| whitequark | ZirconiumX: fair enough | 14:55 |
| mwk | - is used in the $fsm cells, I think | 14:55 |
| Sarayan | slang classifies values are 2-state or 4-state, so I guess rtlil doesn't have explicit 2-state? | 14:56 |
| Sarayan | s/are/as/ | 14:56 |
| * ZirconiumX wonders how the heck ghdlsynth lowers VHDL's 9-state logic | 14:56 | |
| mwk | nope, no 2-state | 14:57 |
| Sarayan | 'kay | 14:57 |
| whitequark | Sarayan: in RTLIL you can put any of its 5 (6 if you count m) states in any position where a constant is valid | 14:57 |
| whitequark | in some of those places, only 0/1 are in fact valid | 14:58 |
| whitequark | actually, now that I think about it, what happens if you feed a $add cell 'z? | 14:59 |
| Sarayan | wq: A black hole opens and swallows the computer? | 14:59 |
| mwk | 'x happens on the output | 14:59 |
| whitequark | ah, makes sense | 14:59 |
| Sarayan | mwk: I liked my version more | 14:59 |
| ZirconiumX | That sounds like a bash.org quote | 15:01 |
| *** emeb has quit IRC | 15:14 | |
| *** vidbina_ has joined #yosys | 15:16 | |
| daveshah | https://usercontent.irccloud-cdn.com/file/MajYKnuf/frame.png | 15:18 |
| daveshah | making progress with ghdl and cxxrtl! | 15:18 |
| daveshah | all a horrible hack but at least it is doing something | 15:18 |
| *** emeb has joined #yosys | 15:19 | |
| *** Vinalon has joined #yosys | 15:21 | |
| gtw | haha nice choice of screenshot daveshah :) | 15:22 |
| daveshah | it's the MiST SNES core | 15:23 |
| whitequark | daveshah: whoa nice | 15:23 |
| whitequark | how's the performance like? | 15:23 |
| daveshah | It took about 20 minutes to get to that point | 15:23 |
| whitequark | flattened design? | 15:23 |
| daveshah | But it's a big and messy core | 15:23 |
| daveshah | No | 15:23 |
| whitequark | oh | 15:23 |
| whitequark | yeah that would do it | 15:23 |
| whitequark | non-flattened designs run orders of magnitude slower | 15:24 |
| gtw | Is this an appropriate place to ask prjtrellis questions, or is there somewhere better? I am wondering about adding a bunch more SVF options to ecppack... | 15:24 |
| daveshah | gtw: sure | 15:24 |
| mwk | gtw: it's ok, though there's also ##openfpga | 15:24 |
| gtw | daveshah: sure it's appropriate, or sure add more SVF? | 15:25 |
| whitequark | daveshah: if you don't flatten then two things happen | 15:25 |
| gtw | mwk: ok thanks :) | 15:25 |
| whitequark | first, there is no splitnets | 15:25 |
| daveshah | gtw: both | 15:25 |
| whitequark | second, you have comb dependencies between submodules | 15:25 |
| Sarayan | How do you add a port to a RTLIL::Module? | 15:25 |
| whitequark | both of which mean you probably have hundreds of delta cycles | 15:25 |
| whitequark | (I'm curious how many) | 15:25 |
| daveshah | ack | 15:25 |
| daveshah | how do I know? | 15:25 |
| whitequark | .step() returns that | 15:26 |
| gtw | daveshah: OK I will send a pull request once I get a round tuit :) | 15:26 |
| daveshah | gtw: thanks! | 15:26 |
| *** npe has joined #yosys | 15:28 | |
| Sarayan | (adding a wire and setting its port_id blows up because it's not in the ports array) | 15:28 |
| daveshah | whitequark: looks like up to 62 delta cycles, but that is during startup so maybe more once more parts start running | 15:29 |
| whitequark | daveshah: i would expect at least a 10x speedup if you flatten | 15:30 |
| whitequark | quite possibly mre | 15:30 |
| Sarayan | oh, looks like I have to class fixup_ports() at some mysterious point | 15:30 |
| whitequark | daveshah: oh and if you do -b 'cxxrtl -header' you can rebuild your bench code without rebuilding the generated code | 15:33 |
| daveshah | whitequark: thanks, absolutely flying with flatten as expected | 15:34 |
| whitequark | daveshah: curious what the speedup is | 15:34 |
| Sarayan | ok, I have the ports and internal variables translating, weee | 15:35 |
| daveshah | whitequark: took about 2 minutes to get to the point it took noflatten about 20 minutes | 15:36 |
| daveshah | so about 10x as expected | 15:36 |
| whitequark | nice | 15:36 |
| whitequark | how many delta cycles is it now? | 15:36 |
| whitequark | (both on posedge and negedge) | 15:37 |
| whitequark | also, does the flattened design have any feedback arcs, per the backend output? | 15:38 |
| daveshah | up to about 5 delta cycles | 15:41 |
| daveshah | i'll see what the backend output is | 15:41 |
| whitequark | 5 delta cycles is reasonable | 15:41 |
| daveshah | I think there is even a generated clock deep inside | 15:41 |
| whitequark | ah, then my next suggestion wouldn't work | 15:42 |
| whitequark | (stop toggling the clock and instead set posedge_p_clk = true; directly, which lets you skip negedge cycles) | 15:42 |
| daveshah | Yes, one feedback arc around the PPU | 15:42 |
| whitequark | ok, yes, won't work then | 15:42 |
| daveshah | there is definitely stuff happening on the negede too | 15:42 |
| whitequark | ahh | 15:42 |
| whitequark | this is really nice to hear that cxxrtl actually handles that well | 15:43 |
| whitequark | i've only really built it for fully synchronous single-clock nmigen designs | 15:43 |
| whitequark | well | 15:43 |
| whitequark | that was my task. i built it to handle literally any imaginable rtlil because why not | 15:43 |
| daveshah | Almost everything is on the same clock tbf | 15:43 |
| daveshah | But it still seems to do very well | 15:43 |
| whitequark | daveshah: how do you grab the images btw? | 15:48 |
| daveshah | whitequark: writing a csv file and processing it with PIL | 15:54 |
| daveshah | just using hsync falling edge = start new line and vsync falling edge = start new file | 15:54 |
| whitequark | oh, so you're basically sampling it at each pixel clock? | 15:55 |
| daveshah | Yeah, every other system clock which I think is one pixel clock | 15:55 |
| whitequark | do you think blackboxes would help you here? | 15:56 |
| daveshah | The video output is top level at the moment anyway, so it wouldn't make a big difference | 15:56 |
| whitequark | ah ok | 15:56 |
| ZirconiumX | I think it'd be at least a little more fun to see it render in SDL or whatever | 15:56 |
| whitequark | yeah but you don't necessarily need blackboxes for that | 15:56 |
| daveshah | ZipCPU did something like that with Verilator | 15:57 |
| whitequark | ZirconiumX: my idea for nmigen-soc is that it would come with peripherals you could drop into your design and they'd have simulation versions hooked up to the host system | 15:57 |
| whitequark | one of them could very well be SDL output | 15:57 |
| daveshah | That's a really nice idea | 15:58 |
| daveshah | Being able to do that for the CPU should give a good speedup too | 15:58 |
| whitequark | yes, lambdaconcept suggested it, based on the concept pioneered by litex | 15:58 |
| whitequark | we are actually quite close to it working | 15:58 |
| whitequark | two yosys PRs away from having all the knobs I need in nmigen for turnkey integration | 15:59 |
| whitequark | and i already have a working design for the first one | 15:59 |
| ZirconiumX | https://gist.github.com/ZirconiumX/dcf5f76675658f2d10937f176adc4a6e <-- if people are curious, here's how Yosys attosoc synthesis compares to Quartus attosoc synthesis | 16:00 |
| tpb | Title: quartus_v_yosys.txt · GitHub (at gist.github.com) | 16:00 |
| whitequark | there's some... quite unfortunate C++ code involved | 16:00 |
| whitequark | but so can be said about the rest of cxxrtl | 16:01 |
| whitequark | it's reliable and relatively simple, i just hate it | 16:01 |
| *** strongsaxophone has joined #yosys | 16:01 | |
| lambda | ZirconiumX: is that still with LUT ROM? | 16:02 |
| gtw | ZirconiumX: nice :) | 16:02 |
| ZirconiumX | lambda: No, flop ROM, AFAICT; I don't yet have BRAM initialisation | 16:02 |
| whitequark | ZirconiumX: nice! | 16:02 |
| whitequark | about 30% more area, is it? | 16:03 |
| ZirconiumX | 60% more :P | 16:04 |
| whitequark | oh, right | 16:04 |
| lambda | ZirconiumX: ah, interesting, wouldn't have expected flops to be anywhere near as cheap as LUTs | 16:04 |
| ZirconiumX | lambda: It's possible Yosys is lowering them to constant drivers | 16:05 |
| ZirconiumX | Since the flops are used for ROM | 16:05 |
| whitequark | daveshah: if you ever feel like making cxxrtl faster, there's something i don't quite understand | 16:05 |
| whitequark | i think there is a bug in a scheduler somewhere that prevents designs without feedback arcs from taking only 2 delta cycles | 16:05 |
| whitequark | i haven't looked into it yet because... well, it's just slightly slower this way, yet still reliable | 16:06 |
| whitequark | (a curious advantage of a design with delta cycles is that bugs in scheduler only result in slowdown, never correctness issues) | 16:07 |
| ZirconiumX | I don't foresee adding 7-input functions because they're too specific for scavenging them from ABC9 output to produce meaningful results | 16:07 |
| ZirconiumX | DSP inference is going to be awkward, because naturally it's not documented anywhere | 16:09 |
| ZirconiumX | And BRAM inference requires directly instantiating the target cell | 16:10 |
| ZirconiumX | Which is apparently like five layers of unsupported | 16:10 |
| ZirconiumX | *BRAM initialisation | 16:12 |
| ZirconiumX | whitequark: It surprises me how often I go back to the DE10-Nano support I added to nmigen-boards to remember the pin numberings | 16:18 |
| whitequark | heh :) | 16:18 |
| *** citypw has quit IRC | 16:20 | |
| *** jakobwenzel has quit IRC | 16:21 | |
| daveshah | welp, not quite a title screen yet, this is probably something wrong with my attempt to remove altera ram primitives though | 16:29 |
| daveshah | https://usercontent.irccloud-cdn.com/file/O41XpDWy/frame.png | 16:29 |
| ZirconiumX | altsyncram, right? | 16:30 |
| * ZirconiumX has been wondering about trying to instantiate $mem or something from it | 16:30 | |
| whitequark | daveshah: ooh, send it to @mcclure111! | 16:31 |
| ZirconiumX | FPGA glitch art :P | 16:31 |
| mwk | ZirconiumX: like, making sim models for block RAMs? | 16:32 |
| mwk | I tried and failed | 16:32 |
| daveshah | ZirconiumX: no the dpram, spram, dpram_dif, etc IPs | 16:32 |
| ZirconiumX | mwk: No, turning a user altsyncram into something memory_bram can operate on | 16:32 |
| ZirconiumX | daveshah: oh lord | 16:33 |
| daveshah | I don't really blame them | 16:33 |
| daveshah | We all know BRAM inference is screwy and they only care about building with Quartus | 16:33 |
| ZirconiumX | This attitude seems to persist with MiSTer... | 16:37 |
| whitequark | to be fair, supporting multiple toolchains with verilog is hard | 16:39 |
| daveshah | Indeed | 16:41 |
| ZirconiumX | https://gist.github.com/ZirconiumX/dcf5f76675658f2d10937f176adc4a6e <-- my chess move generator (using post-fit stats and Fmax) | 16:45 |
| tpb | Title: qvy_chess.txt · GitHub (at gist.github.com) | 16:45 |
| daveshah | Some parts of memory inference is even more cursed in VHDL than Verilog | 16:46 |
| ZirconiumX | It's *way* closer here | 16:46 |
| whitequark | daveshah: you represent the memory as one gigantic register and then read chunks of it, right? | 16:47 |
| daveshah | No, you can have arrays | 16:48 |
| daveshah | It's true dual port that gets weird as you start to get into shared variables, which were significantly changed in VHDL 08 so one pattern stopped working | 16:48 |
| ZirconiumX | 10MHz less Fmax, 2 LABs more area. That's not too shabby. | 16:49 |
| lambda | ZirconiumX: wow, nice | 16:49 |
| ZirconiumX | On the other hand I'm very consciously giving it workloads without things like RAM or multipliers | 16:49 |
| daveshah | Hmm, that's very impressive | 16:50 |
| daveshah | Particularly in terms of area which Yosys/ABC usually do quite badly on | 16:50 |
| whitequark | nice | 16:50 |
| ZirconiumX | My hunch is that it's the LUT4s that ABC is producing | 16:50 |
| lambda | daveshah: from what I can tell shared variables were never a very good pattern, but somehow very common anyway. The "one process, two clock edges" approach should've always worked and is cleaner in a few ways | 16:51 |
| ZirconiumX | Because an ALM can fit two independent LUT4s and two LUT5s that share only two terms | 16:51 |
| ZirconiumX | I don't think it's that ABC is doing particularly well here, rather that Quartus can pack the result efficiently | 16:51 |
| whitequark | what if you mark the LUTs as keep? | 16:52 |
| ZirconiumX | I don't have e.g. WYSIWYG primitive resynthesis enabled, so it should be treated as keep | 16:53 |
| *** dys has joined #yosys | 17:00 | |
| ZirconiumX | wq: Yeah, no difference to the Yosys results | 17:02 |
| whitequark | I see | 17:04 |
| *** az0re has joined #yosys | 17:05 | |
| ZirconiumX | I can try enabling resynthesis, if you're curious | 17:06 |
| whitequark | i am | 17:10 |
| ZirconiumX | ADV_NETLIST_OPT_SYNTH_WYSIWYG_REMAP | 17:12 |
| ZirconiumX | Memorable, ain't it? | 17:12 |
| *** vidbina_ has quit IRC | 17:13 | |
| *** N2TOH_US has quit IRC | 17:22 | |
| ZirconiumX | wq: slightly decreased area, slightly decreased Fmax. | 17:23 |
| ZirconiumX | (stats on same link) | 17:23 |
| whitequark | interesting | 17:24 |
| ZirconiumX | Reduced flops, though | 17:25 |
| ZirconiumX | Which is probably some level of sequential synthesis | 17:25 |
| *** dys has quit IRC | 17:59 | |
| daveshah | Yay, was a typo between vram1 and vram2 | 18:16 |
| daveshah | https://usercontent.irccloud-cdn.com/file/xz3AejOz/frame.png | 18:16 |
| *** strongsaxophone has quit IRC | 18:41 | |
| lambda | daveshah: awesome :D | 19:22 |
| gtw | Very cool! | 19:22 |
| cr1901_modern | nice... I forgot there was a free SNES HDL core | 19:24 |
| *** az0re has quit IRC | 19:31 | |
| ZirconiumX | Remind me again what BRAM transparency means? | 19:52 |
| daveshah | Transparent means that when you read from a address that is being written to in the same cycle as the read address arrived, the new rather than old data appears | 19:54 |
| ZirconiumX | If it's configurable, should I pick it or not? | 19:55 |
| daveshah | It can be configurable in Yosys too | 19:55 |
| ZirconiumX | Doesn't that then produce a parameter to instantiate? | 19:57 |
| daveshah | Yes | 19:58 |
| ZirconiumX | Unfortunately memory_bram doesn't tell me what the parameter is called | 19:59 |
| whitequark | ZirconiumX: the manual lists the parameter | 20:00 |
| ZirconiumX | whitequark: Where? It's not in command-reference-manual.tex | 20:02 |
| daveshah | It looks like the parameters for memory_bram created cells are indeed undocumented | 20:03 |
| whitequark | hm | 20:04 |
| whitequark | did I forget to put them in? apologie | 20:04 |
| whitequark | *apologies | 20:04 |
| *** strobokopp has joined #yosys | 20:07 | |
| ZirconiumX | It seems to be the RD_TRANSPARENT parameter? | 20:13 |
| daveshah | I think that is for $mem cells | 20:15 |
| daveshah | It is called TRANSPn for memory_bram created cells | 20:15 |
| daveshah | where n is the port | 20:15 |
| daveshah | *not the port, but the number given in the transp section in the config | 20:16 |
| ZirconiumX | transp 0 2 <-- this would have a TRANSP2? | 20:16 |
| daveshah | Yes | 20:16 |
| ZirconiumX | What about if `clocks` is configurable? | 20:17 |
| daveshah | clocks isn't configurable | 20:17 |
| daveshah | values greater than 1 are just different clock signals | 20:18 |
| daveshah | with 0 being unclocked | 20:18 |
| ZirconiumX | Yeah, but an MLAB read port can either be sync or async | 20:18 |
| daveshah | Then you need two different BRAM entries | 20:18 |
| ZirconiumX | Okay | 20:19 |
| *** az0re has joined #yosys | 20:24 | |
| *** Cerpin has quit IRC | 20:30 | |
| *** Cerpin has joined #yosys | 20:30 | |
| *** emeb_mac has joined #yosys | 20:55 | |
| *** npe has quit IRC | 20:58 | |
| ZirconiumX | Quartus is giving me a headache | 21:02 |
| ZirconiumX | It lets you build a 32x2 LUTRAM (as the documentation says) but only sometimes | 21:02 |
| *** N2TOH has joined #yosys | 21:07 | |
| *** jfcaron has quit IRC | 21:23 | |
| ZirconiumX | daveshah: Having problem mapping the ROM in attosoc; I have an async-read initialisable LUTRAM (that I'm using for testing) but memory_bram is giving up | 21:29 |
| daveshah | Yeah, the rom in attosoc doesn't map to bram | 21:30 |
| daveshah | It was a horrible pattern because at the time objcopy didn't write more than 8 bit inits | 21:30 |
| daveshah | And I cba to write a better was at the time ecp5 bram wasn't even supported | 21:31 |
| daveshah | *better way | 21:31 |
| ZirconiumX | Ugh; I need a testbench for BRAM init | 21:31 |
| daveshah | This newer attosoc variant should | 21:32 |
| daveshah | https://github.com/daveshah1/nextpnr-xilinx/tree/xilinx-upstream/xilinx/examples/attosoc | 21:32 |
| tpb | Title: nextpnr-xilinx/xilinx/examples/attosoc at xilinx-upstream · daveshah1/nextpnr-xilinx · GitHub (at github.com) | 21:32 |
| ZirconiumX | Yep, it does | 21:34 |
| *** twnqx has joined #yosys | 21:36 | |
| twnqx | is there a simple, yosys-friendly way to say "output 0 if the number of set bits is 0 or 1, output 1 else" with four inputs? | 21:38 |
| ZirconiumX | twnqx: Write a case, I suppose | 21:39 |
| ZirconiumX | Or else a small if/else chain | 21:39 |
| twnqx | thought so. ok | 21:40 |
| ZirconiumX | daveshah: So, uh, new attosoc doesn't boot under either Quartus or Yosys | 21:59 |
| daveshah | Are the LEDs half on by any chance? | 22:00 |
| ZirconiumX | No; under Quartus they are fully on, and under Yosys it gets to 2 and then freezes | 22:00 |
| daveshah | Oh, that's odd | 22:01 |
| ZirconiumX | No, it's even /s | 22:01 |
| daveshah | That is a simulation test I realise so it has no delay loop | 22:01 |
| daveshah | Try this firmware with it | 22:01 |
| daveshah | https://github.com/daveshah1/nextpnr-xilinx/blob/xilinx-upstream/xilinx/examples/zcu104/firmware.hex | 22:01 |
| tpb | Title: nextpnr-xilinx/firmware.hex at xilinx-upstream · daveshah1/nextpnr-xilinx · GitHub (at github.com) | 22:01 |
| daveshah | Note that one only uses 4 LEDs | 22:01 |
| ZirconiumX | That works | 22:04 |
| *** strobokopp has quit IRC | 22:08 | |
| ZirconiumX | Now I have the fun question of trying to figure out why RAM init is failing | 22:09 |
| ZirconiumX | Which is fairly tricky when there are encrypted simulation models | 22:10 |
| ZirconiumX | daveshah: How do I convert an integer into a hex string in Verilog? | 22:14 |
| daveshah | Some for loop monstrosity probably | 22:14 |
| ZirconiumX | The reason I ask is this hint: parameter mem_init0 = ""; | 22:15 |
| *** N2TOH has quit IRC | 22:49 | |
| *** N2TOH_ has joined #yosys | 22:50 | |
| *** X-Scale` has joined #yosys | 23:03 | |
| *** X-Scale has quit IRC | 23:03 | |
| *** X-Scale` is now known as X-Scale | 23:04 | |
| *** twnqx has quit IRC | 23:06 | |
| *** develonepi3 has joined #yosys | 23:17 | |
| *** develonepi3 has left #yosys | 23:20 | |
| *** dxld has quit IRC | 23:31 | |
| *** dxld has joined #yosys | 23:33 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
