Hi,

If I wish to contribute my code (mainly SPI cores), how can it be done?
Also, what is the process for verifying different aspects (such as, design done, FPGA proven etc.)? are there any strict guidelines I should follow?

Thank you for this site, it has helped me a lot,
Refael.

Welcome to open cores! Please, feel free to step in and contribute!

I think you will find answers to all of your questions in the how/to/faq page linked off to the left. Certainly the site/FAQ subpage answers questions such as how to start a project, the project subpage describes how to build your project's opencores page, and the svn subpage discusses how to add or modify sources and component files associated with your cores. You'll even find an example template spefication for your core as a link off of the FAQ page, as well as a link for the coding guidelines suggested by the open cores team.

Hope this helps, feel free to post if you have further questions,

Dan

Looks like I missed a question:

I have not found any written standards for when a project meets the various stages of being "done" either. To my knowledge, there is no independent verification of whether or not the developer's claims regarding the project status are valid or not. I have been using the following therefore, and I'll leave it up to others to pipe in and comment if they have better ideas:

• Design done: the code is entirely written, and all necessary features are included. This means the project has the logic necessary for its functionality.
• FPGA proven: the code has been demonstrated on an FPGA, and it works. This means the project can be synthesized, that the synthesis results make sense in terms of FPGA resource usage, and that it can be mapped into an FPGA with all of the constraints that requires.
• Specification done: documentation has been written for the core, describing both what it does and how to interface with it and use it.
• Open Cores Certified: This is the only project aspect that I have found written criteria for. You'll find this criteria on the faq/project page. That said, I have yet to receive responses to the requests I've made to have projects certified, so I don't know if this certification is still available or not.

As for the project stage, I'd really love to have someone step in and offer definitions for the various stages. Having none, I offer my best guess:

• Planning: The project exists, has a defined goal and purpose, but does not yet offer a capability. This might also be described as "in development."
• Mature: A version of the project exists, and has most of its capability implemented and simulated with some success. It may not yet be complete, and it may not yet have touched hardware, but there's at least a lot there.
• Alpha: The project has demonstrated some success in both simulation and on actual hardware.
• Beta: The project has met all of its goals in hardware, and the major bugs and deficiencies have been found.
• Stable: The project has been in use for some time without any significant maintenance issues.

If anyone else reading this has other ideas, please pipe in.

I hope this helps, and I look forward to seeing your contributions,

Dan

Hi Dan,

Thank you for your in-depth reply.

I designed my SPI core as a project at my workplace, but not sure if it will ever get implemented, so I've decided to share it here (that way I hope, someone will be able to benefit from it).

Regarding your suggestion on how to divide different development stages - many thanks, it was exactly what I was looking for.

On a side note, I read through OpenCores's guide, and saw that synchronous design is highly recommended - is it a MUST demand? My design style is not strictly synchronized with the clock signal, as I rely heavily on data signals as a mean to reduce power consumption.

Refael.

Hi Refael,

if your design isn't strictly synchronous, I have a question: how do you avoid metastability?
Or do you ignore this problem? What are then the expected failure rates?

Hellwig

Hi Hellwig,

Thank you for your reply.
During my development of this core, I used data signal as a stimuli for initiating communication between FPGA and the applicable unit.
Everything else is either synchronized with the global clock, or the SPI clock.
Basically, I implemented the concept of asynchronous design - a timed operation with request and acknowledge.

Do you have a more in-depth understanding of how asynchronous design works?
If so, I'll be more than happy if you can share your insights with me.

Refael.

Refael,

constructing a truly asynchronous circuit is extremely difficult. Every good book on digital design has at least a chapter describing the process, but warns the reader, that this subject should normally be avoided. How then should external signals be handled? Quite easy: you synchronize them with one (or better two) flip-flops *before* you do anything else with the signal. This does of course not eliminate the problem of metastability, but reduces its probability so much that it can be ignored.

Perhaps I did not understand your initial statement well. You said: "My design style is not strictly synchronized with the clock signal...". At the board-level there are certainly signals which are not synchronous with respect to the FPGA's clock. But your design within the FPGA should indeed be strictly synchronous, or at least, you should meticulously pay attention to all signals crossing clock regions.

Hellwig

In hindsight, I think I'd like to modify my definition of a project that is an alpha release to the following:

• Alpha - The core builds and runs with some features, but neither the feature set nor the interface are stable. In the case of soft core CPU's, the instruction set may yet undergo revision. In the case of other core types, the input/output port list is still subject to change.

Thoughts?

Dan