| *** tpb has joined #yosys | 00:00 | |
| promach_ | finnb : use your own local installed iverilog | 01:06 |
|---|---|---|
| promach_ | finnb: if I use reg [(NUM_OF_INTERMEDIATE_LAYERS-1):0] middle_layers [0:(SMALLER_WIDTH-1)] [(A_WIDTH+B_WIDTH-1):0]; , yosys-smtbmc gives me out-of-bound array access warnings | 01:08 |
| promach_ | ZipCPU: is it true that yosys-smtbmc does not support reg [A-1:0][B-1:0][C-1:0] array; ? | 01:25 |
| ZipCPU | yosys gives you the error, or yosys-smtbmc? | 01:27 |
| promach_ | ZipCPU: sby | 01:28 |
| ZipCPU | Sigh. That doesn't answer the question. To my knowledge, yosys itself doesn't support multi-dimensional arrays | 01:28 |
| promach_ | ZipCPU: ok, so I cannot do formal verification of this code using sby ? | 01:29 |
| ZipCPU | I'm not even sure the SMT format supports multidimensional memories | 01:29 |
| ZipCPU | Perhaps this isn't a memory? | 01:30 |
| promach_ | huh ? it is still a 3d array, whether it is memory or not | 01:32 |
| promach_ | ZipCPU: I thought the only difference noticeable by the tool is either the array is packed or unpacked | 01:33 |
| *** promach_ has quit IRC | 01:36 | |
| *** emeb_mac has joined #yosys | 01:42 | |
| *** emeb has quit IRC | 01:49 | |
| *** X-Scale` has joined #yosys | 02:00 | |
| *** X-Scale has quit IRC | 02:01 | |
| *** X-Scale` is now known as X-Scale | 02:01 | |
| *** gsi_ has joined #yosys | 02:26 | |
| *** gsi__ has quit IRC | 02:29 | |
| *** xdeller_ has quit IRC | 03:04 | |
| *** xdeller_ has joined #yosys | 03:05 | |
| *** proteusguy has joined #yosys | 03:37 | |
| *** leviathanch has joined #yosys | 03:49 | |
| *** jevinskie has joined #yosys | 04:08 | |
| *** rohitksingh_work has joined #yosys | 04:30 | |
| *** pie__ has joined #yosys | 04:37 | |
| *** pie___ has quit IRC | 04:41 | |
| *** dys has quit IRC | 06:44 | |
| *** emeb_mac has quit IRC | 06:57 | |
| *** dys has joined #yosys | 08:07 | |
| *** rohitksingh_work has quit IRC | 08:08 | |
| *** rohitksingh_work has joined #yosys | 08:09 | |
| *** dys has quit IRC | 08:22 | |
| *** m4ssi has joined #yosys | 08:57 | |
| *** X-Scale` has joined #yosys | 09:07 | |
| *** X-Scale has quit IRC | 09:09 | |
| *** X-Scale` is now known as X-Scale | 09:09 | |
| *** leviathanch has quit IRC | 09:21 | |
| *** rohitksingh_work has quit IRC | 11:21 | |
| *** rohitksingh has joined #yosys | 12:13 | |
| *** rohitksingh has quit IRC | 12:58 | |
| *** rohitksingh has joined #yosys | 14:26 | |
| somlo | daveshah: I haven't taken care of the uart's "back-pressure" wait signal -- in the attosoc setup it effectively stalls the mmio write, but with the rocket, through the layers of AXI interfaces, there's no simple way to do that from where I hooked it up | 14:32 |
| daveshah | I found the problem with the UART. It was actually the PLL's feedback config being wrong, throwing the freq off | 14:33 |
| somlo | so we'd have to add some sort of buffering to get all the uart output queued up properly | 14:33 |
| daveshah | https://github.com/daveshah1/yoloRISC | 14:33 |
| tpb | Title: GitHub - daveshah1/yoloRISC: porting lowRISC to yosys/nextpnr/trellis on the Lattice ECP5 fpga (at github.com) | 14:33 |
| somlo | ah, I redid the pll and started the compilation last night, then went home -- so I just got back and was going to try it out :) | 14:33 |
| daveshah | Compile time should be down to 15 minutes synth and PnR with that analytic placer PR | 14:34 |
| somlo | and yeah, tweet away if you think it's worth it :) | 14:34 |
| somlo | was going to try that today too | 14:34 |
| somlo | all we need now is a DRAM controller and we can have a self-hosting Linux computer that can fully recompile its own "hardware" | 14:35 |
| * sxpert wonders why we keep using Dram on those fpga boards, when srams are so cheap | 14:41 | |
| daveshah | sxpert: SRAM is much more expensive for a given capacity | 14:41 |
| sxpert | I see | 14:41 |
| sxpert | and dram is a PITA to work with | 14:42 |
| daveshah | SDRAM is fine | 14:42 |
| daveshah | it's the more modern DRAMs that are a pain (but the fancier modern SRAMs are not super easy either) | 14:42 |
| daveshah | But largest available SRAM (288Mbit) is ~$300, whereas 1Gbit of DDR3 is ~$3 (single quantity pricing) | 14:44 |
| daveshah | so you can see why DRAM becomes preferable | 14:44 |
| sxpert | ah, I see indeed | 14:45 |
| sxpert | I understand that SRAM is much lower power | 14:46 |
| sxpert | so that may be preferable for a portable app | 14:46 |
| daveshah | In practice large SRAMs are performance optimised and pretty power hungry | 14:47 |
| daveshah | smartphones manage fine with low power DRAM | 14:47 |
| sxpert | my app would need about 1MB of ram | 14:47 |
| daveshah | That is definitely SRAM territory | 14:48 |
| daveshah | or perhaps HyperRAM, which is DRAM with a simpler and lower pin count interface | 14:48 |
| sxpert | found some at digikey that would fit with 60mA consumption or so, for 5€ | 14:49 |
| daveshah | That seems like a lot of current for SRAM | 14:50 |
| sxpert | or maybe I didn't read that properly ;) | 14:51 |
| *** Cerpin has joined #yosys | 14:51 | |
| sxpert | was looking at this one http://www.issi.com/WW/pdf/61-64WV51216EDBLL.pdf | 14:58 |
| sxpert | or that one, don't remember http://www.issi.com/WW/pdf/61-64WV51216EDBLL.pdf | 14:59 |
| sxpert | daveshah: anyhow, getting ahead of myself... last night I heeded your advice and rewrote most of the code I had | 15:07 |
| *** FL4SHK has quit IRC | 15:15 | |
| MoeIcenowy | daveshah: does HyperRAM have self-refresh? | 15:17 |
| daveshah | Yes, it does | 15:17 |
| sxpert | https://www.digikey.com/products/en?keywords=hyperram | 15:19 |
| sxpert | not much choice there though | 15:19 |
| sxpert | funny how that looks strangely similar to what is described in the saturn CPU docs ;) | 15:21 |
| somlo | daveshah: how did you come up with the pll parameters? I just ran ecppll from the command line and got something different (which btw, doesn't work :) ) | 15:24 |
| daveshah | I ended up using Diamond | 15:24 |
| somlo | oh, fair enough :) | 15:24 |
| *** rohitksingh has quit IRC | 15:35 | |
| somlo | daveshah: what does uart_dbg do on the versa5g? | 15:47 |
| daveshah | That connects to pin 4 on X3 (EXPCON1), so I could look at the UART with a logic analyser | 15:47 |
| somlo | semi-related: dropping down to 9600 baud helps avoid overwhelming the UART, or was that accomplished just by fixing the pll? (I *still* haven't recompiled it, just studying your changes :) | 15:51 |
| *** rohitksingh has joined #yosys | 15:53 | |
| somlo | daveshah: oh, I see you added a 2000 delay in putchar, that's probably what avoids dealing with the "wait" signal :) | 15:55 |
| daveshah | The 9600 was a test in case the baud rate accuracy of 115200 at 10MHz was too poor | 15:57 |
| daveshah | 115200 should be fine now too | 15:57 |
| MoeIcenowy | oops | 15:58 |
| MoeIcenowy | hyperram seems to be bga | 15:58 |
| *** AlexDaniel has joined #yosys | 15:59 | |
| daveshah | MoeIcenowy: yeah, if you don't want BGA then QSPI PSRAM is the best bet | 16:00 |
| *** rohitksingh has quit IRC | 16:17 | |
| *** finnb has joined #yosys | 16:26 | |
| finnb | Any idea what this yosys error message means? | 16:27 |
| finnb | https://pastebin.com/7K2aKn08 | 16:27 |
| tpb | Title: ERROR: Found error in internal cell \mandelbrot.$lt$projects/mandelbrot/hdl/mand - Pastebin.com (at pastebin.com) | 16:27 |
| daveshah | finnb: Seems to be signedness related | 16:29 |
| daveshah | https://github.com/YosysHQ/yosys/blob/master/kernel/rtlil.cc#L733 | 16:29 |
| tpb | Title: yosys/rtlil.cc at master · YosysHQ/yosys · GitHub (at github.com) | 16:29 |
| daveshah | quite possibly an internal bug in the frontend or optimisation | 16:30 |
| finnb | interesting | 16:35 |
| finnb | I basically have a value which is "if foo > -BAR" where localparam BAR = $sqrt(BAZ) | 16:36 |
| finnb | where foo is a signed register | 16:36 |
| finnb | I can solve it if I calculate manually what BAR is | 16:36 |
| finnb | i.e BAR = 64 | 16:37 |
| ddrown | what about -1*BAR | 16:42 |
| finnb | Only seems a problem when using $sqrt | 16:49 |
| daveshah | Let me have a look | 16:49 |
| daveshah | Seems like a Yosys bug | 16:49 |
| finnb | https://pastebin.com/dwE69hKX | 16:56 |
| tpb | Title: escaped_i[0] <= ((im + im_c_pipe[WIDTH + 1]) > MAX_SQUARE) - Pastebin.com (at pastebin.com) | 16:56 |
| finnb | that's the actual part which fails | 16:56 |
| finnb | where MAX_SQUARE is -BAR in my example | 16:57 |
| daveshah | finnb: I've created https://github.com/YosysHQ/yosys/issues/807 | 17:00 |
| tpb | Title: "Found error in internal cell" when comparing signed against negated square root · Issue #807 · YosysHQ/yosys · GitHub (at github.com) | 17:00 |
| finnb | Thanks :) | 17:01 |
| finnb | so it wasn't just me then | 17:01 |
| cr1901_modern | Excellent daveshah :) https://github.com/YosysHQ/nextpnr/pull/228 Unfortunately I kinda forgot why I wanted this in the first place (it's been a busy month) :P | 17:13 |
| tpb | Title: ecp5: Embed baseconfigs in nextpnr by daveshah1 · Pull Request #228 · YosysHQ/nextpnr · GitHub (at github.com) | 17:14 |
| *** m4ssi has quit IRC | 17:14 | |
| *** jevinskie has quit IRC | 17:29 | |
| *** finnb has quit IRC | 17:34 | |
| *** rohitksingh has joined #yosys | 18:45 | |
| *** m4ssi has joined #yosys | 18:55 | |
| *** m4ssi has quit IRC | 18:56 | |
| *** rohitksingh has quit IRC | 19:00 | |
| *** m4ssi has joined #yosys | 19:03 | |
| *** m4ssi has quit IRC | 20:09 | |
| somlo | daveshah: after getting derailed several times by unrelated dayjob stuff, I finally managed to test the rocket-chip blinky bitstream, and (spoiler alert) -- it works! :) | 21:29 |
| somlo | amazing how I could just throw rocket at yosys/trellis/nextpnr and it "Just Worked", practically out of the box -- awesome toolchain, many thanks for your hard work on it!!! | 21:30 |
| daveshah | Awesome | 21:31 |
| daveshah | Thanks for your work getting this running too! | 21:31 |
| somlo | next on the agenda is for me to take nextpnr PR#219 for a spin, and report back some additional before/after run time datapoints | 21:33 |
| *** dys has joined #yosys | 21:43 | |
| sxpert | I have 2 20 bits reg, how can I do an unsigned >= ? | 22:05 |
| *** mjoldfield has quit IRC | 22:19 | |
| ZipCPU | sxpert: The same way as always? | 23:12 |
| ZipCPU | I must be missing something | 23:12 |
| sxpert | nah, I was ;-) | 23:15 |
| sxpert | the thing ended up being replaced with a bunch of assign and wires | 23:15 |
| sxpert | and substractions, grabbing the carry | 23:17 |
| ZipCPU | Cool! You are on your way | 23:17 |
| * ZipCPU is writing a blog article about how fast a CPU can toggle a GPIO pin | 23:17 | |
| sxpert | https://github.com/sxpert/hp-saturn/blob/master/hp48_02_sys_ram.v | 23:18 |
| tpb | Title: hp-saturn/hp48_02_sys_ram.v at master · sxpert/hp-saturn · GitHub (at github.com) | 23:18 |
| sxpert | see here ;-) | 23:18 |
| ZipCPU | Are you working off your own bus standard, or one of the ones I'm less familiar with? | 23:18 |
| sxpert | ZipCPU: I'm replicating an HP48, so I'm replicating the bus it uses internally | 23:19 |
| ZipCPU | You know what I'm going to recommend, right? ;) | 23:20 |
| sxpert | nope | 23:20 |
| ZipCPU | I'm going to recommend you build a file containing formal properties associated with any bus interaction. You can then include that file in any design that interacts with the bus and verify that the bus acts "appropriately" (whatever that means) | 23:20 |
| ZipCPU | It's an easy/cheap bang for your buck, and one of the easiest and most useful bits of formal to do | 23:21 |
| sxpert | oh, I rewrote the thing from scratch over the evening last night | 23:21 |
| ZipCPU | Add in the formal properties .... you'll go faster | 23:22 |
| sxpert | and separated bus and decoder as much as possible | 23:22 |
| sxpert | it was going faster at last compile, 120Mhz or so | 23:22 |
| ZipCPU | Which chip? iCE40? | 23:22 |
| sxpert | ESP5 | 23:23 |
| ZipCPU | Nice | 23:23 |
| ZipCPU | Have you ever tried the formal tools? | 23:23 |
| sxpert | nope | 23:23 |
| ZipCPU | Your missing a real treat | 23:23 |
| sxpert | hah | 23:24 |
| ZipCPU | If you save them for later, though, you'll be missing out on their biggest utility | 23:24 |
| ZipCPU | Some folks like the idea of building a design, then verifying it. On the other hand, if you use formal while building your design, it gets a whole lot easier to design | 23:24 |
| sxpert | my formal method is paper & pen | 23:24 |
| sxpert | and lots of scribbling | 23:24 |
| ZipCPU | Mine used to be a test bench wrapper and simulation. Then I tried formal, and realized how many bugs I'd been missing. | 23:25 |
| ZipCPU | After getting *REALLY* burned by some ugly bugs that were painful to find in hardware, I've been starting with formal. *Especially* for any sort of bus interaction. | 23:25 |
| sxpert | well the bus interaction is entirely inside the fpga, between modules | 23:26 |
| sxpert | not with outside things for now | 23:26 |
| ZipCPU | Well, both | 23:26 |
| ZipCPU | The problem with a bus bug is that it tends to cause the design to freeze and lock up hard, leaving you with no idea what just happened | 23:26 |
| ZipCPU | Getting unstuck from there can take a lot of work. Formal can keep that from happening in the first place | 23:27 |
| sxpert | yeah | 23:27 |
| sxpert | I did the classic 4 phase clocking here | 23:27 |
| ZipCPU | Here, try this bug story out for size: http://zipcpu.com/zipcpu/2017/12/28/ugliest-bug.html | 23:28 |
| tpb | Title: Mystery post: The ugliest bug I've ever encountered (at zipcpu.com) | 23:28 |
| ZipCPU | See if you can guess where the bug was (it's revealed at the end) | 23:28 |
| sxpert | I see | 23:43 |
| ZipCPU | Since writing that, I discovered formal. Finding and fixing that bug was quite painful. I prefer avoiding such pain, if at all possible. ;) | 23:44 |
| sxpert | well, nextpnr complains about there beeing combinatorial loops... | 23:44 |
| sxpert | ahem | 23:44 |
| ZipCPU | Lol | 23:45 |
| sxpert | last time around it was using 600 slices, it uses 43000 now, wtf ? | 23:47 |
| ZipCPU | What uses 43k? Your design? | 23:47 |
| ZipCPU | Check your multiplies | 23:47 |
| sxpert | yeah | 23:48 |
| sxpert | no multiplies | 23:48 |
| ZipCPU | That and any block RAM | 23:48 |
| sxpert | ah | 23:48 |
| sxpert | that may be the issue | 23:48 |
| sxpert | I have reg [3:0]sys_ram [0:SYS_RAM_LEN - 1]; | 23:48 |
| ZipCPU | How big is SYS_RAM_LEN/ | 23:48 |
| ZipCPU | ? | 23:48 |
| sxpert | normally should be 256k 4 bit values | 23:49 |
| sxpert | I limited to 64k at this time | 23:49 |
| ZipCPU | Oh, and why only 4-bits wide? Some block RAM's (iCE40) have a minimum width of 16 bits or so | 23:49 |
| sxpert | oh ! | 23:49 |
| daveshah | ECP5 BRAM are fine at 4 bits | 23:50 |
| daveshah | I'm pretty sure iCE40 are too | 23:50 |
| daveshah | It's bitstream configurable | 23:50 |
| sxpert | guess it didn't generate blockrams for that | 23:50 |
| ZipCPU | daveshah: Do you remember what some of the block RAM synthesis problems are that someone might find with an ECP5? | 23:51 |
| sxpert | is there a magic incantation ? | 23:51 |
| daveshah | The most common problem would be more than one write port | 23:51 |
| daveshah | Or possibly excessively complex read/write enable logic | 23:51 |
| ZipCPU | Do the write and read ports need to share a common address? | 23:51 |
| daveshah | Not in the modes that Yosys supports | 23:52 |
| sxpert | daveshah: all writes are in the same always () | 23:52 |
| sxpert | at only one location even | 23:52 |
| daveshah | In that case it's probably https://github.com/YosysHQ/yosys/issues/710 | 23:53 |
| tpb | Title: Yosys fails to infer BRAM with complex enable logic · Issue #710 · YosysHQ/yosys · GitHub (at github.com) | 23:53 |
| daveshah | Looking at your code the BRAM access is deep inside a state machine | 23:53 |
| ZipCPU | Ok, that's the problem | 23:53 |
| daveshah | Yosys can struggle with that sometimes | 23:53 |
| sxpert | ah | 23:53 |
| ZipCPU | You can't place multiple block RAM reads from the same block RAM into an always block | 23:53 |
| sxpert | I see | 23:54 |
| * sxpert refactors | 23:54 | |
| * sxpert adds more enable wires | 23:56 | |
| ZipCPU | sxpert: Check out the basic block RAM rules in this tutorial file: http://zipcpu.com/zipcpu/2017/12/28/ugliest-bug.html | 23:58 |
| tpb | Title: Mystery post: The ugliest bug I've ever encountered (at zipcpu.com) | 23:58 |
| ZipCPU | Sorry, wrong link | 23:58 |
| ZipCPU | Here: http://zipcpu.com/tutorial/lsn-08-memory.pdf | 23:58 |
| ZipCPU | Rule #3: Don't put a RAM in a cascaded if (or case statement for that matter) | 23:59 |
| ZipCPU | Rule #5: Don't put a RAM in a block with other things--not all synthesizers can handle it | 23:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!