| --- Log opened Thu Sep 11 00:00:47 2014 | ||
| stekern | olofk: may I suggest that the 'busy' signal is renamed to either 'stall' or invert it and call it 'read_enable'/'write_enable' (re/we)? | 04:00 |
|---|---|---|
| stekern | to me, busy sounds like the core is busy and can't address a request | 04:01 |
| stekern | I think I'd prefer re/we | 04:10 |
| olofk | stekern: Yes, I would like to invert it too, but I couldn't come up with a good name | 06:23 |
| olofk | I'm thinking of using rdy or ready instead, as in AXI4 | 06:26 |
| olofk | Could someone throw me some rough speed/area estimates of mor1kx in different configurations? | 06:44 |
| stekern | olofk: but rdy still sounds like an output, not an input | 07:22 |
| olofk | Heavily inspired by AXI4 here | 07:23 |
| olofk | In which case it's always contra directonal to the data flow | 07:23 |
| poke53281 | stekern ran some benchmarks. I think, the speed is comparable to a Pentium 90. | 07:23 |
| poke53281 | But this depends on his FPGA | 07:24 |
| stekern | olofk: yes, but the rdy signals there are prepended by the 'signal type' name | 07:25 |
| olofk | Isn't that the case here as well? stream_rdy, stream_data, stream_dv? | 07:26 |
| olofk | I love the smell of bikeshedding in the morning :) | 07:26 |
| jagadeesh | stekern: u pointed me to http://pastie.org/7340535# but i have a trouble in cof file's offset hex address and | 07:27 |
| stekern | no, because stream_data and stream_dv are outputs | 07:27 |
| olofk | And stream_rdy is contra directional to that | 07:27 |
| stekern | yes, and that's not how axi4 does it | 07:27 |
| olofk | Yes, it does | 07:27 |
| stekern | afaict at least | 07:27 |
| olofk | I've been doing a lot of AXI4 (Stream to be more exact) the last years | 07:28 |
| stekern | ok, but then axi4 is backwards ;) | 07:29 |
| olofk | Yes, in so many ways, but that's beside the point ;) | 07:30 |
| stekern | my argument is that stream_rdy sounds like stream_data is ready, not that someone wants to acquire data from it | 07:32 |
| olofk | I see your point | 07:32 |
| stekern | for the reader, rdy might make sense | 07:32 |
| stekern | bikeshedding yes ;) | 07:34 |
| stekern | jagadeesh: what's the problem? | 07:34 |
| jagadeesh | the cof file addresses? how do i determine that | 07:35 |
| jagadeesh | the sof data chooses the starting address of epcs followed by hex data | 07:36 |
| stekern | olofk: speed/area estimates. in the minimal cappuccino configuration around 100MHz on cyclone iv, 200MHz on kintex 7. area, according to sb0 - bloated ;) | 07:36 |
| olofk | Can that run Linux comfortably? | 07:37 |
| stekern | jagadeesh: I don't understand the question, I gave you an example http://oompa.chokladfabriken.org/tmp/orpsoc.cof | 07:38 |
| stekern | olofk: that is with the mmu disabled, so no | 07:39 |
| olofk | So, about 80 on CycloneIV with a standardish config? | 07:39 |
| stekern | 85 MHz was the latest figure quartus gave me | 07:40 |
| olofk | cool | 07:40 |
| stekern | jagadeesh: please write your answers here and not in priv | 07:41 |
| stekern | I didn't read the privmsgs | 07:41 |
| jagadeesh | im using this http://pastie.org/9544184 cof file for jic file generation, i dont get the code working. Question: do i have problem with cof file or the bootrom initialization | 07:44 |
| stekern | but you don't have any addresses defined there | 07:45 |
| jagadeesh | yes i dont know how to detemine the address, for the cof i showed u the sof is at start of address and hex is next to it. this i learned for map file | 07:46 |
| jagadeesh | But i think the bootrom reads from epsc start address to laod to sdram am i right | 07:46 |
| jagadeesh | Tel me where i went wrong | 07:47 |
| stekern | you just need to define them so there's enough room | 07:47 |
| jagadeesh | There is no problem with placed of data in epcs i.e 0 to some xxxx for sof and xxxx to xxxx for hex | 07:48 |
| stekern | ok, but then you need to just define the address in the bootrom bootloader | 07:49 |
| jagadeesh | ah thats where i was stuck | 07:49 |
| jagadeesh | tel me is this right: I mention start address of hex to bootrom so that it writes my hex data to sdram from 0x100 | 07:50 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/sw/board/include/board.h | 07:51 |
| jagadeesh | stekern can point to some documentation i dont have proper documents for orpsoc system devlopment | 07:52 |
| stekern | that's the address that was used in orpsocv2 | 07:52 |
| jagadeesh | stekern: is there any document for newbies on orpsocv2 | 08:00 |
| stekern | well, there's the orpsocv2 documentation in the repo | 08:01 |
| stekern | but you shouldn't really bother with orpsocv2 other than stealing the bootrom code from it | 08:02 |
| jagadeesh | yes i got stuck with bootrom code i can run app from sdram.. writing to epcs is my problem | 08:04 |
| stekern | yes, but you got the address now, 0x0b0000 | 08:07 |
| jagadeesh | yes i ll try with this again | 08:09 |
| olofk | stekern: I'm renaming them to data, valid and ready. Both AXI4 and Avalon Stream uses those names | 08:47 |
| stekern | ok, I agree with the consistency in that | 09:11 |
| -!- aburgess_ is now known as aburgess | 09:15 | |
| stekern | olofk: is the idea here to just set a default that can be overridden? https://github.com/olofk/wb_streamer/blob/master/rtl/verilog/wb_stream_writer.v#L5 | 09:18 |
| stekern | i.e. MAX_BURST_LEN can be != 2**FIFO_AW in some cases? | 09:19 |
| sb0 | olofk, yes. bloated. as in a few times the size of LM32, with similar functionality and performance. | 09:23 |
| stekern | a few times is exaggerating, it's not even twice the size | 10:17 |
| stekern | olofk: you are driving wbm_cti_o from two different blocks: https://github.com/olofk/wb_streamer/blob/master/rtl/verilog/wb_stream_writer_ctrl.v#L55 and https://github.com/olofk/wb_streamer/blob/master/rtl/verilog/wb_stream_writer_ctrl.v#L103 | 10:37 |
| hesham | stekern: The simple approach of copying bootrom.v with hard-coded boot program did not work. Not sure the problem is with spi, uart, or the way I generate the mcs file. I think I noticed something says the UART won't work with some core. | 10:45 |
| jagadeesh | hesham: me too trying for the same but with de0_nano for orpsocv2 | 10:54 |
| stekern | hesham: what did you put in the mcs? | 10:55 |
| hesham | jagadeesh: I was able to run orpsocv2 with bare-metal hello and u-boot for Atlys | 10:55 |
| hesham | stekern: Bare-metal hello (worked with orpsocv2) | 10:55 |
| hesham | bitgen -w -g StartUpClk:CClk orpsoc_top.ncd orpsoc_top_spi.bit | 10:55 |
| jagadeesh | yes can u do it with writing the fpga configuration and sw to flash | 10:55 |
| hesham | promgen -spi -p mcs -w -o orpsoc_top_spi.mcs -s 16384 -u 0 orpsoc_top_spi.bit -data_file up 1c0000 hello-bsw.bin | 10:56 |
| hesham | jagadeesh: Yes | 10:56 |
| jagadeesh | great i'm stuck here with my de0_nano board | 10:57 |
| jagadeesh | stekern suggested me to checkout the bootrom file | 10:58 |
| jagadeesh | i have some addressing issues in copying the data form flash to sdram | 10:58 |
| hesham | jagadeesh: When I used orpsocv2, the command to get it write was so easy (make orpsoc.mcs BOOTLOADER_BIN=/path/to/ur/bootloader) | 10:58 |
| hesham | right* | 10:59 |
| jagadeesh | yeah did u try this link http://www.rte.se/blog/blogg-modesty-corex/loading-and-executing-program/2.7 | 10:59 |
| jagadeesh | I think u got it right | 11:00 |
| hesham | jagadeesh: I did not see this link before but I used another tutorial that is similar to this link. However, I used hello and u-boot instead of the LED program there, and it works. | 11:11 |
| jagadeesh | hesham: r u trying with fusesoc | 11:13 |
| hesham | Yes, but was not lucky until now.. | 11:14 |
| jagadeesh | did u try copying the rom.v along with the generated bootrom.v that we use in orpsocv2 | 11:15 |
| jagadeesh | in orpsocv2 rom.v holds the bootcode | 11:16 |
| jagadeesh | olofk was trying some bootloader for fusesoc | 11:17 |
| jagadeesh | the first thing i do if i got this right is a good document | 11:24 |
| hesham | In orpsocv2, bootrom.v also included in rom.v, I did the same with fusesoc, but it did not work. | 11:25 |
| jagadeesh | have anyone tried orpsoc with de0 nano applications running from epcs | 12:36 |
| jagadeesh | someone refer me any link | 12:36 |
| jagadeesh | a simple led blink example would help | 12:37 |
| olofk | stekern: I had some ideas that it could be more efficient to allow different max burst lengths and FIFO depth, but now I only think that will make things more complicated | 17:11 |
| olofk | stekern: Nice catch with wbm_cti_o | 17:12 |
| olofk | On the way back from FPGA world now. Seems like documentation is the number one issue people have with this project | 17:14 |
| stekern | olofk: quartus did the catching ;) | 17:23 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/64bc9cb75b05...6394a800368e | 17:24 |
| mor1kx | mor1kx/master bcbcde3 Stefan Kristiansson: simple_dpram_sclk: change "TRUE"/"FALSE" parameter logic to 1/0 | 17:24 |
| mor1kx | mor1kx/master 6394a80 Stefan Kristiansson: simple_dpram_sclk: add read enable logic... | 17:24 |
| stekern | mor1kx_rf_ram, be afraid, be very afraid. Your days are counted | 17:25 |
| olofk | Thank you Quartus then ;) | 17:25 |
| jagadeesh | stekern:i got leds up with epcs flash in de0_nano... thank u very much | 17:56 |
| jagadeesh | stekern:now processing with fusesoc for the same | 17:56 |
| stekern | jagadeesh: \o/ | 17:57 |
| jagadeesh | stekern:the mistake i did was not reading the user-guide properly.... any way i got it working thank you again | 17:57 |
| jagadeesh | i will make a clean document or a blog post on this.... | 17:58 |
| stekern | no problems, you did the lion's share of it anyway | 17:58 |
| olofk | jagadeesh: Cool. Blog posts about this is very welcome. Just tell me if you want some proof-reading | 17:59 |
| jagadeesh | olofk: yeah sure ill frame the contents and ask u if i need help.......... thank you all for your help | 18:01 |
| PaulfraOSAA | olofk, thank you for an interesting presentation today | 18:13 |
| PaulfraOSAA | Ping? | 18:15 |
| stekern | PaulfraOSAA: he made some sound here a moment ago | 18:21 |
| PaulfraOSAA | Ok, he mentioned a or1k version starting with m today, just trying to google it and failing | 18:24 |
| stekern | https://github.com/openrisc/mor1kx | 18:25 |
| olofk | PaulfraOSAA: pong! | 18:26 |
| PaulfraOSAA | thnx | 18:27 |
| olofk | Test bench is paying off. Starting to catch quality bugs now. stekern, be prepared for a push of my stream writer later tonight | 18:27 |
| * stekern is waiting anticipatedly | 19:02 | |
| olofk | ...as soon as I catch the bug in my fifo_reader | 19:04 |
| olofk | ...which I have been trying to do for some time | 19:05 |
| olofk | I'll push it anyway | 19:05 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/6394a800368e...2440fab35319 | 19:08 |
| mor1kx | mor1kx/master 0454b5b Stefan Kristiansson: store_buffer: remove redundant fifo_raddr signal... | 19:08 |
| mor1kx | mor1kx/master 2440fab Stefan Kristiansson: store_buffer: use re logic of ram instead of registering fifo_dout... | 19:08 |
| olofk | Hmm.. looks like it works now | 19:13 |
| olofk | And regression tests for fifo still works as well | 19:13 |
| olofk | Yep. fifo and wb_streamer pushed now | 19:16 |
| olofk | That was a good train journey | 19:16 |
| stekern | ok, let me take it for a spin | 19:18 |
| olofk | Looks like someone else is working on a SoC building tool | 19:19 |
| olofk | Competition is bad. I will start spreading lies about his project | 19:20 |
| stekern | who/what? | 19:29 |
| stekern | olofk: you still have the duplicate wbm_cti assignment | 19:52 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/9abd671b8628310951d1aebc1b931310e5a81cb4 | 20:33 |
| mor1kx | mor1kx/master 9abd671 Stefan Kristiansson: rf: use mor1kx_simple_dpram_sclk instead of rf_ram... | 20:33 |
| olofk | stekern: Doh! Forgot to check wb_stream_ctrl.v. Was concentrating on the other direction today | 20:41 |
| olofk | Fixed now (I think) | 20:41 |
| poke53281 | *Frontier: Elite II* runs. And it's even playable! | 21:00 |
| _franck__ | stekern: (SoC building tool) http://opencores.org/forum,OpenRISC,0,5532 | 21:01 |
| -!- _franck__ is now known as _franck_ | 21:01 | |
| poke53281 | olofk: http://jor1k.com/jor1k/ "cd /usr/share/games/frontier" and then ./frontier | 21:02 |
| poke53281 | The resolution is still 320x200. But I will change that. | 21:02 |
| olofk | poke53281: That's so fucking cool :) | 21:19 |
| stekern | olofk: https://github.com/olofk/wb_streamer/blob/master/rtl/verilog/wb_stream_writer_ctrl.v#L103 | 21:40 |
| stekern | but that makes me wonder why there's a https://github.com/olofk/wb_streamer/blob/master/rtl/verilog/wb_stream_ctrl.v too | 21:41 |
| poke53281 | olofk: Interesting is the conversion history: David Braben's brain -> Atari ST Assembler -> Atari ST 68k binary -> Atari ST disassembly -> C-Code -> openrisc binary. | 21:48 |
| poke53281 | and the binary has now a size of almost 5MB. | 22:06 |
| poke53281 | "You may .... give exact copies of the original evaluation SOFTWARE to anyone; and distribute the | 22:11 |
| poke53281 | evaluation SOFTWARE in its unmodified form via electronic means" | 22:11 |
| poke53281 | stekern, olofk: Do you think, that this conversion can be called "unmodified"? ;) | 22:11 |
| --- Log closed Fri Sep 12 00:00:48 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!