IRC logs for #openrisc Thursday, 2015-08-20

--- Log opened Thu Aug 20 00:00:07 2015
andrzejrolofk, Isim kept crashing so I have added support for Xsim:01:39
andrzejrBTW, your wishbone bfm does the job pretty well. But it looks like the main problem is that the DDR2 i/f never asserts the app_rdy signal. Will debug it later.01:41
andrzejrAlso, I will have to add more transaction types. At the moment the adapter only supports ones issued by Mor1kx.01:42
-!- anthony is now known as Guest8046604:43
-!- Guest80466 is now known as bentley`04:45
olofkandrzejr: Fantastic. Almost doubled the number of supported simulators in about a week :)05:29
olofkLet me know if I can help out with the DDR2 IF. I've been spending an awful lot of time trying to debug Xilinx DDR2 IPs05:30
olofkpoke53281, stekern: I saw both your names on the OpenRISC ASIC donators page. Happy with the progress so far? :)11:37
poke53281Yeah, I guess my money is now used for some republican presidental campaign or so.11:38
poke53281I am excited if lowRISC will manage it sooner or later.11:39
olofkWell, the lowRISC team seems to know what they're doing and is putting some effort behind it. None of which could be said about the OpenRISC ASIC11:40
poke53281I have discussed this at lowRISC. Just the initial cost of a lithografy mask are millions for a modern CPU nowadays.11:40
poke53281lithographie ...11:41
poke53281arghh, Lithography11:41
poke53281they talk about 45m.11:43
poke53281I would start to find someone, who is doing this for for 1um or so. Maybe that's cheaper.11:43
ysionneauyou can try older technologies, yes, you can also try "shared waffers" which are cheaper11:51
olofkWhat about all the successfull UNI tapeouts of RISC-V that can be read about? Apparently the UNIs seem to be able to afford it11:51
ysionneaubut not high volume11:51
wallentothey are MPW I suppose11:51
wallentosharing mask costs11:52
olofkCan the masks be reused to single project wafers?11:52
wallentoor yes, if you throw away 99% of the wafer11:53
wallentoactually it is quite affordable to do a MPW run11:54
wallentothe most expensive part is packaging11:55
wallentoyou can get your 20-50 dies for 15000 to 50000 euro depending on technology11:55
wallentobut _each_ package can be multiple hundred euros11:55
olofkHow does that compare to using older processes or going with something like eASIC?11:55
wallentoeASIC is a good alternative11:56
wallentoalthough I never thought it through11:56
wallentoand there are no actual prices out there :)11:56
wallentomodern MPW are 65nm and 40nm11:56
olofkI've been doing eASIC and Altera Hardcop before11:57
wallentobut there are older ones for <15000 euro11:57
wallentoAltera hardcopy is their "we guarantuee you only the bitstream you gave us will work on them"?11:57
olofkNo, that's Xilinx crap thing11:57
olofkI think11:58
olofkTotally useless and not that much cheaper11:58
wallentoyes, exactly11:58
olofkHardcopy is basically the FPGA fabric with a single application-specific interconnect layer11:58
wallentoah, okay11:58
wallentowhats the pricing there?11:58
olofkBut they stopped doing that. I've heard from rumours that it wasn't profitable for Altera11:59
olofkI think they were competing with eASIC, so I guess the prices would be roughly the same11:59
olofkBut I wasn't the one paying for it, so it's mainly guesswork11:59
wallentoWe are considering eASIC for a prototype tapeout12:01
wallentobut I haven't gone deeper into it12:01
wallentoMemory IP adds to bill etc.12:02
olofkYes, it seems to be hard to get around memory IP12:08
olofkas well as SERDES12:08
olofkI'm really excited about high speed serial memories (hybrid memory cube or whatever they call it)12:13
olofkI think it makes so much sense12:13
olofkStill need a SERDES of course, but the possibility to avoid regular DDR* interfaces is worth a lot12:16
wallentofull ack12:29
stekernyeah, especially considering messy DDR3/4 training sequences and whatnot...15:44
andrzejrBy now 0.18u should be affordable. Because it is old enough it doesn't benefit so much from flip-chip packaging, SERDES interfaces, PLLs and to some degree caching. So NRE costs should be much (2 orders of magnitude) smaller.17:25
andrzejrfor newer processes, 40nm currently has the best performance/cost ratio. 28nm (high-K metal gate) is denser and has lower static leakage, not much improvement in raw performance.17:27
andrzejr20nm is essentially an exercise in scaling, zero improvement in performance. But high cost due to double-patterning.17:29
andrzejrNewer processes (Fin-FETs/FD-SOI) do offer better performance but because of cost are out of reach for most applications and are not easily available anyway.17:33
poke53281olofk, stekern: What's so bad about DDR3/DDR4? Is it so complicated?17:49
olofkpoke53281: Yes, it's complicated, and on FPGA you have to deal with a lot of undocumented internal primitives18:31
olofkAnd it's so small margins and a huge amount of pins so the PCB design is pretty complex18:33
poke53281I guess the future CPUs, even from Intel and AMD, will have stacked RAM. So they will use their own protocols.18:38
olofkYeah, that might be required to get increased performance18:39
olofkand lower power18:39
olofkBut I guess that external RAM will live on for a while18:39
poke53281Yeah, probably.18:41
poke53281But I guess there is usually no nead to access DDR RAM directly via an FPGA. FPGAs have built-in stuff to do it.18:42
homeless_hi everyone18:52
homeless_i am gonna ask you a question about fusesoc18:52
homeless_i am getting an error while building an atlys system. dvi_clk cannot be routed18:54
homeless_what can be the reason? I have tried several versions of ISE but the problem remains18:55
homeless_@olofk hi18:55
olofkFor fuck sake. Could someone pleeeease fix that damn atlys dvi clock once and for all19:31
olofkhomeless_: The problem you're having seems to be the most reported bug for FuseSoC :)20:08
olofkI think it has been 'fixed' like three times already20:08
olofkAny of the Atlys users here who has a working workaround?20:09
homeless_What do you mean by three times?20:11
homeless_Is it fixed or not? I got all the packages through git. So the packages are all updated.20:12
homeless_I am sorry I don't understand. why do we need a workaround if it is already fixed?20:14
olofkhomeless_: The problem is that the error seems to appear randomly, so whenever someone has fixed it there seem to be someone else who still gets the error20:15
olofkBut I think the safest option is to move the BUFG for clk50m from dvi_gen_top to orpsoc_top20:17
homeless_"randomly" is a little bit an understatement in my case. Because I have tried on ISE 14.4 14.7 and 13.x . I don't remember the last ones exact version.20:17
olofkFrom experience, ISE seem to prefer having all bufg in the top-level20:18
homeless_So you are saying when I do this, there will not be any functional change?20:18
olofkYes. It's only the stupid fucking Xilinx tools that somehow gets confused by its own clock nets20:19
homeless_I see20:19
olofkI see now that this was solved in another way, but that I haven't merged this patch20:19
olofkSo you can try that also. Looks like he solved it by moving the bufg to clkgen.v instead20:20
olofkBut I actually think that it was in clkgen.v, but was moved at some point because it failed for someone20:21
olofkSo moving it to the top-level would be my recommendation20:21
homeless_Ok I am gonna try that and let you know.20:22
olofkIt's very annoying, because every time someone reports this error, I try to build it and it always works on my machine, so I can't really fix this myself20:22
olofkYeah. Please let me know. I would love to get this fixed one more time20:22
homeless_One more question? How do you test this on FPGA? Are you writng an assembly code or what? Because I saw some people trying to boot from SPIFlash without succes20:24
homeless_I mean test the orpsocv320:28
homeless_I have doen a lot of tests with orpsocv2 on FPGA but with v3 no luck yet20:28
olofkI know that several people in here have been booting from SPI Flash without problems20:30
olofkOn Atlys20:31
olofkThere is one poor guy who can't get it to work, but we haven't really figured out the problem yet20:31
homeless_Hmm. So you are saying SPI Flash should work too in v3 with the same method that we use in v2?20:38
homeless_olofk: Buy the way, is this dvi_clk used for display? What happens if I totally remove/comment it? I am not using a display after all.21:00
olofkhomeless_: The SPI boot stuff is not entirely the same as it was in orpsocv2, but the files that are in the Atlys system seems to work for most people21:02
olofkAnd you can remove all the dvi stuff if you don't use it. I know some people have done that too21:02
olofkRegarding SPI booting, I'm working on an improved solution to use for all the systems in orpsoc-cores, but so far I have only validated that it works on de0_nano21:03
homeless_I have implemented v2 with a simple led blink example. I have written that in assembly language21:05
homeless_It works21:05
olofkThen you should hopefully be able to reuse that21:06
homeless_How do you test your v3 build on atlys?21:06
olofkI haven't had an Atlys board myself for several years now21:06
olofkBut it's a popular board, and several people in here run the FuseSoC system on it21:07
homeless_So you haven't tried exactly. Ok.21:07
homeless_No problem. I will be one of those people. Hopefully! Thanks man. I am going for a smoke :))21:08
olofkme too :)21:08
andrzejrolofk, homeless_, strange, I just built atlys without any problems. I remember seeing some warning about clocks before21:51
homeless_andrzejr: what is your version of ISE?21:51
andrzejr14.7, lin6421:52
andrzejrI made some minor fixes but they should not be relevant:21:53
homeless_yes it is not relavant21:54
homeless_Now I am using the same 14.7 linux 64bit21:54
andrzejr(listing changes just in case)21:55
homeless_What is your linux distribution?21:56
homeless_Mine is the latest mint 17.221:57
andrzejr(x)ubuntu 15.0421:57
homeless_My God!21:57
homeless_I can't believe that almost the same distribution. But ISE still gives the error21:58
homeless_I mean how can it give these errors when everything is identical21:58
andrzejrI was seeing the error before. I don't really know what has changed. Well, I bumped memory from 4GB to 8GB but I can only hope such things don't matter.21:59
andrzejrwhat exactly is the error, can you put it on pastebin?21:59
andrzejrI used to see some weird errors when I was experimenting with the code and disabled parts of the system. ISE was complaining if it couldn't find some paths annotated in .ucf (because they were disabled or optimized out).22:02
andrzejrYup, I've seen this one.22:06
homeless_Not anymore?22:07
andrzejrI re-run the build today just to see if the error is still there - it's not.22:08
homeless_But that is your modified code, right?22:09
andrzejrThere are no modifications to atlys system (other than the syntax error) but I wonder about the bus code fix.22:09
homeless_Have you ever tested pure atlys build?22:09
homeless_What syntax error?22:10
andrzejrIt could trigger different placement of logic - placer is very sensitive to even minor design changes.22:11
andrzejrcheck my commits^22:11
homeless_I saw it. Despite the error, ISE does not give error for that22:16
andrzejrafair it was affecting simulation22:16
homeless_But it should have given. You know22:17
andrzejrtry patching wb_data_resize - this could indirectly impact synthesis.22:17
homeless_Where should I put that?22:19
andrzejrmeanwhile I will pull a fresh version of orpsoc-cores22:20
andrzejrthis doesn't seem right:22:34
andrzejrWARNING:Timing:3159 - The DCM, dvi_gen0/PCLK_GEN_INST, has the attribute DFS_OSCILLATOR_MODE not set to PHASE_FREQ_LOCK. No phase22:35
andrzejr   relationship exists between the input clock and CLKFX or CLKFX180 outputs of this DCM. Data paths between these clock domains must be22:35
andrzejr   constrained using FROM/TO constraints.22:35
andrzejrhomeless_, I can confirm this error is reproducible with freshly checked out orpsoc-cores22:39
homeless_I am gonna try to change that attribute and see what happens22:41
homeless_By the way, modifiying wb_data_resize did not make any difference22:43
andrzejrI get this warning *also* in the successful build22:43
andrzejrI checked that there is no change to systems/atlys (other than the syntax fix). But I have modified some cores. I don't think any of these would "fix" the error but may change the placement just enough the error is not triggered.22:45
homeless_Maybe yeah. The attribute "DFS_OSCILLATOR_MODE" is not accesible from the user side, so says Xilix guys22:51
homeless_Have you tried booting from SPIFlash?22:52
andrzejrnope, I don't have this board. I only used the code as a starting point for my work on Nexys4-DDR22:53
andrzejrbtw, I compared build/atlys/src trees. There are only 3 differences to RTL:22:54
andrzejr- syntax error fix in xilinx_ddr2_if.v22:55
andrzejr- wb_data_resize.v - patch above22:55
homeless_Ok, tnx22:56
andrzejr- adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog/adbg_defines.v - commented out line: `define DBG_JSP_SUPPORTED22:57
homeless_what is this?22:58
andrzejrgo to cores/adv_debug_sys23:04
andrzejrgit pull
andrzejrcomment out the line in adbg_defines.v23:05
andrzejrcomment out the [provider] section in adv_debug_sys.core file23:06
andrzejr(I don't remember what was the purpose of this change, but it is a change nevertheless)23:07
--- Log closed Fri Aug 21 00:00:09 2015

Generated by 2.15.2 by Marius Gedminas - find it at!