IRC logs for #openrisc Friday, 2013-09-06

--- Log opened Fri Sep 06 00:00:43 2013
poke53282Oh 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
poke53282One more reason for open hardware00:07
olofkhno: 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 revision05:44
stekern_franck_: I can't come up with a reason not to do that, so pulled05:45
stekernhno, 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
stekernbecause I think in many cases we do *not* want to lock to a certain commit05:51
stekernthat said, olofk, I think it's a mistake to not have the git repo as such in the "build" directory05:57
olofkstekern: You mean in cache?06:10
olofkAnd not all repos that are fetched will be git either, so git submodules won't work06:11
stekernof course it could work, for the ones that are in git06:13
olofkMy 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 there06:14
stekernyeah, fair enough06:15
olofkHmm.. 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 concept06:15
stekernhmm, that would work, but actully, using a flat model of the depency in the .core file seems a lot less messy06:17 least if the github-core would be a submodule of the opencores-core and that would be a submodule of the first from github06:18
olofkFlat model...? Care to explain?06:18
stekernI just meant in contrary to the submodule of a submodule of a submodule06:19
olofkYes. The dependency tree is basically flattened internally to a list, so that would probably be ok06:20
stekernyou 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 file06:21
stekern(the top git repo here would be orpsoc-cores)06:21
stekernfor an example of git submodules, look here
stekernbut I still think the .core file approach is right here06:26
olofkI see06:29
stekernah, the git repos are in cache/. sorry, I retract my statement about "mistake not being in build" then06: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
olofkI don't have access to the Altera libraries here06:44
_franck_olofk: vsim_options = -L altera_mf_ver -L altera_mf07:14
_franck_it works07:15
hnoolofk, you mean of a single repository? That's git archive07:17
_franck_Warning: Design size of 84 instances exceeds ModelSim ALTERA recommended capacity07:18
_franck_This may because you are loading cell libraries which are not recommended with07:18
_franck_the ModelSim Altera version. Expect performance to be adversely affected.07:18
_franck_never noticed this warning while using the GUI07:19
hnoI 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 crippled07:23
olofkhno: In this case, most people will never touch the repos. They just need a static copy.07:24
stekernhno: maybe it's easier to explain by showing what we are speaking about, this are the cores:
stekernso, 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 from07:40
stekernthis is an example of a .core file:
stekernnow, you *could* of course still use git submodules, but all of the cores are not in git:
stekernand some are even local:
stekernmy point is, I think git submodules will just add overhead and break an unified way of describing the provider for a core07:45
stekernplus, you loose some flexibility07: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
stekernsure, but you do the changes in the *provider* then07:50
stekernbut actually, thinking about it a bit more, we could of course use git submodules and just treat them as local providers07:52
stekernhno: 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
stekernif that's good or bad... that's another matter, and I feel that that's where this discussion is heading08:03
olofkThere's nothing as good as a Version Control System to trigger an eternal discussion about good and evil :)08:47
stekernolofk: what was the idea with 'sdt'?09:37
stekernwhat did the s stand for?09:37
_franck_slave data transfert09:38
stekernor, I mean, I know the problem it solves09:38
stekernI just think we should use rdat and wdat if we're going to use something else09: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 again09:39
_franck_no, first time I saw this I was like "it that a new wishbone signal ?"09:40
stekerncan you easily tell emacs to turn off verilog mode? or create a modified verilog mode and switch between them09: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 messy09:43
_franck_than when olofk has finished his interconnect generator, this module could be autogenerated09:44
stekernI 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 scenario09:47
stekernI'm interested in what martin will show us about that on orconf, and I'm also interested in exploring migen for that task09:48
stekern(back to sdt) or, we could name all the signals wb_m2s_xxx and wb_s2m_xxx09:51
stekerns&m xxx09:51
_franck_yes I like this like SPI miso, mosi so there is no doubt09:53
stekernI think I like that better than rdata and wdata too09:55
stekernthen we still follow the wb spec for the names, we just prefix them for clarity for our own sake09:56
stekern_franck_: is this right? or1200_top #(.boot_adr(32'hf0000000))09:57
stekerndoes or1200 add the 0x100 by itself?09:57
_franck_no it's not right09: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
stekernheh, ok10:00
hnostekern, ok. That is fine, if used as a GPL compliance to record what was included in a build.10:11
stekernhno: umm?10:22
LoneTechstekern: 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 buffer10:48
stekernLoneTech: thanks, the fundamental-mode was what I was looking for10:59
stekernI'll have to explore the verilog mode config later10:59
LoneTechI do like the clarity of m2s and s2m11:07
LoneTechrecently had the fun experience of going RTFS to figure out which of d0 and d1 on am335x were miso and mosi11:08
olofkI disagree with the m2s naming11:44
olofkOr wait.. I misunderstood11:45
olofkI could go with that, but I prefer rdt (as I renamed my previous sdt signal)11:45
olofkMy interconnect generator is done now, but I haven't been able to test it yet11:46
olofkAnd in my opinion, it's a different problem from top-level generation11:46
_franck_olofk: give me a link and some instructions and I'll test it11:50
olofk_franck_: Great.
olofkThere's updated wb_mux and wb_arbiter in the archive12:01
olofkAnd a intercon.v that is the output, so you can compare with the one that you generate12:02
olofkRun with : python <config file>12:02
stekernwhy do you prefer rdt?12:05
olofkMainly to avoid signal name length creep :)12:06
olofkBut I see the merits of the [ms]2[sm] naming too12:06
stekernand 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 files12:06
stekernah, I think signal name length creep is less of a problem than tla creep ;)12:07
olofkYeah, I see what you mean.12:07
stekernespecially when the tla isn't a tla12:07
olofkOn both your comments12:07
stekernor1200 is horrible in that regard, everything is shortened to something12:08
stekernit's like reading a ieee standard12:09
olofkThat doesn't make any sense. something is only one letter shorter than everything12:09
stekernstill shorter12:11
stekernand it's very confusing when something is shortened to something12:12
olofkThey asked one of the original UNIX guys what he regrets most about UNIX, and he said they should never have shortened create to creat12:12
_franck_FWIW I like long names12:13
olofkI'll consider changing it12:15
stekernthere are of course shortened names that are fine, idioms like tmp, cnt etc12:16
_franck_olofk: your intercon generator could produce something like this: :)12:17
stekernheh, that'd be cool12:18
stekernI've got a minimal sockit orpsocv3 system building now at least12:19
stekernbut only with clock and reset connected so far12:19
stekernit's a pity I haven't cracked the usbblaster ii nut12:21
_franck_I'll be glad to give it a try when I have time12:22
_franck_did you made some progress so far ?12:22
stekernyes, 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 way12:23
stekernand you need to insert extra control words into the communication, but I can't remember the details of those right now12:24
stekernit's all in the irc logs ;)12:25
_franck_yeah I remember you talking to yourself about this ;)12:27
stekernactually, a lot of it was with LoneTech ;)12:30
LoneTechthat must be a statistic anomaly, everybody knows I don't talk12:31
olofk_franck_: That's beautiful. I should add hooks to asciidraw in the generator code :)12:34
stekernmaybe it was just me talking, hoping that you were listening then12:35
olofkLoneTech: :)12:35
stekern...but from what I recall, I got some valuable feedback from you12:35
olofkThere are two larger differences in my interconnect strategy compared to the one in orpsocv212:36
_franck_LoneTech: I remember now you were talking :)12:36
olofk1. I don't have a separate byte bus. Just resize blocks on the slaves that need them12:37
olofk2. It should be possible to have either crossbar or shared interconnects12:37
stekernolofk: I don't understand what this does:
olofkstekern: It's a workaround for a crash in verilator12:38
stekernperhaps a comment above that would be in place? ;)12:38
stekernis the arbiter above that this one?
olofkIt's a priority encoder12:38
olofkIf bit 1 is set, then output 1, else if bit 2 is set then output 2...12:39
olofkPretty fucking ugly code12:39
olofkI guess I should submit a test case with the original code to verilator12:41
LoneTechah, 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 process12:43
olofkLoneTech: Exactly. Only that verilator got caught in an endless loop when it tried to run that code12:43
olofkHopefully the synthesis tools can make something good out of it anyway12:44
stekernwhy do you need ot priority encode it?12:45
olofkI wanted a mux selector signal12:46
olofkPatches are welcom :)12:46
olofkAhh.. I see now that I could as well have put all the wbs_*_o assignments inside the for loop12:47
olofkNo, that would probably make verilator angry12:48
stekernso, was it something like this that made verilator angry?
olofkYep. That was what I had before, but not in a function12:50
stekernbecause I realise that that's also priority encoding (but it doesn't need to be)12:50
olofkI suspect it will generate the same logic anyway12:52
olofkMore or less12:52
stekerna comment with the old code and an explanation that verilator chokes on it would have saved us from this conversion ;)12:54
olofkWhat? Do you want to take away my only contact with other human specimen?12:55
olofkEvery line in ORPSoCv3 is constructed to raise questions, so that I can practice interaction with humanoids12:56
stekernall my bugs in wb_sdram_ctrl was also just to get some interaction from people12:56
juliusbhello from OHS201313:15
juliusbstekern: 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).013:17
juliusband fixes specific to x.y go onto that branch only, and x.y becomes x.(y+1)?13:18
juliusbstekern: so, I was going to ask how we differentiate between the 1.0 which is on master and 1.0 which is branched13:22
juliusbbut... we'll never have a 1.0 which is branched will we? we'll have a 1.1, right?13:22
juliusbalso... 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 RTL13:23
juliusbsomething 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 that13:24
stekernjuliusb: actually, I was thinking the branch would start at .013:55
stekernand 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 release13:56
stekernbut the same is also true for commits in between .0 and .1 in the branched tree13: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
stekernyes, but I meant the major number, i.e. 1.0 to 2.013:58
stekernI'm not married to it though, I put the idea out for discussion14:00
_franck_I think each commit in the branched tree should increase the minor number14:04
_franck_master will always be x.014:07
juliusbit was more of a health report on the open source RTL effort14:52
juliusbstekern: regarding versioning....why don't we let the minor version crank up with the releases?14:58
juliusbsorry, with the commits14:58
juliusbso master major version is always the same as the last major release, but the minor ticks up rather quickly14:59
juliusbwe can go up to 255 I believe14:59
juliusbas it's an 8-bit field in the register14:59
juliusbso 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
juliusbi wonder if it's possible to have the checkin automatically increment the minor version?15:02
juliusbor maybe we manage that15: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 though15:33
stekernotoh, it removes the burden when to make the call to move up to x.1...15:47
juliusbstekern: I really think there should be some way to differentiate between the tag and the big released version and what is being developed on master16:17
juliusbI 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
juliusbin which case, I'm fine wth the versioning system, as long as we can figure out exactly which commit we built from16:20
juliusbwhich 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
juliusbISRs! that's it16:27
juliusb8 of them * 32-bit = 256-bits!16:29
_franck_juliusb: , we can not have master and release with the same version16:35
juliusbsure, not at the same time, but it doesn't mean there's not images sitting around with those versions16:36
juliusband then you get confused, so having the commit ID would be good16:38
_franck_"not at the same time" you're right, I didn't think about this16:45
_franck_olofk: it would be great if we add support for wb_data_resize in your wb_intercon_gen17:01
stekernjuliusb: "big released version" <- that's what I'm trying to say that the .0 release shouldn't be17:34
stekerneverything with .0 on it is shaky stuff17:34
stekernthe .0 release should just come from "I feel like doing a release today"17:35
stekernthen we bake that into a .1 that is the first stable version17:35
stekernthe problem I'm trying to solve with that is that it should be a no-big-deal thing to do a .0 release17:36
stekernotherwise the situation where we continuosly postponed the 1.0 release for over a year will just go on17:37
stekernbut 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 better17:51
stekernlooks like it's not a trivial task to get uart output on the sockit board18:25
stekernthe usb-uart port is connected to the hps18:25
stekernso is the only pinheader with "diy" access18: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_: no21:06
_franck_I cannot get anything out of the sdram...21:09
_franck_must be something big in front of my eyes21:09
_franck_could you take a look at this when you have some time ?21:14
_franck_looks like my wiredelay in the testbench is the problem21:20
_franck_it was...21:23
hansfbaierjuliusb: What is the program on the lower left on the 3rd slide?21:56
hansfbaierjuliusb: alliance?21:56
--- Log closed Sat Sep 07 00:00:45 2013

Generated by 2.15.2 by Marius Gedminas - find it at!