Re: [myhdl-list] Re: Opencores project

[Tom D. <td...@di...>]

I will add my thoughts to this:

Our designs which are normally math oriented, need a model up front to=20
be sure the implementation will work, just a math model, but it really=20
has to be bit accurate to prove the logic implementation of the =20
algorithm will work in a math sense. It is a good thing if this model=20
can be created very rapidly and makes it easy to explore different=20
alternatives to the implementation.

After that the model needs to be turned into logic and the logic is=20
tested against the model to verify it is implemented properly. I would=20
not expect to be able to synthesize anything like the math model and end=20
up with logic that would be useful. So a logic representation must be=20
created, hopefully using a lot of modules already designed in MyHDL and=20
easily accessible (parametric and tested).

MyHDL has the potential to do this very well, as python is a great place=20
to do the modeling and MyHDL allows for the simulation and conversion to=20
logic along with verification of the converted logic.

Tom





Jan Decaluwe wrote:

> David Brochart wrote:
>
>> From my experience the current toVerilog cannot be used in a real=20
>> project. But
>> it can be easily improved by adding more and more features.
>
>
> It could be either expectations that are too high, or a
> feature set that is too small. I would like to find that
> out, so to avoid any misunderstandings I=B4ll first describe
> my view on the role of toVerilog in a real project.
>
> In a project of certain complexity, it is normal to find 2
> levels of modeling:
>
> 1. a very high level reference model. This is a model to
> experiment with algorithms and architectures, with little
> concern for implementation details. MyHDL should be a
> good choice here. Others may use C, C++, SystemC, Matlab,
> perl ...
>
> 2. an implementation-oriented model. Used to synthesize or
> define the implementation. Typically done in Verilog or VHDL.
>
> I think this matches what you have done in your project.
>
> The role of toVerilog is not to convert a type 1 model into
> a type 2 model. Considering the extreme power of Python
> (which is very useful for type 1 modeling) this seems like
> an impossible task.
>
> Rather, the purpose of toVerilog is that the type 2 model
> can *also* be written in MyHDL, instead of having to use
> another language. Potential benefits: familiar language,
> partial reuse of code and verification environment, potentially
> several backends (Verilog, VHDL) from a single code base.
>
> In short, one would still have to write 2 models, but both could
> be in MyHDL. However, learning about the =B4=B4synthesizable subset=B4=B4
> will still be unavoidable for type 2 modeling.
>
> If we agree on the above, we can consider the feature set.
> I have not done any real projects myself with MyHDL or toVerilog,
> so I cannot judge wether the feature set is sufficient, although
> the intention with the release was that it would be. On the
> other hand, I=B4m pretty sure that I would also encounter difficulties
> in a real project.
>
> The suggested approach to improve things is one feature at a time.
> Start a discussion on the most pressing feature, with a rationale
> and a small example. The more specific, the better.
> The current discussion on Verilog memories is a good example.
>
> Regards, Jan
>