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
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
sb0_ has joined #m-labs
sb0_ has quit [Client Quit]
<sb0>
rjo, don't you want to see a spectrum, e.g. to check for single-mode operation?
<rjo>
the counter spitting out garbage is indication enough.
<sb0>
well "garbage" is hard to debug
<sb0>
don't you want to see how many modes there are etc.?
<sb0>
re. cpld support: can you put that into migen/build directly?
<sb0>
maybe FT'ing a ~1MHz signal was difficult when those devices were designed?
<rjo>
no. number of modes doesn't tell you much as long as there are multiple.
<rjo>
you have to FT two signals. and there are multiple other effects that compete with your signal if you do FT and not just counting. counting is incredibly robust
<rjo>
and a wavemeter would not be my tool of choice to tune up a laser.
<rjo>
sb0: sure. but it needs ripping out a bunch of things in _run_ise()
<rjo>
there is so much ad-hoc stuff there that i am reluctant to touch it.
<sb0>
what would be your tool of choice?
<rjo>
a cavity.
<sb0>
fp interferometer? why is it better than a wavemeter?
<sb0>
faster response time?
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
<rjo>
and better view of the modes, higher dynamic range, mode shape.
rohitksingh has joined #m-labs
key2 has joined #m-labs
<key2>
hi
<key2>
I want to have a "csr storage" that is 256byte long. what is the clean way to do that ? should I declare a big CSR of 256*8 ? should I declare 256 CSR of size 8 ? or there is a way to map a memory ?
<cr1901_modern>
key2: Check out the identifier peripheral... h/o two secs
<key2>
So if I do a CSRBank on a module that has CSRS + Identifier() for example, it should map it's mem ?
<cr1901_modern>
Well, identifier doesn't use a CSRBank... it just initializes a Memory and the SoCCore class "knows to do the right thing"
<cr1901_modern>
Identifier() class exports a get_memories() function. CSRBankArray() looks for whether a Module you want to put on the bus has get_memories() function and sticks it somewhere on the CSR bus if it does.
<cr1901_modern>
Misoc uses introspection like that all over the place. Lets it do cool things like automatically infer SRAMs, CSR registers of classes-within-classes, etc. But it's still wacky
<key2>
I see
<key2>
so basically if I was not using a SOC
<key2>
but a wisbhone point ot point
<key2>
i could use it on Identifier() ?
<cr1901_modern>
key2: Well, the wishbone module come with a Wishbone.SRAM class. In that case what I would do is just pass in the return value from Memory.get_port() to the Wishbone.SRAM class
<key2>
yes but your ram would be in the same addr range as your other CSRs ?
<cr1901_modern>
No, it wouldn't. If you want to access a CSR bus from a Wishbone point-to-point, use Wishbone2CSR
<key2>
ok
<key2>
but then how would I manage to have a core that has CSR + Memory on the same bus ?
<key2>
as if the Memory was an array of CSRs
<cr1901_modern>
CSRBankArray will automatically ensure each CSR peripheral (even Identifier, which is just a "memory", is a CSR peripheral) gets its own slice of address space.
<key2>
mmh
<key2>
let me try to dig that
<key2>
what would be the syntax of CSRBankArray when using Identifier() ?
<cr1901_modern>
key2: H/o... looking at how Misoc does it (I understand you don't want a full SoC, but the SoCCore class is basically the docs on how to use everything else)
<key2>
but i was trying to find out what to put for self.get_csr_dev_address,
<key2>
which should be a func with 3 arg
<key2>
so at the end csrbankarray will hit the get_memories() of identifier
<cr1901_modern>
"so at the end csrbankarray will hit the get_memories() of identifier" <-- That's CSRBankArray constructor's responsibility
<cr1901_modern>
it'll automatically detect it, so you don't need to do anything
<cr1901_modern>
erm, let me rephrase: it'll automatically detect that your CSR device has a get_memories() function exported
<cr1901_modern>
key2: ^^ (Sorry forgot to notify)
<key2>
mmh
<key2>
well what should I put there then ?
<cr1901_modern>
key2: Now you're making me think :P, give me a minute
<key2>
hahaha
<key2>
:)
<key2>
I want to do that the clean way, I could always find another way of course. but don't think that if I do a Case() with 256 CSR() that would be clean.
<cr1901_modern>
key2: No, you don't need to do that. At the very least, SoCCore doesn't. What's confusing me is that SoCCore's get_csr_device_address function only returns the index() into the csr_devices array. I.e. a number from 0 to array.len() exclusive.
<cr1901_modern>
CSRBank is specific to a single CSR peripheral. The address decoding is done against the 9th address bit and above
<cr1901_modern>
this means no matter what, each CSR peripheral in a CSRBankArray is given an address space of 512 bytes.
<key2>
ok
<cr1901_modern>
So your get_csr_device_address function should return a number represents "which 512-byte chunk of address space I want"
<key2>
ok
<cr1901_modern>
0 represents "first 512 bytes", 1 represents "second 512 bytes", 2 represents "offset 1024 into the CSRBankArray", etc
<cr1901_modern>
up to the power of two that exhaust the number of address bits you have for your CSR bus :)
<key2>
at least it does something :0
<cr1901_modern>
CSR peripherals seem inherently limited to 512 bit chunks (why do I remember this value being configurable?)
* cr1901_modern
is checking a SoC he already has generated just to make sure he understands the code correctly
<cr1901_modern>
key2: I screwed up my numbers somewhere... I meant 1024-bit chunks.* And additionally in my SoC design I'm looking at, the CSR bus begins at 0xe0000800. bit 10, not bit 9 is set, so CSRBankArray must've skipped over two devices (starting from offset 2)
<cr1901_modern>
key2: Right now I can't do the math in my head, but something to keep in mind is that CSR is 8-bit, and Wishbone (as provided by MiSoC) is 32-bit, so the addresses you're trying to access will be offset by 2-bits
<cr1901_modern>
(I.e. lower 2 addr bits unused in Wishbone)
mumptai has joined #m-labs
<key2>
Ha i'm gonna giveup and use a SoC
rohitksingh has quit [Read error: Connection reset by peer]