<Guest10>
Hello again _florent_ I implemented the liteeth standalone core on artix7 fpga and when I tried to get the dhcp I ran into issues. When I do dhcp_start, MAC sends in DHCP discover message (should I expect it to send dhcp options 50 with requesting IP address) and receives DHCP Offer back but, when sending the DHCP request the Client IP address will
<Guest10>
be 0.0.0.0 and not the offered IP address. I want to debug this issue and so tried to simulate the RTL in vivado and ran into "FATAL_ERROR: Iteration limit 10000 is reached. Possible zero delay oscillation detected where simulation time can not advance. Please check your source code. Note that the iteration limit can be changed using switch
<Guest10>
-maxdeltaid." It seems this error is caused by infinite loop but, I couldn't find any.
<Guest10>
Can you please point on how to simulate the standalone core with DHCP. Thank you in advance. Any help is much appreciated.
sakman has quit [Remote host closed the connection]
somlo_ has joined #litex
sakman has joined #litex
somlo has quit [Remote host closed the connection]
<josuah>
sorry for this bug I introduced!
<josuah>
should I bundle pull-requests together to void bloating the backlog?
Guest10 has joined #litex
whitequark[cis] has joined #litex
<whitequark[cis]>
in my experience putting more stuff in a single PR makes it harder to merge
Guest10 has quit [Ping timeout: 246 seconds]
somlo_ is now known as somlo
Guest10 has joined #litex
<somlo>
re. "structuring PRs", I find this: https://kernelnewbies.org/PatchSeries to be useful advice (where a "patch series" would be equivalent to a PR, and with the added note that a "series" or PR should consist of individual patches (or commits) that are somehow semantically related to each other, i.e. trying to fix the same overall problem or implement the same overall feature)
<tpb>
Title: PatchSeries - Linux Kernel Newbies (at kernelnewbies.org)
<somlo>
IOW, "don't fix multiple unrelated problems in the same PR" :)
<whitequark[cis]>
linux kernel has a fairly different culture but i would broadly speaking consider this good advice
<somlo>
whitequark: IMHO it's less about culture, and more about making it easy for others (but most importantly, one's own self) to figure out what the thinking was behind making a change, no matter how long ago :)
<zyp>
I agree, but it depends a bit on how large or controversial changes we're talking
<zyp>
if while working one issue, I run into a minor unrelated issue with an obvious fix, I'd be inclined to include a commit fixing that in the same PR
<zyp>
but then we're talking issues small and uncontroversial enough that it should pass straight through a review
<zyp>
if we're talking separate issues that needs separate discussions before merging, those should be separate PRs
<josuah>
somlo: thank you, good advise
<josuah>
s/advise/advice/ (spelled right earlier!)
<josuah>
this sounds about identifying what is the unit of change submission