IRC logs for #openrisc Sunday, 2016-09-11

--- Log opened Sun Sep 11 00:00:06 2016
shorneZipCPU|Laptop: 25 clock to return data?  thats horrible any insight of where the latency i.e. what is between the requestor and the memory (wb-bus, sdram_controller, sdram) can you see the timine all the way to sdram?03:50
ZipCPU|Laptopshorne: I cannot see the latency all the way to the memory right now, but ...07:07
ZipCPU|Laptopthe MIG leaves its source code lying around.  It may be possible to examine and draw some conclusions from.07:07
ZipCPU|LaptopI, personally, wouldn't be surprised if the difference had anything to do with how difficult the AXI07:08
ZipCPU|Laptopbus is to interact with.07:08
ZipCPU|LaptopAnother measure of interest: My entire design takes about 14.5k LUTs.  Of these, 5.6k or about 40%07:10
ZipCPU|LaptopOF MY ENTIRE DESIGN is spent by the MIG.07:10
ZipCPU|LaptopOn some designs I've worked on--this would cost more logic than the entire chip has.07:14
shorneZipCPU|Laptop: why not use wb_sdram_ctrl? or another memory interface?08:12
shorneeasy of use?08:13
ZipCPUshorne: Good questions.08:27
ZipCPUI got most of the way through building a wishbone compliant alternative.08:28
ZipCPUI got all the logic working 2-3 times, and after every time discovered something I'd messed up.08:28
ZipCPUWhen I went to start over the last time, I got to thinking: If I build this, it's only going to work for a couple of devices, but if I build a (better) wishbone to axi translator, that would work on every device.08:29
ZipCPUWhile I intend to return to the wbddr3 design, I noticed some things about Xilinx --- they're entire approach to DDR3 interaction is via undocumented IO features: PHASOR's, phasor controllers, IOPLLs, and more.08:30
ZipCPUYet ... while undocumented, their MIG does offer one example design one might follow.08:30
ZipCPUGoing that approach will likely take me a lot of time.  The improved/pipelined wishbone to axi converter allows me to get my design moving before I've invested that kind of time.08:31
ZipCPUStill ... don't be surprised if I do invest that kind of time.08:32
ZipCPUThis actually provides me with a *new* reason why you want a resource efficient CPU: because the Xilinx Memory Interface Generator is going to hog *ALL* your remaining logic!!!08:42
-!- heroux_ is now known as heroux12:55
olofkZipCPU: Yes. MIG has been one of the most common target for unspeakable words during my career16:05
olofkRegarding the latency, I know that they tell you to use their native (UI) interface instead of AXI4 if you need full speed. But I can't possibly see how their AXI layer could add 25-9 extra cycles16:06
LaksenIf it's using wide ID's and normal memory ordering it would need a heap of bookkeeping logic16:51
olofkThat could definitely be a reason16:54
LaksenDecoding wrap operations, burst length chopping, resizing, ensuring enough space in all outstanding transaction ID RX fifo's, ensuring enough data is received in all available ID slots16:54
LaksenAXI is beautiful in some ways, but very complicated in certain other ways :|16:56
olofkYeah. I love especially the handshaking. Been using AXI4Stream quite a lot16:57
olofkAXI4 is more or less five streams :)16:57
LaksenAXI4 streaming is great16:59
LaksenBut it just seems like there are some loose ends in the AXI4 full spec16:59
LaksenOr not loose as such, just weird. Like if there's a decoding error early in a burst you have to just empty up to 256 words on the data pipe and finally then report an error17:01
olofkError handling is hard17:04
LaksenVery true17:06
--- Log closed Mon Sep 12 00:00:08 2016

Generated by 2.15.2 by Marius Gedminas - find it at!