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
mumptai has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0>
mithro, or hook up your vhdl simulator with migen
<sb0>
myhdl does that for at least verilog, look at it
<mithro>
sb0: I think you mean mumptai who left the channel?
<cr1901_modern>
sb0: Didn't you say yourself that adding verilog sim support to the migen simulator was nontrivial b/c of synchronization issues? I don't remember the details of the conversation, other than it's "nontrivial"
<sb0>
rjo, did you hear anything back from BBN about the GTH JESD204 port?
<sb0>
cr1901_modern, and no, misoc_extra_software_packages() won't touch the bios
<sb0>
whitequark, please use version numbers and dependencies. the current artiq 3.0.dev with pythonparser 0.0-py_5 and works with 0.0-py_6, but updating artiq won't automatically update pythonparser
<sb0>
*crashes with pythonparser 0.0-py_5
<cr1901_modern>
sb0: Yea, turns out I couldn't use the bios anyway, so I just manually reset _software_packages and added my own
<cr1901_modern>
(bios needed a UART, I have a design where I don't need nor want the UART b/c I need FT245 queue mode)
<sb0>
whitequark, also artiq_run blocks forever on socket RX, I suppose this is the same bug that breaks the unittest
<sb0>
(socket RX for check_ident())
fengling has joined #m-labs
kuldeep has quit [Ping timeout: 244 seconds]
kuldeep has joined #m-labs
stekern has quit [Ping timeout: 244 seconds]
rohitksingh has joined #m-labs
mumptai has quit [Remote host closed the connection]
stekern has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
<cr1901_modern>
sb0: What is the design rationale for wishbone devices getting 256MB of addr space in MiSoC?
<cr1901_modern>
emphasis devices, not memory
<cr1901_modern>
Contrast to "not making the devices internal buffers visible in the addr space, and using a DMA controller to transfer internal device buffers to main RAM using a small set of addresses per device"
<sb0>
decoding on a few address bits is the simplest thing to do
<sb0>
the sdram itself is a wishbone device
<cr1901_modern>
sb0: But doesn't this also mean you're limited to 256MB of sdram total? More than enough for now, but shrinking the allocations for i/o devices prob can't hurt in the future
<cr1901_modern>
And also, a DMA controller is gonna be faster than moving io device buffers to main memory
<sb0>
this has nothing to do with DMA controllers
<sb0>
and yes, but you can override the decoding function if you want
<sb0>
but using the same one for all devices is simpler
<sb0>
and small comparators are smaller and faster
<cr1901_modern>
Fair enough.
<cr1901_modern>
"this has nothing to do with DMA controllers" All I was getting at is that if for whatever reason MiSoC eventually supports boards with up to 2GB of RAM, the number of addresses reserved for I/O devices total will have to shrink dramatically. >>
<cr1901_modern>
So instead of doing memcpy over contiguous addresses, one would have to keep reading from the same set of memory addresses to grab each 32 bits individually when they wanted to get data from an I/O device
<cr1901_modern>
that is a good use case for impl a DMAC for MiSoC IMO.
<sb0>
I/O devices use almost none of their allocated space
<sb0>
note that more address space doesn't imply more resource usage, but the opposite.
<sb0>
smaller address spaces require more comparator bits
<cr1901_modern>
And that slows down the core
<cr1901_modern>
well slows down the max speed possible*
<sb0>
also, for DMA, you don't want to pump in and out of the same bus anyway
<cr1901_modern>
Is there a mux to choose between whether you're using the CPU bus or the DMA bus?
<cr1901_modern>
at the interface to memory*
<cr1901_modern>
(Btw, reason I'm asking this: I haven't actually implemented a wishbone IO device for MiSoC yet, but I think I'm going to need to. Simple DAQ interface to test a third-party FPGA core, litescope is overkill)
acathla has quit [Ping timeout: 252 seconds]
acathla has joined #m-labs
<cr1901_modern>
I assume the convention for MiSoC cores is "wait for device interrupt signifying 'input buffer full', and then copy over all the data to main memory at once via memcpy"?
acathla has quit [Ping timeout: 244 seconds]
acathla has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
<rjo>
sb0: 2392113 looks good. it might be nice to just generate a vivado clock net for every migen clock domain.
<rjo>
sb0: iirc the scansta thing is transparent/automaticall deactivated if we roll our stuff.
<rjo>
sb0: he just replied saying that they will decide whether the jesd latency is something they can live at all and whether they would use our jesd204b core. a week or so i guess.
<rjo>
larsc: from the top of your head, do you know of any adi board using the hmc7044 with an adc or dac?
<sb0>
rjo, vivado doesn't let you create a clock without a period
<rjo>
sb0: ah.
stekern has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 245 seconds]
<GitHub77>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vXmfW
<GitHub77>
artiq/master 617e345 whitequark: gateware: fix kernel CPU exec address.
fengling has joined #m-labs
stekern has joined #m-labs
rohitksingh has joined #m-labs
<whitequark>
sb0: uhm, is lab. down ?
<whitequark>
ah no
fengling has quit [Ping timeout: 268 seconds]
<larsc>
rjo: I know a board, but I don't know the name ;)