| --- Log opened Thu Oct 22 00:00:36 2015 | ||
| stekern | andrzejr: cool, could you do a pull request for it? | 05:38 |
|---|---|---|
| wbx | stekern: ping | 07:16 |
| stekern | pong | 07:16 |
| wbx | stekern: you made the musl port, right? | 07:17 |
| stekern | yes | 07:17 |
| wbx | stekern: 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 |
| stekern | I only used or1ksim and real hw | 07:18 |
| wbx | okay. good to know. so I should try or1ksim. | 07:19 |
| robtaylor | anyone spent any time looking at LEAP? | 12:20 |
| robtaylor | or latency-insensitive channels? | 12:20 |
| juliusb_ | LEAP? | 13:22 |
| robtaylor | juliusb_: https://github.com/LEAP-FPGA/leap-documentation/wiki | 13:24 |
| wallento | " To get started with LEAP, you need AWB" | 13:38 |
| wallento | seems you first need to learn many acronyms | 13:39 |
| robtaylor | yeah, its pretty obscurely done | 13: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 |
| wallento | sounds 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 hell | 13:52 | |
| robtaylor | juliusb_: basically just an abstract in-order channel | 13:52 |
| wallento | and? | 13:53 |
| juliusb_ | I don't really understand the problem TBH, but in-order = use a FIFO | 13:53 |
| juliusb_ | :) | 13:53 |
| robtaylor | juliusb_: and you substitute it depending on your depolyment hardware - aimed at accelerators | 13:53 |
| juliusb_ | sure, standardising how you shovel data or control around, fair enough | 13:53 |
| wallento | I am out of academia for four months and even I don't understand this | 13:53 |
| robtaylor | so my channel may be concretely, e.g. a QPI link | 13:53 |
| wallento | like glip.io ;) | 13:53 |
| robtaylor | yep :) | 13:54 |
| robtaylor | LEAP also has some intersting looking bits for scratchpad and coherence scratchpad ram | 13:54 |
| juliusb_ | a candidate for inclusion on librecores.org | 13:54 |
| robtaylor | for communiating with the host | 13:54 |
| wallento | I don't get the latency-insensitive | 13:54 |
| robtaylor | basically, think of the stuff Guarav was presenting | 13:54 |
| robtaylor | wallento: well, its more a design statment - when this is "deployed", we wont' know the latencey, and you're probably in differnt clock domains | 13: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 :P | 13:55 |
| wallento | wouldn't that be the standard case? | 13:55 |
| robtaylor | at least, thats my very rudimenatary understanding ;) | 13:55 |
| robtaylor | juliusb_: yuo | 13:56 |
| juliusb_ | Bluespec were talking about releasing some tools for free when I chatted to them at the RISC-V thing in Jan | 13:56 |
| robtaylor | yeah, though i've heard nothing since | 13:56 |
| robtaylor | well, apart from same discussion in june | 13:57 |
| robtaylor | i offered some help, it wasnt accepted | 13:57 |
| robtaylor | tbf i find bsv horribly illegible, so i don't really care... ;) | 13:58 |
| wallento | so the main offering is best effort communication (which is a standardized term for "latency-insensitive") | 13:58 |
| robtaylor | wallento: best effort implies you may have packet loss (in NoC/interconnect terms) | 13:59 |
| wallento | no | 13:59 |
| wallento | best effort vs. guarantees | 13:59 |
| wallento | usually does not involve loss | 13:59 |
| wallento | lossy is an orthogonal issue | 13:59 |
| wallento | guarantees are hard to match with lossy nocs | 13:59 |
| robtaylor | mm, yes, depends on your routing appraoch | 14:00 |
| robtaylor | (preallocated channels etc) | 14:01 |
| wallento | lossy is lossy ;) | 14:01 |
| wallento | even pre-allocated | 14:01 |
| wallento | but what you mean is exactly the QoS vs. best effort discussion | 14:01 |
| wallento | for nocs | 14:01 |
| wallento | another big hype | 14:01 |
| wallento | :) | 14:01 |
| robtaylor | mm, lossy is too loose a term | 14:02 |
| robtaylor | teh distinction is guaranteed delivery *if sent*, versus non guaranteed delivery | 14:02 |
| wallento | lossy nocs are exposed to sporadic failures | 14:02 |
| robtaylor | only if they're badly designed. which most are, i hear.. | 14:02 |
| wallento | no | 14:03 |
| wallento | due to noise, crosstalk, defects | 14:03 |
| wallento | thats the current big thing in nocs I suppose | 14:03 |
| robtaylor | ah, ok, though those must be design tradeoffs | 14:04 |
| wallento | some are due to technology shrinking | 14:04 |
| wallento | but there are no real numbers out there | 14:04 |
| wallento | and until now everything is supposedly lossless in reality | 14:05 |
| robtaylor | makes sense | 14:05 |
| wallento | but academia thinks ahead (or just creates its own truth to do something new) | 14:05 |
| wallento | ;) | 14:05 |
| robtaylor | anyhow, this stuff isn't really about nocs per se - its more about development and deployment | 14:06 |
| wallento | yeah, from what I read it seems they are into this FPGA in the loop thing | 14:07 |
| wallento | on the FSB | 14:07 |
| robtaylor | yep | 14:08 |
| robtaylor | QPI | 14:08 |
| wallento | too big data-ish for me ;) | 14:09 |
| robtaylor | yeah. I think this is the problem Intel will have | 14:09 |
| robtaylor | too softwarey for hardware guys, too hardwarey for software guys | 14:10 |
| wallento | such 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 |
| wallento | yes, exactly | 14:11 |
| * robtaylor was glad when clifford asked the intel guy about documenting the bitstream | 14:12 | |
| robtaylor | s/vivado/quartus ;) | 14:13 |
| robtaylor | wallento: 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 https://github.com/LEAP-Core/leap-platforms-intel/tree/master/modules/leap/virtual-platform/physical-channel/qa | 15:00 |
| juliusb_ | bsv that is? | 15:02 |
| -!- Netsplit *.net <-> *.split quits: Empyrium, trevorman, poke53281 | 15:06 | |
| -!- Netsplit over, joins: poke53281 | 15:11 | |
| robtaylor | juliusb_: i'm assuming so, filenames are just .sv though | 15:15 |
| -!- Empyrium_ is now known as Empyrium | 15:21 | |
| juliusb_ | .bsv I see | 15:28 |
| juliusb_ | and what's in it aint system verilog | 15:28 |
| robtaylor | juliusb_: *nod* the *.sv is elswhere https://github.com/LEAP-Core/leap-platforms-intel/tree/master/modules/bluespec/common/fpgaenv/physical-platform/physical-devices/qa/qa_driver | 15:35 |
| homeless | olofk: hi | 17:36 |
| homeless | I saw you have changed bootrom.S for de0nano in openrisc v3 | 17:37 |
| homeless | I didn't understand some assembly codes here | 17:38 |
| homeless | for example "l.jr r9" | 17:38 |
| homeless | You have never assigned any value to r9 | 17:39 |
| homeless | So how can u use it? | 17:39 |
| homeless | It is one line before the last line | 17:40 |
| homeless | To all: Do you have any bootrom.S f | 17:40 |
| homeless | Sorry :) | 17:41 |
| homeless | To all: Do you have any bootrom.S file for openrisc v3 system for atlys board | 17:41 |
| homeless | I modified the spi_uimage_loader.S (changed the BOOTROM_ADDR) and used it in v3 but no luck | 17:43 |
| homeless | Can somebody point me to right direction here? | 17:44 |
| stekern | homeless: r9 is a special register, the value of PC+8 is set to it when an l.jal or l.jalr instruction is executed | 18:18 |
| homeless | stekern: I see.. Thanks very much. | 18:25 |
| homeless | stekern: Are you using atlys board for openrisc v3? | 18:26 |
| stekern | I did... until it broke | 18:27 |
| stekern | the board that is | 18:27 |
| homeless | Do you have a working bootrom.S file? | 18:27 |
| homeless | for atlys board I mean | 18:27 |
| homeless | In my setup I couldn't get it run with bootrom.v. Instead I instantiated a blockram with initial conditions. | 18:29 |
| homeless | I wrote some small assembly codes. They work with using the blockram | 18:30 |
| homeless | But not with the spiboot content | 18:30 |
| homeless | stekern: are you there? | 18:31 |
| stekern | yeah, no, I never used spiboot with fusesoc | 18:31 |
| homeless | Ok so how do you use it? I mean openrisc v3? | 18:32 |
| homeless | in openriscv3, did you use the same bootrom.S that we have in orpsoc-v2? | 18:36 |
| homeless | stekern: ??? | 18:56 |
| stekern | no, I used a bootrom that just spins and loaded with jtag | 18:57 |
| stekern | as I said, my atlys board unfortunately broke down shortly after I done the fusesoc port for it | 18:58 |
| homeless | ok thanks | 18:59 |
| bandvig | homeless: some time ago I posted my bootrom.S on http://pastie.org/ (? do not remember exactly), so you can brose log of the chat. | 19:24 |
| homeless | bandvig: Can you please send again? | 19:25 |
| homeless | Ok I found your bootrom.v | 19:26 |
| homeless | But Can you please send the assembly file bootrom.S | 19:27 |
| homeless | bandvig: are you there? | 19:29 |
| bandvig | as far as I remember the assembly code is already in bootrom.v as comments :) | 19:31 |
| bandvig | any way, here you are http://pastie.org/10500516 | 19:32 |
| homeless | Thanks. I will try this | 19:33 |
| homeless | bandvig: Should I define anything before the compilation? | 19:40 |
| homeless | BOOTROM_LOOP_LEDS ? | 19:41 |
| bandvig | for compilation you need board.h http://pastie.org/10500546 | 19:45 |
| bandvig | BOOTROM_LOOP_LEDS - I just played with round switching LEDs here | 19:46 |
| homeless | Ok. I see. Thank you. | 19:46 |
| bandvig | The actual correct selection is BOOTROM_SPI_FLASH of cause | 19:46 |
| homeless | So this works with on atlys board with openrisc-v3? | 19:47 |
| bandvig | yes for me at least, also I removed from my Atlys project VGA0, AC97, PS2_* modules by commenting appropriate strings in orpsoc-defines.v | 19:49 |
| homeless | I am gonna do that | 19:53 |
| homeless | remove the unnecessary parts | 19:53 |
| homeless | bandvig: Can I ask which ISE version are you using? | 20:08 |
| bandvig | 14.6 (nt64) | 20:09 |
| homeless | Thanks mine is 14.7 linux 64 bit | 20:10 |
| homeless | I have read the bootrom.S file there is no functional difference between yours and the bootrom.S of openriscv2. You just inserted led lit code | 20:11 |
| homeless | Am I correct? | 20:12 |
| bandvig | actually, yes | 20:13 |
| homeless | So it is still mistery why my setup doesn't work | 20:14 |
| bandvig | there was a bug related wide of address bus connected to rom module, but as I know it was fixed | 20:15 |
| bandvig | additionally, I use U-Boot placed in SPI flash | 20:16 |
| bandvig | and 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 application | 20:19 |
| bandvig | On 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 properly | 20:21 |
| bandvig | well, I gonna sleep | 20:22 |
| andrzejr | stekern, sent the pull request | 20:37 |
| andrzejr | Is 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 |
| andrzejr | I 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!