--- Log opened Thu Sep 19 00:00:02 2013 | ||
stekern | olofk: is there a reason why wb_intercon_gen is missing the .py extension? | 03:02 |
---|---|---|
stekern | getting the wires into a template was dead easy, already done with that | 03:24 |
stekern | adding the instantiation wasn't much harder | 05:15 |
stekern | my first glance turned out to be wrong too, verilogwriter had all the pieces and bits ready | 05:16 |
stekern | I only had to change three lines in that | 05:16 |
stekern | to make it not emit the "module" | 05:17 |
olofk | stekern: Dropping .py is the common practice when you make a python script a main executable | 05:52 |
olofk | And that's awesome! Is it ready for a review? | 05:52 |
olofk | your additions I mean | 05:53 |
olofk | I mean, it's awesome that you added the instantiation template, not that you can drop the .py and make python scripts executable | 05:54 |
stekern | haha, I got that! | 05:56 |
stekern | I reckon it's not taking screenshots and trying to access /var/mail if I run it as ./wb_intercon_gen now then? | 05:57 |
stekern | and yes, you can expect a pull request some time today | 05:57 |
stekern | I'm testing the autogenerated header file righ now | 05:58 |
olofk | Yeah, I saw on the keylogger that you are preparing the pull request | 05:58 |
stekern | =) | 06:00 |
olofk | I really really should have gotten a de0 nano board | 06:20 |
stekern | should have as in "I ordered one and it should have been here already", or "I should have ordered one" | 06:30 |
olofk | I should have ordered one | 06:54 |
olofk | Would feel better to actually have one before orconf | 06:54 |
olofk | Hmm.. might still be time actually | 06:54 |
stekern | olofk: pull request ahoy! | 06:59 |
stekern | seems like farnell even sell them nowadays: http://se.farnell.com/terasic-technologies/p0082/ep4ce22f17c6n-de0-nano-dev-kit/dp/2076463 | 07:02 |
olofk | Yeah, I know. And I see now that they ship the next day, so I probably place an order when I get home | 07:16 |
stekern | I pretty much have a simple de0 nano board port ready btw | 07:25 |
olofk | That's great | 07:25 |
olofk | RAM and UART? | 07:25 |
stekern | SDRAM and UAR | 07:25 |
stekern | T | 07:25 |
olofk | With wb_sdram_ctrl? | 07:25 |
stekern | yes | 07:25 |
olofk | Is that a replacement for versatile_mem_ctrl btw? | 07:26 |
stekern | yes | 07:27 |
olofk | Then I don't think we should add a core for versatile_mem_ctrl, and keep it in their system directories for legacy systems instead | 07:28 |
olofk | That will make it more obvious that wb_sdram_ctrl should be used for new systems | 07:29 |
stekern | are there any systems in orpsocv3 that use it? | 07:33 |
stekern | IIRC it was very cumbersome to generate the files for it (that might have changed), so that alone is an argument for keeping it in the system directories | 07:34 |
olofk | I have a local ordb2a system that uses it. It's more or less a copy of the orpsocv2 version, so I might rewrite it from scratch instead | 07:37 |
olofk | I'm ordering a nano now. Do I need anything else, like a UART adapter or something? | 07:38 |
stekern | do you still have an orsoc debug-adapter? | 07:39 |
olofk | hmm.. I might have returned that when I quit ORSoC | 07:42 |
olofk | But I guess any cheap USB-UART adapter would be enough, right? Or do I want JTAG in the cable too? | 07:43 |
stekern | any cheap USB-UART will do | 07:45 |
olofk | And JTAG through the same cable as I do the programming? | 07:45 |
olofk | The Blaster thing-a-mob | 07:45 |
stekern | the only occasion where you want to use the seperate JTAG interface is when you want to debug or1k at the same time as you have a signaltap connection | 07:46 |
stekern | otherwise you can use JTAG over blaster-thing-a-mob | 07:46 |
stekern | and orpsocv3 have a open source alternative to signaltap anyway - DIILA! ;) | 07:47 |
stekern | I'd love to get insertion of that more automated, and orpsoc is probably a great platform for that | 07:47 |
olofk | Yeah, I've been thinking about something like DIILA a lot, and figured out that it must exist already | 07:48 |
olofk | But as you say, this is the kind of thing where it's important to have good support programs | 07:49 |
stekern | I agree, from an user point of view, DIILA isn't great (yet) | 07:52 |
olofk | fuck users. They are just complaining all the time | 07:53 |
stekern | but it's built with automation in mind, so it should basically just be to write the tools to do it | 07:54 |
olofk | That's good | 07:54 |
olofk | Again, the dot notation would be a godsend here :) | 07:54 |
stekern | yes, I reckon that'll be the most annoying part, pulling out the signals in all of the sources | 07:55 |
stekern | but, on the bright side, we can do that in the build directory, so we don't have to mess with the *actual* sources | 07:58 |
olofk | I don't know how Altera does it, but Xilinx chipscope hooks up to the synthesized edif netlist. | 08:06 |
olofk | But it might be easier to insert it into the hdl code directly | 08:07 |
jeremybennett | juliusb_: Are you online? | 08:12 |
stekern | olofk: I think altera does something similar. but, yes, inserting it into the hdl code sounds easier.. and probably less prone to break with quartus version updates | 08:43 |
stekern | ...and last but not least, it's device independent | 08:43 |
-!- ysionneau is now known as Yannou | 08:49 | |
olofk | Yes, the DI part of DIILA is quite important | 10:15 |
olofk | Hmm.. turns out that the nano was a bit more expensive with VAT added | 10:15 |
olofk | Getting them on ebay from Shenzhen seems to be the cheapest option so far | 10:17 |
stekern | stupid VAT, stealing all our money | 10:31 |
olofk | Yeah, and I'm sure those VAT guys are linked to the government somehow, but I can't prove anything | 10:34 |
olofk | I could probably walk to China and get a DE0-Nano, and it would still have it before my compilation of LibreOffice is finished | 10:51 |
olofk | oh.. it's finished now | 10:52 |
olofk | stekern: I'm not sure that verilog_write supports generating modules without ports with your latest changes | 13:08 |
olofk | ...or actually, I'm not sure what the updates to verilog_writer really do | 13:11 |
stekern | hmm,, can you have modules without ports? | 13:13 |
olofk | ahh ok, I see. If there are no ports, you skip the module header. I'll pull your changes (as we don't generate portless modules atm), but we should fix that somehow | 13:13 |
stekern | I was under the assumption you don't, but if you do, then that is indeed broken | 13:13 |
olofk | portless modules can be useful, for example or1200_monitor or vlog_tb_utils in orpsocv3 | 13:13 |
stekern | ok, yeah, we should fix that then | 13:14 |
olofk | Yeah, but I just add a note to the pull request and let it be. It's better to have the fix as it is now in the tree | 13:14 |
stekern | sounds good, I can take a look into what would be the "right" way to do module-less generation | 13:15 |
stekern | probably feed the verilog_writer a parameter wether you want a module or not | 13:16 |
olofk | Thanks for the patch, btw. This will simplify getting up new systems a whole lot | 13:17 |
stekern | I sent out a pull request for the de0 nano port I had in my local tree btw | 13:17 |
stekern | I've tested it briefly and it works | 13:17 |
stekern | ...but it lacks sim support and SPI | 13:18 |
olofk | (verilog_writer) Something like that should work. | 13:19 |
olofk | Awesome that we got a de0 nano port | 13:19 |
olofk | I should still get a board for myself :) | 13:20 |
olofk | Have you tested it with a debugger too? | 13:24 |
stekern | yes | 13:25 |
olofk | Cool. I haven't had time to try that in orpsocv3 except for with jtag_vpi | 13:26 |
olofk | When you say that simulation doesn't work... what's the problem? | 13:32 |
stekern | ummm, I haven't put any effort into it.. | 13:39 |
stekern | it's basically based on an older version of francks de1 port, so the simulation stuff as he's stuff was then | 13:42 |
stekern | +is | 13:42 |
stekern | so, hook-up to memory model is probably lacking | 13:43 |
stekern | and the question is how "board-like" we want our sims to be | 13:43 |
stekern | i.e. do we want to simulate plls etc | 13:43 |
olofk | I like the traceability of the code in the orpsoc_top header :) | 13:45 |
olofk | I would like to include the real pll if it's a potential issue with it, but that won't work straight away in Icarus | 13:46 |
stekern | mmm, it probably goes even further... but that felt enough | 13:47 |
olofk | We got de0_nano in the tree now. Thanks | 13:52 |
olofk | stekern: Do you have this problem? k. | 13:54 |
olofk | 13:19 < olofk> Awesome that we got a de0 nano port | 13:54 |
olofk | fucking stupid paste | 13:54 |
olofk | http://pastie.org/8338930 | 13:54 |
olofk | ahh... now I know. Haven't cleaned my cache | 13:55 |
stekern | hmm no | 13:55 |
stekern | but mine fails when it tries to compile the pll.v file | 13:55 |
olofk | hmmm..now I get the same issue that _franck_ was complaining about with the conflicting option string --transactions | 13:55 |
stekern | and yes, I have problems with "fucking stupid paste" too ;) | 13:56 |
olofk | :) | 13:56 |
stekern | I didn't know that Gothenburg was in a completely different timezone than the rest of sweden btw | 14:03 |
olofk | Haven't figured out how to fix that | 14:05 |
olofk | I guess it's because my raspberry pi is set to some left-side-driving kidney-pie-eating country's timezone | 14:05 |
ams | stekern: it is because gothenburg belongs to denmark. | 14:09 |
olofk | _franck_: I pushed a fix for the problem with conflicting plusargs | 14:15 |
olofk | stekern: de0_nano simulation almost working in modelsim now | 14:30 |
olofk | It's being picky about some syntax issues | 14:30 |
_franck_ | olofk: good | 14:34 |
_franck_ | my de1 is working with modelsim | 14:34 |
stekern | olofk: I can't see no de1 in de0_nano.system | 15:03 |
stekern | _franck_: yeah, I should probably have brought in the new stuff from your de1 port | 18:33 |
olofk | stekern: I can't see it either now. Wonder where I got that from | 19:09 |
stekern | me neither *puts on my best poker face* | 19:12 |
stekern | I did something forbidden, I noticed those right after I did the pull request so I force pushed that change... | 19:13 |
stekern | didn't think you'd be that quick noticing the request ;) | 19:14 |
olofk | Oh no! You could have slipped in a back door | 19:25 |
stekern | I need to get my screenshots back! | 19:27 |
olofk | :) | 19:33 |
_franck_ | no one is using the mt48lc16m16a2 model in orpsoc-cores ? | 19:36 |
_franck_ | can I update it (the wb_sdram_ctrl testbench will need updates) ? | 19:37 |
_franck_ | parameters are now exported to the top: http://pastie.org/8339774 | 19:38 |
olofk | _franck_: Hmmm... aren't they already exported, but with the old parameter syntax? | 19:39 |
_franck_ | didn't we have defines for SDRAM parameters ? | 19:40 |
olofk | Yes, but that was some weird solution where a define selected which parameters to use | 19:41 |
olofk | Are you using the upstream version or the one from orpsocv2 now? | 19:42 |
_franck_ | upstream + patches | 19:43 |
_franck_ | give me half an hour (for me to branch, checkout, pull, cherry-pick, whatever,...) so I can prepare my pull request for you to see the patch ;) | 19:45 |
olofk | That sounds like a plan :) | 19:46 |
_franck_ | olofk: done | 19:56 |
olofk | Thanks. I'll take a look | 19:57 |
stekern | I'm trying to get my things around this yocto stuff... | 20:02 |
stekern | I want a native arm toolchain | 20:02 |
stekern | I want to compile an or1k toolchain on the arm | 20:03 |
stekern | s/things/head | 20:04 |
olofk | That would probably be another great stress test for our toolchain | 20:04 |
_franck_ | wb_intercon_gen try with upstream version and stekern wb_intercon.conf : http://pastie.org/8339859 | 20:15 |
olofk | _franck_: You're missing an argument. It needs the output verilog file as the second argument | 20:16 |
olofk | I got a bit lazy with the command line parsing :) | 20:16 |
_franck_ | arf ;) | 20:16 |
olofk | _franck_: I've looked at your pull request now, and I think that patch 0001 is unnecessary. Could you remove that and resend? Looks good otherwise | 20:19 |
olofk | That line separator patch is really annyoing, but I guess it's better to have it | 20:20 |
_franck_ | is that patch 0001 really a problem ? because I would have to change 0002 also to be consistant | 20:25 |
stekern | counter question, is it really a problem to change 0002? =) | 20:29 |
_franck_ | well it is bacause I need git skills for that ;) | 20:30 |
stekern | git rebase -i is your friend | 20:30 |
stekern | you'll get a list with your patches, just remove 0001 in that list and set 0002 to edit | 20:31 |
stekern | (0002 will fail with 0001 so you'd get the chance to edit that anyway though) | 20:32 |
_franck_ | yes I'm using this sometimes. But when my patch is already pushed and I want to change it with rebase -i it breaks everything | 20:32 |
stekern | *with 0001 removed | 20:32 |
stekern | heh, define "breaks everything" | 20:32 |
_franck_ | it doesn't want to push the new "merged" patch because fast foward or something like this | 20:33 |
stekern | you have to define the commit you want to 'git rebase -i' against | 20:33 |
stekern | ah, you just need to force push it | 20:33 |
stekern | git push -f | 20:34 |
_franck_ | ah ok, I'll try this. I need to generate my patch serie again (the one in mt...). Are you sure you want me to do that ? :) | 20:34 |
stekern | what harm can it do me? =) | 20:35 |
_franck_ | I love those new upper case parameters :) If I were you I just leave it like this | 20:36 |
_franck_ | stekern: you already gave me some more work with wb_intercon.vh, I need to update my signals names | 20:38 |
stekern | you're welcome ;) | 20:38 |
_franck_ | should have pushed my de1 system before you did ;) | 20:38 |
_franck_ | the more I wait the more I have things to fix | 20:39 |
_franck_ | I think I'll go for a copy/paste back of orpsoc_tb from de0_nano to de1 | 20:41 |
stekern | orpsoc_top you mean? | 20:41 |
_franck_ | yes | 20:41 |
stekern | yeah, I merged most of the things from sockit into de0_nano | 20:42 |
stekern | and then I just alt-shift-% the rest | 20:43 |
stekern | the kernel I just built with yocto boots at least... | 20:54 |
olofk | _franck_: Yeah, I agree that the upper case parameters look nicer. Just wanted to avoid unncecessary patches. | 20:54 |
olofk | And I too have noticed that some things move fast, so it's best to just push stuff as soon as possible to avoid extra work :) | 20:55 |
stekern | if there would be a chance that they'd be upstreamed, they would probably be less "unnecessary" | 20:55 |
olofk | Yeah, but in this case I don't think we should hold our breath for it :) | 20:56 |
stekern | mmm | 21:02 |
olofk | stekern: Did someone just try to sneak in a .gitignore? Is that to hide your back doors? | 21:03 |
stekern | damn you're onto me, that's what the *.pyc is for... | 21:06 |
olofk | _franck_: I can try to do the rebase stuff for the mt... in my tree and push it if you want | 21:17 |
_franck_ | olofk: it would be great | 21:18 |
_franck_ | thanks | 21:18 |
olofk | hmm.. I'm having some trouble applying the patches | 21:43 |
olofk | I tried to just keep 0000, but it fails to apply that one too | 21:45 |
olofk | Need to sleep now. Will try again tomorrow | 21:46 |
poke53281 | Spend again 5 hours on this stability with X11. | 22:27 |
poke53281 | Reproducible in some way, but different problems for each client. No matter if | 22:27 |
poke53281 | I use xeyes, xclock, glxinfo or glxgears ... every program stops at a another position | 22:27 |
poke53281 | in the server. Eiter segmentation fault, assert, unknown opcode or unaligned access. | 22:27 |
poke53281 | I run even into problems while starting another program which has nothing in common with | 22:27 |
poke53281 | X11 except the use of the shared library uClibc. | 22:27 |
poke53281 | Mysterious is the best word describing it. | 22:27 |
poke53281 | So I don't think the bug is in X but in the kernel. | 22:27 |
poke53281 | Maybe some very rare mapping issue. | 22:27 |
poke53281 | s/stability/unstability/ | 22:36 |
--- Log closed Fri Sep 20 00:00:04 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!