<mattvenn>
ZipCPU: thanks for the quizzes, I've enjoyed them and they've inspired me to start formally verifying my own modules
<ZipCPU>
mattvenn: Yeah, I'm enjoying them as well!
<ZipCPU>
Among other things, I'm enjoying the discussion they create. Often I don't get much discussion on the tweets--the quizes have been a nice contrast.
<ZipCPU>
Of course .... I only have about 7-8 quizes prepared, and ... I'm not sure how I'll transition from the simple and basic quizes to the more complex.
<ZipCPU>
The difficulty being all of the individuals who haven't learned the basics yet.
<ZipCPU>
mattvenn: Let me turn the tables, though, and ask you ... did you read my own article on debouncing?
<ZipCPU>
Or see the bouncing button traces?
<mattvenn>
yes
<ZipCPU>
Cool!
<ZipCPU>
Were they any help to you in your design?
<mattvenn>
I'm fairly sure I made this debouncer before I found your webiste
<mattvenn>
so, no. But I always learn stuff from your blog
<ZipCPU>
I would note that your debouncer is rather heavy on the FF's. You might be able to handle a longer difference between press and bounce if you used a counter instead of a shift register.
<mattvenn>
yes
<mattvenn>
I only start looking at usage if my design doesn't fit!
<ZipCPU>
:D
<mattvenn>
I need to go back over your wishbone scope articles
<ZipCPU>
That's fair. I've just spent so much time working on tight designs, that it's somewhat hard for me to ignore.
<ZipCPU>
I've thought about going back to those scope articles, and discussing how to create a non-wb scope, something simpler and more primitive even.
<mattvenn>
I've been really impressed with Greg's work on the boson camera - have you followed them?
<ZipCPU>
I've seen several of his tweets, but, no, I'm not following him thoroughly.
<mattvenn>
as my designs get more complex I think I need to start using a astandard bus
<mattvenn>
and write new modules that can hang off it
<ZipCPU>
It *REALLY* helps
<mattvenn>
Greg
<mattvenn>
's got a riskv core
<mattvenn>
with wishbone, and then attaches the camera, ram and flash all off of that
<ZipCPU>
Have you seen my Verilator based camera simulator?
<mattvenn>
yes, counterpart to your screen simulator!
<ZipCPU>
Yes
<mattvenn>
that's another tool I need to start using (verilator)
<ZipCPU>
Definitely!
<ZipCPU>
It's amazing what you can do with it.
<mattvenn>
but I think I will keep on with the formal methods until I have a better understanding
<mattvenn>
I liked your recent article about what it's like to develop with formal
<mattvenn>
it appears to me so much better than test benches
<mattvenn>
which is all I've used iverilog and verilator for so far
<mattvenn>
ok - got to go and set up some more shelves - just saw your answer on twitter and wanted to say hi
<ZipCPU>
That article was a surprise to me. From my standpoint, it felt like a long runon sentence.
<ZipCPU>
I'll be tweeting some more. Enjoy your morning!
<mattvenn>
cheers!
awygle has quit [Quit: No Ping reply in 180 seconds.]
<maikmerten>
if I make one happy, I'll make the other unhappy
<maikmerten>
overall, verilator seems to be much more picky, and usually makes pretty sane suggestions, so I wonder if I shall just ignore the yosys warning there
adamgreig has joined #yosys
* ZipCPU
takes a peek
<ZipCPU>
maikmerten: Clifford and I have argued this one back and forth. I think Verilator has the right answer. But, since you've asked, let me pull up my Verilog specification and let's see what it says.
<ZipCPU>
BTW ... this only happens with memories as I recall. I think everything else is in agreement.
<maikmerten>
thanks!
* ZipCPU
is still searching the spec
<ZipCPU>
The Verilog spec gives an example of initial for (index = 0; index < MAX; index=index+1) memory[index] = 0;
<ZipCPU>
So, I'd say that's valid syntax. I'm still looking for the discussion of it though.
<maikmerten>
I've seen your great article on using verilator, btw, and plan to add that to my simulation toolbox
<ZipCPU>
Thanks!
<maikmerten>
currently I maintain a SoC emulator in Java (eeek) and guess that with verilator, it should be very much possible to avoid this double-implementation-thingie-with-subtle-differences
<ZipCPU>
I built a C++ ZipCPU emulator once, that just executed every instruction "properly".
<ZipCPU>
I struggled with this when it came to peripherals, though ... if I was already making and implementing peripherals in Verilog, which I could access in any Verilator based design, it was becoming twice the work to keep/maintain the ZipCPU C++ emulator going.
<ZipCPU>
I realized the problem once I wanted to implement the serial port and the interrupt register. Of course, things were only going to get worse from there.
<ZipCPU>
Hence, I now do all my CPU simulation directly from Verilator--that way I only need to keep one implementation around.
* maikmerten
nods
awygle has joined #yosys
<awygle>
good morning all
<ZipCPU>
Good morning!
<sorear>
o/
<awygle>
everyone prepared for monday?
<ZipCPU>
Not at all!
<awygle>
oh dear
AlexDaniel has quit [Ping timeout: 268 seconds]
develonepi3 has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 252 seconds]
massi has quit [Remote host closed the connection]
azonenberg_work has joined #yosys
<awygle>
when running nextpnr-bench, is it necessary to do so single-threaded to get useful results? is nextpnr entirely single threaded?
<awygle>
ha! building libtrellis i got a gcc ICE
<awygle>
hello libboost my old friend
<q3k>
awygle: nextpnr's algorithms are currently single threaded
<q3k>
awygle: for the GUI there's also a main GUI thread and a third thread for CPU visualization computation
<awygle>
q3k: thanks. so that sounds like i should be able to -j up to at least the number of physical cores without affecting benchmarking much
<awygle>
possibly not up to hyperthreads, i'm not totally sure how well that all works
<sorear>
running more physical cores will definitely affect benchmark results
<awygle>
aw, really? bummer.
<sorear>
(a) you effectively have less L3 cache per process, since that's a global resource and shared (b) you get less memory bandwidth (c) intel and amd processors will run 1 core at a higher clock speed if the rest are idle
<awygle>
yeah, that's true... damn
digshadow has quit [Ping timeout: 252 seconds]
digshadow has joined #yosys
m_t has joined #yosys
maikmerten has quit [Remote host closed the connection]
gekko7 has quit [Ping timeout: 268 seconds]
mirage335 has quit [Ping timeout: 252 seconds]
mirage335 has joined #yosys
digshadow has quit [Ping timeout: 244 seconds]
mwk has quit [Ping timeout: 260 seconds]
<cr1901_modern>
Please join me tonight as I try to make nextpnr create a bitstream which crashes an ice40 FPGA :D
<cr1901_modern>
B/c knowing my luck that's what will happen
digshadow has joined #yosys
mwk has joined #yosys
seldridge has quit [Ping timeout: 268 seconds]
<cr1901_modern>
Ya know, I was actually hoping that nextpnr would create a bitstream that actually works, but alas it doesn't
<cr1901_modern>
I just cannot get tinyfpga to boot a pipelined softcore
<tinyfpga>
cr1901_modern: what clock is it running at?
<cr1901_modern>
16.00 MHz
<tinyfpga>
cr1901_modern: is nextpnr reporting any timing information? Have you tried icecube2 or radiant?
<cr1901_modern>
netpnr claims 20MHz
<cr1901_modern>
vexriscv doesn't work on arachne and nextpnr, lm32 doesn't work on arachne and icecube2
<cr1901_modern>
haven't installed radiant
<cr1901_modern>
but this is getting ridiculous...
<sorear>
does, uh, blinky work
<cr1901_modern>
sure it has in the past, I'll fire up pulseview right now if it doesn't crash for the 10 millionth time because none of the devs have ever heard of Windoze
xdeller has quit [Remote host closed the connection]
xdeller has joined #yosys
<cr1901_modern>
yes the blinky part of the bitstream is working
<cr1901_modern>
(same bitstream, only the softcore portion has crashed)
* cr1901_modern
halves the clock and see what happens
<sorear>
i was under the impression nextpnr didn't do memory and so you were limited to the few Kbit you can make with lut+ffs
<awygle>
it must either be convenient or very inconvenient that referring to tinyfpga's products also summons him
<cr1901_modern>
No, I wanted to summon him.
<awygle>
sure, i just meant in general, for him
<sorear>
has that been fixed yet? are you using off-chip memory? are you using vexriscv with a sufficiently tiny rom+ram that it doesn't matter?
<awygle>
i would be really annoyed personally
<sorear>
it's weird to imagine being someone with a brand so narrow you can name yourself after exactly one product
<tinyfpga>
awygle: it’s great for me :)
<cr1901_modern>
The design should've died if nextpnr doesn't route memory
<awygle>
i thought the no memory thing was ecp5-specific
<awygle>
but i could be wrong
<sorear>
uh is cr1901_modern on EX or BX
<sorear>
oh he said "ice40" above n/m
<cr1901_modern>
B2*
<cr1901_modern>
it's like the only way I'll ever figure this out is via interactive mode where I remove connections from a GUI until the crash goes away
<cr1901_modern>
I'm convinced at this point it's either the platform, or my FPGA specifically
<cr1901_modern>
i.e. ice40lp problems
<ZipCPU>
Yes, nextpnr should have no problems with ice40 memory
<cr1901_modern>
I'll try a post-synthesis sim halving the clock freq fails
<cr1901_modern>
The problem w/ submitting a bug is that this design is too big (even in it's smallest form) and I'm unsure how to go about tearing out bits and pieces until I can dup the bug
danieljabailey has quit [Ping timeout: 252 seconds]
<cr1901_modern>
halving the clock has no effect...
* cr1901_modern
notices something odd, and will try fixing that. But not getting my hopes up :P