clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
emeb_mac has joined #yosys
_whitelogger has joined #yosys
digshadow has joined #yosys
promach_ has joined #yosys
develonepi3 has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
promach_ has quit [Ping timeout: 268 seconds]
roh has quit [Ping timeout: 260 seconds]
promach_ has joined #yosys
roh has joined #yosys
_whitelogger has joined #yosys
dys has quit [Ping timeout: 248 seconds]
promach_ has quit [Ping timeout: 240 seconds]
promach_ has joined #yosys
emeb_mac has quit [Ping timeout: 248 seconds]
leviathan has joined #yosys
xerpi has joined #yosys
dys has joined #yosys
philtor has quit [Ping timeout: 260 seconds]
xerpi has quit [Quit: Leaving]
philtor has joined #yosys
promach_ has quit [Ping timeout: 245 seconds]
develonepi3 has joined #yosys
promach_ has joined #yosys
<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.
<cr1901_modern> And it makes much use of brams
oldtopman has quit [Ping timeout: 256 seconds]
emeb_mac has joined #yosys
oldtopman has joined #yosys
dxld has quit [Quit: Bye]
dxld has joined #yosys
AlexDani` has joined #yosys
AlexDaniel has quit [Ping timeout: 240 seconds]
AlexDani` is now known as AlexDaniel
dxld has quit [Quit: Bye]
dxld has joined #yosys
<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
<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.
<cr1901_modern> I've switched back to icecube for now for this
<cr1901_modern> btw, anyone know how to specify a memory initialization file to synplify pro?
<daveshah> cr1901_modern: is readmemh not working?
<cr1901_modern> daveshah: still have that 5k top-level I asked you to compile in icecube?
<daveshah> cr1901_modern: let me look
<daveshah> I used LSE though
<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
<knielsen> cr1901_modern: is icecube lattice's "official" ice40 development tool? Does it also have a layout viewer?
<daveshah> I don't think I had any initialised memory though
<cr1901_modern> knielsen: yes
<daveshah> knielsen: yeah, it has a floorplan viewer but no routing viewer
<cr1901_modern> daveshah: actually you probably did
<daveshah> The new tool for the UltraPlus only, Radiant, has limited routing views
<cr1901_modern> for the version tag
<daveshah> cr1901_modern: ah
<knielsen> ok, I see
<daveshah> BTW, you know ice40 initialised memories don't work for a few us after power up
<daveshah> but I think you hold it in reset for a bit anyway
<cr1901_modern> yes, but the device is held in reset for 4096 cycles
<daveshah> that'll be fine then
<cr1901_modern> https://hastebin.com/urupomacik.diff This is enough of a diff to change a nonfunctional bitstream to a functional one
<cr1901_modern> and this is _without_ the spiflash1
<cr1901_modern> None of this makes sense
<daveshah> cr1901_modern: can't immediately find the 5k project or top level
<cr1901_modern> nevermind then
<daveshah> a small change will peturb the net naming and thus pnr
<daveshah> effectively pnr is chaotic
<cr1901_modern> why the hell is that/1
<cr1901_modern> Why is adding a single net change pnr so much?
<daveshah> because it is simulated annealing, and heavily based on randomness
<daveshah> adding a single net is effectively the same as using a different seed
<cr1901_modern> Why?!
<daveshah> because it will change the rng state a bit
<cr1901_modern> It doesn't store the nets in a huge array in (mostly) the same order each initialization?
<daveshah> that doesn't change the fact the rng state has been upset
<cr1901_modern> Why are the nets part of the seed then?
* cr1901_modern grumbles
<daveshah> they aren't
<tinyfpga> cr1901_modern: this is how it works in many, many tools
<daveshah> cr1901_modern: this is ultimately down to the basics of a random number generator
<daveshah> if you take e.g. one more number from a rng, then that will change the state totally forever more
<daveshah> (for an ideal rng)
* cr1901_modern grumbles
<daveshah> *prng
<cr1901_modern> Then I'm never going to find out why it's crashing at this rate
<daveshah> could be a metastability/timing issue
<cr1901_modern> It's 16MHz clk, the design passes timing at nearly twice that
<daveshah> yes, but that doesn't consider metastability issues with external devices e.g. SPI
<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
xerpi has joined #yosys
<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
<daveshah> yes, I think that's the behaviour I saw on the ultraplus
<daveshah> I was seeing that consistently across design modifications and seeds though
<daveshah> and, if my test wasn't broken, also consistent between ys and icecube
<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
<daveshah> what is happening in post-synthesis sim?
<cr1901_modern> Come to think of it, I can't remember what happens if I forcefully enable r0 init
<daveshah> that's odd - all the real ice40 registers init to 0
<daveshah> so I'm not sure why post-synthesis doesn't match that
<cr1901_modern> b/c yosys stores them in bram
<daveshah> hmm, that is still initialised to 0 at reset
<cr1901_modern> not according to what yosys generates :)
<cr1901_modern> it initializes everything to xxxxxxxxx
<daveshah> ah, I see, yosys outputs `.INIT_0(256'hxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx),`
<daveshah> etc
<daveshah> in the post-synthesis netlist
<daveshah> possibly a bug
<cr1901_modern> Well I didn't find anything in the mem usage guide for ice40 to suggest they get initialized to 0
<cr1901_modern> it's not like I didn't check
<cr1901_modern> except for, ya know, actually generating a bitstream and checking
<daveshah> yeah, looks like they might need to be explicitly set to zero in a bitstream actually
<daveshah> yosys probably does that for brams not specifically initialised to zero to keep the bitstream smaller
<cr1901_modern> Well, not sure how to debug the current crash if I can't duplicate it...
<cr1901_modern> Especially considering the design uses 2500 LUTs and it's not like I can just rip out nets/wires at will
<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
<daveshah> It's a really weird one
<daveshah> One thing to do is a post PAR simulation
<daveshah> Use icebox_vlog to back from the asc file to Verilog
<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
<cr1901_modern> (unless the idea is to "remove all the intermediate nets")
pie_ has joined #yosys
<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.
<cr1901_modern> actually, I don't know why the CPU ever works at all, tbh. >>
<cr1901_modern> registers are placed into a BRAM by default initialized to "x"
<cr1901_modern> dual port register means the read port is duplicated between two BRAMs
<cr1901_modern> meaning two copies of registers
<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
<cr1901_modern> so "xor r0, r0, r0" doesn't actually zero out register
<tpb> Title: Lattice iCE40 Ultra internal oscillator - Page 1 (at www.eevblog.com)
<cr1901_modern> small world
<cr1901_modern> Oh and synplify can't seem to route the "spiflash-free" design for some reason
<daveshah> cr1901_modern: yeah, the intermediate nets aren't represented in the verilog but just dumped as comments
<cr1901_modern> And LSE can't meet constraints...
<daveshah> this is all pretty crazy for a design based on a nominally lattice processor
<cr1901_modern> Well, tbf, I had the wrong top level. Now synthesis is just taking forever now and eating 1+GB RAM
<cr1901_modern> This is very much the worst bug I've ever encountered. Period.
<cr1901_modern> Yup, LSE just hangs. I can't deal w/ this shit right now.
<daveshah> ZipCPU would call it FPGA Hell
<cr1901_modern> Yea, it might be a good laugh in about 2 years but it's not funny now
<daveshah> it's weird to find a seemingly (similar things work on other platforms) working design that is broken in Yosys, LSE and Synplify
<ZipCPU> Does the design work in simulation?
<cr1901_modern> Yes
<ZipCPU> Which simulator?
<cr1901_modern> iverilog
<ZipCPU> How much of the design works?
<cr1901_modern> well, yosys creates a bitstream which crashes immediately, Synplify hangs during PAR, and LSE can't synthesize the damn thing
<cr1901_modern> like "I have to go to task manager and forcefully exit" can't synthesize
<ZipCPU> Can you verilate the design? With -Wall and -cc? That often finds a lot of my bugs
<cr1901_modern> No b/c verilator refuses to compile
<cr1901_modern> Well, I'll compile it on my Linux box
<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
<daveshah> it's something I've seen before
<cr1901_modern> I have the RAM option set to "infer BRAM"
<daveshah> yes, but LSE often fails nonetheless
<daveshah> it's its weak point
<cr1901_modern> Then why did it succeed on your machine?
<daveshah> could be the caches that are xploding? I didn't have them enabled
<cr1901_modern> I don't have them enabled either
<daveshah> ah, I've found the project
<cr1901_modern> finally some good news T_T
<daveshah> I was using LSE
<daveshah> looks like I ripped out the ram though
<daveshah> and replaced it with manually instantiated ultraplus ram as a test
<cr1901_modern> you prob had spiflash enabled too
<daveshah> seems I overwrote the original top level module during testing
<daveshah> but I would have ripped out the ram because LSE couldn't cope with it
<cr1901_modern> at least I'm pretty sure that's the file I gave you
<daveshah> yeah, defo had SPI flash enabled because that's what I was probing
<cr1901_modern> ZipCPU: FYI, I can create a failing bitstream w/ a change as small as this: https://hastebin.com/urupomacik.diff
<ZipCPU> Can you tell if the BRAM's are being inferred properly?
<ZipCPU> Should be in the yosys output before arachne-pnr
<cr1901_modern> Yes
<cr1901_modern> They are
<cr1901_modern> (well, the registers BRAM anyway. lemme check the other)
promach_ has quit [Quit: WeeChat 2.1]
<ZipCPU> Is your design on github at all? I have a working verilator version, perhaps I might see something?
<cr1901_modern> Can you give me a few minutes to set it up please?
<ZipCPU> If you wish
<cr1901_modern> In any case, I've confirmed brams are correctly inferred
dys has quit [Ping timeout: 256 seconds]
<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
<tpb> Title: GitHub - cr1901/misoc-lm32-sim: Testing LiteX LM32 SoCs for bugs using Verilog simulation. (at github.com)
<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
<ZipCPU> Hmm ... do I need to pull in lm32_cpu from somewhere?
<cr1901_modern> git submodule init (sorry)
<ZipCPU> then what?
<cr1901_modern> Try "make TARGET=tinyfpga-soc-no-trigger sim"
<ZipCPU> Sorry, don't have lm32-elf-* tools installed
<ZipCPU> Can't I just build the verilog somewhere?
<cr1901_modern> You shouldn't need lm32-elf* tools installed. The verilog is in the repo
develonepi3 has quit [Remote host closed the connection]
<tpb> Title: misoc-lm32-sim/tinyfpga-soc-no-trigger.v at master · cr1901/misoc-lm32-sim · GitHub (at github.com)
<tpb> Title: misoc-lm32-sim/top.v at master · cr1901/misoc-lm32-sim · GitHub (at github.com)
<ZipCPU> Can't find lm32_cpu.v
<cr1901_modern> I just made a Makefile to automate all the files you pass to the simulator
<cr1901_modern> "git submodule update" should bring down the files for you
<ZipCPU> Let me try that
<ZipCPU> Ahh ... that's probably what I was missing
<cr1901_modern> Apologies lol. I need to get better w/ git's easy-and-intuitive UI
<ZipCPU> I might be seeing something already
<cr1901_modern> the traces for no-trigger and trigger (pre-synth) are identical for me (minus the trigger signal)
xerpi has quit [Quit: Leaving]
<tpb> Title: Verilator output · GitHub (at gist.github.com)
<ZipCPU> The delayed assignments in non-clocked blocks are likely to cause the synthesizer problems ... among the other things there
<cr1901_modern> Oh, that's the top-level simulation file
<cr1901_modern> wait... no it's not
<cr1901_modern> I lied :P
<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.
<ZipCPU> That can mask other bugs
<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
<cr1901_modern> What are the semantics of <= in a combinatorial always block?
emeb_mac has quit [Quit: Leaving.]
<ZipCPU> Shouldn't be used. Should use a "=" instead. "<=" doesn't really have any meaning in a combinatorial context.
sebastian has joined #yosys
sebastian is now known as Guest95104
Guest46328 has quit [Ping timeout: 240 seconds]
roh has quit [Ping timeout: 248 seconds]
mazzoo_ has joined #yosys
tinyfpga_ has joined #yosys
mirage33- has joined #yosys
tinyfpga has quit [Ping timeout: 245 seconds]
mazzoo has quit [Ping timeout: 245 seconds]
mirage335 has quit [Ping timeout: 245 seconds]
ar3itrary has quit [Ping timeout: 245 seconds]
kristianpaul has quit [Ping timeout: 245 seconds]
mirage33- is now known as mirage335
kristianpaul has joined #yosys
* cr1901_modern takes a rest
weebull[m] has quit [Ping timeout: 240 seconds]
nrossi has quit [Ping timeout: 245 seconds]
swick has quit [Ping timeout: 245 seconds]
samayra has quit [Ping timeout: 240 seconds]
indefini has quit [Ping timeout: 256 seconds]
jfng has quit [Ping timeout: 240 seconds]
pointfree1 has quit [Ping timeout: 240 seconds]
fevv8[m] has quit [Ping timeout: 255 seconds]
marbler has quit [Ping timeout: 255 seconds]
jayaura has quit [Ping timeout: 256 seconds]
lok[m] has quit [Ping timeout: 256 seconds]
danieljabailey has quit [Ping timeout: 240 seconds]
milk- has joined #yosys
danieljabailey has joined #yosys
<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.
<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.
<ZipCPU> For 32 registers of 32 bits each, that was costing me 2700 LUTs on a 4700 LUT device
* ZipCPU wonders if this is what cr1901_modern was struggling with
<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...
<ZipCPU> Which explains why I wasn't struggling on the Xilinx chips at all--they all have plenty of distributed RAM
<ZipCPU> That might cost me a clock
* ZipCPU frowns
<daveshah> ZipCPU: Yep. Basically every common arch but ice40 has distributed ram
<ZipCPU> But .... if I want my design to support all architectures, I have to build for the lowest common denominator: no distributed RAM
<daveshah> Indeed
roh has joined #yosys
* ZipCPU decides to take a rest, following cr1901_modern 's example
<cr1901_modern> Enjoy your nap, ZipCPU. I just woke up but I'm still taking a break/eating/etc
roh has quit [Ping timeout: 256 seconds]
<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)
<sorear> lp384 doesn’t have block ram either
<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.
leviathan has quit [Ping timeout: 276 seconds]
<cr1901_modern> ZipCPU: Default is to use posedge clock and "pray your synthesizer infers a BRAM" (which is a safe assumption in 2018)
<cr1901_modern> unless you're using LSE apparently
<daveshah> Hmm, if there is a negative edge clock going on that could be the issue
<daveshah> icetime may not work properly in that case, and claim a design passes timing when it doesn't
<cr1901_modern> There's no negedge clk I'm aware of. At least I didn't enable it
<daveshah> That should be OK then
MatrixTraveler[m has joined #yosys
develonepi3 has joined #yosys
xerpi has joined #yosys
zetta has joined #yosys
pointfree1 has joined #yosys
nrossi has joined #yosys
lok[m] has joined #yosys
fevv8[m] has joined #yosys
samayra has joined #yosys
Guest57793 has joined #yosys
jfng has joined #yosys
indefini has joined #yosys
swick has joined #yosys
marbler has joined #yosys
weebull[m] has joined #yosys
kristianpaul has quit [Quit: Lost terminal]
kristianpaul has joined #yosys
mwk has joined #yosys
xerpi has quit [Quit: Leaving]
develonepi3 has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
digshadow1 has joined #yosys
philtor has quit [Ping timeout: 260 seconds]
tpb has quit [Remote host closed the connection]
tpb has joined #yosys