06:52 <sb0> rjo, the PDQ has 3 DACs but only one set of frame control signals. how do you set which frame number configures which DAC(s)?

11:06 <sb0> rjo, do you have a good name to propose for the migen/misoc merger you were advocating a while ago?

12:25 <ysionneau> you wanna merge the two repo together?

12:25 <ysionneau> Btw, for those interested, I will do a quick presentation (demo/tutorial) of migen/misoc in Munich in a few days : https://tum-lis.github.io/orconf2014/

12:26 <ysionneau> on Sunday 12 October

12:50 <sb0> great!

12:51 <sb0> oh, the risc-v folks are here. tell them that their processor is unusable due to bloat ;-)

12:52 <ysionneau> ahah sure, 15k LUT, right?

12:52 <ysionneau> Openrisc is 4k? lm32 3k?

12:53 <sb0> yes, risc-v are 15k.

12:54 <sb0> and iirc lm32 1.4k, mor1kx 2.4k (not totally sure about those last two numbers)

12:54 <ysionneau> the different is huge

12:54 <ysionneau> risc-v is using distributed ram instead of blockram ? ^^"

12:56 <sb0> no. according to the synth report, only a relatively small portion of the LUTs is distributed RAM.

12:56 <sb0> and since they love wrestling with ARM so much, it'd be interesting to pull some number on cortex-m1 or similar

12:58 <sb0> and yes, the difference is that huge. but few things that come out of academia really surprise me these days...

13:02 <ysionneau> Did they release everything yet?

13:02 <ysionneau> I think something was missing

13:02 <ysionneau> some code generator

13:03 <stekern> the numbers fluctate a bit, the last I got was 1.5k/2.2k

13:11 <sb0> ysionneau, they released some pre-generated verilog as part of their demo design which - hilariously - runs on zynq, probably for academic publication cred

13:11 <ysionneau> ah ok so you still cannot regenerate the verilog from their weird language core

13:12 <ysionneau> maybe the issue is in their generator ...

13:12 <ysionneau> I guess Julius will be able to do something better with LowRisc :)

13:12 <sb0> afaict chisel is like migen, but based on scala instead of python

13:13 <sb0> there are not that many ways it can be blamed for a bloated design

13:13 <ysionneau> do you know of a decent super scalar and/or out of order RISC cpu (open source of course)?

13:15 <sb0> this "rocket" risc-v core is in-order. so the OOO/superscalar features are not the reason of the bloat...

13:15 <sb0> and no. in the open source world, we barely have halfway decent CPU cores...

13:16 <sb0> OOO is luxury

13:17 <ysionneau> it seems there is a superscalar OOO implementation of OpenRISC

13:18 <sb0> "Lampret is still refining OpenRISC and has a superscalar version of the core, dubbed OpenRISC 1002, that's optimized for speed. The dual-issue OpenRISC should operate at 170 MHz in a Xilinx XCV-E FPGA and offer about 250 Mips of performance, Lampret said."

13:18 <sb0> in 2000

13:19 <sb0> he should quit engineering and work in politics.

13:21 <ysionneau> =)

13:21 <ysionneau> there is "Woof" as well, which is OOO superscalar (dual issue) OpenRISC implem

13:21 <ysionneau> so far all I can find about it is a pptx though =)

15:04 <stekern> ysionneau: that looks fairly much like vapourware ;)

15:05 <stekern> I want to do a dual-issue OOO implementation though

15:12 <kristianpaul> lol

15:25 <ysionneau> stekern: ah ! super cool!

15:26 <ysionneau> OOO can squeeze nice performances when done correctly

15:26 <ysionneau> on usome workflows

15:26 <ysionneau> on some*

15:27 <ysionneau> workloads*

17:30 <rjo> sb0: the frame and trigger signals are global across dacs and across the boards in a stack (behind one usb-to-parallel converter) and we usually interconnect stacks as well.

17:30 <rjo> sb0: yeah i came up with a great new name: migen ;)

18:29 <rjo> sb0: in the long run you might want something like a standard library and "cman" (comprehensive migen archive network) or "mipi" (migen package index) instead of bundling... ;)