--- Log opened Wed Oct 22 00:00:48 2014 | ||
-!- Netsplit *.net <-> *.split quits: tariq786, zama, simoncook, blueCmd, rokka, pecastro | 00:20 | |
-!- Netsplit over, joins: rokka, tariq786, zama, blueCmd, simoncook | 00:25 | |
-!- Netsplit over, joins: pecastro | 00:26 | |
stekern | olofk: short, but fun. I'll have to buy the rest of the games in the series. | 02:51 |
---|---|---|
olofk | stekern: Yeah, I liked it too. Got them all via humble bundle | 06:07 |
olofk | Did you manage to save the deacon, btw? I ran out of time before I could smash the flask with the rock | 06:08 |
stekern | really, I didn't know that could happen | 06:14 |
stekern | what happens then? | 06:14 |
stekern | iow, the answer to your question is, yes ;) | 06:15 |
olofk | stekern: Didn't make much difference. He was either taken by the demon or went on his own | 07:15 |
stekern | but didn't he go to hell with the demon? | 07:28 |
olofk | Yes, but that was apparently ok too | 07:29 |
stekern | he deserved it | 07:29 |
olofk | Yeah, he looked cold | 07:29 |
stekern | I got stuck at two places, where you had to walk in a certain way to get the dog to bark, and when you quickly had to hide by the phone so the guard didn't see you | 07:30 |
stekern | that kind of 'puzzles' are annoying IMO | 07:30 |
olofk | What I find most annoying is the adventure games where you can only die in a few places. Like Beneath a steel sky, where I happily played through half the game and suddenly there was a place where you could die | 07:32 |
olofk | By that time I had stopped saving too often | 07:32 |
stekern | oh, dying in adventure games is a fun killer | 07:32 |
olofk | That always put me off the Sierra games | 07:33 |
stekern | I never liked the sierra games because of that | 07:33 |
olofk | :) | 07:33 |
stekern | ;) | 07:33 |
olofk | I do like the first Larry though | 07:33 |
stekern | yes | 07:33 |
stekern | the first adventure game I played was king quest iii(?) though | 07:36 |
stekern | it was hilarious to "kick the cat" | 07:36 |
olofk | :) | 07:36 |
stekern | I've never played that to the end though | 07:37 |
olofk | Only played KQ5, and I never finished that either | 07:37 |
olofk | Got to a place where I had to hide from someone while figuring out what to do, and I just died all the time | 07:37 |
stekern | I got lost in the desert | 07:37 |
stekern | (figure, as a guy with no sense of direction) | 07:38 |
olofk | lol | 07:38 |
olofk | _franck_: You are using Firefox, right? | 07:43 |
olofk | Aha! wb_altera_ddr_wrapper has done half the job for me. Excellent | 07:47 |
olofk | hmm... looks like there are some unexpected differences here | 07:50 |
olofk | This could use a refactoring | 07:51 |
_franck__ | olofk: no, I don't. Why are you asking me this ? | 07:51 |
olofk | _franck__: https://github.com/openrisc/orpsoc-cores/blob/master/systems/neek/backend/rtl/verilog/ddr_ctrl_ip/ddr_ctrl_ip.v#L441 | 07:52 |
_franck__ | :) | 07:52 |
_franck__ | oh ! right on my Linux machine | 07:53 |
olofk | Why on earth would Altera want to put that in a verilog file? | 07:53 |
olofk | I wouldn't be suprised to find the root password or a bank account number hidden somewhere there too :) | 07:53 |
olofk | Looks like _franck__ has added synchronisation of the read_done signal that I planned to fix in wb_sdram_ctrl | 08:32 |
olofk | I'm currently splitting out the common stuff from wb_sdram_ctrl and wb_altera_ddr_wrapper to a wb_cached_arbiter component | 08:33 |
olofk | But wb_port.v has diverged a bit. Not sure what to do here | 08:36 |
olofk | _franck__: What's the idea of having separate buf_width for each port? | 08:58 |
_franck__ | IIRC, I wanted to have a bigger burst size for the VGA port | 08:59 |
_franck__ | to optimize bandwidth | 08:59 |
olofk | ah ok | 08:59 |
olofk | stekern: Would that work for wb_sdram_ctrl too? | 09:00 |
olofk | "sorry: Cannot part select bits of parameters" Oh for fuck sake icarus. Why these limitations? | 09:13 |
stekern | I think the buf width is pretty bound to the sdram burst size | 09:21 |
olofk | hmm... | 09:49 |
olofk | I'm starting to rethink things now | 09:49 |
olofk | Just to get things straight, as long as we have icache in the CPU, we don't get any benefit from the wb_port buffer for the instruction bus, right? | 09:53 |
olofk | Because the CPU would fetch a nicely aligned block from RAM | 09:54 |
stekern | if you count out the fact that you have to store the data you are bursting from sdram, you're right | 09:55 |
stekern | +somewhere | 10:00 |
olofk | ah yes. Didn't think of that | 10:17 |
olofk | ok, still throwing around ideas here. Now I'm leaning towards something like this https://www.dropbox.com/s/jkpavb92t0rhyx5/memarch.png?dl=0 | 11:12 |
olofk | https://draw.io is awesome btw | 11:13 |
olofk | with the CDC in wb_interface | 11:17 |
stekern | but you still have the problem that you have to store DQ_WIDTH*BURST_LEN in wb_interface | 11:17 |
stekern | and you have created a bottle-neck between wb_arbiter and wb_interface | 11:18 |
olofk | Yes. It will cost a few hundred FFs to do that | 11:18 |
olofk | I'm not sure it will be a bottle neck. All masters in the drawing will do block accesses | 11:19 |
olofk | I can't see that it will be more of a bottle neck compared to what we have today | 11:20 |
stekern | ibus and dbus will fight over the one 32-bit access-line | 11:21 |
olofk | True, but that's the case we have today, right? | 11:22 |
stekern | instead of, basically, fight over a DQ_WIDTH*BURST_LEN line | 11:22 |
olofk | Yes | 11:23 |
olofk | But I think it might be easier to widen buses as needed with this architecture | 11:24 |
olofk | Or do you mean the stuff in the diagram will perform worse than what we have today? | 11:26 |
stekern | I think it might. wb_interface and wb_arbiter seems redundant to me | 11:26 |
olofk | We only have 32-bit masters right now | 11:27 |
olofk | So we need to bring it down to 32 bits at some point | 11:27 |
olofk | wb_interface is meant as a backend-agnostic wishbone wrapper | 11:28 |
stekern | + it has another disadvantage, moving the arbiter away from the memory controller makes it unaware of possible optimisations | 11:28 |
stekern | but why are you so obsessed with widening the bus on a SDRAM that has dq 16 | 11:29 |
stekern | ? | 11:29 |
olofk | It was my father's last wish before he died | 11:29 |
stekern | haha | 11:29 |
stekern | I want to do it on the sockit, because the memory provides 64-bit data | 11:30 |
olofk | I agree that it makes more sense when DQ Width is >32 | 11:30 |
stekern | if you want to widen the bus inside the SoC, just create a L2 cache then | 11:31 |
olofk | The cached arbiter is more or less an l2 | 11:31 |
stekern | but why can't wb_cached_arbiter be the "backend-agnostic wishbone wrapper"? | 11:35 |
olofk | It could, and that's basically what wb_altera_ddr_wrapper is | 11:36 |
olofk | Which is wb_sdram_ctrl - sdram_ctrl | 11:37 |
stekern | yes | 11:37 |
olofk | I think what led to the drawing is that I wanted to have ibus kept outside of this | 11:37 |
olofk | Because I envision that ibus could be made much wider in the future, but all data masters will probably remain 32 bit | 11:38 |
stekern | sure, but I don't se a problem in wb_cached_arbiter providing configurable data ports | 11:39 |
stekern | +e | 11:39 |
olofk | Have you ever tried to use verilog? :) | 11:39 |
olofk | But I agree. Just splitting out the wb_port* stuff from wb_sdram_ctrl and wb_altera_ddr_wrapper is probably the most important for now | 11:42 |
olofk | So the only difference for wb_sdram_ctrl will be that the internal data port between sdram_ctrl and wb_port_arbiter will be 32 bits | 11:43 |
stekern | or 64-bits? | 11:53 |
olofk | hmm... | 11:56 |
olofk | I say either 32 bit (since everything wb-related is 32-bit, or fully configurable | 11:57 |
stekern | hmm, yeah | 11:58 |
stekern | but currently it's dq | 11:59 |
olofk | Yes, so setting it to 32 bit will allow me to easier reuse the cache and arbiter parts | 11:59 |
olofk | The version in wb_altera_ddr_wrapper is 32 bits | 11:59 |
stekern | ...because 'dq' is 32-bits? | 12:00 |
olofk | I assume that | 12:01 |
olofk | ACtually no. It looks like it's 16 bits | 12:02 |
olofk | But probably the altera IP exposes a 32-bit port | 12:02 |
stekern | ya | 12:02 |
olofk | Yeah, and that's another thing. I think it will be easiest to plug in new memory controllers if the interface to the cached mem arbiter is 32 bits | 12:02 |
stekern | i think it's easier if it's 'dq' (or whatever the IP happens to give) | 12:03 |
olofk | Sure. Going with the IP's width is preferred, but I think that most IPs will have a 32-bit option as well | 12:05 |
olofk | Which saves us some trouble | 12:05 |
stekern | probably, but I want to avoid that | 12:05 |
olofk | For SoCKit? | 12:05 |
stekern | exactly | 12:05 |
stekern | the IP gives 64-bit | 12:06 |
olofk | The problem I see is that none of the other infrastructure supports !32 bits yet | 12:06 |
stekern | and downsizing to 32-bit creates a bottle neck | 12:06 |
olofk | Agree | 12:06 |
stekern | what other infrastructure? that's why I want to have the cached arbiter hooked up straight to the 'IP' | 12:07 |
olofk | ah yes ok. I see it now | 12:07 |
stekern | ...or one of the reasons | 12:07 |
stekern | I think the cached arbiter is the best place to do 1) CDC and 2) port resizing | 12:08 |
olofk | You might be right, since the mem clock is most often faster than the CPU clock, so we want to split up the ports before moving to the slower clock | 12:09 |
stekern | note though, I'm only speaking about CDC and port resizing between memory and bus | 12:09 |
stekern | peripheral bus CDC is a different matter | 12:10 |
stekern | it could make sense to do the arbitration on the other side as well, *but* if you do arbiter on mem side, you get the benefit that you can have masters with different clock freq | 12:11 |
olofk | As soon as someone writes that Wishbone CDC component :) | 12:12 |
stekern | you don't need that | 12:12 |
stekern | if you do the arbiter on the mem side | 12:12 |
olofk | Ah ok. But you need to add support for assigning indivudual clocks | 12:13 |
stekern | yes, it's not going to work as it is now | 12:13 |
olofk | So.. wb_port* needs to be updated to support a generic width towards the memory | 12:14 |
olofk | And in my opinion, they should be moved to a separate core so that we can reuse them for all mem controllers | 12:16 |
olofk | A wb_cached_mem_arbiter | 12:17 |
olofk | with a defined interface towards the memory | 12:17 |
olofk | like the on currently used | 12:17 |
olofk | one | 12:18 |
stekern | yes | 12:18 |
olofk | Could we use a wishbone interface between the mem controller and the arbiter? | 13:30 |
olofk | Or do we explicitly need idle_o, adr_o and acc_o? | 13:31 |
olofk | And how do the burst work? Do we always do cyclic bursts a la wishbone wrap bursts? | 13:45 |
olofk | Towards the memory that is | 13:45 |
olofk | Has anyone bought a MiniSpartan6 board? FPGA is a bit small, but it's a very affordable board with a sensible selection of I/O | 13:49 |
juliusb | looks like the Beyond Semi guys are still doing stuff: http://www.beyondsemi.com/15/clanek/new-ba20-processor-ip-features-zero-stage-pipeline-for-energy-and-performance-efficiency/19/ | 15:18 |
juliusb | and that "zero stage pipeline" thing is bullshit. That's 2 stages. | 15:19 |
juliusb | and a lot like the espresso cores :) | 15:19 |
juliusb | maybe now we should just subtract 2 off the number of pipeline stages and call it the <insert your brand here> Pipeline<WordVersionOfYourPipelineMinusTwoHere> | 15:21 |
juliusb | the "OpenRISC PipelineFour Approach" is used on Cappuccino | 15:22 |
juliusb | :) | 15:22 |
wallento | whats the y axis in the graph? the one is area with scale better and worse ;) | 15:35 |
jeremybennett | juliusb: Could be a quantum computer :) | 16:16 |
jeremybennett | Specify your problem in qbits and collapse the superposition to a solution instantly. | 16:17 |
jeremybennett | D-Wave eat your heart out. | 16:17 |
rschmidlin | hello everyone | 20:02 |
rschmidlin | Are the videos of orconf2014 up somewhere? | 20:02 |
olofk | Not that I know | 20:13 |
rschmidlin | it would be nice. I have heard your talks on orpsoc3 from earlier conferences. That helped :). | 20:26 |
rschmidlin | I also tried the interconnect builder from the cores library. | 20:26 |
rschmidlin | I’m leaving guys, g’night | 20:41 |
olofk | stekern: If I do a wishbone burst read of 4 consecutive words starting from address 0x18, will this result in wb_sdram_ctrl fetching 0x00-0x1C and then 0x20-0x3C? | 21:14 |
--- Log closed Thu Oct 23 00:00:49 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!