sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<whitequark>
sb0: yes, I've looked at the entire dma code, including FSM states, quite extensively
<whitequark>
and I've checked that FSMs don't get stuck (the state when the code hangs is always 0)
<whitequark>
this is why I suspected the arbiter, in fact
<sb0>
cr1901_modern, it does bypass verilog generation
<cr1901_modern>
sb0: I think I figured it out. whitequark and I were talking in ##openfpga. They suggested that migen could target yosys directly and skip verilog generation, to offer an "alternative backend" that obeys the semantics of Migen (which match in both simulation and synthesis) instead of targeting verilog, where synthesis and sim semantics differ. >>
<cr1901_modern>
sb0: What I didn't realize is that in order for this to work, *I* have to convert fragments into EDIF that yosys understands
<sb0>
cr1901_modern, edif is for synthesized netlists, so it won't work for this purpose
<sb0>
cr1901_modern, and the migen verilog output has no particular simulation/synthesis mismatch
<cr1901_modern>
okay, then nevermind.
<sb0>
plugging the migen output directly into yosys via some NIH format won't improve the simulation/synthesis matching at all
<cr1901_modern>
Why is the edif backend useful then?
<sb0>
the idea of the EDIF backend was to perform what yosys does in python, working directly with the Migen FHDL objects, so you don't have to reinvent a verilog parser/pattern matcher
<cr1901_modern>
But you can only create instances/specials right now. Any fragment that has a comb or sync attribute will cause edif to bomb.
<cr1901_modern>
The instances and specials *have* to come from somewhere external (not migen)
<sb0>
cr1901_modern, of course. how would you represent a comb statement in edif?
<cr1901_modern>
sb0: I thought the idea was to examine the "comb" statements and match it to something that could be put into an edif file
<sb0>
cr1901_modern, this "matching" is called synthesis
<cr1901_modern>
like a Case statement would become a "mux" cell
<sb0>
there are no "mux cells", edif doesn't define what the cells are, it's device-dependent
<cr1901_modern>
sb0: Can we continue this convo at another time? I think I grossly misunderstand the purpose of EDIF
<sb0>
well, I guess you could put all of FHDL into EDIF directly using some special set of cells, and then have yosys read that and optimize/map it, but it's a very bad format for doing that
<cr1901_modern>
sb0: So basically it's up to me to provide the synthesis stage by operating on FHDL fragments, and converting them to black box instances?
<cr1901_modern>
If it's device dependent, then that sounds like a lot of work to remove the verilog component for very little gain.
<cr1901_modern>
The linked convo just got me thinking, is all
<cr1901_modern>
Okay, the mist code is *very* helpful. My idea was to map to yosys RTLIL as the "special set of cells", which is fairly generic. Why is edif a very bad format for that?
<mithro>
(which means we have i2c, liteeth, flash, uart all working)
<cr1901_modern>
I need to test whether single-width spiflash works under misoc (misoc and litex diverged in their spiflash code, and I don't think the misoc side was ever tested)