<lkcl>
many migen riscv socs aren't actual migen socs, they're wrappers around verilog
<lkcl>
this is an evaluation of whether *migen* can be used to make a high-performance SoC.
<lkcl>
with a focus on clarity, maintenance, and, critically, flexibility of python OO because we will need to do a *lot* of experimentation
<lkcl>
the absolute last thing we need is to find that the data paths to the SIMD ALUs aren't wide enough, and we have to do a total redesign of the verilog
<lkcl>
so the idea is, use python (migen) to specify lane widths, bus widths etc. etc. and many other aspects, then experiment with different parameters
<cr1901_modern>
mithro: Did you figure out your memory/clock domain issue?
<mithro>
cr1901_modern: Yes, see whitequark's mention about the port not being added to specials
<cr1901_modern>
oh right... been there done that
<cr1901_modern>
mithro: Also, TIL (or maybe I knew, but I've since forgotten) that the following Python expression is False: >>
<cr1901_modern>
ClockSignal("sys") is self.cd_sys.clk
<cr1901_modern>
(Apparently ClockSignal("sys") doesn't actually return a Signal, but something that looks like it. Yay duck typing?)
<cr1901_modern>
<migen.fhdl.structure.ClockSignal object at 0x0000000003075898>
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
<cr1901_modern>
I got myself so sufficiently confused that I wrote up a doc so I remember from here on out
<cr1901_modern>
sb0: Does this look okay (when you get the chance)?
<lkcl>
cr1901_modern, cool
<attie>
cr1901_modern: nice doc. reading backscroll, I don't think anybody answered about what's meant by the clock periods specified in simulation being "integral"
<attie>
it will change the value of the clock signal in the .vcd every clk_p//2
<attie>
so if clk_p is not an int or even not an even integer, you get a different timing than specified
<attie>
(well for floats it would give an error I guess)
<cr1901_modern>
attie: Thanks for the feedback :). I'm a bit too tired right now, so I'll try parsing the "integral" stuff later when I wake up :D. Thanks for the explanation
<attie>
well just remember that it has to be divisible by 2 to do what you want it to do
<attie>
the one thing I personally can never remember about clock domains is how to arrange the parentheses for ClockDomainRenamer
<cr1901_modern>
ClockDomainsRenamer is a decorator, thus it returns a function. So you need two pairs of closed-parentheses after "ClockDomainsRenamer"
<attie>
yeah
<cr1901_modern>
e.g. ClockDomainsRenamer(inputs_to_decorator)(inputs_to_function_returned_from_decorator)
<attie>
({'':''})(()) if I remove all the identifiers, but it's a bit of an overwhelming amount of punctuation
<attie>
I average about three tries to get it right
<cr1901_modern>
I think ({'':''})() is sufficient? Idk... E_3AM
m4ssi has joined #m-labs
<attie>
the other one is from the module that is instantiated
<attie>
CDR({'clk':'n_clk'})(Module())
<attie>
the longer the identifiers get the harder it gets to see what is going on
<attie>
self.submodules.in_fifo = [ClockDomainsRenamer({"write":"stream", "read":"sys"}) (AsyncFIFO(width=msg_len, depth=64)) for j in range(config.addresslayout.num_fpga - 1)]
<attie>
a typical line of code illustrating the problem
<cr1901_modern>
yea okay, that kinda bites
<cr1901_modern>
where's "j" used?
<attie>
it's not in this particular line of code
<attie>
I could've used _ but i like keeping the identifier in all mentions of the same list so I don't accidentally use the wrong one somewhere
<cr1901_modern>
Tbh I didn't know "self.submodules.identifier" would accept a list
<cr1901_modern>
I thought that was only legal when doing self.submodules += [anonymous_list_of_submodules]
<attie>
nope, works fine!
<sb0>
whitequark: can all syscalls become methods of the core device object? we need a way to simulate them to test complex driver/phy interfaces
<attie>
probably gets handed off to the same place internally?
<cr1901_modern>
Probably... will have to try it myself
<attie>
not actually a common subfunction but the code is the same in either case
<attie>
self._fm._submodules += [(name, e) for e in _flat_list(value)]
<attie>
self._fm._submodules += [(None, e) for e in _flat_list(other)]
<cr1901_modern>
... huh ._.
<sb0>
it should be doable to implement odd clock periods without the big rounding error
<sb0>
just add a jitter of 1 tick on every other falling edge (which is not used anyway except to make VCD readers happy) when it's odd
<attie>
sb0: once you can handle 4.5, you can handle 5.33 too, right?
<sb0>
iirc clocks have to be integer, because they have to be integer in the vcd
<attie>
I was thinking of using a higher resolution
<sb0>
that's equivalent to multiplying all the integers by the same number
<attie>
yep
<attie>
but the time on the axis would allow you to actually find a given time
<attie>
if my testbench tells me something went wrong at cycle 1835
<attie>
and you multiply everything by some random value it gets hard to tell where that is
<cr1901_modern>
sb0: Is there anything in my linked doc that's blatantly incorrect? Most of the stuff is in the manual, but I needed it presented in a different way (perhaps I could also add it to the manual)
<sb0>
cr1901_modern: looks fine, i don't know what the i/o signal request has to do with it
<sb0>
attie: you can do renamer = ClockDomainsRenamer({"write":"stream", "read":"sys"}) and then reuse it in the list comprehension
<cr1901_modern>
sb0: The i/o signal request is relevant because if you don't create _any_ clock domains and you use migen.build, you get one set of behavior (create a default clock domain, request a default i/o clock) >>
<attie>
hmm, I could, but then it gets dangerous to reorder statements
<cr1901_modern>
and if you create _any_ clock domain manually, you get a different set of behavior
<cr1901_modern>
And it's thrown me and a number of ppl off expecting that the sys clock domain is handled specially in migen.build even if I created other clock domains manually
<sb0>
cr1901_modern: so change the test to "is sys defined" rather than "is any clock domain defined"?
<cr1901_modern>
Sure, if it doesn't break stuff (don't see why not, but hey I broke the tests w/ my last PR), I'd love to do that. Will look into it once I finish fixing the tests.
<sb0>
whitequark: what is syscall() supposed to do when its argument is a string?
<sb0>
whitequark: shouldn't it be syscall=arg instead of syscall=function.__name__?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_florent__ has joined #m-labs
early` has joined #m-labs
awygle_ has joined #m-labs
<attie>
by the way, sb0, are you planning to make it possible to export parametrized modules when you do the hierarchical export?
<attie>
well, they would have a default value I suppose, and when simulating either the value would be bound already or you use the default
<attie>
what kind of analysis are we talking here?
<sb0>
even something as simple as len(some_expression)
<sb0>
if you have some core that does something based on the length of a signal that's given to it, which happens regularly, and then you make that length a parameter
<attie>
hmm I see
<sb0>
if len() assumes the default parameter value, the the core will break when you change the parameter from vwerilog...
<q3k>
ie does the platform output/save the bitstream filename somewhere?
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
mauz555 has quit [Remote host closed the connection]
<whitequark>
nopd
<whitequark>
8nope
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit []
rohitksingh has quit [Ping timeout: 272 seconds]
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1142: Honestly I am not sure how necessary this is as an ARTIQ feature; we have already written simple "set DDS"-type experiments that achieve the desired injection, and I think that this is a cleaner way of doing it than having implicit experiment submissions coming from the DDS panel, especially given the potential for latency (e.g. if another experiment is already runni