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
<cr1901_modern>
sb0: Did that riscv to lm32 translation layer ever go anywhere?
<sb0>
no
<sb0>
you mean the modified lm32 to run riscv?
<cr1901_modern>
sb0: Yes.
<rqou>
wait what
<cr1901_modern>
rqou: Don't remember who did it, but someone used to idle in this room, and they were working on making the lm32 core accept riscv insns
<cr1901_modern>
b/c they're similar enough that a conversion is doable
<rqou>
wouldn't that just make it a riscv core?
<cr1901_modern>
rqou: Indeed, but sb0 doesn't like the existing riscv impls
<rqou>
i dare you to use my riscv implementation :P
<cr1901_modern>
sb0: Why is that, btw? I never asked specifically, just I know you don't care for the _impls_.
<rqou>
anyways, my riscv implementation was a shitty 3-stage pipeline that had all of the complexity of a 5-stage pipeline but none of the speed advantages
<rqou>
combined with a .ucf for the ml505 virtex-5 to just barely run at 100mhz
<rqou>
good enough to turn in as a class project :P
<cr1901_modern>
rqou: If I'm being perfectly honest, I've never designed _any_ circuit that ran at 100MHz (except for testing the limits of ice40's PLL, which doesn't count) :P. Then again I never had access to a virtex
<rqou>
oh this wasn't my board or anything
<rqou>
it's a classroom board
<rqou>
anyways, cr1901_modern:
<rqou>
"Timing estimate: 11.24 ns (88.99 MHz)"
<rqou>
this is my <redacted> rom dumper design
<rqou>
and this is on a not-particularly-fast ice40
<cr1901_modern>
4k/8k or 1k?
<rqou>
8k
<cr1901_modern>
Ahhh, that might explain it, I only have a 1k
<rqou>
is the 1k slower?
<cr1901_modern>
Well space constrained and I assume it's related
<rqou>
usually smaller parts are faster
<cr1901_modern>
Oh, well maybe I just suck at creating fast designs... totally possible
<sb0>
rqou, why one do that? because most other riscv implementations, like yours, have shitty pipelines (or none at all) that have the complexity and resource usage of lm32 without the performance.
<rqou>
i see
<rqou>
hey, my excuse is that it was a class project :P
<sb0>
the idea is that because lm32 and rv instruction sets are rather similar, one could take the lm32 and make only minor modifications to it (mostly instruction decoder) to make a decent riscv core
<rqou>
i learned how not to do it
<cr1901_modern>
sb0: What's your opinion on Rocket?
<cr1901_modern>
I meant boom*, not Rocket; the out-of-order riscv core.
<sb0>
unusable for fpga, seems to work on asic
<rqou>
what implementation is in the sifive microcontroller?
<sb0>
that one
<sb0>
rocket
<cr1901_modern>
rocket is a generator; boom apparently can be used w/ it.
<cr1901_modern>
I like lm32's pipeline, and if I were to do a CPU I'd do riscv but with the same pipeline as lm32.
<cr1901_modern>
B/c for better or worse, even if lm32 is the better design, lm32's _toolchain_ is stagnant.
<cr1901_modern>
For now...
<rqou>
didn't the toolchain get upstreamed?
<rqou>
i know lm32 kernel support didn't though
<cr1901_modern>
well ysionnea1 wrote an MMU for lm32, there was an EdgeBSD port for it IIRC
<cr1901_modern>
rqou: Yes, toolchain is upstreamed, but it's still a vendor-supplied port for a non-mainstream arch. I.e. "good enough".
<sb0>
is that MMU really working?
<cr1901_modern>
sb0: I've never used it, but I assume you signed off on it. And it's not like lm32 impl has changed in any appreciable capacity
rohitksingh_work has joined #m-labs
froggytoad has joined #m-labs
<cr1901_modern>
rqou, sb0: While it's on my mind, there is another reason to prefer lm32 over riscv- single implementation. riscv only specifies a few microarchitectural things like "implementations must have no delay slots", and they refuse to support custom instructions upstream. This leads me to believe that custom microarch tailoring also won't be supported, so the generated gcc isn't going to be "optimal" for a given impl.
_whitelogger has joined #m-labs
FabM has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<sb0>
rjo, do you want to do all the SPI DAC and ADC development?
<sb0>
writing the basic Zotino driver is something that mntng can do
<sb0>
FYI I already requested one Zotino for HK. but it's delayed because of this current consumption issue that Greg found. I don't strictly need adapters for connecting it to the KC705, I can hack something together
<sb0>
if things are in the HK lab, I can also leave them connected to the computer for remote use
<Ishan_Bansal>
attie : Remember you ask me the difference between the two statements
<GitHub166>
[artiq] hartytp commented on issue #780: > @gkasprow It looks like the I/O direction choosing IC on fmc-vhdci adapter has an ill defined power-on state. This is SN74LV595APWT. Is that right? Working now on figuring out how to initialize it for all-output.... https://github.com/m-labs/artiq/issues/780#issuecomment-316435950
<GitHub1>
pdq/master a9cf489 Robert Jordens: doc: update requirements
<GitHub15>
[artiq] jbqubit commented on issue #780: I can now successfully drive output on 3U BNC. Thanks to @npisenti for help playing with the SN74LV595APWT. It's not a full driver but enough to get basic stuff working the lab. See the following commit. ... https://github.com/m-labs/artiq/issues/780#issuecomment-316451176
sb0 has joined #m-labs
<sb0>
whitequark, i suggest they package the releases. we'll make a 0.5 soon (coincident with artiq 3.0rc1)
<sb0>
Ishan_Bansal, I suppose you need Array (see examples)
kyak has joined #m-labs
kyak has joined #m-labs
sb0 has quit [Quit: Leaving]
rohitksingh has quit [Quit: Leaving.]
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.2.0/20170613225334]]
<GitHub76>
[artiq] npisenti commented on issue #780: An additional caveat here too that @jbqubit and I realized today is if you're using KC705 + fmc adapters, you'll also have to synchronize the lvds buffer directionality on the fmc -> vhdci boards. This is potentially more problematic (unless I've misread the data sheet), since they are set via shift register with a global latch which might mean undesirable directionality on other i/o lines during the reprog