On Sun, May 20, 2012 at 9:26 AM, R. Diez <[email protected]>wrote:
> Hi all OpenRISC gurus:
>
> I've been thinking about forking the or1200 core. I find the current
> Verilog code difficult to understand, and every time I've looked inside in
> order to try and fix some minor glitch, I ended up frustrated.
>
>
Yes there is a lot to do for the or1200 but is also has a rather large
community and we have to figure out how fix and improve it while all the
others are still trying to use it for their own projects. I would not
recommend branching but rather create a new database where we can
completely reexamine how we can create, use and reuse IP cores in a more
effective manner. This would isolate our work and ensure that nothing we do
could impact existing users. We would start with the latest copy of the
or1200 code and a test suite that gives us fairly good coverage for all the
code.
When you have many designers and a lot of work to do then the best way to
manage it is in very small "baby steps". You break your work up into a lot
of very small steps that are easy to implement and test. You update your
local copy, make your changes, run the test suite then check in your
changes. The key is the have a robust and every growing test suite that
serves as a safety net. Each designer would need to present their proposed
changes and explain why it will help. Unless there is a problem then they
should be given the ok to implement, test and check in their code. By
starting off with only the or1200 cpu then we only need to pass a test
suite for that component.
It also means that when we will need stop all work on the current code and
make all bug fixes and improvements in the new database. Once the new
database has proven it self then most users will start using it.
I have been trying out this process in my socgen project but I haven't been
keeping it updated with the latest patches so it is starting to diverge
from the official code.
Some things that we do have to change are:
1) Decouple the component from the design environment(DE).
Everybody creates a DE on their computer where they can build, simulate
and synthesis their or1200 SOC. The problem is that the custom has been to
then check this entire DE into the repository. While this works fine for
simple designs you eventually get components that use other components that
also have their own DE's. This gets to be a real mess. You want to be able
to run each components own test suite on that component using your DE. You
must first create your DE and then you check out any and all repositories
that you want to use. You run all their test suites under your DE. You do
not include a DE in every component.
2) Create a library level storage container.
The opencores.org repository is a flat filespace containing thousands of
different components. The sizes of todays designs is making this hard to
manage. The industry is moving to the model of the VLNV (vendor, Library,
Component name and Version). We should consider creating an additional
storage area that would accommodate libraries as well as components if we
expect to stay relevant.
=============================================================
At the very minimum, there should be asserts like this at many places:
if ( some_assert_condition )
begin
$display( "My assert failed." );
$finish;
end;
The goal is that, if something is not quite right, the core shouldn't just
blindly run further in the simulation, it should stop as soon as possible
in order to help debug the core, like I'm used to with C/C++ software.
However, I would also consider some other assert syntax, as long as it's
easy to understand and available on most platforms.
===============================================================
Actually you really don't want to do that.
Anytime you display anything in a sim you always must have four fields.
Timestamp showing $realtime
Source usually %m for the generating instance
Severity ERROR, WARNING or INFO. "My assert failed."
Message "My assert failed."
That will save you a lot of time when debugging large designs.
You also do not want a bunch of $finish statements in your sims. In my
socgen project I use a module from
socgen/projects/opencores/Testbench/ip/clock_gen as the clock and reset
generator for every sim. When I detect an assert failure I call a task in
this module that prints out the fail message and increments a fail counter.
Each sim ends with a call to a end task that checks the fail counter and
prints out if the sim passed or failed. There is also a timeout counter
that will fail the sim if it times out before the end task is called. This
is the only module that is allowed to finish the sim. You should try using
that module in your sims.
John Eaton
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
