<rjo>
sb0: bah. could you set the default branch to "master" on misoc? that little hiccup made legacy the default branch and i can't change the github default branch...
sb0_ has joined #m-labs
<sb0_>
rjo, your initial push was to the right repos/branch, no?
<sb0_>
rjo, where would you use CSRConstant?
<sb0_>
ah I get it, you wanted to push to your own repos
travis-ci has joined #m-labs
<travis-ci>
m-labs/misoc#23 (master - 92385d3 : Robert Jordens): The build passed.
<sb0_>
it belongs there, but if it's a CSRConstant, where would you put it?
<rjo_>
just where it is. in the namespace of the top module.
<rjo_>
if NIST_QC1 had a CSRStatus, where would you put that?
<sb0_>
CSRs aren't supported at the top level
<sb0_>
what would the csr_map entry look like?
<rjo_>
CSRConstants are not supported either
<rjo_>
they are not mapped on the bus.
<rjo_>
my example from soc_core.py is bad.
<rjo_>
but only because the add_constant stuff is ugly.
<rjo_>
if the CRG was an AutoCSR (could be for other reasons) then the CLOCK_FREQUENCY could live in there nicely.
<sb0_>
yes
mahap2 has joined #m-labs
mahap1 has quit [Ping timeout: 240 seconds]
<sb0_>
well, the only problem I have with CSRConstant is with top-level constants, like RTIO_DDS_CHANNEL....
<rjo_>
if you generate the header for the runtime, you would handle CSRConstants appropriately and either generate _read() or do as before with compile time defines.
<sb0_>
sure
<rjo_>
the question is what would you do if you needed a CSRStorage at the to level?
<rjo_>
top level
<sb0_>
take it off the top-level and put it in a core
<rjo_>
yes.
<rjo_>
if you want to use the naming niceties (and the dual usability in FHDL) of CSRConstant you would do that as well.
<rjo_>
otherwise you can still do add_constant()
<sb0_>
but those CSRStorage always have some logic attached to them, and so it makes sense to put that into a core
<sb0_>
whereas CSRConstant may just contain system-level information
<rjo_>
is NIST_QC1 not a "core"?
<sb0_>
no, it's what connects the cores together
<rjo_>
cores can also connect other cores together, right?
<sb0_>
yes, to take the NIST_QC1 example, it connects PHYs to the RTIO core
<rjo_>
but the fact that NIST_QC1 connect cores does not exclude it from being a core itself.
<rjo_>
after all, it does other things as well: e.g. pull ttl_l_tx_en high
<sb0_>
I guess you could figure out a way for the SoC classes to reference themselves in csr_map/mem_map
<sb0_>
but that's additional complexity
<sb0_>
and nontrivial logic should go in (sub-)cores anyway imo
<rjo_>
and if you don't want to do that you can still use add_constant for things that are really "system-level information" i would think that one can usually extract or push that.
<sb0_>
or the SoC class can simply extract its own CSRConstant
<rjo_>
yes. also CSRConstant uses the add_constant() as the "backend".
<sb0_>
let's have a single mechanism for constants
<sb0_>
if there is CSRConstant, there should not be add_constant() anymore
<rjo_>
maybe. for your example, of RTIO_DDS_CHANNEL, the nice way might be to have each channel export a CSRConstant about its "type". and rtio.RTIO export one about the total number.
<sb0_>
the C code does: rtio_set_channel(RTIO_DDS_CHANNEL) and that needs to be fast
<sb0_>
would the C preprocessor iterate over channel types? :)
<sb0_>
RTIO_DDS_CHANNEL contains the channel number that the runtime should use to talk to the DDSes
<rjo_>
sure. then RTIO can figure that channel number out and export it.
<sb0_>
that breaks the core/PHY separation
<rjo_>
it already has the right name.
<rjo_>
the runtime breaks that anyway
<sb0_>
how?
<rjo_>
because it treats the dds channel specially.
<sb0_>
only the DDS driver does, and it obviously needs to
<sb0_>
the idea is the RTIO core knows nothing about the type of PHY it is connected to, but sure, at the upper layers you need to send commands appropriate for the PHY on each channel
<rjo_>
yes. if you want to keep RTIO unaware, you can do self.dds_channel.index = CSRConstant(len(rtio_channels)) in NIST_QC1.
<rjo_>
or you can shovel all the "system-level constants" into one "Configuration(AutoCSR)".
<sb0_>
the second option sounds good
<sb0_>
maybe that can go into soc_core as an alternative to the SoC class scanning its own CSRConstant
rjo_ has quit [Quit: leaving]
kristianpaul has joined #m-labs
wbx_ has joined #m-labs
<mithro>
sb0_: The usage of lots of yields in the new misoc simulation stuff makes me think of MyHDL
<sb0_>
cocotb is also similar... generators are a pretty nice thing for this sort of problem
kristian1aul has quit [Ping timeout: 246 seconds]
wbx has quit [Ping timeout: 246 seconds]
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [*.net *.split]
mithro has quit [*.net *.split]
_florent_ has quit [*.net *.split]
mithro has joined #m-labs
_florent_ has joined #m-labs
wbx_ is now known as wbx
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<sb0_>
not only is QTreeView a pain to use, it also has obvious display bugs
<sb0_>
the area at the left of the text is not repainted when changing the selection until the mouse moves over it, which after you have changed the selection a few times makes the widget look like some sort of CGA-era paint program
<sb0_>
this is the third Qt bug that I hit...
<cr1901_modern>
sb0_: Is that why you forked pyqtgraph (to patch up more Qt bugs than the main dev tree has)?
<sb0_>
the pyqtgraph bugs come in addition to the qt bugs.
<sb0_>
and yes, bugfixes + new features
<sb0_>
whitequark, are you familiar with the QAbstractItemModel mess?
<whitequark>
sb0_: yes
rohitksingh has joined #m-labs
<cr1901_modern>
Why do I have like 10 JFETs for every MOSFET that I have? Who the hell uses a JFET nowadays?
<cr1901_modern>
Hmm... looks like they make good analog switches when used correctly...
ylamarre has joined #m-labs
kralor has quit [Read error: Connection reset by peer]
kralor has joined #m-labs
<GitHub176>
[artiq] sbourdeauducq pushed 6 new commits to master: http://git.io/v4uPv