Hi,
Can you please clarify if the TAPR Open Hardware License is an accepted license for Fedora? If not, should we check with Fedora Legal? If yes, how do we package the content to FEL?
Thanks!
SK
On Fri, Dec 11, 2009 at 7:58 AM, Shakthi Kannan shakthimaan@gmail.com wrote:
Hi,
Can you please clarify if the TAPR Open Hardware License is an accepted license for Fedora? If not, should we check with Fedora Legal? If yes, how do we package the content to FEL?
I think it could be accepted. However, it would be better that Fedora Legal add it into the licensing matrix: http://fedoraproject.org/wiki/Licensing
Please ask the Fedora Legal about this.
Chitlesh
Hi,
--- On Fri, Dec 11, 2009 at 12:55 PM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | I think it could be accepted. However, it would be better that Fedora | Legal add it into the licensing matrix: | http://fedoraproject.org/wiki/Licensing | | Please ask the Fedora Legal about this. --
I have asked Fedora Legal for feedback. In this regard, if we were to package VHDL and Verilog cores under an open hardware license, I would like to know as to how we should package them into FEL?
For example, if we package opencores.org cores, do we have a naming convention like opencores.org-<project-name>, and put them under /usr/share/opencores.org/<project-name>, or just /usr/share/<project-name>?
Or, do we need to come up packaging guidelines for hardware designs that people can use with FEL tools?
Appreciate your inputs in this regard,
SK
On Sat, Dec 12, 2009 at 7:14 AM, Shakthi Kannan < > wrote:
I have asked Fedora Legal for feedback. In this regard, if we were to package VHDL and Verilog cores under an open hardware license, I would like to know as to how we should package them into FEL?
For example, if we package opencores.org cores, do we have a naming convention like opencores.org-<project-name>, and put them under /usr/share/opencores.org/<project-name>, or just /usr/share/<project-name>?
Or, do we need to come up packaging guidelines for hardware designs that people can use with FEL tools?
Appreciate your inputs in this regard,
Yes indeed this deserves some thinking.
Unlike other software and even fonts, these cores have no significant meaning to the users (from a software engineer point of view). They will fall in the same situation as OVM packaging, that is they will be refused during packaging reviews if they can't at least be used _out of the box_ with software distributed by fedora.
FYI: OVM was refused because there was no opensource tool to use it.
* From a fedora software packaging point of view
We have to ensure that these cores can either be compiled with iverilog or ghdl. A script or Makefile should be shipped with the rpm. All proprietary scripts should be in docdir of a subpackage -extra. The advantage of packaging these cores is that once we got one core fully packaged, others will have the same template and it will be very smooth.
* From an opensource hardware point of view
I agree with your proposed naming convention:opencores.org-<project-name>
I would opt of /usr/share/opencores.org/<project-name> as it pays respect to the work opencores.org has done in creating set of guidelines for HDL development, directory structure and community building.
We should only compile those cores which are tagged as done/complete. Those cores without documentation are pretty useless for the user. So I would say we should prioritize those having documentation.
Prepare a spec file and a SRPM for one of the cores hence we can identify the elements we should pay attention.
Last year, I tried to compile a draft template for opencores IP distribution based on the designer's needs. But never got time to complete it http://chitlesh.fedorapeople.org/temp/ I should spend some time to learn how companies are selling their IPs as a distribution point of view and improve that template.
Chitlesh
Hi,
--- On Sat, Dec 12, 2009 at 7:48 PM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | * From a fedora software packaging point of view | | We have to ensure that these cores can either be compiled with | iverilog or ghdl. A script or Makefile should be shipped with the rpm. --
Yes, we will ship only those that work with FEL tools.
--- | All proprietary scripts should be in docdir of a subpackage -extra. --
We shouldn't ship proprietary scripts that don't have the sources or are not under a free/open software/hardware license.
--- | The advantage of packaging these cores is that once we got one core | fully packaged, others will have the same template and it will be very | smooth. --
Agreed.
--- | We should only compile those cores which are tagged as done/complete. | Those cores without documentation are pretty useless for the user. So | I would say we should prioritize those having documentation. --
Ok. Could you point me to where I can find documentation on the workflows provided in FEL?
Thanks,
SK
On Sat, Dec 12, 2009 at 5:57 PM, Shakthi Kannan <> wrote:
Ok. Could you point me to where I can find documentation on the workflows provided in FEL?
We don't have an official flow but I'm blogged parts of it.
* iverilog, emacs, dinotrace (on my blog) * spice released - on fel hosted page * xcircuit, ngspice (on my blog) * alliance - in the its -doc package * a basic mixed signal flow with gdsII on ngspice, magic, xcircuit, pharosc,... on the presentation for fosdem 2009 * LVS: magic, xcircuit, netgen ( on my blog and a NOR2 example on git)
These should be added in the latex document we discussed earlier. It would be much easier to access, don't you think ?
Chitlesh
Hi,
--- On Sun, Dec 13, 2009 at 4:05 AM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | These should be added in the latex document we discussed earlier. It | would be much easier to access, don't you think ? --
We can create a git project repo for the above documentation workflows in https://fedorahosted.org? I shall then make a project request to them.
The documentation and code will be in CC-license?
Let me know,
SK
On Sun, Dec 13, 2009 at 6:10 PM, Shakthi Kannan <> wrote:
We can create a git project repo for the above documentation workflows in https://fedorahosted.org? I shall then make a project request to them.
The documentation and code will be in CC-license?
Yes the documentation should be the CC license fedora just adopted.
Since you are a git expert, can you set up the repo in such a way that FEL12 branch reflects FEL12 items such as release notes and flyer etc.. same for a FEL13 branch. Currently that git repo is just a dumping area. With your super git skills, can you propose the best way we can use that repo effectively based on its current contents?
Now since we are focussing on FEL-13, the documentation will be placed on the branch master, then we'll branch it to FEL13 during the Freeze period.
Chitlesh
Hi,
--- On Sun, Dec 13, 2009 at 11:27 PM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | Since you are a git expert, --
This hasn't happenend yet, actually.
What is the name of this documentation project that you would prefer, 'fel-workflows', or any other suggestions?
SK
Hi,
--- On Mon, Dec 14, 2009 at 5:11 PM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | fel-userguide-<release> ? --
Ok. Project name will "fel-userguide". I shall create a ticket to Fedora Infrastructure.
Thanks,
SK
On Mon, Dec 14, 2009 at 12:57 PM, Shakthi Kannan shakthimaan@gmail.com wrote:
Hi,
--- On Mon, Dec 14, 2009 at 5:11 PM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | fel-userguide-<release> ? --
Ok. Project name will "fel-userguide". I shall create a ticket to Fedora Infrastructure.
ok wait, do you need another git repo ? why can't we use the current repo ?
I fear that the more we poke the infrastructure the more the budget will increase.
Chitlesh
Hi,
--- On Mon, Dec 14, 2009 at 5:34 PM, Chitlesh GOORAH chitlesh@fedoraproject.org wrote: | ok wait, do you need another git repo ? why can't we use the current repo ? --
Sorry, but, where is it?
SK
On Mon, Dec 14, 2009 at 1:36 PM, Shakthi Kannan < > wrote:
Sorry, but, where is it?
https://fedorahosted.org/fedora-electronic-lab/wiki/developers#UsingFELgitre...
Chitlesh
electronic-lab@lists.fedoraproject.org