<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #967: @hartytp: yes you can do that. You also said you had spi issues with trying to debug hmc830. If that's something easy to reproduice, that would be interesting to test you still have issues. https://github.com/m-labs/artiq/issues/967#issuecomment-379755479
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #967: @hartytp: yes you can do that. You also said you had spi issues with trying to debug hmc830. If that's something easy to reproduce, that would be interesting to test you still have issues. https://github.com/m-labs/artiq/issues/967#issuecomment-379755479
rohitksingh has joined #m-labs
<GitHub-m-labs>
[artiq] hartytp commented on issue #967: I never got to the point of having a proper test that reproducibly crashed the ser-WB as there were other more pressing issues at the time.... https://github.com/m-labs/artiq/issues/967#issuecomment-379756371
<GitHub-m-labs>
[artiq] hartytp commented on issue #981: Well, sometimes it passes mem test even with the RTM:https://hastebin.com/upijulaten.rb But, even then the eye scans look bad, which isn't the case without the RTM. https://github.com/m-labs/artiq/issues/981#issuecomment-379794579
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #981: @hartytp: that was one of my suspicion when i was having better results than you with your AMC alone. (i was able to get errors but less than what you had). With the work we did around SDRAM, i was no longer able to get errors, so we improved things.... https://github.com/m-labs/artiq/issues/981#issuecomment-379816919
<GitHub-m-labs>
[artiq] hartytp commented on issue #981: > (i was able to get errors but less than what you had). With the work we did around SDRAM, i was no longer able to get errors, so we improved things.... https://github.com/m-labs/artiq/issues/981#issuecomment-379858716
<GitHub-m-labs>
[artiq] hartytp commented on issue #981: @enjoy-digital I'm not really up to speed on the details of what happens on Sayma AMC during boot. From the gatware/firmware side of things (i.e. not considering PI etc for now), what difference does having the RTM plugged in make? e.g. are all the JESD lanes/ser-wb held in reset until after mem tests, or do things start powering up straight away? https://github.com/
<GitHub-m-labs>
[artiq] gkasprow commented on issue #981: The question is if it is power supply that causes that failure. You can check with unpowered RTM. The easiest way is to disable the Enable signal that goes from I2C extender to the power supply block. https://github.com/m-labs/artiq/issues/981#issuecomment-379861965
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #981: @hartytp: current AMC gateware does not load RTM, so your RTM FPGA is not loaded. The JESD lines are kept in reset until AD9154 are initialized, so in your case in reset. serwb is trying continously to detect a link, but that's the same behaviour with or without RTM. https://github.com/m-labs/artiq/issues/981#issuecomment-379867665
<cr1901_modern>
$dut will "return the verilog signal equivalent" of an internal signal of the module "m" under test
<q3k>
hm
<q3k>
so you prefer this approach instead of adding an assertion 'syntax' to migen?
<cr1901_modern>
q3k: No, not really. But sb0 doesn't want me invasively touching migen, and it's been 6 months since I worked on it, and I've forgotten why I needed to invasively touch migen
<q3k>
hm :/
<cr1901_modern>
q3k: In the miform repo, grep for "XXX: "
<cr1901_modern>
Well, just "XXX". That will return some ugly stuff
<q3k>
to be honest, having a macros system where you already have code to fully generate verilog... sounds extremely hacky
<cr1901_modern>
It is
<q3k>
i'd personally make effort to integrate formal into migen properly
<cr1901_modern>
Well, that makes 2 ppl who want it.
<GitHub-m-labs>
[artiq] hartytp commented on issue #981: > @hartytp: current AMC gateware does not load RTM, so your RTM FPGA is not loaded. The JESD lines are kept in reset until AD9154 are initialized, so in your case in reset. serwb is trying continously to detect a link, but that's the same behaviour with or without RTM.... https://github.com/m-labs/artiq/issues/981#issuecomment-379875366
<cr1901_modern>
q3k: I'm not against working on it again if I have more flexibility to modify migen, but right now I have time sensitive work till end of Apr or so
<q3k>
well, I might just try to integrate this into migen and fire off a PR
<q3k>
if that doesn't work, worst case I'll maintain my own migen fork ¯\_(ツ)_/¯
<cr1901_modern>
I think we'd like to avoid forks if we can
<cr1901_modern>
q3k: In any case, I wanted something like "self.formal.comb += [Assert(...)]"
<cr1901_modern>
or self.comb.formal*
<q3k>
that should be okay for the basics
<q3k>
then there's also things like supporting $past() and $cover()
<cr1901_modern>
(Actually it'll have to be self.formal for stuff like global clock)
<cr1901_modern>
Past(...) Cover(...)
<q3k>
Yeah
mumptai has joined #m-labs
<cr1901_modern>
The main semantics of self.formal.* is it "allows you to use Assert, Past, Cover, etc without erroring out in Migen, puts all these statements guarded by `ifdef FORMAL`, and also accepts any other migen statement.
<q3k>
and then there's all the things that yosys doesn't (yet) support like concurrent assertions, sequences, implication...
<q3k>
we could even consider having implications emitted into (complex) verilog that yosys does understand
<cr1901_modern>
Concurrent assertions (even the ones yosys doesn't support) should be doable too as-is in my repo
<q3k>
because using $past() isn't that much fun
<cr1901_modern>
No property blocks tho
<q3k>
anyway. i'm just asking around for now, I probably won't have time for this in the upcoming few weeks, anyway.
<cr1901_modern>
Ask me again at around the end of April
<q3k>
aye
mumptai has quit [Remote host closed the connection]