<kbeckmann> Are inout wires supported in nextpnr-ecp5? Getting a crash in a minimal case, should I create an issue?
<whitequark> yes
<_whitenotifier-6> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhfhb
<_whitenotifier-6> [whitequark/Glasgow] whitequark 4417f36 - gateware.boneless: fix pins testbench.
<sorear> if you're geting "a crash" how is that even a question
<_whitenotifier-6> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/471217538?utm_source=github_status&utm_medium=notification
<kbeckmann> alright, creating an issue.
<_whitenotifier-6> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhfjs
<_whitenotifier-6> [whitequark/Glasgow] whitequark 85f9279 - gateware.boneless: fix pins testbench.
<_whitenotifier-6> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/471219137?utm_source=github_status&utm_medium=notification
jevinskie has quit [Quit: Textual IRC Client: www.textualapp.com]
Maya-sama has joined ##openfpga
mumptai has quit [Quit: Verlassend]
Miyu has quit [Ping timeout: 240 seconds]
Flea86 has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
Maya-sama has quit [Ping timeout: 244 seconds]
pie__ has quit [Remote host closed the connection]
pie___ has joined ##openfpga
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
<azonenberg_work> kbeckmann: yeah as a general rule, crashing always warrants a bug report
<azonenberg_work> the only question is if the "fix" means declaring the behavior unsupported and making it fail gracefully, or making it work as hoped
<whitequark> azonenberg_work: do you know verilog?
<whitequark> like, in disgusting, repulsive detail?
<azonenberg_work> whitequark: Depends, what in particular?
<whitequark> i have a simulation-synthesis mismatch where i believe the *simulator* is wrong
<whitequark> there is an assignment statement that just never executes
<whitequark> in iverilog
<azonenberg_work> can has rtl?
<whitequark> here's the source: https://paste.gnome.org/pydbshfxh
<whitequark> it's not veyr minimal but the relevant parts are hopefully very easy to see
<whitequark> so, state and state$next are 1, and next_state and next_state$next are 0
<whitequark> always
<whitequark> line 616 should assign one to the other
<whitequark> this never happens
<whitequark> why?
indy has quit [Read error: No route to host]
<azonenberg_work> what assigns next_state?
<azonenberg_work> is it a function of state$next?
<whitequark> line 877
<whitequark> and it is a function of state
<whitequark> so, state -> next_state$next -> next_state -> state$next
<azonenberg_work> (what i'm wondering is if we have a combinatorial loop)
<whitequark> the loop is broken by a process on line 576
<whitequark> which is synchronous
<sorear> next_state$next is a reg but it's being written to in a combinational block?
<whitequark> I don't know why yosys decided to make it a reg
<whitequark> iirc there is some obscure corner case for regs written in always @* blocks
<whitequark> this may be my bug, or a yosys bug
indy has joined ##openfpga
dj_pi has joined ##openfpga
<ZipCPU> whitequark: Ever considered trying to see if you could get an assertion to fail with this code? That'd provide you with a trace showing what's going on
<whitequark> ZipCPU: so this case is a bit tricky, because it works in nMigen's simulator, for example
<whitequark> and I think it correctly synthesizes in Yosys as well
<whitequark> this is almost certainly a quirk (not sure if "bug") of write_verilog alone
<ZipCPU> So at issue is whether or not this is a bug in iverilog then?
<whitequark> and/or the way I'm using write_verilog
<whitequark> it could be an issue with iverilog or yosys write_verilog or the way i use the latter
<ZipCPU> (BTW, assigning to a reg with an always @* is quite legal--assigning to a wire is not)
<whitequark> oh right, that was the corner case, thanks
<ZipCPU> I was just thinking that a trace, however generated, might help reveal what was going on. An ad-hoc assertion, inserted by hand, might be an easy way to create such
<whitequark> what would I use to generate it? I don't think iverilog supports anything other than $display statements
<whitequark> which, now that I think about it, would help
<whitequark> interestingly... if I tell yosys to expand processes, iverilog now hangs
<azonenberg_work> whitequark: in general a "wire" is something assigned via a port or an "assign" statement
<azonenberg_work> and a "reg" is something written via an always block
<whitequark> and interestingly#2, if I tell yosys to do coarse-grained synthesis, iverilog does moooore or less what i expect
<whitequark> sort of
<whitequark> there's a lot of x's from somewhere, which might well be my fault
<cr1901_modern> ZipCPU: I didn't even know you could a <= b; in an always @(posedge clk) when "a" is a wire
<whitequark> but the state machine works as intended
<azonenberg_work> cr1901_modern: you shouldnt be able to
<azonenberg_work> the lvalue of an always block must be a reg
<azonenberg_work> the lvalue of an assign must be a wire
<cr1901_modern> azonenberg_work: That's what I thought :P
<ZipCPU> cr1901_modern: You can't. Did I mis-speak?
<cr1901_modern> ZipCPU: More I misinterpreted.
<ZipCPU> k
<ZipCPU> azonenberg_work has it right. The lvalue of an always block must be a reg. It doesn't matter if it's an always @* or an always @(posedge i_clk) or other. It must be a reg, never a wire
<ZipCPU> Ouch ... just chased down how a 13 was being turned into a 19 with no intervening set statement. printf %2x vs %2d
Miyu has joined ##openfpga
<whitequark> azonenberg_work: so, any idea about this verilog code?
<whitequark> the only thing I can come up with is maybe splitting that gigantic always @*
<whitequark> into smaller blocks
<whitequark> but that's a lot of effort and it's not even clear if it'll work
<ZipCPU> Yaayyy ... the MIPI/CSI-2 simulator works again! (after fixing the %2x vs %2d bug) https://imgur.com/a/XlJqcxN
<whitequark> nice
<dj_pi> ZipCPU, are you doing the MIPI/CSI-2 conversion through like...the resistor chain that I've seen in a couple app notes from xilinx and altera?
<cr1901_modern> that's pretty cool
<ZipCPU> dj_pi: My goal today was to get the design to build for actual hardware. Once done, the simulation stopped working. That's just a graph showing the sim working again.
<ZipCPU> The next step will be to load the (now modified) design onto an icebreaker, and display it through an RPi3
<ZipCPU> dj_pi: I do have a set of resistors (looks like a couple of dividers) in my adaptor card
<dj_pi> that's pretty cool. i did the app note thing where i broke out a MIPI signal coming from a TI camera hub type chip, through an FMC connector and in to an altera eval board
<dj_pi> i follow your blog so i'm guessing we'll be seeing updates on stuff
<dj_pi> you always got good in depth stuff...much appreciated. i read it! :)
<ZipCPU> Thanks!
<ZipCPU> I've now set out several times to blog about an I-cache implementation I have
<ZipCPU> I've gotten stuck every time on the "motivation" section, also known as "why do I need an I-cache"
<ZipCPU> Trying to explain this "simply" has so far eluded me. :/
<dj_pi> well....you're more motivated than me....
<ZipCPU> :D
<dj_pi> i got in to an 'fpga-hell' situation as you describe in your blog and i've been stuck there since
<ZipCPU> I'm enjoying explaining things to folk
<ZipCPU> Ever since? Ouch!
<dj_pi> my project is fallen to the side as i've gotten more and more pcb layout stuff to do
<ZipCPU> I've been in and out of FPGA-Hell this week, but it seems like I keep getting indulgences from somewhere
<dj_pi> for me it's just time management...which i have no time anymore
<ZipCPU> dj_pi: What was your project?
<ZipCPU> *is*
<dj_pi> i have a side project where i'd like to develop a video capture circuit using the FTDI FT602 USB 3.0 chip
<sorear> you've already blogged at length about "I need a prefetcher because off-chip flash is really slow", seems like a natural extension of that
<dj_pi> it does 4 simultaneous 4K streams out of it
<ZipCPU> Oooohh ... nice
<dj_pi> FTDI provides some sample verilog but its very...well...hard to follow
<dj_pi> looks like the guy who developed the chip for FTDI must have done the code as well
<ZipCPU> sorear: Yes. In my most recent rewrite (and toss-into-the-trash) that was my last approach
<dj_pi> so...i followed their code and massaged it, in to what i'm doing
<ZipCPU> How fast do the I/O's run?
<dj_pi> it all boils down to a state machine with some handshaking
<dj_pi> either 66MHz or 100MHz...? can't remember
<ZipCPU> Oh, well that's quite reasonable
<ZipCPU> Does your design work in simulation at all?
<dj_pi> well...probing the signals the handshake appears to happen all nicely and right before the transfer the FTDI chip pulls a line up and screws everything
<dj_pi> yes...i simulated all my blocks as well as theirs....things appeared to be working
<dj_pi> let me link you to an eval board i'm using...
<ZipCPU> But ... your simulation doesn't quite match where they pull that line up, huh? Ouch
<dj_pi> yeah....i have to 'mimic' what i'm seeing from the actual chip
<dj_pi> so...eh...yeah :-P
<dj_pi> but if i can get it to work...sky's the limit for some video applications i have been wanting to do
<dj_pi> as mentioned though...besides my main job i get bogged down with contract work mostly doing pcb design and uC firmware
* ZipCPU looks over the data sheet
<ZipCPU> Which wire was getting pulled up inappropriately? Do you remember at all?
<dj_pi> if you look in their datasheet....figure 4.1 has what i'm trying to do
<ZipCPU> That shows three jumpers. Do I have the right figure 4.1?
<dj_pi> its been a while since i looked at this...can't remember which signal was the one that's giving me problems
<dj_pi> i think you're looking at the app note for the board itself
<dj_pi> anyways...it's one of those, "i'm going to get back to it..." type things
* ZipCPU finds fig 4.1
* ZipCPU wonders how hard it would be to formally verify a core communicating over that protocol ...
<dj_pi> yeah...i've looked at what you're been preaching about formal verification and have thought about that too
<ZipCPU> You know, I haven't intended to "preach" about it, it's just honestly found more bugs in my code faster and simpler anything else.
<dj_pi> i don't mean it in a bad way
<ZipCPU> Sure ... it's just that ... I seem to be getting a reputation. ;)
<ZipCPU> For me, it's just the easiest way to do things. If I can formally verify something, that's the fastest/easiest/cheapest way to get it to where I know it works
<dj_pi> well, i don't think there's many other people out there that a) show how they're debugging fpga designs and b) give some actual approach to it
<ZipCPU> Thanks
<dj_pi> like i said...informative blog
<ZipCPU> Hopefully I'll get that cache article out and written soon ... I really see a need for it, and it will be fun to share.
<ZipCPU> BTW: Integrating the latest updates to the data cache improved my benchmark speed by over 50% .. :D
_whitelogger has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
dj_pi has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Quit: Leaving]
<tnt> whitequark: did you find your bug ? Kinda looks like the 'rst' case always matches.
_whitelogger has joined ##openfpga
<whitequark> tnt: hm? why would it?
Bob_Dole has quit [Ping timeout: 260 seconds]
Bob_Dole has joined ##openfpga
<tnt> whitequark: I have no idea, can't see what 'rst' state is or where it's coming from .
<whitequark> it's coming from the testbench
<whitequark> and tied to 0
<tnt> Ah well, there goes that theory then.
<_whitenotifier-6> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/471290677?utm_source=github_status&utm_medium=notification
m_t has joined ##openfpga
pie___ has quit [Remote host closed the connection]
pie___ has joined ##openfpga
dj_pi has joined ##openfpga
dj_pi has quit [Read error: Connection reset by peer]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
zng has joined ##openfpga
GenTooMan has joined ##openfpga
Miyu has joined ##openfpga
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
<tnt> swetland: it the spacing between the gnd and signal pad match the small 'spring' stuff at the end of the probes ? :P
<tnt> s/it/does/
<swetland> it's mostly just a bit of elbow room and space for the silkscreen. I don't have a specific probe design I'm targeting (beyond LA stuff like saleae-8/16 type setups)
jevinskie has joined ##openfpga
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
rohitksingh has quit [Remote host closed the connection]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
azonenberg has joined ##openfpga
_whitelogger has joined ##openfpga
<TD-Linux> swetland, same. I'm going to have huge pile of pcbs on my doorstep when I get back from visiting my family for holidays
mumptai has joined ##openfpga
oter_ has joined ##openfpga
oter has joined ##openfpga
oter_ has quit [Quit: Mutter: www.mutterirc.com]
oter_ has joined ##openfpga
oter has quit [Quit: Textual IRC Client: www.textualapp.com]
oter_ has quit [Quit: Mutter: www.mutterirc.com]
oter has joined ##openfpga
oter_ has joined ##openfpga
oter_ has quit [Client Quit]
oter_ has joined ##openfpga
oter has quit [Quit: Textual IRC Client: www.textualapp.com]
oter_ has quit [Client Quit]
azonenberg_work has left ##openfpga [##openfpga]
oter has joined ##openfpga
foo_ has joined ##openfpga
foo_ is now known as oter_
oter_ has quit [Client Quit]
oter has quit [Client Quit]
oter has joined ##openfpga
oter_ has joined ##openfpga
oter is now known as oter__
oter__ is now known as oter
oter_ has quit [Client Quit]
oter_ has joined ##openfpga
oter_ has quit [Client Quit]
catplant has quit [Quit: WeeChat 2.2]
oter_ has joined ##openfpga
catplant has joined ##openfpga
mumptai has quit [Quit: Verlassend]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
oter__ has joined ##openfpga
_whitelogger has joined ##openfpga
<pie___> kic-aaaaa-d