IRC logs for #openrisc Thursday, 2015-10-22

--- Log opened Thu Oct 22 00:00:36 2015
stekernandrzejr: cool, could you do a pull request for it?05:38
wbxstekern: ping07:16
wbxstekern: you made the musl port, right?07:17
wbxstekern: did you ever use qemu to test your musl stuff? or always on real hardware? wanna do some test runs via qemu-system-or32.07:18
stekernI only used or1ksim and real hw07:18
wbxokay. good to know. so I should try or1ksim.07:19
robtayloranyone spent any time looking at LEAP?12:20
robtayloror latency-insensitive channels?12:20
wallento" To get started with LEAP, you need AWB"13:38
wallentoseems you first need to learn many acronyms13:39
robtayloryeah, its pretty obscurely done13:40
juliusb_I don't get it - some set of peripherals to abstract away interfaces to even more peripherals?13:48
juliusb_"latency-insensitive channel-based communications among multiple heterogeneous platforms" = UARTs + interrupts?13:50
wallentosounds really academic :)13:51
juliusb_yeah I can imagine an academic spending 4 years on writing a UART and some fancy drivers and bullshitting their way out of it at the end ;)13:52
* robtaylor finds himself in a world of perl hell13:52
robtaylorjuliusb_: basically just an abstract in-order channel13:52
juliusb_I don't really understand the problem TBH, but in-order = use a FIFO13:53
robtaylorjuliusb_: and you substitute it depending on your depolyment hardware - aimed at accelerators13:53
juliusb_sure, standardising how you shovel data or control around, fair enough13:53
wallentoI am out of academia for four months and even I don't understand this13:53
robtaylorso my channel may be concretely, e.g. a QPI link13:53
wallentolike ;)13:53
robtayloryep :)13:54
robtaylorLEAP also has some intersting looking  bits for scratchpad and coherence scratchpad ram13:54
juliusb_a candidate for inclusion on librecores.org13:54
robtaylorfor communiating with the host13:54
wallentoI don't get the latency-insensitive13:54
robtaylorbasically, think of the stuff Guarav was presenting13:54
robtaylorwallento: well, its more a design statment - when this is "deployed", we wont' know the latencey, and you're probably in differnt clock domains13:55
juliusb_and even if you think you nkow what he's on about, you still can't use it because it's written in Bluespec :P13:55
wallentowouldn't that be the standard case?13:55
robtaylorat least, thats my very rudimenatary understanding ;)13:55
robtaylorjuliusb_: yuo13:56
juliusb_Bluespec were talking about releasing some tools for free when I chatted to them at the RISC-V thing in Jan13:56
robtayloryeah, though i've heard nothing since13:56
robtaylorwell, apart from same discussion in june13:57
robtaylori offered some help, it wasnt accepted13:57
robtaylortbf i find bsv horribly illegible, so i don't really care... ;)13:58
wallentoso the main offering is best effort communication (which is a standardized term for "latency-insensitive")13:58
robtaylorwallento: best effort implies you may have packet loss (in NoC/interconnect terms)13:59
wallentobest effort vs. guarantees13:59
wallentousually does not involve loss13:59
wallentolossy is an orthogonal issue13:59
wallentoguarantees are hard to match with lossy nocs13:59
robtaylormm, yes, depends on your routing appraoch14:00
robtaylor(preallocated channels etc)14:01
wallentolossy is lossy ;)14:01
wallentoeven pre-allocated14:01
wallentobut what you mean is exactly the QoS vs. best effort discussion14:01
wallentofor nocs14:01
wallentoanother big hype14:01
robtaylormm, lossy is too loose a term14:02
robtaylorteh distinction is guaranteed delivery *if sent*, versus non guaranteed delivery14:02
wallentolossy nocs are exposed to sporadic failures14:02
robtayloronly if they're badly designed. which most are, i hear..14:02
wallentodue to noise, crosstalk, defects14:03
wallentothats the current big thing in nocs I suppose14:03
robtaylorah, ok, though those must be design tradeoffs14:04
wallentosome are due to technology shrinking14:04
wallentobut there are no real numbers out there14:04
wallentoand until now everything is supposedly lossless in reality14:05
robtaylormakes sense14:05
wallentobut academia thinks ahead (or just creates its own truth to do something new)14:05
robtayloranyhow, this stuff isn't really about nocs per se - its more about development and deployment14:06
wallentoyeah, from what I read it seems they are into this FPGA in the loop thing14:07
wallentoon the FSB14:07
wallentotoo big data-ish for me ;)14:09
robtayloryeah. I think this is the problem Intel will have14:09
robtaylortoo softwarey for hardware guys, too hardwarey for software guys14:10
wallentosuch things have been around for a while now (NI does it in automation for many years already), but now everybody is creating big frameworks around it. in the end vivado will still crash on half of the designs ;)14:11
wallentoyes, exactly14:11
* robtaylor was glad when clifford asked the intel guy about documenting the bitstream 14:12
robtaylors/vivado/quartus ;)14:13
robtaylorwallento: juliusb_: btw, I'm really only interested in this bit, seems there's already open source for communcation between host and FPGA on intel's new stuff - again, shame its in SV
juliusb_bsv that is?15:02
-!- Netsplit *.net <-> *.split quits: Empyrium, trevorman, poke5328115:06
-!- Netsplit over, joins: poke5328115:11
robtaylorjuliusb_: i'm assuming so, filenames are just .sv though15:15
-!- Empyrium_ is now known as Empyrium15:21
juliusb_.bsv I see15:28
juliusb_and what's in it aint system verilog15:28
robtaylorjuliusb_:  *nod* the *.sv is elswhere
homelessolofk: hi17:36
homelessI saw you have changed bootrom.S for de0nano in openrisc v317:37
homelessI didn't understand some assembly codes here17:38
homelessfor example "l.jr r9"17:38
homelessYou have never assigned any value to r917:39
homelessSo how can u use it?17:39
homelessIt is one line before the last line17:40
homelessTo all: Do you have any bootrom.S f17:40
homelessSorry :)17:41
homelessTo all: Do you have any bootrom.S file for openrisc v3 system for atlys board17:41
homelessI modified the spi_uimage_loader.S (changed the BOOTROM_ADDR) and used it in v3 but no luck17:43
homelessCan somebody point me to right direction here?17:44
stekernhomeless: r9 is a special register, the value of PC+8 is set to it when an l.jal or l.jalr instruction is executed18:18
homelessstekern: I see.. Thanks very much.18:25
homelessstekern: Are you using atlys board for openrisc v3?18:26
stekernI did... until it broke18:27
stekernthe board that is18:27
homelessDo you have a working bootrom.S file?18:27
homelessfor atlys board I mean18:27
homelessIn my setup I couldn't get it run with bootrom.v. Instead I instantiated a blockram with initial conditions.18:29
homelessI wrote some small assembly codes. They work with using the blockram18:30
homelessBut not with the spiboot content18:30
homelessstekern: are you there?18:31
stekernyeah, no, I never used spiboot with fusesoc18:31
homelessOk so how do you use it? I mean openrisc v3?18:32
homelessin openriscv3, did you use the same bootrom.S that we have in orpsoc-v2?18:36
homelessstekern: ???18:56
stekernno, I used a bootrom that just spins and loaded with jtag18:57
stekernas I said, my atlys board unfortunately broke down shortly after I done the fusesoc port for it18:58
homelessok thanks18:59
bandvighomeless: some time ago I posted my bootrom.S on (? do not remember exactly), so you can brose log of the chat.19:24
homelessbandvig: Can you please send again?19:25
homelessOk I found your bootrom.v19:26
homelessBut Can you please send the assembly file bootrom.S19:27
homelessbandvig: are you there?19:29
bandvigas far as I remember the assembly code is already in bootrom.v as comments :)19:31
bandvigany way, here you are
homelessThanks. I will try this19:33
homelessbandvig: Should I define anything before the compilation?19:40
homelessBOOTROM_LOOP_LEDS ?19:41
bandvigfor compilation you need board.h
bandvigBOOTROM_LOOP_LEDS - I just played with round switching LEDs here19:46
homelessOk. I see. Thank you.19:46
bandvigThe actual correct selection is BOOTROM_SPI_FLASH of cause19:46
homelessSo this works with on atlys board with openrisc-v3?19:47
bandvigyes for me at least, also I removed from my Atlys project VGA0, AC97, PS2_* modules by commenting appropriate strings in orpsoc-defines.v19:49
homelessI am gonna do that19:53
homelessremove the unnecessary parts19:53
homelessbandvig: Can I ask which ISE version are you using?20:08
bandvig14.6 (nt64)20:09
homelessThanks mine is 14.7 linux 64 bit20:10
homelessI have read the bootrom.S file there is no functional difference between yours and the bootrom.S of openriscv2. You just inserted led lit code20:11
homelessAm I correct?20:12
bandvigactually, yes20:13
homelessSo it is still mistery why my setup doesn't work20:14
bandvigthere was a bug related wide of address bus connected to rom module, but as I know it was fixed20:15
bandvigadditionally, I use U-Boot placed in SPI flash20:16
bandvigand I suppose there is a bug in board initialization sequece (placed by NewLIB toolchain in .elf file), so there is a problem to run stand alone NewLIB-based application20:19
bandvigOn the othe hand, U-Boot perform board initialization itself in correct way, so after loading (by Ethernet or UART) NewLIB-based program it could operate properly20:21
bandvigwell, I gonna sleep20:22
andrzejrstekern, sent the pull request20:37
andrzejrIs there any way to access internal signals in sub-modules at the top level? I want to probe some signals with diila and modifying port lists and instantiations is rather tedious.21:37
andrzejrI found that instance.signal paths are quietly ignored by ise (treaded as zero constants), unless the path contains a generate label, in which case ise reports an error.21:38
--- Log closed Fri Oct 23 00:00:38 2015

Generated by 2.15.2 by Marius Gedminas - find it at!