Saturday, 2018-06-09

*** tpb has joined #yosys00:00
*** emeb_mac has joined #yosys00:11
*** _whitelogger has quit IRC00:46
*** _whitelogger has joined #yosys00:48
*** digshadow has joined #yosys01:10
*** promach_ has joined #yosys01:33
*** develonepi3 has quit IRC02:16
*** emeb has quit IRC02:17
*** promach_ has quit IRC03:42
*** roh has quit IRC03:48
*** promach_ has joined #yosys03:59
*** roh has joined #yosys04:32
*** _whitelogger has quit IRC04:43
*** _whitelogger has joined #yosys04:45
*** dys has quit IRC05:18
*** promach_ has quit IRC05:49
*** promach_ has joined #yosys05:52
*** emeb_mac has quit IRC06:16
*** leviathan has joined #yosys06:55
*** xerpi has joined #yosys07:18
*** dys has joined #yosys08:59
*** philtor has quit IRC09:54
*** xerpi has quit IRC11:39
*** philtor has joined #yosys11:48
*** promach_ has quit IRC12:14
*** develonepi3 has joined #yosys12:22
*** promach_ has joined #yosys12:29
cr1901_modernknielsen: 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_modernAnd it makes much use of brams13:52
*** oldtopman has quit IRC13:55
*** emeb_mac has joined #yosys14:09
*** oldtopman has joined #yosys14:28
*** dxld has quit IRC14:35
*** dxld has joined #yosys14:37
*** AlexDani` has joined #yosys14:48
*** AlexDaniel has quit IRC14:50
*** AlexDani` is now known as AlexDaniel14:54
*** dxld has quit IRC14:56
*** dxld has joined #yosys15:03
knielsencr1901_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 right15:32
knielsencr1901_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_modernI've switched back to icecube for now for this15:33
cr1901_modernbtw, anyone know how to specify a memory initialization file to synplify pro?15:33
daveshahcr1901_modern: is readmemh not working?15:34
cr1901_moderndaveshah: still have that 5k top-level I asked you to compile in icecube?15:34
daveshahcr1901_modern: let me look15:35
daveshahI used LSE though15:35
cr1901_modernIn 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 $readmemh15:35
knielsencr1901_modern: is icecube lattice's "official" ice40 development tool? Does it also have a layout viewer?15:35
daveshahI don't think I had any initialised memory though15:35
cr1901_modernknielsen: yes15:35
daveshahknielsen: yeah, it has a floorplan viewer but no routing viewer15:36
cr1901_moderndaveshah: actually you probably did15:36
daveshahThe new tool for the UltraPlus only, Radiant, has limited routing views15:36
cr1901_modernfor the version tag15:36
daveshahcr1901_modern: ah15:36
knielsenok, I see15:36
daveshahBTW, you know ice40 initialised memories don't work for a few us after power up15:36
daveshahbut I think you hold it in reset for a bit anyway15:37
cr1901_modernyes, but the device is held in reset for 4096 cycles15:37
daveshahthat'll be fine then15:37
cr1901_modern This is enough of a diff to change a nonfunctional bitstream to a functional one15:37
cr1901_modernand this is _without_ the spiflash115:38
cr1901_modernNone of this makes sense15:38
daveshahcr1901_modern: can't immediately find the 5k project or top level15:38
cr1901_modernnevermind then15:38
daveshaha small change will peturb the net naming and thus pnr15:38
daveshaheffectively pnr is chaotic15:38
cr1901_modernwhy the hell is that/115:39
cr1901_modernWhy is adding a single net change pnr so much?15:39
daveshahbecause it is simulated annealing, and heavily based on randomness15:39
daveshahadding a single net is effectively the same as using a different seed15:40
daveshahbecause it will change the rng state a bit15:40
cr1901_modernIt doesn't store the nets in a huge array in (mostly) the same order each initialization?15:40
daveshahthat doesn't change the fact the rng state has been upset15:40
cr1901_modernWhy are the nets part of the seed then?15:41
* cr1901_modern grumbles15:41
daveshahthey aren't15:41
tinyfpgacr1901_modern: this is how it works in many, many tools15:41
daveshahcr1901_modern: this is ultimately down to the basics of a random number generator15:42
daveshahif you take e.g. one more number from a rng, then that will change the state totally forever more15:42
daveshah(for an ideal rng)15:42
* cr1901_modern grumbles15:42
cr1901_modernThen I'm never going to find out why it's crashing at this rate15:42
daveshahcould be a metastability/timing issue15:43
cr1901_modernIt's 16MHz clk, the design passes timing at nearly twice that15:44
daveshahyes, but that doesn't consider metastability issues with external devices e.g. SPI15:44
cr1901_modernokay, 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 address15:45
*** xerpi has joined #yosys15:46
cr1901_modernif I modify the verilog file so that that nonexistent addr mirrors the SPI flash, the CPU continues but refuses to honor jumps15:46
daveshahyes, I think that's the behaviour I saw on the ultraplus15:46
daveshahI was seeing that consistently across design modifications and seeds though15:47
daveshahand, if my test wasn't broken, also consistent between ys and icecube15:47
cr1901_modernI 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 work15:50
daveshahwhat is happening in post-synthesis sim?15:50
cr1901_modernCome to think of it, I can't remember what happens if I forcefully enable r0 init15:52
daveshahthat's odd - all the real ice40 registers init to 015:52
daveshahso I'm not sure why post-synthesis doesn't match that15:52
cr1901_modernb/c yosys stores them in bram15:52
daveshahhmm, that is still initialised to 0 at reset15:53
cr1901_modernnot according to what yosys generates :)15:53
cr1901_modernit initializes everything to xxxxxxxxx15:53
daveshahah, I see, yosys outputs `.INIT_0(256'hxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx),`15:54
daveshahin the post-synthesis netlist15:54
daveshahpossibly a bug15:54
cr1901_modernWell I didn't find anything in the mem usage guide for ice40 to suggest they get initialized to 015:55
cr1901_modernit's not like I didn't check15:55
cr1901_modernexcept for, ya know, actually generating a bitstream and checking15:55
daveshahyeah, looks like they might need to be explicitly set to zero in a bitstream actually15:56
daveshahyosys probably does that for brams not specifically initialised to zero to keep the bitstream smaller15:56
cr1901_modernWell, not sure how to debug the current crash if I can't duplicate it...16:01
cr1901_modernEspecially considering the design uses 2500 LUTs and it's not like I can just rip out nets/wires at will16:06
cr1901_modernmaybe if yosys/a simulator had a "show which wires were unused for the duration of the simulation and rip them out" feature16:07
daveshahIt's a really weird one16:14
daveshahOne thing to do is a post PAR simulation16:15
daveshahUse icebox_vlog to back from the asc file to Verilog16:15
cr1901_modernThat would've helped me a few days ago, although I don't see how it's possible to represent PAR info in Verilog16:18
cr1901_modern(unless the idea is to "remove all the intermediate nets")16:18
*** pie_ has joined #yosys16:19
cr1901_modernOne 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_modernactually, I don't know why the CPU ever works at all, tbh. >>16:23
cr1901_modernregisters are placed into a BRAM by default initialized to "x"16:23
cr1901_moderndual port register means the read port is duplicated between two BRAMs16:23
cr1901_modernmeaning two copies of registers16:24
cr1901_modernwhose to say that "r0" in one BRAM will be initialized to one value, and "r0" in the other value will take on another random value16:24
cr1901_modernso "xor r0, r0, r0" doesn't actually zero out register16:24
tpbTitle: Lattice iCE40 Ultra internal oscillator - Page 1 (at
cr1901_modernsmall world16:34
cr1901_modernOh and synplify can't seem to route the "spiflash-free" design for some reason16:34
daveshahcr1901_modern: yeah, the intermediate nets aren't represented in the verilog but just dumped as comments16:39
cr1901_modernAnd LSE can't meet constraints...16:40
daveshahthis is all pretty crazy for a design based on a nominally lattice processor16:41
cr1901_modernWell, tbf, I had the wrong top level. Now synthesis is just taking forever now and eating 1+GB RAM16:47
cr1901_modernThis is very much the worst bug I've ever encountered. Period.16:48
cr1901_modernYup, LSE just hangs. I can't deal w/ this shit right now.16:51
daveshahZipCPU would call it FPGA Hell16:51
cr1901_modernYea, it might be a good laugh in about 2 years but it's not funny now16:51
daveshahit's weird to find a seemingly  (similar things work on other platforms) working design that is broken in Yosys, LSE and Synplify16:51
ZipCPUDoes the design work in simulation?16:52
ZipCPUWhich simulator?16:52
ZipCPUHow much of the design works?16:52
cr1901_modernwell, yosys creates a bitstream which crashes immediately, Synplify hangs during PAR, and LSE can't synthesize the damn thing16:53
cr1901_modernlike "I have to go to task manager and forcefully exit" can't synthesize16:54
ZipCPUCan you verilate the design?  With -Wall and -cc?  That often finds a lot of my bugs16:54
cr1901_modernNo b/c verilator refuses to compile16:54
cr1901_modernWell, I'll compile it on my Linux box16:55
daveshahcr1901_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 FFs16:55
daveshahit's something I've seen before16:55
cr1901_modernI have the RAM option set to "infer BRAM"16:55
daveshahyes, but LSE often fails nonetheless16:56
daveshahit's its weak point16:56
cr1901_modernThen why did it succeed on your machine?16:57
daveshahcould be the caches that are xploding? I didn't have them enabled16:57
cr1901_modernI don't have them enabled either16:57
daveshahah, I've found the project16:58
cr1901_modernfinally some good news T_T16:58
daveshahI was using LSE16:59
daveshahlooks like I ripped out the ram though17:00
daveshahand replaced it with manually instantiated ultraplus ram as a test17:00
cr1901_modernyou prob had spiflash enabled too17:00
daveshahseems I overwrote the original top level module during testing17:00
daveshahbut I would have ripped out the ram  because LSE couldn't cope with it17:00
cr1901_modernat least I'm pretty sure that's the file I gave you17:00
daveshahyeah, defo had SPI flash enabled because that's what I was probing17:01
cr1901_modernZipCPU: FYI, I can create a failing bitstream w/ a change as small as this:
ZipCPUCan you tell if the BRAM's are being inferred properly?17:08
ZipCPUShould be in the yosys output before arachne-pnr17:08
cr1901_modernThey are17:08
cr1901_modern(well, the registers BRAM anyway. lemme check the other)17:09
*** promach_ has quit IRC17:09
ZipCPUIs your design on github at all?  I have a working verilator version, perhaps I might see something?17:10
cr1901_modernCan you give me a few minutes to set it up please?17:11
ZipCPUIf you wish17:12
cr1901_modernIn any case, I've confirmed brams are correctly inferred17:13
*** dys has quit IRC17:20
cr1901_modernZipCPU: "make TARGET=tinyfpga-soc-no-trigger sim" and "make TARGET=tinyfpga-soc-no-trigger sim-post-synth" will get you started17:47
tpbTitle: GitHub - cr1901/misoc-lm32-sim: Testing LiteX LM32 SoCs for bugs using Verilog simulation. (at
cr1901_modernI'd love to abstract away the simulator used, but I'm not familiar enough w/ Verilator to know how to do this17:47
ZipCPUHmm ... do I need to pull in lm32_cpu from somewhere?17:51
cr1901_moderngit submodule init (sorry)17:51
ZipCPUthen what?17:53
cr1901_modernTry "make TARGET=tinyfpga-soc-no-trigger sim"17:53
ZipCPUSorry, don't have lm32-elf-* tools installed17:54
ZipCPUCan't I just build the verilog somewhere?17:54
cr1901_modernYou shouldn't need lm32-elf* tools installed. The verilog is in the repo17:54
*** develonepi3 has quit IRC17:55
tpbTitle: misoc-lm32-sim/tinyfpga-soc-no-trigger.v at master · cr1901/misoc-lm32-sim · GitHub (at
tpbTitle: misoc-lm32-sim/top.v at master · cr1901/misoc-lm32-sim · GitHub (at
ZipCPUCan't find lm32_cpu.v17:55
cr1901_modernI just made a Makefile to automate all the files you pass to the simulator17:56
cr1901_modern"git submodule update" should bring down the files for you17:56
ZipCPULet me try that17:56
ZipCPUAhh ... that's probably what I was missing17:56
cr1901_modernApologies lol. I need to get better w/ git's easy-and-intuitive UI17:57
ZipCPUI might be seeing something already17:58
cr1901_modernthe traces for no-trigger and trigger (pre-synth) are identical for me (minus the trigger signal)18:00
*** xerpi has quit IRC18:00
tpbTitle: Verilator output · GitHub (at
ZipCPUThe delayed assignments in non-clocked blocks are likely to cause the synthesizer problems ... among the other things there18:01
cr1901_modernOh, that's the top-level simulation file18:02
cr1901_modernwait... no it's not18:02
cr1901_modernI lied :P18:02
ZipCPUYou'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
ZipCPUThat can mask other bugs18:03
ZipCPUAs 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 UNUSED18:03
cr1901_modernWhat are the semantics of <= in a combinatorial always block?18:05
*** emeb_mac has quit IRC18:05
ZipCPUShouldn't be used.  Should use a "=" instead.  "<=" doesn't really have any meaning in a combinatorial context.18:05
*** sebastian has joined #yosys18:05
*** sebastian is now known as Guest9510418:06
*** Guest46328 has quit IRC18:06
*** roh has quit IRC18:06
*** mazzoo_ has joined #yosys18:07
*** tinyfpga_ has joined #yosys18:07
*** mirage33- has joined #yosys18:07
*** tinyfpga has quit IRC18:08
*** mazzoo has quit IRC18:08
*** mirage335 has quit IRC18:08
*** ar3itrary has quit IRC18:08
*** kristianpaul has quit IRC18:08
*** mirage33- is now known as mirage33518:08
*** kristianpaul has joined #yosys18:08
* cr1901_modern takes a rest18:09
*** weebull[m] has quit IRC18:10
*** nrossi has quit IRC18:10
*** swick has quit IRC18:10
*** samayra has quit IRC18:10
*** indefini has quit IRC18:11
*** jfng has quit IRC18:11
*** pointfree1 has quit IRC18:11
*** fevv8[m] has quit IRC18:11
*** marbler has quit IRC18:11
*** jayaura has quit IRC18:11
*** lok[m] has quit IRC18:11
*** danieljabailey has quit IRC18:11
*** milk- has joined #yosys18:12
*** danieljabailey has joined #yosys18:13
ZipCPUWow.  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
ZipCPUI 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
ZipCPUFor 32 registers of 32 bits each, that was costing me 2700 LUTs on a 4700 LUT device19:03
* ZipCPU wonders if this is what cr1901_modern was struggling with19:04
daveshahZipCPU: 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
ZipCPUWhich explains why I wasn't struggling on the Xilinx chips at all--they all have plenty of distributed RAM19:06
ZipCPUThat might cost me a clock19:07
* ZipCPU frowns19:07
daveshahZipCPU: Yep. Basically every common arch but ice40 has distributed ram19:09
ZipCPUBut .... if I want my design to support all architectures, I have to build for the lowest common denominator: no distributed RAM19:10
*** roh has joined #yosys19:11
* ZipCPU decides to take a rest, following cr1901_modern 's example19:12
cr1901_modernEnjoy your nap, ZipCPU. I just woke up but I'm still taking a break/eating/etc19:14
*** roh has quit IRC19:15
cr1901_modernAnd from prior experience studying lm32 internals, yosys should "do the right thing" wrt the clock (including adding bypass logic for transparent read)19:16
sorearlp384 doesn’t have block ram either19:22
ZipCPUcr1901_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 IRC20:23
cr1901_modernZipCPU: Default is to use posedge clock and "pray your synthesizer infers a BRAM" (which is a safe assumption in 2018)20:25
cr1901_modernunless you're using LSE apparently20:25
daveshahHmm, if there is a negative edge clock going on that could be the issue20:30
daveshahicetime may not work properly in that case, and claim a design passes timing when it doesn't20:31
cr1901_modernThere's no negedge clk I'm aware of. At least I didn't enable it20:33
daveshahThat should be OK then20:34
*** MatrixTraveler[m has joined #yosys20:39
*** develonepi3 has joined #yosys21:05
*** xerpi has joined #yosys21:07
*** zetta has joined #yosys21:20
*** samayra has joined #yosys21:25
*** pointfree1 has joined #yosys21:25
*** lok[m] has joined #yosys21:25
*** fevv8[m] has joined #yosys21:25
*** nrossi has joined #yosys21:25
*** Guest57793 has joined #yosys21:25
*** marbler has joined #yosys21:25
*** swick has joined #yosys21:25
*** indefini has joined #yosys21:25
*** jfng has joined #yosys21:25
*** weebull[m] has joined #yosys21:25
*** kristianpaul has quit IRC21:34
*** kristianpaul has joined #yosys21:36
*** mwk has joined #yosys21:48
*** xerpi has quit IRC22:16
*** develonepi3 has quit IRC22:33
*** digshadow has quit IRC22:50
*** digshadow1 has joined #yosys22:50
*** philtor has quit IRC23:26

Generated by 2.13.1 by Marius Gedminas - find it at!