| --- Log opened Tue May 06 00:00:36 2014 | ||
| skip__ | stekern: thanks for the help! :), I was off by one somewhere in the MMU, sim essentially boots now http://pastebin.com/5pcpUMXU | 00:19 |
|---|---|---|
| stekern | skip__: congrats! | 04:44 |
| stekern | but why are you using an ancient Linux version? | 04:44 |
| stekern | there are probably loads of bugs that are fixed in that | 04:44 |
| stekern | loads of bugs in that, which are fixed in later versions | 04:52 |
| stekern | =) | 04:53 |
| stekern | olofk: I updated the systemc pull-request, was there any kind of notification about that? | 06:04 |
| stekern | just want to know if such a work-flow could work | 06:05 |
| stekern | still not completely happy how that works in githubs pull-requests | 06:05 |
| stekern | but if at least some notification is sent when you update it like I just did, I guess it's something I can live with | 06:06 |
| stekern | Xilinx website is as solid as their tools... | 06:39 |
| stekern | I went to download ISE, and it started to download vivado | 06:40 |
| stekern | i.e., I went to this page: http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm | 06:41 |
| stekern | and pressed "Download ISE WebPACK software for Windows and Linux." | 06:41 |
| stekern | https://plus.google.com/102150693225130002912/posts/YDKRFDwHwr6 | 07:14 |
| stekern | even with sw tlb refill, we're not that slow | 07:14 |
| stekern | at least not in terms of clock cycles ;) | 07:15 |
| olofk | stekern: #46 fot FuseSoc, right? No notice for the changes | 07:21 |
| stekern | yes #46 | 07:24 |
| stekern | I even changed the "comment" message, why isn't such changes notified? | 07:24 |
| stekern | obviously you need to add new comments... and it's annoying that the old comments disappears when you force-push the fixed branch | 07:25 |
| stekern | http://ootbcomp.com/docs/ | 08:10 |
| olofk | ahh..the Mill CPU | 08:27 |
| olofk | I haven't gotten my head around that thing yet | 08:27 |
| olofk | Is it any good? | 08:27 |
| olofk | That link looked like a very readable introduction though. I should probably start there | 08:28 |
| LoneTech | it's fairly interesting.. whether it's good will be very program dependent | 08:31 |
| LoneTech | they've reduced the penalties of a very wide issue VLIW machine a bit, but not eliminated them | 08:31 |
| stekern | I haven't read up on it yet, a guy at work came up and spoke warmly about it. | 08:54 |
| stekern | mostly as a contrast to the "boring RISC cpus" | 08:54 |
| LoneTech | the memory design with automatically blanked cache line allocation and deferred load makes sense | 08:54 |
| stekern | he's right of course =) | 08:54 |
| stekern | yeah, he explained the deferred load, I didn't get it 100% though. Need to read it to get it I think | 08:55 |
| LoneTech | it has to do with the absence of a register file as such. you do content addressing of the pipelines instead, largely | 08:56 |
| LoneTech | with the deferred loads, you ask for the result to appear at a specific time in the instruction stream | 08:56 |
| LoneTech | there's also a bunch of metadata tracking allowing things like not causing an exception on broken values (for instance, bad loads) if they end up unused | 08:57 |
| stekern | ah, ok. so, basically *if* it were a traditional risc machine with register file it'd be like 1: load r1,addr; 2: add r2, r3; 3: add r3, r4; 4: add r4,r1 | 09:01 |
| stekern | but instead, you say 'load @4' | 09:01 |
| stekern | ? | 09:01 |
| stekern | well, 'load @4, addr', perhaps | 09:02 |
| stekern | kinda like load-delay-slots on steroids | 09:03 |
| stekern | or am I completely off track? | 09:03 |
| LoneTech | you're not completely off track | 09:08 |
| LoneTech | looks like a pretty good description actually | 09:09 |
| LoneTech | the basic effect is that the compiler is allowed to hoist and speculate fetches, so the processor does not need to predict them | 09:11 |
| stekern | and the processor doesn't need to keep track of register usage if/when it deferres loads internally | 09:19 |
| LoneTech | well, the load takes a pipeline slot in the load unit, effectively. the address it appears on is stored there, and it doesn't appear until the marked delay - if the load isn't finished yet it may stall | 09:20 |
| stekern | right | 09:20 |
| LoneTech | much of the mill design is removing large logic blocks that served to reduce the large processor design to an obsolete ISA model | 09:22 |
| stekern | my point was just that, deferring loads as such isn't anything spectalurly innovative, getting rid of the downsides is | 09:22 |
| LoneTech | right | 09:22 |
| LoneTech | the "belt" uses instruction position in the execution stream to decide on value names, which removes the destination operand at the expense of old values dropping off | 09:28 |
| LoneTech | (turns out there aren't that many you want kept a long time - mostly the context pointers, which might be special cases, I don't recall right now) | 09:30 |
| stekern | yeah, it's definitely an interesting approach | 09:39 |
| LoneTech | the generational naming also allows it to hide values from other subroutines on calls | 09:42 |
| LoneTech | a bit sparcish, but somewhat more precise | 09:43 |
| stekern | back to more down-to-earth problems... how the h*ll do I obtain a Vivado WebPACK License? | 09:55 |
| LoneTech | oh, did they make it more broken again? I'll never understand why these companies keep throwing so much money at flexlm to break their software | 09:58 |
| stekern | I don't know if this is flexlm related, but when I click the "get Vivado webpack licenses" in the license manager I get to a webpage that gives me this message: http://pastie.org/9145397 | 10:03 |
| LoneTech | oh yes, that's most definitely flexlm breaking it for you | 10:04 |
| LoneTech | it's also extra helpful in guessing instead of diagnosing the problem | 10:04 |
| stekern | what a POS | 10:13 |
| LoneTech | there's a possibility you have a license that could be found in an account page somewhere | 10:20 |
| stekern | but isn't that for ISE? | 10:22 |
| LoneTech | could be. it's just one of the guesses they provide you with is "we're not giving you a license because we already gave you one", and if so, that one might be stored elsewhere also | 10:23 |
| LoneTech | (of course the sensible thing to do would be handing it out again in the first place, but there's a serious divide between LM/DRM and sensible) | 10:24 |
| stekern | I have a bunch of .lic licenses, but this is the new "fancy" activation license stuff... | 10:26 |
| LoneTech | it's just harder to use. same fundamental crap | 10:27 |
| stekern | hah, yeah... from the vivado manual: http://pastie.org/9145455 | 10:30 |
| stekern | I guess my harddrives can't be trusted or something then... | 10:30 |
| LoneTech | yep, you're the customer, ergo the enemy. isn't it a wonderful attitude? | 10:31 |
| LoneTech | never mind that this "trusted area" differs from the file only in obscurity and fragility | 10:32 |
| stekern | luckily enough, non-paying customer... | 10:32 |
| stekern | err, non-paying enemy, I mean | 10:33 |
| stekern | I don't get why they need to have any licenses for the web-pack stuff anyway... | 10:33 |
| stekern | can't it just work to a certain level without a license..? | 10:34 |
| LoneTech | they don't. it's pure BS. also, earlier versions didn't | 10:34 |
| stekern | well, of course they don't *need* to. I mean, why do they *insist* on it ;) | 10:35 |
| LoneTech | they've been flip-flopping on it. they removed it once, because it was troublesome, now they reintroduced it because somebody sold them on it | 10:35 |
| stekern | maybe it's just part of an assimilation process, so you'll be accustomed to it when you buy the product | 10:36 |
| LoneTech | they don't want you buying the product; they want you to petition them for the boon of renting partial access. | 10:37 |
| stekern | looks like I'm attending Assembly this year | 10:41 |
| stekern | ...collecting empty bottles | 10:42 |
| stekern | =) | 10:43 |
| stekern | to raise money for my sons football team | 10:45 |
| LoneTech | good luck | 10:46 |
| stekern | for future references, running the vivado license manager as root "fixes" the issue | 11:33 |
| blueCmd | stekern: Assembly is just the poor mans Dreamhack :) | 12:17 |
| stekern | ;) | 12:25 |
| stekern | Assembly was bigger in the golden era of demo parties though | 12:29 |
| LoneTech | stekern: good to know. I am guessing the "trusted" region requires a privilege escalation (which does not give me a reason to trust it) | 12:33 |
| stekern | LoneTech: yes, maybe... the funny thing is that I could "install the .xml into the trusted area" as a regular user | 12:34 |
| stekern | could be something silly that it couldn't read some info about the machine as a regular user to create the request too | 12:35 |
| LoneTech | or even sillier, like not finding the tool to do so in your path | 12:35 |
| LoneTech | (for instance, /sbin/ifconfig is runnable as user, you just can't change things) | 12:36 |
| stekern | yes, I was thinking about something in line with that too | 12:36 |
| LoneTech | sometimes the people writing installers and similar toss in checks for root for no reason at all | 12:37 |
| stekern | but since it doesn't emit any messages at all about what's wrong, I guess we'll never know | 12:37 |
| LoneTech | you could start over and strace it, but it's probably not worth the effort | 12:37 |
| stekern | heh, yeah... no, I think I pass | 12:38 |
| --- Log closed Wed May 07 00:00:37 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!