| --- Log opened Fri Sep 06 00:00:43 2013 | ||
| poke53282 | Oh man, next terrible news from the NSA leak front. It's in all news. What will be next? Network device firmware hacking of all manufacturers? | 00:06 |
|---|---|---|
| poke53282 | One more reason for open hardware | 00:07 |
| olofk | hno: But submodules is when you have a repo that uses another repo internally, right? That's not the case here. I just want a tar ball with the files in a tree at a certain revision | 05:44 |
| stekern | _franck_: I can't come up with a reason not to do that, so pulled | 05:45 |
| stekern | hno, olofk: I was first about to suggest submodules too, but I think I agree with olofk here, it's possibly not the right tool for the problem. | 05:50 |
| stekern | because I think in many cases we do *not* want to lock to a certain commit | 05:51 |
| stekern | that said, olofk, I think it's a mistake to not have the git repo as such in the "build" directory | 05:57 |
| olofk | stekern: You mean in cache? | 06:10 |
| olofk | And not all repos that are fetched will be git either, so git submodules won't work | 06:11 |
| stekern | of course it could work, for the ones that are in git | 06:13 |
| olofk | My reasoning here is that it will be more light-weight to download a compressed archive, and if you plan to do development on a core, you can make a copy, remove the provider section and clone the repo there | 06:14 |
| stekern | yeah, fair enough | 06:15 |
| olofk | Hmm.. If I have a dependency chain that uses a core from github that uses one from opencores that uses one from github... would that work with submodules? I'm not very familiar with the concept | 06:15 |
| stekern | hmm, that would work, but actully, using a flat model of the depency in the .core file seems a lot less messy | 06:17 |
| stekern | ...at least if the github-core would be a submodule of the opencores-core and that would be a submodule of the first from github | 06:18 |
| olofk | Flat model...? Care to explain? | 06:18 |
| stekern | I just meant in contrary to the submodule of a submodule of a submodule | 06:19 |
| olofk | aha | 06:20 |
| olofk | Yes. The dependency tree is basically flattened internally to a list, so that would probably be ok | 06:20 |
| stekern | you can of course do the flat module with git submodules as well, just have a top git repo with the submodules as you would have it in the .core file | 06:21 |
| stekern | (the top git repo here would be orpsoc-cores) | 06:21 |
| stekern | for an example of git submodules, look here https://github.com/kevinmehall/openrisc-tools-build | 06:22 |
| stekern | but I still think the .core file approach is right here | 06:26 |
| olofk | I see | 06:29 |
| stekern | ah, the git repos are in cache/. sorry, I retract my statement about "mistake not being in build" then | 06:36 |
| olofk | _franck_: Could you try to see if it's enough to just add -L altera_mf to your vsim_options to load the altera libraries? | 06:44 |
| olofk | I don't have access to the Altera libraries here | 06:44 |
| _franck_ | olofk: vsim_options = -L altera_mf_ver -L altera_mf | 07:14 |
| _franck_ | it works | 07:15 |
| hno | olofk, you mean of a single repository? That's git archive | 07:17 |
| _franck_ | Warning: Design size of 84 instances exceeds ModelSim ALTERA recommended capacity | 07:18 |
| _franck_ | This may because you are loading cell libraries which are not recommended with | 07:18 |
| _franck_ | the ModelSim Altera version. Expect performance to be adversely affected. | 07:18 |
| _franck_ | never noticed this warning while using the GUI | 07:19 |
| hno | I don't quite follow... sure tarballs is slightly more lightweight than git clone, but if you start with a tarball and then want a checkout then it's all wasted. | 07:21 |
| olofk | _franck_: Yeah, I saw that too when I simulated the generic system. Altera's modelsim is very crippled | 07:23 |
| olofk | hno: In this case, most people will never touch the repos. They just need a static copy. | 07:24 |
| stekern | hno: maybe it's easier to explain by showing what we are speaking about, this are the cores: https://github.com/openrisc/orpsoc-cores/tree/master/cores | 07:39 |
| stekern | so, in theory, each of those could be transformed to a git submodule. *But*, we still need to have the .core description file to describe other properties of the core than were to fetch it from | 07:40 |
| stekern | this is an example of a .core file: https://github.com/openrisc/orpsoc-cores/blob/master/cores/mor1kx/mor1kx.core | 07:41 |
| stekern | now, you *could* of course still use git submodules, but all of the cores are not in git: https://github.com/openrisc/orpsoc-cores/blob/master/cores/uart16550/uart16550.core | 07:42 |
| stekern | and some are even local: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_bfm/wb_bfm.core | 07:43 |
| stekern | my point is, I think git submodules will just add overhead and break an unified way of describing the provider for a core | 07:45 |
| stekern | plus, you loose some flexibility | 07:46 |
| hno | <hno> olofk, I disagree. Quite often you need to touch something. And the step from being just a consumer to contribute should be as small as possible. | 07:47 |
| hno | <hno> and equally important, it should be very easy to check IF anything have been touched. | 07:47 |
| hno | <hno> and when you need to touch something, easy to keep track of your changes. | 07:47 |
| stekern | sure, but you do the changes in the *provider* then | 07:50 |
| stekern | but actually, thinking about it a bit more, we could of course use git submodules and just treat them as local providers | 07:52 |
| stekern | hno: the place where the actual "tar ball" ends up is a "build" directory, you should not do changes there, it's considered "auto generated". (this is very much like how qsys works too) | 08:01 |
| stekern | if that's good or bad... that's another matter, and I feel that that's where this discussion is heading | 08:03 |
| olofk | There's nothing as good as a Version Control System to trigger an eternal discussion about good and evil :) | 08:47 |
| stekern | olofk: what was the idea with 'sdt'? | 09:37 |
| stekern | what did the s stand for? | 09:37 |
| stekern | slave? | 09:37 |
| _franck_ | slave data transfert | 09:38 |
| stekern | or, I mean, I know the problem it solves | 09:38 |
| stekern | I just think we should use rdat and wdat if we're going to use something else | 09:38 |
| stekern | ...because I read sdt = store data, and that's the opposite to what it is, but perhaps that's just me being stupid again | 09:39 |
| _franck_ | no, first time I saw this I was like "it that a new wishbone signal ?" | 09:40 |
| stekern | can you easily tell emacs to turn off verilog mode? or create a modified verilog mode and switch between them | 09:42 |
| stekern | ? | 09:42 |
| _franck_ | but yes, we should try to be consistant over our systems tops files (same signals names, same coding style,...) | 09:43 |
| _franck_ | what do you think of having a new module with all the bus interconnect. So the top would be less messy | 09:43 |
| _franck_ | than when olofk has finished his interconnect generator, this module could be autogenerated | 09:44 |
| stekern | I think the top module and bus interconnect should be autogenerated, so... | 09:46 |
| stekern | ...breaking it out to a seperate file wouldn't gain anything in that scenario | 09:47 |
| stekern | I'm interested in what martin will show us about that on orconf, and I'm also interested in exploring migen for that task | 09:48 |
| stekern | (back to sdt) or, we could name all the signals wb_m2s_xxx and wb_s2m_xxx | 09:51 |
| stekern | s&m xxx | 09:51 |
| _franck_ | yes I like this like SPI miso, mosi so there is no doubt | 09:53 |
| stekern | I think I like that better than rdata and wdata too | 09:55 |
| stekern | then we still follow the wb spec for the names, we just prefix them for clarity for our own sake | 09:56 |
| stekern | _franck_: is this right? or1200_top #(.boot_adr(32'hf0000000)) | 09:57 |
| stekern | does or1200 add the 0x100 by itself? | 09:57 |
| _franck_ | no it's not right | 09:58 |
| _franck_ | but as I'm always using the debugger it didn't matter until yesterday when I started a simu and didn't commit this change ;) | 09:59 |
| stekern | heh, ok | 10:00 |
| hno | stekern, ok. That is fine, if used as a GPL compliance to record what was included in a build. | 10:11 |
| stekern | hno: umm? | 10:22 |
| LoneTech | stekern: the easy way to switch mode I know is to hit M-x fun Tab enter, to go to fundamental-mode ... not so sure about verilog-mode configurations, most modes have tons of variables you could set per buffer | 10:48 |
| stekern | LoneTech: thanks, the fundamental-mode was what I was looking for | 10:59 |
| stekern | I'll have to explore the verilog mode config later | 10:59 |
| LoneTech | I do like the clarity of m2s and s2m | 11:07 |
| LoneTech | recently had the fun experience of going RTFS to figure out which of d0 and d1 on am335x were miso and mosi | 11:08 |
| olofk | I disagree with the m2s naming | 11:44 |
| olofk | Or wait.. I misunderstood | 11:45 |
| olofk | I could go with that, but I prefer rdt (as I renamed my previous sdt signal) | 11:45 |
| olofk | My interconnect generator is done now, but I haven't been able to test it yet | 11:46 |
| olofk | And in my opinion, it's a different problem from top-level generation | 11:46 |
| _franck_ | olofk: give me a link and some instructions and I'll test it | 11:50 |
| olofk | _franck_: Great. https://www.dropbox.com/s/cjskgr1j4hh1oba/wb_intercon_gen.tar.gz | 12:01 |
| olofk | There's updated wb_mux and wb_arbiter in the archive | 12:01 |
| olofk | And a intercon.v that is the output, so you can compare with the one that you generate | 12:02 |
| olofk | Run with : python wb_intercon_gen.py <config file> | 12:02 |
| stekern | why do you prefer rdt? | 12:05 |
| olofk | Mainly to avoid signal name length creep :) | 12:06 |
| olofk | But I see the merits of the [ms]2[sm] naming too | 12:06 |
| stekern | and of course interconnect generation is a different problem from top-level generation, I just meant that I'm of the opinion that they both should be automated, so I have no opinion on seperating them into two files | 12:06 |
| stekern | ah, I think signal name length creep is less of a problem than tla creep ;) | 12:07 |
| olofk | Yeah, I see what you mean. | 12:07 |
| stekern | especially when the tla isn't a tla | 12:07 |
| olofk | On both your comments | 12:07 |
| stekern | or1200 is horrible in that regard, everything is shortened to something | 12:08 |
| stekern | it's like reading a ieee standard | 12:09 |
| olofk | That doesn't make any sense. something is only one letter shorter than everything | 12:09 |
| stekern | still shorter | 12:11 |
| stekern | and it's very confusing when something is shortened to something | 12:12 |
| olofk | They asked one of the original UNIX guys what he regrets most about UNIX, and he said they should never have shortened create to creat | 12:12 |
| _franck_ | FWIW I like long names | 12:13 |
| olofk | I'll consider changing it | 12:15 |
| stekern | there are of course shortened names that are fine, idioms like tmp, cnt etc | 12:16 |
| _franck_ | olofk: your intercon generator could produce something like this: https://github.com/fjullien/orpsocv3/blob/master/systems/de1/soc_intercon.txt :) | 12:17 |
| stekern | heh, that'd be cool | 12:18 |
| stekern | I've got a minimal sockit orpsocv3 system building now at least | 12:19 |
| stekern | but only with clock and reset connected so far | 12:19 |
| stekern | it's a pity I haven't cracked the usbblaster ii nut | 12:21 |
| _franck_ | I'll be glad to give it a try when I have time | 12:22 |
| _franck_ | did you made some progress so far ? | 12:22 |
| stekern | yes, I have determined that it's very similar to the usbblaster 1 communication but it seems like the bitbanging mode doesn't work the same way | 12:23 |
| stekern | and you need to insert extra control words into the communication, but I can't remember the details of those right now | 12:24 |
| stekern | it's all in the irc logs ;) | 12:25 |
| _franck_ | yeah I remember you talking to yourself about this ;) | 12:27 |
| stekern | actually, a lot of it was with LoneTech ;) | 12:30 |
| LoneTech | that must be a statistic anomaly, everybody knows I don't talk | 12:31 |
| olofk | _franck_: That's beautiful. I should add hooks to asciidraw in the generator code :) | 12:34 |
| stekern | maybe it was just me talking, hoping that you were listening then | 12:35 |
| olofk | LoneTech: :) | 12:35 |
| stekern | ...but from what I recall, I got some valuable feedback from you | 12:35 |
| olofk | There are two larger differences in my interconnect strategy compared to the one in orpsocv2 | 12:36 |
| _franck_ | LoneTech: I remember now you were talking :) | 12:36 |
| olofk | 1. I don't have a separate byte bus. Just resize blocks on the slaves that need them | 12:37 |
| olofk | 2. It should be possible to have either crossbar or shared interconnects | 12:37 |
| stekern | olofk: I don't understand what this does: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/wb_arbiter.v#L97 | 12:37 |
| olofk | stekern: It's a workaround for a crash in verilator | 12:38 |
| stekern | perhaps a comment above that would be in place? ;) | 12:38 |
| stekern | is the arbiter above that this one? https://github.com/openrisc/orpsoc-cores/tree/master/cores/verilog-arbiter | 12:38 |
| olofk | It's a priority encoder | 12:38 |
| olofk | If bit 1 is set, then output 1, else if bit 2 is set then output 2... | 12:39 |
| olofk | Pretty fucking ugly code | 12:39 |
| olofk | I guess I should submit a test case with the original code to verilator | 12:41 |
| LoneTech | ah, so it uses an array of muxes to do priority encoding from constant integers. the sort of thing one would use a local variable to do in a process | 12:43 |
| olofk | LoneTech: Exactly. Only that verilator got caught in an endless loop when it tried to run that code | 12:43 |
| olofk | Hopefully the synthesis tools can make something good out of it anyway | 12:44 |
| stekern | why do you need ot priority encode it? | 12:45 |
| olofk | I wanted a mux selector signal | 12:46 |
| olofk | Patches are welcom :) | 12:46 |
| olofk | Ahh.. I see now that I could as well have put all the wbs_*_o assignments inside the for loop | 12:47 |
| olofk | No, that would probably make verilator angry | 12:48 |
| stekern | so, was it something like this that made verilator angry? https://github.com/skristiansson/wb_sdram_ctrl/blob/master/rtl/verilog/wb_port_arbiter.v#L187 | 12:49 |
| olofk | Yep. That was what I had before, but not in a function | 12:50 |
| stekern | because I realise that that's also priority encoding (but it doesn't need to be) | 12:50 |
| olofk | http://git.opencores.org/?a=commitdiff&p=orpsoc&h=37ce1fbc734f0a079f31d04963cd2c66392cf4fa | 12:51 |
| olofk | I suspect it will generate the same logic anyway | 12:52 |
| olofk | More or less | 12:52 |
| stekern | a comment with the old code and an explanation that verilator chokes on it would have saved us from this conversion ;) | 12:54 |
| olofk | What? Do you want to take away my only contact with other human specimen? | 12:55 |
| stekern | haha | 12:55 |
| olofk | Every line in ORPSoCv3 is constructed to raise questions, so that I can practice interaction with humanoids | 12:56 |
| stekern | all my bugs in wb_sdram_ctrl was also just to get some interaction from people | 12:56 |
| olofk | :) | 12:56 |
| juliusb | hello from OHS2013 | 13:15 |
| juliusb | stekern: regarding the version stuff, I think I get you now, so master always sits on an x.0 and then when we do a release we release x.y .... and master proceeds onto (x+1).0 | 13:17 |
| juliusb | and fixes specific to x.y go onto that branch only, and x.y becomes x.(y+1)? | 13:18 |
| juliusb | stekern: so, I was going to ask how we differentiate between the 1.0 which is on master and 1.0 which is branched | 13:22 |
| juliusb | but... we'll never have a 1.0 which is branched will we? we'll have a 1.1, right? | 13:22 |
| juliusb | also... I would want to be able to track to exactly a commit the state of the RTL. that's why I think it's probably useful to somehow inject part or all of the commit hash into the RTL | 13:23 |
| juliusb | something which we really need is full tracability in terms of exactly the state of the RTL on the board. So having all the parameters available in those registers I added, plus having the git hash should allow us to do that | 13:24 |
| stekern | juliusb: actually, I was thinking the branch would start at .0 | 13:55 |
| stekern | and without the thing you just mentioned, you can't make out the difference between the master .0 and the commit that get branched as a .0 release | 13:56 |
| stekern | but the same is also true for commits in between .0 and .1 in the branched tree | 13:57 |
| _franck_ | didn't you say the master gets a commit to increase the version number as soon as we tagged a version ? | 13:57 |
| stekern | yes, but I meant the major number, i.e. 1.0 to 2.0 | 13:58 |
| stekern | I'm not married to it though, I put the idea out for discussion | 14:00 |
| _franck_ | I think each commit in the branched tree should increase the minor number | 14:04 |
| _franck_ | http://pastebin.com/sMC2ptH5 | 14:07 |
| _franck_ | master will always be x.0 | 14:07 |
| juliusb | https://plus.google.com/115038002894382480638/posts/NjJ5rwyqQ8j | 14:47 |
| juliusb | slides: https://www.dropbox.com/s/bybyk5h8riju77f/julius-baxter-open-chip-design.pdf | 14:51 |
| juliusb | it was more of a health report on the open source RTL effort | 14:52 |
| juliusb | stekern: regarding versioning....why don't we let the minor version crank up with the releases? | 14:58 |
| juliusb | sorry, with the commits | 14:58 |
| juliusb | so master major version is always the same as the last major release, but the minor ticks up rather quickly | 14:59 |
| juliusb | we can go up to 255 I believe | 14:59 |
| juliusb | as it's an 8-bit field in the register | 14:59 |
| juliusb | so we do a commit which moves a nice moment on the master up to (major_version+1).0 and that gets tagged and branched? | 15:01 |
| juliusb | i wonder if it's possible to have the checkin automatically increment the minor version? | 15:02 |
| juliusb | or maybe we manage that | 15:03 |
| stekern | (increase minor each commit) I guess we could do that. I liked the idea that the x.0 release would be a staging area for a stable x.1 though | 15:33 |
| stekern | otoh, it removes the burden when to make the call to move up to x.1... | 15:47 |
| juliusb | stekern: I really think there should be some way to differentiate between the tag and the big released version and what is being developed on master | 16:17 |
| juliusb | I nkow, it's kind-of in the future, though, so if you have an image which says it's version 2.0 and another image which says it's 2.0 in the version registers, how do you tell the difference between a build which was off the releaed version and one which was the developmental version? | 16:18 |
| juliusb | .. but maybe I'm wrong, maybe the release will be 2.1? | 16:19 |
| juliusb | in which case, I'm fine wth the versioning system, as long as we can figure out exactly which commit we built from | 16:20 |
| juliusb | which is why I added enough regsiters to store a 256-bit git hash value to the spec ;) | 16:20 |
| juliusb | (or did I?) | 16:23 |
| juliusb | ISRs! that's it | 16:27 |
| juliusb | 8 of them * 32-bit = 256-bits! | 16:29 |
| _franck_ | juliusb: http://pastebin.com/sMC2ptH5 , we can not have master and release with the same version | 16:35 |
| juliusb | sure, not at the same time, but it doesn't mean there's not images sitting around with those versions | 16:36 |
| juliusb | and then you get confused, so having the commit ID would be good | 16:38 |
| _franck_ | "not at the same time" you're right, I didn't think about this | 16:45 |
| _franck_ | olofk: it would be great if we add support for wb_data_resize in your wb_intercon_gen | 17:01 |
| _franck_ | s/add/had | 17:01 |
| stekern | juliusb: "big released version" <- that's what I'm trying to say that the .0 release shouldn't be | 17:34 |
| stekern | everything with .0 on it is shaky stuff | 17:34 |
| stekern | the .0 release should just come from "I feel like doing a release today" | 17:35 |
| stekern | then we bake that into a .1 that is the first stable version | 17:35 |
| stekern | the problem I'm trying to solve with that is that it should be a no-big-deal thing to do a .0 release | 17:36 |
| stekern | otherwise the situation where we continuosly postponed the 1.0 release for over a year will just go on | 17:37 |
| stekern | but we can of course have .0 only in master, then we break out a .1 call that "shaky" and build upon that if you feel it is better | 17:51 |
| stekern | looks like it's not a trivial task to get uart output on the sockit board | 18:25 |
| stekern | the usb-uart port is connected to the hps | 18:25 |
| stekern | so is the only pinheader with "diy" access | 18:25 |
| _franck_ | stekern: when you do a board simulation with your wb_sdram_ctrl, are you waiting for the sdram power up delay is finished before release the cpu reset ? | 20:30 |
| stekern | _franck_: no | 21:06 |
| _franck_ | I cannot get anything out of the sdram... | 21:09 |
| _franck_ | must be something big in front of my eyes | 21:09 |
| _franck_ | could you take a look at this https://www.dropbox.com/s/je1zhp1q3ng0tk6/de1.vcd when you have some time ? | 21:14 |
| _franck_ | looks like my wiredelay in the testbench is the problem | 21:20 |
| _franck_ | it was... | 21:23 |
| hansfbaier | juliusb: What is the program on the lower left on the 3rd slide? | 21:56 |
| hansfbaier | juliusb: alliance? | 21:56 |
| --- Log closed Sat Sep 07 00:00:45 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!