| *** tpb has joined #yosys | 00:00 | |
| *** emeb_mac has joined #yosys | 00:11 | |
| *** _whitelogger has quit IRC | 00:46 | |
| *** _whitelogger has joined #yosys | 00:48 | |
| *** digshadow has joined #yosys | 01:10 | |
| *** promach_ has joined #yosys | 01:33 | |
| *** develonepi3 has quit IRC | 02:16 | |
| *** emeb has quit IRC | 02:17 | |
| *** promach_ has quit IRC | 03:42 | |
| *** roh has quit IRC | 03:48 | |
| *** promach_ has joined #yosys | 03:59 | |
| *** roh has joined #yosys | 04:32 | |
| *** _whitelogger has quit IRC | 04:43 | |
| *** _whitelogger has joined #yosys | 04:45 | |
| *** dys has quit IRC | 05:18 | |
| *** promach_ has quit IRC | 05:49 | |
| *** promach_ has joined #yosys | 05:52 | |
| *** emeb_mac has quit IRC | 06:16 | |
| *** leviathan has joined #yosys | 06:55 | |
| *** xerpi has joined #yosys | 07:18 | |
| *** dys has joined #yosys | 08:59 | |
| *** philtor has quit IRC | 09:54 | |
| *** xerpi has quit IRC | 11:39 | |
| *** philtor has joined #yosys | 11:48 | |
| *** promach_ has quit IRC | 12:14 | |
| *** develonepi3 has joined #yosys | 12:22 | |
| *** promach_ has joined #yosys | 12:29 | |
| cr1901_modern | knielsen: How difficult would it be to add bram to your viewer? B/c I have an ice40 design that crashes if I breathe wrong, and I'd like to know why. | 13:52 |
|---|---|---|
| cr1901_modern | And it makes much use of brams | 13:52 |
| *** oldtopman has quit IRC | 13:55 | |
| *** emeb_mac has joined #yosys | 14:09 | |
| *** oldtopman has joined #yosys | 14:28 | |
| *** dxld has quit IRC | 14:35 | |
| *** dxld has joined #yosys | 14:37 | |
| *** AlexDani` has joined #yosys | 14:48 | |
| *** AlexDaniel has quit IRC | 14:50 | |
| *** AlexDani` is now known as AlexDaniel | 14:54 | |
| *** dxld has quit IRC | 14:56 | |
| *** dxld has joined #yosys | 15:03 | |
| knielsen | cr1901_modern: It shouldn't be difficult at such. It's mostly just a lot of details, getting all the coordinates for the wires and annotations right | 15:32 |
| knielsen | cr1901_modern: The main issue with brams is probably just finding a good way to present all the information. There are a lot of wires and configurations for a bram, and IIRC it spans two tiles, etc. | 15:32 |
| cr1901_modern | I've switched back to icecube for now for this | 15:33 |
| cr1901_modern | btw, anyone know how to specify a memory initialization file to synplify pro? | 15:33 |
| daveshah | cr1901_modern: is readmemh not working? | 15:34 |
| cr1901_modern | daveshah: still have that 5k top-level I asked you to compile in icecube? | 15:34 |
| daveshah | cr1901_modern: let me look | 15:35 |
| daveshah | I used LSE though | 15:35 |
| cr1901_modern | In any case; @W: CG371 :"C:\msys64\home\William\src\tinyfpga-soc\archive\build-132e503\gateware\top.v":851:1:851:9|Cannot find data file mem.init for task $readmemh | 15:35 |
| knielsen | cr1901_modern: is icecube lattice's "official" ice40 development tool? Does it also have a layout viewer? | 15:35 |
| daveshah | I don't think I had any initialised memory though | 15:35 |
| cr1901_modern | knielsen: yes | 15:35 |
| daveshah | knielsen: yeah, it has a floorplan viewer but no routing viewer | 15:36 |
| cr1901_modern | daveshah: actually you probably did | 15:36 |
| daveshah | The new tool for the UltraPlus only, Radiant, has limited routing views | 15:36 |
| cr1901_modern | for the version tag | 15:36 |
| daveshah | cr1901_modern: ah | 15:36 |
| knielsen | ok, I see | 15:36 |
| daveshah | BTW, you know ice40 initialised memories don't work for a few us after power up | 15:36 |
| daveshah | but I think you hold it in reset for a bit anyway | 15:37 |
| cr1901_modern | yes, but the device is held in reset for 4096 cycles | 15:37 |
| daveshah | that'll be fine then | 15:37 |
| cr1901_modern | https://hastebin.com/urupomacik.diff This is enough of a diff to change a nonfunctional bitstream to a functional one | 15:37 |
| cr1901_modern | and this is _without_ the spiflash1 | 15:38 |
| cr1901_modern | None of this makes sense | 15:38 |
| daveshah | cr1901_modern: can't immediately find the 5k project or top level | 15:38 |
| cr1901_modern | nevermind then | 15:38 |
| daveshah | a small change will peturb the net naming and thus pnr | 15:38 |
| daveshah | effectively pnr is chaotic | 15:38 |
| cr1901_modern | why the hell is that/1 | 15:39 |
| cr1901_modern | Why is adding a single net change pnr so much? | 15:39 |
| daveshah | because it is simulated annealing, and heavily based on randomness | 15:39 |
| daveshah | adding a single net is effectively the same as using a different seed | 15:40 |
| cr1901_modern | Why?! | 15:40 |
| daveshah | because it will change the rng state a bit | 15:40 |
| cr1901_modern | It doesn't store the nets in a huge array in (mostly) the same order each initialization? | 15:40 |
| daveshah | that doesn't change the fact the rng state has been upset | 15:40 |
| cr1901_modern | Why are the nets part of the seed then? | 15:41 |
| * cr1901_modern grumbles | 15:41 | |
| daveshah | they aren't | 15:41 |
| tinyfpga | cr1901_modern: this is how it works in many, many tools | 15:41 |
| daveshah | cr1901_modern: this is ultimately down to the basics of a random number generator | 15:42 |
| daveshah | if you take e.g. one more number from a rng, then that will change the state totally forever more | 15:42 |
| daveshah | (for an ideal rng) | 15:42 |
| * cr1901_modern grumbles | 15:42 | |
| daveshah | *prng | 15:42 |
| cr1901_modern | Then I'm never going to find out why it's crashing at this rate | 15:42 |
| daveshah | could be a metastability/timing issue | 15:43 |
| cr1901_modern | It's 16MHz clk, the design passes timing at nearly twice that | 15:44 |
| daveshah | yes, but that doesn't consider metastability issues with external devices e.g. SPI | 15:44 |
| cr1901_modern | okay, so I just remembered something... I was able to change some net routing and duplicate the crash in the SPI bitstream; the CPU locks up b/c it attempts to access nonexistant address | 15:45 |
| *** xerpi has joined #yosys | 15:46 | |
| cr1901_modern | if I modify the verilog file so that that nonexistent addr mirrors the SPI flash, the CPU continues but refuses to honor jumps | 15:46 |
| daveshah | yes, I think that's the behaviour I saw on the ultraplus | 15:46 |
| daveshah | I was seeing that consistently across design modifications and seeds though | 15:47 |
| daveshah | and, if my test wasn't broken, also consistent between ys and icecube | 15:47 |
| cr1901_modern | I am really quite fed up w/ how uncooperative this is being. post-synthesis sim does not give any useful info. pre-synthesis says the design should work | 15:50 |
| daveshah | what is happening in post-synthesis sim? | 15:50 |
| cr1901_modern | https://twitter.com/cr1901/status/1004940561168654337 | 15:51 |
| cr1901_modern | Come to think of it, I can't remember what happens if I forcefully enable r0 init | 15:52 |
| daveshah | that's odd - all the real ice40 registers init to 0 | 15:52 |
| daveshah | so I'm not sure why post-synthesis doesn't match that | 15:52 |
| cr1901_modern | b/c yosys stores them in bram | 15:52 |
| daveshah | hmm, that is still initialised to 0 at reset | 15:53 |
| cr1901_modern | not according to what yosys generates :) | 15:53 |
| cr1901_modern | it initializes everything to xxxxxxxxx | 15:53 |
| daveshah | ah, I see, yosys outputs `.INIT_0(256'hxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx),` | 15:54 |
| daveshah | etc | 15:54 |
| daveshah | in the post-synthesis netlist | 15:54 |
| daveshah | possibly a bug | 15:54 |
| cr1901_modern | Well I didn't find anything in the mem usage guide for ice40 to suggest they get initialized to 0 | 15:55 |
| cr1901_modern | it's not like I didn't check | 15:55 |
| cr1901_modern | except for, ya know, actually generating a bitstream and checking | 15:55 |
| daveshah | yeah, looks like they might need to be explicitly set to zero in a bitstream actually | 15:56 |
| daveshah | yosys probably does that for brams not specifically initialised to zero to keep the bitstream smaller | 15:56 |
| cr1901_modern | Well, not sure how to debug the current crash if I can't duplicate it... | 16:01 |
| cr1901_modern | Especially considering the design uses 2500 LUTs and it's not like I can just rip out nets/wires at will | 16:06 |
| cr1901_modern | maybe if yosys/a simulator had a "show which wires were unused for the duration of the simulation and rip them out" feature | 16:07 |
| daveshah | It's a really weird one | 16:14 |
| daveshah | One thing to do is a post PAR simulation | 16:15 |
| daveshah | Use icebox_vlog to back from the asc file to Verilog | 16:15 |
| cr1901_modern | That would've helped me a few days ago, although I don't see how it's possible to represent PAR info in Verilog | 16:18 |
| cr1901_modern | (unless the idea is to "remove all the intermediate nets") | 16:18 |
| *** pie_ has joined #yosys | 16:19 | |
| cr1901_modern | One thing that I wish verilog could determine (but I understand why it can't) is whether two nets with value "x" originate from the same place. "x ^ x" would in fact equal 0 in that case. | 16:23 |
| cr1901_modern | actually, I don't know why the CPU ever works at all, tbh. >> | 16:23 |
| cr1901_modern | registers are placed into a BRAM by default initialized to "x" | 16:23 |
| cr1901_modern | dual port register means the read port is duplicated between two BRAMs | 16:23 |
| cr1901_modern | meaning two copies of registers | 16:24 |
| cr1901_modern | whose to say that "r0" in one BRAM will be initialized to one value, and "r0" in the other value will take on another random value | 16:24 |
| cr1901_modern | so "xor r0, r0, r0" doesn't actually zero out register | 16:24 |
| cr1901_modern | https://www.eevblog.com/forum/microcontrollers/lattice-ice40-ultra-internal-oscillator/ | 16:34 |
| tpb | Title: Lattice iCE40 Ultra internal oscillator - Page 1 (at www.eevblog.com) | 16:34 |
| cr1901_modern | small world | 16:34 |
| cr1901_modern | Oh and synplify can't seem to route the "spiflash-free" design for some reason | 16:34 |
| daveshah | cr1901_modern: yeah, the intermediate nets aren't represented in the verilog but just dumped as comments | 16:39 |
| cr1901_modern | And LSE can't meet constraints... | 16:40 |
| daveshah | this is all pretty crazy for a design based on a nominally lattice processor | 16:41 |
| cr1901_modern | Well, tbf, I had the wrong top level. Now synthesis is just taking forever now and eating 1+GB RAM | 16:47 |
| cr1901_modern | This is very much the worst bug I've ever encountered. Period. | 16:48 |
| cr1901_modern | Yup, LSE just hangs. I can't deal w/ this shit right now. | 16:51 |
| daveshah | ZipCPU would call it FPGA Hell | 16:51 |
| cr1901_modern | Yea, it might be a good laugh in about 2 years but it's not funny now | 16:51 |
| daveshah | it's weird to find a seemingly (similar things work on other platforms) working design that is broken in Yosys, LSE and Synplify | 16:51 |
| ZipCPU | Does the design work in simulation? | 16:52 |
| cr1901_modern | Yes | 16:52 |
| ZipCPU | Which simulator? | 16:52 |
| cr1901_modern | iverilog | 16:52 |
| ZipCPU | How much of the design works? | 16:52 |
| cr1901_modern | well, yosys creates a bitstream which crashes immediately, Synplify hangs during PAR, and LSE can't synthesize the damn thing | 16:53 |
| cr1901_modern | like "I have to go to task manager and forcefully exit" can't synthesize | 16:54 |
| ZipCPU | Can you verilate the design? With -Wall and -cc? That often finds a lot of my bugs | 16:54 |
| cr1901_modern | No b/c verilator refuses to compile | 16:54 |
| cr1901_modern | Well, I'll compile it on my Linux box | 16:55 |
| daveshah | cr1901_modern: the LSE Issue is probably because it fails to infer blockram so the ram explodes into tens or hundreds of thousands of LCs and FFs | 16:55 |
| daveshah | it's something I've seen before | 16:55 |
| cr1901_modern | I have the RAM option set to "infer BRAM" | 16:55 |
| daveshah | yes, but LSE often fails nonetheless | 16:56 |
| daveshah | it's its weak point | 16:56 |
| cr1901_modern | Then why did it succeed on your machine? | 16:57 |
| daveshah | could be the caches that are xploding? I didn't have them enabled | 16:57 |
| cr1901_modern | I don't have them enabled either | 16:57 |
| daveshah | ah, I've found the project | 16:58 |
| cr1901_modern | finally some good news T_T | 16:58 |
| daveshah | I was using LSE | 16:59 |
| daveshah | looks like I ripped out the ram though | 17:00 |
| daveshah | and replaced it with manually instantiated ultraplus ram as a test | 17:00 |
| cr1901_modern | you prob had spiflash enabled too | 17:00 |
| daveshah | seems I overwrote the original top level module during testing | 17:00 |
| daveshah | but I would have ripped out the ram because LSE couldn't cope with it | 17:00 |
| cr1901_modern | at least I'm pretty sure that's the file I gave you | 17:00 |
| daveshah | yeah, defo had SPI flash enabled because that's what I was probing | 17:01 |
| cr1901_modern | ZipCPU: FYI, I can create a failing bitstream w/ a change as small as this: https://hastebin.com/urupomacik.diff | 17:06 |
| ZipCPU | Can you tell if the BRAM's are being inferred properly? | 17:08 |
| ZipCPU | Should be in the yosys output before arachne-pnr | 17:08 |
| cr1901_modern | Yes | 17:08 |
| cr1901_modern | They are | 17:08 |
| cr1901_modern | (well, the registers BRAM anyway. lemme check the other) | 17:09 |
| *** promach_ has quit IRC | 17:09 | |
| ZipCPU | Is your design on github at all? I have a working verilator version, perhaps I might see something? | 17:10 |
| cr1901_modern | Can you give me a few minutes to set it up please? | 17:11 |
| ZipCPU | If you wish | 17:12 |
| cr1901_modern | In any case, I've confirmed brams are correctly inferred | 17:13 |
| *** dys has quit IRC | 17:20 | |
| cr1901_modern | ZipCPU: https://github.com/cr1901/misoc-lm32-sim "make TARGET=tinyfpga-soc-no-trigger sim" and "make TARGET=tinyfpga-soc-no-trigger sim-post-synth" will get you started | 17:47 |
| tpb | Title: GitHub - cr1901/misoc-lm32-sim: Testing LiteX LM32 SoCs for bugs using Verilog simulation. (at github.com) | 17:47 |
| cr1901_modern | I'd love to abstract away the simulator used, but I'm not familiar enough w/ Verilator to know how to do this | 17:47 |
| ZipCPU | Hmm ... do I need to pull in lm32_cpu from somewhere? | 17:51 |
| cr1901_modern | git submodule init (sorry) | 17:51 |
| ZipCPU | then what? | 17:53 |
| cr1901_modern | Try "make TARGET=tinyfpga-soc-no-trigger sim" | 17:53 |
| ZipCPU | Sorry, don't have lm32-elf-* tools installed | 17:54 |
| ZipCPU | Can't I just build the verilog somewhere? | 17:54 |
| cr1901_modern | You shouldn't need lm32-elf* tools installed. The verilog is in the repo | 17:54 |
| *** develonepi3 has quit IRC | 17:55 | |
| cr1901_modern | https://github.com/cr1901/misoc-lm32-sim/blob/master/targets/tinyfpga-soc-no-trigger/tinyfpga-soc-no-trigger.v | 17:55 |
| tpb | Title: misoc-lm32-sim/tinyfpga-soc-no-trigger.v at master · cr1901/misoc-lm32-sim · GitHub (at github.com) | 17:55 |
| cr1901_modern | https://github.com/cr1901/misoc-lm32-sim/blob/master/targets/tinyfpga-soc-no-trigger/gateware/top.v | 17:55 |
| tpb | Title: misoc-lm32-sim/top.v at master · cr1901/misoc-lm32-sim · GitHub (at github.com) | 17:55 |
| ZipCPU | Can't find lm32_cpu.v | 17:55 |
| cr1901_modern | I just made a Makefile to automate all the files you pass to the simulator | 17:56 |
| cr1901_modern | "git submodule update" should bring down the files for you | 17:56 |
| ZipCPU | Let me try that | 17:56 |
| ZipCPU | Ahh ... that's probably what I was missing | 17:56 |
| cr1901_modern | Apologies lol. I need to get better w/ git's easy-and-intuitive UI | 17:57 |
| ZipCPU | I might be seeing something already | 17:58 |
| cr1901_modern | the traces for no-trigger and trigger (pre-synth) are identical for me (minus the trigger signal) | 18:00 |
| *** xerpi has quit IRC | 18:00 | |
| ZipCPU | https://gist.github.com/ZipCPU/ef88a1c60854d6b483fca3a74edbcf90 | 18:01 |
| tpb | Title: Verilator output · GitHub (at gist.github.com) | 18:01 |
| ZipCPU | The delayed assignments in non-clocked blocks are likely to cause the synthesizer problems ... among the other things there | 18:01 |
| cr1901_modern | Oh, that's the top-level simulation file | 18:02 |
| cr1901_modern | wait... no it's not | 18:02 |
| cr1901_modern | I lied :P | 18:02 |
| ZipCPU | You've also got a lot of signal definitions not found. I'd recommend adding the line: "`default_nettype none" to your source files. | 18:02 |
| ZipCPU | That can mask other bugs | 18:03 |
| ZipCPU | As for the signals not used, if you know it should be used then: // verilator lint_off UNUSED\n wire unused; unused = { unused_signals };\n//verilator lint_on UNUSED | 18:03 |
| cr1901_modern | What are the semantics of <= in a combinatorial always block? | 18:05 |
| *** emeb_mac has quit IRC | 18:05 | |
| ZipCPU | Shouldn't be used. Should use a "=" instead. "<=" doesn't really have any meaning in a combinatorial context. | 18:05 |
| *** sebastian has joined #yosys | 18:05 | |
| *** sebastian is now known as Guest95104 | 18:06 | |
| *** Guest46328 has quit IRC | 18:06 | |
| *** roh has quit IRC | 18:06 | |
| *** mazzoo_ has joined #yosys | 18:07 | |
| *** tinyfpga_ has joined #yosys | 18:07 | |
| *** mirage33- has joined #yosys | 18:07 | |
| *** tinyfpga has quit IRC | 18:08 | |
| *** mazzoo has quit IRC | 18:08 | |
| *** mirage335 has quit IRC | 18:08 | |
| *** ar3itrary has quit IRC | 18:08 | |
| *** kristianpaul has quit IRC | 18:08 | |
| *** mirage33- is now known as mirage335 | 18:08 | |
| *** kristianpaul has joined #yosys | 18:08 | |
| * cr1901_modern takes a rest | 18:09 | |
| *** weebull[m] has quit IRC | 18:10 | |
| *** nrossi has quit IRC | 18:10 | |
| *** swick has quit IRC | 18:10 | |
| *** samayra has quit IRC | 18:10 | |
| *** indefini has quit IRC | 18:11 | |
| *** jfng has quit IRC | 18:11 | |
| *** pointfree1 has quit IRC | 18:11 | |
| *** fevv8[m] has quit IRC | 18:11 | |
| *** marbler has quit IRC | 18:11 | |
| *** jayaura has quit IRC | 18:11 | |
| *** lok[m] has quit IRC | 18:11 | |
| *** danieljabailey has quit IRC | 18:11 | |
| *** milk- has joined #yosys | 18:12 | |
| *** danieljabailey has joined #yosys | 18:13 | |
| ZipCPU | Wow. Clifford told me about this a while ago, but I just came up head to head against it ... ice40 block RAM requires a posedge clock for reading. | 19:02 |
| ZipCPU | I was trying to read from my register file in combinatorial logic, so I could do other things with the register on the same clock. | 19:03 |
| ZipCPU | For 32 registers of 32 bits each, that was costing me 2700 LUTs on a 4700 LUT device | 19:03 |
| * ZipCPU wonders if this is what cr1901_modern was struggling with | 19:04 | |
| daveshah | ZipCPU: yeah, in a typical FPGA blockram requires a clock edge whereas distributed ram supports async reads. But the ice40 has no distributed RAM... | 19:05 |
| ZipCPU | Which explains why I wasn't struggling on the Xilinx chips at all--they all have plenty of distributed RAM | 19:06 |
| ZipCPU | That might cost me a clock | 19:07 |
| * ZipCPU frowns | 19:07 | |
| daveshah | ZipCPU: Yep. Basically every common arch but ice40 has distributed ram | 19:09 |
| ZipCPU | But .... if I want my design to support all architectures, I have to build for the lowest common denominator: no distributed RAM | 19:10 |
| daveshah | Indeed | 19:10 |
| *** roh has joined #yosys | 19:11 | |
| * ZipCPU decides to take a rest, following cr1901_modern 's example | 19:12 | |
| cr1901_modern | Enjoy your nap, ZipCPU. I just woke up but I'm still taking a break/eating/etc | 19:14 |
| *** roh has quit IRC | 19:15 | |
| cr1901_modern | And from prior experience studying lm32 internals, yosys should "do the right thing" wrt the clock (including adding bypass logic for transparent read) | 19:16 |
| sorear | lp384 doesn’t have block ram either | 19:22 |
| ZipCPU | cr1901_modern: Fascinating ... lm32 either has the same clock trouble as I do with distributed RAM, or it uses a negative clock edge driven RAM to deal with it. Not what I would've expected. | 19:49 |
| *** leviathan has quit IRC | 20:23 | |
| cr1901_modern | ZipCPU: Default is to use posedge clock and "pray your synthesizer infers a BRAM" (which is a safe assumption in 2018) | 20:25 |
| cr1901_modern | unless you're using LSE apparently | 20:25 |
| daveshah | Hmm, if there is a negative edge clock going on that could be the issue | 20:30 |
| daveshah | icetime may not work properly in that case, and claim a design passes timing when it doesn't | 20:31 |
| cr1901_modern | There's no negedge clk I'm aware of. At least I didn't enable it | 20:33 |
| daveshah | That should be OK then | 20:34 |
| *** MatrixTraveler[m has joined #yosys | 20:39 | |
| *** develonepi3 has joined #yosys | 21:05 | |
| *** xerpi has joined #yosys | 21:07 | |
| *** zetta has joined #yosys | 21:20 | |
| *** samayra has joined #yosys | 21:25 | |
| *** pointfree1 has joined #yosys | 21:25 | |
| *** lok[m] has joined #yosys | 21:25 | |
| *** fevv8[m] has joined #yosys | 21:25 | |
| *** nrossi has joined #yosys | 21:25 | |
| *** Guest57793 has joined #yosys | 21:25 | |
| *** marbler has joined #yosys | 21:25 | |
| *** swick has joined #yosys | 21:25 | |
| *** indefini has joined #yosys | 21:25 | |
| *** jfng has joined #yosys | 21:25 | |
| *** weebull[m] has joined #yosys | 21:25 | |
| *** kristianpaul has quit IRC | 21:34 | |
| *** kristianpaul has joined #yosys | 21:36 | |
| *** mwk has joined #yosys | 21:48 | |
| *** xerpi has quit IRC | 22:16 | |
| *** develonepi3 has quit IRC | 22:33 | |
| *** digshadow has quit IRC | 22:50 | |
| *** digshadow1 has joined #yosys | 22:50 | |
| *** philtor has quit IRC | 23:26 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!