<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>
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 .
<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