OpenCores.org: see any benefits to Parallax hosting files on their site?
Ken Gracey
Posts: 7,392
Hey all,
I spent some time this afternoon on opencores.org and didn't leave the site without a ton of clarity about the benefits to Parallax and the community if we hosted some files on the site. I sent a message and I'm awaiting a call so I could understand where we'd fit in exactly.
I would appreciate knowing what the community thinks of the site's goals. Do you think it would be beneficial to our community and Parallax? If so, why?
Please share your thoughts.
Thanks,
Ken Gracey
I spent some time this afternoon on opencores.org and didn't leave the site without a ton of clarity about the benefits to Parallax and the community if we hosted some files on the site. I sent a message and I'm awaiting a call so I could understand where we'd fit in exactly.
I would appreciate knowing what the community thinks of the site's goals. Do you think it would be beneficial to our community and Parallax? If so, why?
Please share your thoughts.
Thanks,
Ken Gracey
Comments
So if any files posted there, always have links to Obex and Forums, you lose nothing.
OpenCores is a common educational point of reference, so it gives you a way to reach those who have never heard of Prop / Parallax.
However, to Parallax it could be yet another opportunity to expose the Propeller chip.
You would need to check that they accept GPL3 licensed code.You also want a link to the Parallax site and forums.
I think it would be worthwhile for Parallax.
It is one of the first places I look when I look for ... umm ... open cores
I don't know how you guys are getting organized, but a few days ago I read that Heater had already set up a Github location for file management. Anybody able to confirm the location of the Github and is it true that all of you will be working from the same source?
If we're well-organized then I could make a case to opencores that external file hosting is okay in our case. One difference between Parallax and the other cores listed on their site is community - we have a solid community outside of their system. I'm not clear we can live the same way in two places.
Indeed, I see benefits of getting exposure from their system.
Ken Gracey
I suspect they don't allow linking, simply because things may move, change, go away, get corrupted, be malware, etc... If they host it, then they know what they've got. Since the Propeller Verilog is GPL, pretty much anyone can drop it there, and whatever happens, happens openly, so whether or not we even get along, developments would be known to all parties.
As for living the same way... That's pretty much off the table. Open means open. We do what we do, and even among ourselves, do what we do differently. Anyone can make a repository, anyone can make changes, anyone can make other repositories, etc... They probably have community standards, or maybe more basically, ways they prefer to work. They will, or are likely to be, different from ours, and again, even here, there are differences.
The PropGCC team is using Google Code. Some of us will, or are using GitHub. Still others may well refuse all of that and just do files, folders and zip files. I've done that the whole time for P1. It's what others did kind of thing, though I sort of wish I had setup on a repository back a few years ago... Others may setup their own local repositories, so they can stay organized, but not depend on something found online....
I guess it really doesn't matter, though - the cat's outta the bag and increasing access to the content is what I should do. With this in mind, I may as well just put it all up on opencores too.
Ken Gracey
I forked Heater GitHub repository to get a copy of the P1V code initially and have since pushed the reset bug fix and the BE Micro directory to my repository so I already have a different looking collection of files that anyone else. I'm sure I will have issues incorporating other changes because of the way I set it up. Time will tell. If I can always go back to one known good, official Parallax source for the latest "official" code, then I think I'm ok.
You have the master files on your product server - whether you move those to OpenCores or someplace else to start a living (updated) repository is just going to come down to a Parallax choice as Potatohead pointed out. Whichever you pick, someone won't like it - they can either set up their own repository or learn to like it.
Sounds good, just make sure the files have links to the forums, and a Parallax page.
It may pay to not rush an upload, give it a few days to settle down, as some revisions are already coming through.
Someone has Xilinx builds coming too.
I agree that it may pay to wait few days. I think Parallax should hold the original master (with the bugs corrected) on your site for download.
At some future stage, it may be beneficial to hold another version(s) there too. This gives you control of these sources.
Sure, put them up elsewhere. But once you do that they are out there in the wild.
I know nothing of github and am not interested in learning for now, so I will do my own thing with some others on this forum.
Until the licensing situation for this forum is resolved, I will just post snippets. If I need to exchange files I will do that via email for now.
Others have put the code up on github, and they can work with this too.
Later I may learn about github and possibly then I will use it, but for now this old duck has enough to learn with verilog.
Sounds like you should spend some days or a week thinking about opencores and the repository issues.
As an open MCU design OpenCores is a natural place for it to be. It would certainly get the P1 design noticed.
From what you say there are some reservations.
1) SVN.
We can have religious debates about source code management as much as editors, language and whitespace. However their insistence on SVN is out of order. Your project should be managed how you like not how they like.
For a lot of reasons git is the way to go. The biggie for me is that it is a distributed system. All clones of a git repository are peers. There are no "master" repositories. That level of policy is up to you to manage how you like.
Github is a big attraction, it is something of a standard today. You will find Facebook, Twitter and others using it for their open code. Github has a great user interface, it has issue tracking, it has a wikis, it has a place to put your projects own web site.
None of this means Github is the "master" of anything. All git repos are "peers". That repo on the PC under Chips desk is probably the "master" repo. At least for as long as he chooses it to be. When he gets home he might have another one. Chip as the final authority and will push changes to the github repo or pull them into there from other users forks of the repo.
2) Opencores doesn't like links to external web sites
Perhaps I can see why, but really, that's not what the web is about is it?
There is no reason Parallax could not have a P1 project on opencores and even mirror the stable HDL versions into their SVN repository. Meanwhile development can go on elsewhere.
3) Heater had already set up a Github...
Yes, it's here: https://github.com/ZiCog/P8X32A_Emulation
No, it's not true that I expect anyone will be working from that. I only put in there for my convenience. A place to have the original released version available from no matter where I am. Anything to avoid messing with ZIP files. A place were I can tweak stuff if need be.
So far all I have changed is replacing the tabs with spaces to fix the broken formatting and make the source actually readable everywhere (Like on this forum)
But as you see my repo has been "forked" twice already. Those forks are "peers" of mine. mindrobots has fixed the reset issue in his fork. He could send me a "pull request" and I could have his reset fix in my code in minutes. If I like it that is.
As you see, if Parallax had the P1 in github you would already have developer contributions. You would not have Chip posting fixes to the forum and floating around in the noise.
In short. Yep put the project in GitHuB. Put the project on opencores. Development happens in the modern distributed git world. Interested users get stable versions the OpenCores route.
@mindrobots, Send me that pull request!
The ZPU is maintained in git. http://repo.or.cz/w/zpu.git. It has an opencores page with plenty of links to the real thing http://opencores.org/project,zpu. The latest snap shots are available from an opencores as tarballs. Been this way for years.
This points out some of the fun we'll be having with this code in the wild. The original patch is valid and works but once there is cog.v patched with that floating around and cog.v patched with the "official" patch floating around, we have two different versions of P1V that aren't significantly different.
Ray
I would take Linus Torvalds and the Linux kernel as a role model here.
Chip is the final authority on what a "Parallax Propeller" is. And any future versions. Like Linus is the final authority on what the Linux kernel is.
We hackers and tinkerers out here can fork and clone an hack and tweak the P1 in any way we like. Just as you can the Linux kernel.
If we come up with bug fixes or optimizations, or cross-platform support (Xilinx any one? or VHDL?) or even new features then if we are sensible and organized and playing in the system we can suggest them as changes to Chip to be pulled into the main line repository. Wherever Chip chooses to keep that. Git automates all that nicely. If he does not like those changes they don't get merged. Then you have forever your own fork, better not call it a "Parallax Propeller" for trade mark reasons. Just like "Linux" is trade marked.
In the extreme the owner of a project, Chip or Linus, might fall down on this job and contributors will get frustrated. At that point it's possible the developer base forgets all about Chip and Parallax and someone steps up to the plate to be the project "owner". A real "fork". A very unlikely and rare happening in the Open Source world.
Note for example that the reset bug is actually fixed by a patch from Chip himself. Hapazzardly posted here somewhere. Then changed. And who knows what is the right solution now? He could have just pushed the change into github and we are done.
This should be happening Parallax's repo, not mine. What do I know of Verlog or FPGA's or the P1? Almost nothing.
But if fixes like the reset issue turn up, in the absence of any better organization, I will be glad to pull them into that repo.
If I like them that is
When I apply this fix and build for the Nano it does not work.
Official fix: // 2014_08_10 fix from CGRACEY for reset problem always @(posedge clk_cog or negedge ena) if (!ena) dira <= 32'b0; else if (setdira) dira <= alu_r;When I revert to this fix:
// Initial fix - 2014_08_09 CGracey & PIK33 always @(posedge clk_cog or negedge ena) if (!ena) outa <= 32'b0; else if (setouta) outa <= alu_r; always @(posedge clk_cog or negedge ena) if (!ena) dira <= 32'b0; else if (setdira) dira <= alu_r;The Nano works as expected (F7 and F10 work repeatedly)
I don't really want to commit the "unofficial" fix even though it works if there will be a fixed "official" fix at some future point. Doing that would just lead to two slightly different sources floating around.
Can anyone else confirm or deny the working of the "official" fix?
That is clear as mud:)
Let's say that I fork Heater's repository(repo) and then make changes in my fork...and then Heater makes changes in the main repo... how do his changes in the main repo get reflected into my fork? Do I automate this or is that part of the environment?
how do I keep his changes from over-riding my changes?
As an extreme minor (if even that) in this endevor I have questions about the github thing. Still using Win7 due to issues with linux live cd, what program do you recommend to use github? I kinda vote for a more simple download system. Git hub seams kinda esoteric for my likes. :blank:
Just my 2 cents worth...
So much to learn so little time but I am fascinated by the FPGA thing!
Professional programmers use source code management. If Parallax wants to project a professional image of their code then Git is the way to go, and Github is the defacto standard.
As far as OpenCores.org goes: I've never used it, or had need to use it during my educational years. I'd only put code up there if Parallax had an officially sponsored repository, otherwise it will just contribute to a management nightmare.
I think Parallax should start a Github repository, point all links there, and only provide updates to Github. It's a bit draconian, but that's the only way it's going to work. Once that's done then we have an easily updated "master" that is public. And, even better, we have the history of the code. No more "see Chip's post #12534 for A, and Beau's post #2523 for B". If there's a Github repository then there's no reason not to set it up to automatically push changes to the OpenCores.org repository as a type of mirror.
I agree. "One ring to rule them all, One ring to find them, One ring to bring them all ...."
The "one" official Parallax Propeller 1 verilog repository should be easy to find and clone. And Jim Ewald knows all about git, so there you go.
When changes are made by Parallax, they go to that repository and they get tagged in various ways. People can go and make zip files with the buttons they find on the page.
That's the "official" repository, and it's official because Parallax says it's official, and they get to say that, because they are the creators and current knowledge authority on that code, as well as producer of chips, etc...
There will be any number of peer repositories containing everything from a simple clone of official, to who knows what?
Anybody anywhere can setup their own repositories and clone a bunch of that stuff to their machine, and GitHub will keep them organized. If they are working with Bill's segment register P1, and Cluso's big RAM model, and plain old bug fixed P1 from Parallax, they clone all of those and go to work.
As they work, they find they create something really useful! Others can join the party, and at the end of the day, you've got this distributed, managed, network of people writing code, and passing bits of it between one another as they see fit.
With files and folders, this goes bonkers quickly, and generally does not scale, unless everybody involved is very diciplined, or somebody, or a few people slog through stuff and produce coherent releases. Painful and expensive by comparison.
That's what the pull request and approval system is for. Additionally, it's revision control, meaning there is history.
Here's the big difference: In directory (folder --and I hate the word folder) land, there are these files. If you copy something over one of them, what was there is gone. Thus, people worry about overwriting changes. So what do they do. They make lots of copies of stuff, and or they use numbering schemes and make code edits to build "trees" of code that can all exist together in file folder land.
Andre' recommends the latter in his HYDRA book, and that's what I've done over the years working here. You probably have seen something like 05_graphics.spin, and there might be an 03, 10, whatever out there.
Others use copies, so there are dates! Here's one from last year, last month, and yesterday kind of thing.
In Git, we use tags for that, and Git keeps the older stuff in the repository for you. So you don't overwrite things as much as you combine them to make new things, if that makes any sense. Done that way, one can always revert to an older state, and compare it to a newer state.
This is like opening the files from last year and today and going through line by line to see what changed. GitHub has nice tools for this, and the process is called a "diff"
Stack overflow: As far as I know this is not true. Stackoverflow is full of Smile sometimes. Unless Github is doing something very weird nothing gets "pushed" or "pulled" in or out of your repository without you initiating it, if you want to.
Certainly I can can clone a repo, say it was github/parallax/propeller to my local machine and then totally forget about where it came from. Unless I want to "pull" new parallax changes to my repo or Parallax wants to "pull" my changes back into theirs (In which case my repo had better be accessible on the public internet)
So, no, clone my repo and then your copy is totally under your control. All git repositories are equal peers.
KMyers, That would be "git" the command line program. I like simple to.
If you want the source code what could be easier than copy and pasting the command: from the repositories home page: https://github.com/ZiCog/P8X32A_Emulation?
Or for the terminally GUI bound just hit the "Download ZIP" button prominently displayed there.
If you just want the binary to load to your FPGA then that is included in this case. However such binaries, derived from sources, should not normally be included in a source code repository. Other buttons can be provided to allow that.
Current rules specify all code hosted here, on the forum, is MIT. Now we add GPL code to it, and people have to be careful about what they combine and put here.
If we use GitHub, anybody can fetch a copy of whatever anybody else is doing, avoid big packages on the forum itself, avoid errors in licensing and distribution (mixing things that should not be mixed), and generally get along with lots of projects without lots of hassles.