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
<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
<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
<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?
<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]