| --- Log opened Thu Aug 20 00:00:07 2015 | ||
| andrzejr | olofk, Isim kept crashing so I have added support for Xsim: | 01:39 |
|---|---|---|
| andrzejr | https://github.com/andrzej-r/fusesoc/tree/andrzej-r | 01:39 |
| andrzejr | BTW, 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 |
| andrzejr | Also, 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 Guest80466 | 04:43 | |
| -!- Guest80466 is now known as bentley` | 04:45 | |
| olofk | andrzejr: Fantastic. Almost doubled the number of supported simulators in about a week :) | 05:29 |
| olofk | Let 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 IPs | 05:30 |
| olofk | poke53281, stekern: I saw both your names on the OpenRISC ASIC donators page. Happy with the progress so far? :) | 11:37 |
| poke53281 | Yeah, I guess my money is now used for some republican presidental campaign or so. | 11:38 |
| poke53281 | I am excited if lowRISC will manage it sooner or later. | 11:39 |
| olofk | Well, 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 ASIC | 11:40 |
| poke53281 | I have discussed this at lowRISC. Just the initial cost of a lithografy mask are millions for a modern CPU nowadays. | 11:40 |
| poke53281 | lithographie ... | 11:41 |
| poke53281 | arghh, Lithography | 11:41 |
| poke53281 | they talk about 45m. | 11:43 |
| poke53281 | I would start to find someone, who is doing this for for 1um or so. Maybe that's cheaper. | 11:43 |
| ysionneau | you can try older technologies, yes, you can also try "shared waffers" which are cheaper | 11:51 |
| olofk | What about all the successfull UNI tapeouts of RISC-V that can be read about? Apparently the UNIs seem to be able to afford it | 11:51 |
| ysionneau | but not high volume | 11:51 |
| wallento | they are MPW I suppose | 11:51 |
| wallento | sharing mask costs | 11:52 |
| olofk | Can the masks be reused to single project wafers? | 11:52 |
| wallento | no | 11:52 |
| wallento | or yes, if you throw away 99% of the wafer | 11:53 |
| olofk | :) | 11:53 |
| wallento | actually it is quite affordable to do a MPW run | 11:54 |
| wallento | the most expensive part is packaging | 11:55 |
| wallento | you can get your 20-50 dies for 15000 to 50000 euro depending on technology | 11:55 |
| wallento | but _each_ package can be multiple hundred euros | 11:55 |
| olofk | How does that compare to using older processes or going with something like eASIC? | 11:55 |
| wallento | eASIC is a good alternative | 11:56 |
| wallento | although I never thought it through | 11:56 |
| wallento | and there are no actual prices out there :) | 11:56 |
| wallento | modern MPW are 65nm and 40nm | 11:56 |
| olofk | I've been doing eASIC and Altera Hardcop before | 11:57 |
| wallento | but there are older ones for <15000 euro | 11:57 |
| olofk | hardcopy | 11:57 |
| wallento | Altera hardcopy is their "we guarantuee you only the bitstream you gave us will work on them"? | 11:57 |
| olofk | No, that's Xilinx crap thing | 11:57 |
| olofk | Easypath! | 11:57 |
| olofk | I think | 11:58 |
| olofk | Totally useless and not that much cheaper | 11:58 |
| wallento | yes, exactly | 11:58 |
| olofk | Hardcopy is basically the FPGA fabric with a single application-specific interconnect layer | 11:58 |
| wallento | ah, okay | 11:58 |
| wallento | noice | 11:58 |
| wallento | whats the pricing there? | 11:58 |
| olofk | But they stopped doing that. I've heard from rumours that it wasn't profitable for Altera | 11:59 |
| olofk | I think they were competing with eASIC, so I guess the prices would be roughly the same | 11:59 |
| olofk | But I wasn't the one paying for it, so it's mainly guesswork | 11:59 |
| wallento | We are considering eASIC for a prototype tapeout | 12:01 |
| wallento | but I haven't gone deeper into it | 12:01 |
| wallento | Memory IP adds to bill etc. | 12:02 |
| olofk | Yes, it seems to be hard to get around memory IP | 12:08 |
| olofk | as well as SERDES | 12:08 |
| olofk | I'm really excited about high speed serial memories (hybrid memory cube or whatever they call it) | 12:13 |
| olofk | I think it makes so much sense | 12:13 |
| olofk | Still need a SERDES of course, but the possibility to avoid regular DDR* interfaces is worth a lot | 12:16 |
| wallento | full ack | 12:29 |
| wallento | ;) | 12:29 |
| olofk | :) | 12:30 |
| stekern | yeah, especially considering messy DDR3/4 training sequences and whatnot... | 15:44 |
| andrzejr | By 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 |
| andrzejr | for 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 |
| andrzejr | 20nm is essentially an exercise in scaling, zero improvement in performance. But high cost due to double-patterning. | 17:29 |
| andrzejr | Newer 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 |
| poke53281 | olofk, stekern: What's so bad about DDR3/DDR4? Is it so complicated? | 17:49 |
| olofk | poke53281: Yes, it's complicated, and on FPGA you have to deal with a lot of undocumented internal primitives | 18:31 |
| olofk | And it's so small margins and a huge amount of pins so the PCB design is pretty complex | 18:33 |
| poke53281 | I guess the future CPUs, even from Intel and AMD, will have stacked RAM. So they will use their own protocols. | 18:38 |
| olofk | Yeah, that might be required to get increased performance | 18:39 |
| olofk | and lower power | 18:39 |
| olofk | But I guess that external RAM will live on for a while | 18:39 |
| poke53281 | Yeah, probably. | 18:41 |
| poke53281 | But 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 everyone | 18:52 |
| homeless_ | i am gonna ask you a question about fusesoc | 18:52 |
| homeless_ | i am getting an error while building an atlys system. dvi_clk cannot be routed | 18:54 |
| homeless_ | what can be the reason? I have tried several versions of ISE but the problem remains | 18:55 |
| homeless_ | @olofk hi | 18:55 |
| homeless_ | hi | 18:58 |
| olofk | For fuck sake. Could someone pleeeease fix that damn atlys dvi clock once and for all | 19:31 |
| olofk | homeless_: The problem you're having seems to be the most reported bug for FuseSoC :) | 20:08 |
| olofk | I think it has been 'fixed' like three times already | 20:08 |
| olofk | Any 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 |
| olofk | homeless_: 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 error | 20:15 |
| olofk | But I think the safest option is to move the BUFG for clk50m from dvi_gen_top to orpsoc_top | 20: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 |
| olofk | From experience, ISE seem to prefer having all bufg in the top-level | 20:18 |
| homeless_ | So you are saying when I do this, there will not be any functional change? | 20:18 |
| olofk | Yes. It's only the stupid fucking Xilinx tools that somehow gets confused by its own clock nets | 20:19 |
| homeless_ | I see | 20:19 |
| olofk | I see now that this was solved in another way, but that I haven't merged this patch | 20:19 |
| olofk | https://github.com/openrisc/orpsoc-cores/pull/83/commits | 20:19 |
| olofk | So you can try that also. Looks like he solved it by moving the bufg to clkgen.v instead | 20:20 |
| olofk | But I actually think that it was in clkgen.v, but was moved at some point because it failed for someone | 20:21 |
| olofk | So moving it to the top-level would be my recommendation | 20:21 |
| homeless_ | Ok I am gonna try that and let you know. | 20:22 |
| olofk | It'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 myself | 20:22 |
| olofk | Yeah. Please let me know. I would love to get this fixed one more time | 20: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 succes | 20:24 |
| homeless_ | I mean test the orpsocv3 | 20:28 |
| homeless_ | I have doen a lot of tests with orpsocv2 on FPGA but with v3 no luck yet | 20:28 |
| olofk | I know that several people in here have been booting from SPI Flash without problems | 20:30 |
| olofk | On Atlys | 20:31 |
| olofk | There is one poor guy who can't get it to work, but we haven't really figured out the problem yet | 20: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 |
| olofk | homeless_: 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 people | 21:02 |
| olofk | And you can remove all the dvi stuff if you don't use it. I know some people have done that too | 21:02 |
| olofk | Regarding 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_nano | 21:03 |
| homeless_ | Hmm | 21:04 |
| homeless_ | I have implemented v2 with a simple led blink example. I have written that in assembly language | 21:05 |
| homeless_ | It works | 21:05 |
| olofk | Then you should hopefully be able to reuse that | 21:06 |
| homeless_ | How do you test your v3 build on atlys? | 21:06 |
| olofk | I haven't had an Atlys board myself for several years now | 21:06 |
| olofk | But it's a popular board, and several people in here run the FuseSoC system on it | 21: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 |
| olofk | me too :) | 21:08 |
| andrzejr | olofk, homeless_, strange, I just built atlys without any problems. I remember seeing some warning about clocks before | 21:51 |
| homeless_ | andrzejr: what is your version of ISE? | 21:51 |
| andrzejr | 14.7, lin64 | 21:52 |
| andrzejr | I made some minor fixes but they should not be relevant: | 21:53 |
| andrzejr | https://github.com/andrzej-r/orpsoc-cores/commit/72c9037f1c30093d5bd4a3989389f56e83ee21f9 | 21:53 |
| homeless_ | yes it is not relavant | 21:54 |
| andrzejr | https://github.com/andrzej-r/orpsoc-cores/commit/0cf2de8767bf7ed09fe108f3ab5817d7b34ffc12 | 21:54 |
| homeless_ | Now I am using the same 14.7 linux 64bit | 21:54 |
| andrzejr | (listing changes just in case) | 21:55 |
| homeless_ | What is your linux distribution? | 21:56 |
| homeless_ | Mine is the latest mint 17.2 | 21:57 |
| andrzejr | (x)ubuntu 15.04 | 21:57 |
| homeless_ | My God! | 21:57 |
| andrzejr | ? | 21:57 |
| homeless_ | I can't believe that almost the same distribution. But ISE still gives the error | 21:58 |
| homeless_ | I mean how can it give these errors when everything is identical | 21:58 |
| andrzejr | I 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 |
| andrzejr | what exactly is the error, can you put it on pastebin? | 21:59 |
| andrzejr | I 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 |
| homeless_ | http://www.pastebin.ca/3118689 | 22:04 |
| andrzejr | Yup, I've seen this one. | 22:06 |
| homeless_ | Not anymore? | 22:07 |
| andrzejr | I 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 |
| andrzejr | There 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 |
| andrzejr | It could trigger different placement of logic - placer is very sensitive to even minor design changes. | 22:11 |
| andrzejr | check my commits^ | 22:11 |
| homeless_ | I saw it. Despite the error, ISE does not give error for that | 22:16 |
| andrzejr | afair it was affecting simulation | 22:16 |
| homeless_ | But it should have given. You know | 22:17 |
| andrzejr | try patching wb_data_resize - this could indirectly impact synthesis. | 22:17 |
| homeless_ | wb_data_resize? | 22:19 |
| homeless_ | Where should I put that? | 22:19 |
| andrzejr | cores/wb_intercon/wb_data_resize.v | 22:20 |
| andrzejr | meanwhile I will pull a fresh version of orpsoc-cores | 22:20 |
| andrzejr | this doesn't seem right: | 22:34 |
| andrzejr | WARNING:Timing:3159 - The DCM, dvi_gen0/PCLK_GEN_INST, has the attribute DFS_OSCILLATOR_MODE not set to PHASE_FREQ_LOCK. No phase | 22:35 |
| andrzejr | relationship exists between the input clock and CLKFX or CLKFX180 outputs of this DCM. Data paths between these clock domains must be | 22:35 |
| andrzejr | constrained using FROM/TO constraints. | 22:35 |
| andrzejr | homeless_, I can confirm this error is reproducible with freshly checked out orpsoc-cores | 22:39 |
| homeless_ | Hmm | 22:40 |
| homeless_ | I am gonna try to change that attribute and see what happens | 22:41 |
| homeless_ | By the way, modifiying wb_data_resize did not make any difference | 22:43 |
| andrzejr | I get this warning *also* in the successful build | 22:43 |
| andrzejr | I 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 guys | 22:51 |
| homeless_ | Have you tried booting from SPIFlash? | 22:52 |
| andrzejr | nope, I don't have this board. I only used the code as a starting point for my work on Nexys4-DDR | 22:53 |
| andrzejr | btw, I compared build/atlys/src trees. There are only 3 differences to RTL: | 22:54 |
| andrzejr | - syntax error fix in xilinx_ddr2_if.v | 22:55 |
| andrzejr | - wb_data_resize.v - patch above | 22:55 |
| homeless_ | Ok, tnx | 22:56 |
| andrzejr | - adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog/adbg_defines.v - commented out line: `define DBG_JSP_SUPPORTED | 22:57 |
| homeless_ | what is this? | 22:58 |
| andrzejr | go to cores/adv_debug_sys | 23:04 |
| andrzejr | git pull [email protected]:olofk/adv_debug_sys.git | 23:05 |
| andrzejr | comment out the line in adbg_defines.v | 23:05 |
| andrzejr | comment out the [provider] section in adv_debug_sys.core file | 23: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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!