myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Re: toVerilog and memories

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

>The first thing ISE tripped over was that the memL array is inside the
>always statement. Moving it out from there made it go on, but then there
>is a blocking and nonblocking assignment inside the always statement and
>that one it did not like either.
>
>Is it possible to change that with the toVerilog conversion?
>
>  
>
Guenter makes a good point here. We will actually need the array to be 
defined outside the always block and accessible from multiple always blocks.

For a true dual port (dual clock) we need something like the following:

    reg [7:0] mem [31:0];

    always @(posedge write_clock)
        if (wea)
            mem[addr_write] <= data_in;

    always @(posedge read_clock)
        data_out <= mem[addr_read];

Tom

Re: [myhdl-list] Re: toVerilog and memories

[<dan...@we...>]

Jan,

I tried a simple example with the memory and to implement it with ISE
6.3, but ran into some problems. I am not sure whether I did something
wrong how I wrote the MyHDL code or need to do some special ISE
settings? I basically pulled in the generated Verilog file into a ISE
project with the standard settings and ran it through implementation.

Here is the MyHDL code that I used:


def ram(clk, dout, din, addr, we, d_width=8, depth=4) :

  memL = [intbv(0)[d_width:] for i in range(depth)]

  while 1:
    yield posedge(clk)

    if we:
      memL[int(addr.val)][:] = din.val

    dout.next = memL[int(addr.val)]




and that is the generated Verilog code:


module inst_ram (
    clk,
    dout,
    din,
    addr,
    we
);

input [0:0] clk;
output [7:0] dout;
reg [7:0] dout;
input [7:0] din;
input [1:0] addr;
input we;



always @(posedge clk) begin: _MYHDL1_BLOCK
    reg [8-1:0] memL [0:4-1];
    if (we) begin
        memL[addr] = din;
    end
    dout <= memL[addr];
end

endmodule


The first thing ISE tripped over was that the memL array is inside the
always statement. Moving it out from there made it go on, but then there
is a blocking and nonblocking assignment inside the always statement and
that one it did not like either.

Is it possible to change that with the toVerilog conversion?

I also recognized that the 'clk' signal is specified as input [0:0]
whereas the 'we' signal is specified only as input.


Regards

Guenter




Jan Decaluwe wrote:
> Jan Decaluwe wrote:
> 
>> Here is my proposed plan:
>>
>> I will work on an implementation of list comprehensions mapped to
>> Verilog memories, along the lines described om my previous mail. I´ll
>> post an alpha release to the newsgroup for you and others to test it
>> before committing it to the next release.
> 
> 
> Attached you find a patch to MyHDL to support Verilog memories.
> 
> A list comprehension with intbv elements in a generator is
> converted to a Verilog memory.
> 
> To install the patch, replace the myhdl/_toVerilog directory
> in a 0.4.1 installation by the attached directory.
> 
> There are several constraints, but I'm not providing an example
> in order to ensure that the error handling is tested also :-)
> 
> Regards,
> 
> Jan
> 

Re: [myhdl-list] Re: toVerilog and memories

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

Jan,

That works great, I use it with the following code:

  memL =3D [intbv(0,min=3Ddout._min,max=3Ddout._max) for i in range(depth=
)]
  =20
  while 1:
        yield posedge(clk)
        if we:
          memL[int(addr)][:] =3D din
          # print "ram: wrote %d to %d"%(din,addr)
        dout.next =3D memL[int(addr)]

This synthesized into Virtex blockRAM using Mentor Precision just fine.

Now, I should have thought of this earlier, but I am working=20
sequentially here.

ROMs are also needed and easy to infer in synthesis. It would be very=20
good if the following would produce a case statement in Verilog:

def rom(dout,addr,clk=3DNone,dataL=3DNone) :
  """
    rom : rom module

    Inputs:
      addr        : input address
      clk         : clock for synchronous roms, =3D=3D None for async
    Outputs:
      dout        : output port, width determines width of rom
    Params:
      dataL       : list of values for rom, length is depth of rom
  """

  memL =3D [intbv(data,min=3Ddout._min,max=3Ddout._max) for data in dataL=
]
  =20
  while 1:
        yield posedge(clk)
        dout.next =3D memL[int(addr)]


You would need to be able to figure out that the values in memL never=20
get modified after it is defined.

The important thing here, is the memL define and the dout.next=20
assignment need to get mapped to a case statement:

always @(posedge clk)
  case(addr) :
    0 : dout <=3D dataL[0] ;
    1 : dout <=3D dataL[1] ;
    .
    .
    .

This also works in XST.

Now you may also want some control around this, or possibly asynchronous=20
so only the list needs to become the case statement, that case statement=20
may end up inside come control statements. Possibly a clock enable.

This is very helpful. There are also dual port ROMs, so you would need=20
two case statements on the same list, with a separate address into the li=
st.

You  can also initialize the values of a RAM. This is more obscure and=20
I've never actually used it. But it too can be inferred from HDL. I will=20
forward the coding style when I find it. I could not find it today.

Anyhow, thanks for the help thus far on the memories and let me know=20
what you think of the rom idea.

Tom





=20

Jan Decaluwe wrote:

> Jan Decaluwe wrote:
>
>> Here is my proposed plan:
>>
>> I will work on an implementation of list comprehensions mapped to
>> Verilog memories, along the lines described om my previous mail. I=B4l=
l
>> post an alpha release to the newsgroup for you and others to test it
>> before committing it to the next release.
>
>
> Attached you find a patch to MyHDL to support Verilog memories.
>
> A list comprehension with intbv elements in a generator is
> converted to a Verilog memory.
>
> To install the patch, replace the myhdl/_toVerilog directory
> in a 0.4.1 installation by the attached directory.
>
> There are several constraints, but I'm not providing an example
> in order to ensure that the error handling is tested also :-)
>
> Regards,
>
> Jan
>

[myhdl-list] Re: toVerilog and memories

[Jan D. <ja...@ja...>]

Jan Decaluwe wrote:

> Here is my proposed plan:
> 
> I will work on an implementation of list comprehensions mapped to
> Verilog memories, along the lines described om my previous mail. I´ll
> post an alpha release to the newsgroup for you and others to test it
> before committing it to the next release.

Attached you find a patch to MyHDL to support Verilog memories.

A list comprehension with intbv elements in a generator is
converted to a Verilog memory.

To install the patch, replace the myhdl/_toVerilog directory
in a 0.4.1 installation by the attached directory.

There are several constraints, but I'm not providing an example
in order to ensure that the error handling is tested also :-)

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: Opencores project

[<dan...@we...>]

Jan,

Jan Decaluwe wrote:

...

> 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.

...

> In short, one would still have to write 2 models, but both could
> be in MyHDL. However, learning about the ´´synthesizable subset´´
> will still be unavoidable for type 2 modeling.
> 

That approach has the disadvantage that 2 separate models have to be
done. I think MyHDL has the potential to combine that and that would be
a great benefit as it could speed up the development process.

Just as one example, there are numerous math functions available for
python that makes it in some cases a perfect substitute for Matlab.


> If we agree on the above, we can consider the feature set.

I agree on that, but would like to discuss a 3. feature and that is some
kind of framework that allows to merge the 2 features.

...

> 
> 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
> 

I agree, that first two features need to be set in order to add the
third idea. I would like to describe it here, in order to see whether it
is really feasible.

My idea is to have some type of framework class, that is the basic
building block to model with MyHDL. Instead of using functions that
resemble modules in Verilog my suggestion would be to use classes.

To model, one would derive a class from the framework class, which
provides predefined member functions that need to be filled with logic.

One member function is for the *behavioral* modeling and is used to do
the higher layer modeling. Level 1 as you called it.

So it is possible to model just with that, create instances of the class
and run it with the MyHDL simulator as before.


The merge would come from a second member function that allows to do the
*rtl* or level 2 modeling. In that member function it is possible to
model the logic in a way that it can be converted with toVerilog and
create synthesizable logic.

The advantage from that approach would be that behavioral and rtl
modeling are close together, grouped together in an object oriented
manner. That would allow to do verification on the individual class
instances.

One idea would be for example that there is a third member function that
allows to run the simulation of the behavioral model, take data from
that and compare it with co-simulation results of the toVerilog code.

Now I am not that experienced with MyHDL and logic development in
general to know what an effort that proposed framework would be. Also I
am not sure whether classes would become too complex, as it would hold
behavioral, rtl modeling and verification code.

It would be interesting to hear some of your thoughts about this idea.


Regards,

Guenter

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
>

[myhdl-list] Re: Opencores project

[Jan D. <ja...@ja...>]

David Brochart wrote:

> From my experience the current toVerilog cannot be used in a real 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´ll 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 ´´synthesizable subset´´
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´m 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

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: Opencores project

[Jan D. <ja...@ja...>]

David Brochart wrote:
> Günter,
> 
> Yes, I started from the toVerilog for the toVHDL convertor. It is quite easy to
> identify where to replace the Verilog generated code with the VHDL generated
> code. But the thing is that MyHDL looks like Verilog in its structure, and VHDL
> is quite different, so that is where the difficulty is.

If it looks more like Verilog, that´s certainly not the intention :-)

For crucial features, the main inspiration has been VHDL, for example
the delta-cycle algorithm, the strict separation between signals and
variables, strong typing (thanks to Python of course), ...

However, I certainly believe that writing toVHDL by starting from
toVerilog is difficult. Here are two considerations:

- Verilog is a lower level language, with loose typing. This may
make it easier in the direction from MyHDL to Verilog. Easier,
because they are more different, in this case :-)

- the main reason is probably that toVerilog has code that may
*seem* generic, but isn´t. In the ideal case, there would be a
generic analyzer, with just a dedicated backend in the conversion
stage. However, that´s not the case. The whole thing was certainly
written with Verilog in mind. If I would write toVHDL, I would start
from scratch (benefiting from the toVerilog experience, of course.)

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Black box discussion

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

OK, here is my start to a black box implementation discussion.


>
> I=B4ll think about the black box feature. It would really be useful
> though to start a discussion here about the details of such a feature
> (in a new thread). Getting a well thought-out, detailed spec is a large
> part of the solution! To get started, some issues to consider:
> - what should the user interface be exactly (as simple as possible)
> - how to handle parameters
>
>

For the interface I would propose something like this:

portD =3D {'xPort':xSig,'aPort':aSig,'bPort':bSig}
parmD =3D {'parm1':num1,'parm2':num2}
blackBox('modName','instName',portD,partD)

modName is the module name you are connecting to, instName the instance=20
name, both just strings. Then just the port dictionary, connects MyHDL=20
signals (xSig,aSig,bSig)  to the port names. Same with the parameter=20
dictionary. num1 and num2 are both python numbers, but could be=20
anything, just needs to be turned into a string.

blackBox() is a MyHDL function. The MyHDL source that contains this=20
would need to knwo toVerilog was running and substitute the blackBox()=20
for the behavior model used during MyHDL simulation.

What we need on the Verilog side is:

modName #(
  .parm1(num1),
  .parm2(num2)
) instName (
  .xPort(xSig),
  .aPort(aSig),
  .bPort(bSig)
)

I think that would do it, but I probably have not thought this all the=20
way through.

Tom

Re: [myhdl-list] Re: toVerilog and memories

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

Jan,

> Are verilog memories actually synthesized by your synthesis tool (and
> which is it)? I don=B4t know of an ASIC tool that has this, though I
> see how this could work for FPGAs. That would be very useful of
> course, and a strong argument to support it.


Yes, we use Mentor Precision and it works very well. It will infer all=20
kinds of memory structures and map to the appropriate FPGA memory. It=20
keeps the source more or less generic and makes the synthesis tool do=20
the work.

>
> Here is my proposed plan:
>
> I will work on an implementation of list comprehensions mapped to
> Verilog memories, along the lines described om my previous mail. I=B4ll
> post an alpha release to the newsgroup for you and others to test it
> before committing it to the next release.
>
> Give me a few days (can=B4t start before Tuesday) - if it takes longer
> I=B4ll post about the progress.


Sounds great. Let me know if you need any help.

Tom

[myhdl-list] Re: Opencores project

[David B. <dav...@fr...>]

G=FCnter,

Yes, I started from the toVerilog for the toVHDL convertor. It is quite e=
asy to
identify where to replace the Verilog generated code with the VHDL genera=
ted
code. But the thing is that MyHDL looks like Verilog in its structure, an=
d VHDL
is quite different, so that is where the difficulty is.

Regards,

David.



Selon G=FCnter Dannoritzer <dan...@we...>:

> David,
>
> David Brochart wrote:
>
> ...
>
> > (multi-dimensional arrays, list of instanciations...). I started writ=
ing a
> > toVHDL equivalent to toVerilog because I know what I want to be trans=
lated
> and
> > I'm more familiar in VHDL than in Verilog, but I'm not finished with =
it
> ...
>
> That is great, so there is a toVHDL in progress.
>
> > Also, my toVHDL translator was
> > not so clean and as Jan said, it is important to start with a clean s=
pec of
> the
> > things that should be translated and the things that should not. So I=
 will
> need
> > to spend more time on the toVHDL translator.
>
> Did you start out with the toVerilog? I was reading a bit how the
> toVerilog works and I was wondering whether a quick trick would be to
> take the part that generates the Verilog code and just replace it by
> VHDL. But I guess I am not that experienced with VHDL and Verilog to se=
e
> whether that really would go that easy.
>
>
> >>From my experience the current toVerilog cannot be used in a real pro=
ject.
> But
> > it can be easily improved by adding more and more features.
> >
> > Regards,
> >
> > David.
> >
>
> Thanks for sharing that.
>
> Guenter
>
>
>
> ...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happ=
ening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dua=
l
> core and dual graphics technology at this free one hour event hosted by=
 HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: toVerilog and memories

[Jan D. <ja...@ja...>]

Tom Dillon wrote:

> To use MyHDL effectively for making logic, I would like to be able to 
> synthesize the Verilog generated, that is my real end goal. So I would 
> really add the requirement that the subset of Verilog used was 
> synthesizable by a decent FPGA synthesis tool.

I agree completely, it should even be a superset. (In some areas,
it already is in fact.)

Are verilog memories actually synthesized by your synthesis tool (and
which is it)? I don´t know of an ASIC tool that has this, though I
see how this could work for FPGAs. That would be very useful of
course, and a strong argument to support it.

> Alternatively, and really needed as well, is a way to include a black 
> box into the simulation(Verilog)/synthesis flow. So you would use a 
> MyHDL function for behavioral MyHDL simulation, then substitute in a 
> block box when either doing co-simulation or synthesis. Possible an 
> attribute on the function or something to trigger this.

I agree that this is needed also. I had been thinking about it, but
I haven´t tackled the details.

> I am still really just experimenting with MyHDL but am trying to take 
> some our real logic there to give it a test drive. It is working well, 
> but there isn't much we build that doesn't have memories inside the FPGA.
> 
> Any ideas on how hard it is to implement a black box type connection? 
> That would keep me on my experimentation path and give me a way to solve 
> anything later too. You just need module name, signal connections, and 
> parameters.
> 
> Anyhow, I'm willing to help make changes or test or do whatever I can. 
> Let me know.

Here is my proposed plan:

I will work on an implementation of list comprehensions mapped to
Verilog memories, along the lines described om my previous mail. I´ll
post an alpha release to the newsgroup for you and others to test it
before committing it to the next release.

Give me a few days (can´t start before Tuesday) - if it takes longer
I´ll post about the progress.

I´ll think about the black box feature. It would really be useful
though to start a discussion here about the details of such a feature
(in a new thread). Getting a well thought-out, detailed spec is a large
part of the solution! To get started, some issues to consider:
- what should the user interface be exactly (as simple as possible)
- how to handle parameters

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: Opencores project

[<dan...@we...>]

David,

David Brochart wrote:

...

> (multi-dimensional arrays, list of instanciations...). I started writing a
> toVHDL equivalent to toVerilog because I know what I want to be translated and
> I'm more familiar in VHDL than in Verilog, but I'm not finished with it 
...

That is great, so there is a toVHDL in progress.

> Also, my toVHDL translator was
> not so clean and as Jan said, it is important to start with a clean spec of the
> things that should be translated and the things that should not. So I will need
> to spend more time on the toVHDL translator.

Did you start out with the toVerilog? I was reading a bit how the
toVerilog works and I was wondering whether a quick trick would be to
take the part that generates the Verilog code and just replace it by
VHDL. But I guess I am not that experienced with VHDL and Verilog to see
whether that really would go that easy.


>>From my experience the current toVerilog cannot be used in a real project. But
> it can be easily improved by adding more and more features.
> 
> Regards,
> 
> David.
> 

Thanks for sharing that.

Guenter



...

Re: [myhdl-list] Re: toVerilog and memories

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

Jan,

Thanks for the response.

> As to your model, I see the value, and how it could be done. Basically,
> we would need to support a list comprehension internally in a generator=
,
> and map it to a local Verilog memory. I=B4ll discuss the details to
> try to come up with an implementation spec.

To use MyHDL effectively for making logic, I would like to be able to=20
synthesize the Verilog generated, that is my real end goal. So I would=20
really add the requirement that the subset of Verilog used was=20
synthesizable by a decent FPGA synthesis tool.

Alternatively, and really needed as well, is a way to include a black=20
box into the simulation(Verilog)/synthesis flow. So you would use a=20
MyHDL function for behavioral MyHDL simulation, then substitute in a=20
block box when either doing co-simulation or synthesis. Possible an=20
attribute on the function or something to trigger this.

If the black box was an easier solution for the memory, it seems like=20
that may be OK for now. I have not looked into that yet.

Generic synthesizable memories are very easy in Verilog and that=20
actually would not be a bad solution.

Also, I would use Verilog 2001 if it helps in any way. Our synthesis and=20
simulation tools all support it.

>
> First, why a list of Signals? In MyHDL philosophy (as in VHDL) you
> would use plain variables internally. In your model, you actually
> use it like that, otherwise the assignment would read
>
>    memL[int(addr)].next =3D din

I'm still a little new to MyHDL and was thinking anything going=20
toVerilog needed to be a signal or int. My mistake.

>
> In Verilog 1995, you can only have a memory out of regs, so the natural
> base type for the supported list comprehension would be an intbv
> (and not an int for example). Therefore, only the following kind of lis=
t
> comprehension would be supported:
>
>    memL =3D [intbv(0)[8:] for i in range(depth)]


I would be happy with only being able to build a memory with that style.

>
> Secondly, toVerilog has to able to infer and use type and
> bit width information, or at least be sure that the simulation will tak=
e
> care of it. Because of this, an intbv has always to be
> assigned by modifying its contents, not by overriding it:
>
>    a =3D intbv(0)[8:]
>    a =3D 500 // not supported by toVerilog
>    a[:] =3D 500 // supported (note that simulation will flag an error)
>
> Similarly, the memory assignment would have to look as follows:
>
>    memL[int(addr)][:] =3D din // OK for toVerilog
>
> while the following would not work:
>
>    memL[int(addr)] =3D din // not OK for toVerilog


Would it be possible to flag that as a warning?

I am still really just experimenting with MyHDL but am trying to take=20
some our real logic there to give it a test drive. It is working well,=20
but there isn't much we build that doesn't have memories inside the FPGA.

Any ideas on how hard it is to implement a black box type connection?=20
That would keep me on my experimentation path and give me a way to solve=20
anything later too. You just need module name, signal connections, and=20
parameters.

While it would be nice to be able to toVerilog lists, I think there will=20
be other structures that need to be coded properly on the Verilog side=20
to end up being inferred properly by synthesis.

Anyhow, I'm willing to help make changes or test or do whatever I can.=20
Let me know.

Tom

[myhdl-list] Re: toVerilog and memories

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> I am trying to model generate Verilog for some simple memories. For 
> example:
> 
> def ram(dout,din,addr,we,clk=None,depth=4) :
>  memL = [Signal(intbv(0,min=0,max=2**8)) for i in range(depth)]
>    while 1:
>    yield posedge(clk)
>    if we:
>      memL[addr] = din.val
>    dout.next = memL[addr]
> 
> I want addr to be a Signal as well. I get an error that it needs to be 
> an int.

Use int(addr) to convert it to an int. (Signals support this function.)

> If I use the value of addr, then it simulates fine but I get a list 
> comprehension error when running it through toVerilog.
> 
> Is there a way to do this and get it through toVerilog?

Not with the current version.

What would be needed is support to map a list comprehension to a verilog
memory. I haven´t tackled this yet, partly because verilog memories have
all kinds of limitations that obfuscate what can and what should be
supported. Newer Verilogs (2001 and SystemVerilog) seem to do away
with limitations, but (as always with Verilog) things aren´t very
clear. We will need expertise to move forward carefully.

As to your model, I see the value, and how it could be done. Basically,
we would need to support a list comprehension internally in a generator,
and map it to a local Verilog memory. I´ll discuss the details to
try to come up with an implementation spec.

First, why a list of Signals? In MyHDL philosophy (as in VHDL) you
would use plain variables internally. In your model, you actually
use it like that, otherwise the assignment would read

    memL[int(addr)].next = din

In Verilog 1995, you can only have a memory out of regs, so the natural
base type for the supported list comprehension would be an intbv
(and not an int for example). Therefore, only the following kind of list
comprehension would be supported:

    memL = [intbv(0)[8:] for i in range(depth)]

Secondly, toVerilog has to able to infer and use type and
bit width information, or at least be sure that the simulation will take
care of it. Because of this, an intbv has always to be
assigned by modifying its contents, not by overriding it:

    a = intbv(0)[8:]
    a = 500 // not supported by toVerilog
    a[:] = 500 // supported (note that simulation will flag an error)

Similarly, the memory assignment would have to look as follows:

    memL[int(addr)][:] = din // OK for toVerilog

while the following would not work:

    memL[int(addr)] = din // not OK for toVerilog

Currently, toVerilog always uses an explicit bit width in the Verilog
output. For example:

    a = intbv(0)[8:]
    a[4:] = c
    a[:] = d

is mapped to:

    reg [7:0] a;
    a[3:0] = c;
    a[7:0] = d;

However, Verilog 1995 doesn´t permit bit or slice access to memory
elements. The workaround would be to introduce a special case for
the special [:] slice. For example:

    a[:] = c
    memL[int(addr)][:] = din

would then be mapped to:

    a = c;
    memL[addr] = din;

Now, what to do with true slices and indexing in the MyHDL code?
Even though Verilog 1995 doesn´t support it on memories, newer
Verilogs (2001 and SystemVerilog) do (I think). So, I would just
do the conversion in the obvious way and leave it to the user
to change his MyHDL code if his Verilog doesn´t support it.
I don´t want to introduce Verilog conversion modes - it´s a
street without and end (and probably circular in fact :-)).

Ok - so much for my initial feedback. Other feedback, thoughts,
experiments, welcome.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: Opencores project

[David B. <dav...@fr...>]

Guenter,

If there is some toVerilog usage in the MyHDL description, just forget it=
. It
was a trial and I will clean that in the next release. I realized that I =
was
using much too complex structures in order for toVerilog to translate the=
m
(multi-dimensional arrays, list of instanciations...). I started writing =
a
toVHDL equivalent to toVerilog because I know what I want to be translate=
d and
I'm more familiar in VHDL than in Verilog, but I'm not finished with it a=
nd I
thought that a synthezisable description of the project would be more use=
full,
so that's why I translated it by hand in VHDL. Also, my toVHDL translator=
 was
not so clean and as Jan said, it is important to start with a clean spec =
of the
things that should be translated and the things that should not. So I wil=
l need
to spend more time on the toVHDL translator.
From my experience the current toVerilog cannot be used in a real project=
. But
it can be easily improved by adding more and more features.

Regards,

David.



Selon Guenter Dannoritzer <dan...@we...>:

> David Brochart wrote:
>
> > All,
> >
> > I have posted a project on Opencores. It is a MyHDL model of a turbo
> decoder,
> > still at an early stage of development. You might want to check it ou=
t at:
> > http://www.opencores.org/projects/turbocodes/
> >
> > Regards,
> >
> > David.
> >
>
> David,
>
> I looked into you project to study MyHDL and recognized that there is
> some toVerilog usage, but in the description it does not say anything
> that the MyHDL implementation is able to generate Verilog code. Also yo=
u
> added the VHDL synthesizeable code.
>
> Did you need the code in VHDL or was there some other reason not to use
> the toVerilog?
>
> From you experience how well can the toVerilog be used to generate
> Verilog code?
>
> I saw in a different thread that it is not possible to generate lists o=
f
> Signals. Is there a different way to model Verilog generateable memory?
>
> Thanks for you thoughts.
>
> Guenter
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: toVerilog and memories

[Jan D. <ja...@ja...>]

David Brochart wrote:
> Tom,
> 
> In order to fix the error message on addr, replace memL[addr] with
> memL[int(addr.val)].
> Unfortunately the current version of the Verilog translator doesn't support
> signal list (array) translation.
> Jan, do you plan to support it in the next release(s)?

I understand the need and I think it´s possible to support
a limited form of list comprehensions. There are a number
of (Verilog-related) issues though that have to be resolved,
so we need to think carefully first and come up with a
good spec. I will give the start by replying in detail
to Tom´s original mail - stay tuned.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: Opencores project

[Guenter D. <dan...@we...>]

David Brochart wrote:

> All,
> 
> I have posted a project on Opencores. It is a MyHDL model of a turbo decoder,
> still at an early stage of development. You might want to check it out at:
> http://www.opencores.org/projects/turbocodes/
> 
> Regards,
> 
> David.
> 

David,

I looked into you project to study MyHDL and recognized that there is
some toVerilog usage, but in the description it does not say anything
that the MyHDL implementation is able to generate Verilog code. Also you
added the VHDL synthesizeable code.

Did you need the code in VHDL or was there some other reason not to use
the toVerilog?

From you experience how well can the toVerilog be used to generate
Verilog code?

I saw in a different thread that it is not possible to generate lists of
Signals. Is there a different way to model Verilog generateable memory?

Thanks for you thoughts.

Guenter

Re: [myhdl-list] toVerilog and memories

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

David,

Thanks, I had that part figured out and that made it work in myhdl 
simulation.

I was looking into the _toVerilog code to see how difficult it would be 
to add support but haven't spent enough time on it yet. I have never 
used python code generation so it is all a little new to me but very 
interesting.

Thanks, Tom


David Brochart wrote:

>Tom,
>
>In order to fix the error message on addr, replace memL[addr] with
>memL[int(addr.val)].
>Unfortunately the current version of the Verilog translator doesn't support
>signal list (array) translation.
>Jan, do you plan to support it in the next release(s)?
>
>Regards,
>
>David.
>
>
>
>Selon Tom Dillon <td...@di...>:
>
>  
>
>>I am trying to model generate Verilog for some simple memories. For example:
>>
>>def ram(dout,din,addr,we,clk=None,depth=4) :
>>  memL = [Signal(intbv(0,min=0,max=2**8)) for i in range(depth)]
>>
>>  while 1:
>>    yield posedge(clk)
>>    if we:
>>      memL[addr] = din.val
>>    dout.next = memL[addr]
>>
>>I want addr to be a Signal as well. I get an error that it needs to be
>>an int.
>>
>>If I use the value of addr, then it simulates fine but I get a list
>>comprehension error when running it through toVerilog.
>>
>>Is there a way to do this and get it through toVerilog?
>>
>>Thanks, Tom
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>myhdl-list mailing list
>>myh...@li...
>>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>  
>

Re: [myhdl-list] toVerilog and memories

[David B. <dav...@fr...>]

Tom,

In order to fix the error message on addr, replace memL[addr] with
memL[int(addr.val)].
Unfortunately the current version of the Verilog translator doesn't suppo=
rt
signal list (array) translation.
Jan, do you plan to support it in the next release(s)?

Regards,

David.



Selon Tom Dillon <td...@di...>:

> I am trying to model generate Verilog for some simple memories. For exa=
mple:
>
> def ram(dout,din,addr,we,clk=3DNone,depth=3D4) :
>   memL =3D [Signal(intbv(0,min=3D0,max=3D2**8)) for i in range(depth)]
>
>   while 1:
>     yield posedge(clk)
>     if we:
>       memL[addr] =3D din.val
>     dout.next =3D memL[addr]
>
> I want addr to be a Signal as well. I get an error that it needs to be
> an int.
>
> If I use the value of addr, then it simulates fine but I get a list
> comprehension error when running it through toVerilog.
>
> Is there a way to do this and get it through toVerilog?
>
> Thanks, Tom
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] toVerilog and memories

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

I am trying to model generate Verilog for some simple memories. For example:

def ram(dout,din,addr,we,clk=None,depth=4) :
  memL = [Signal(intbv(0,min=0,max=2**8)) for i in range(depth)]
   
  while 1:
    yield posedge(clk)
    if we:
      memL[addr] = din.val
    dout.next = memL[addr]

I want addr to be a Signal as well. I get an error that it needs to be 
an int.

If I use the value of addr, then it simulates fine but I get a list 
comprehension error when running it through toVerilog.

Is there a way to do this and get it through toVerilog?

Thanks, Tom

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Jan,
> 
> I agree about the hard debugging. I did check and the docs say that the 
> functions that are used are said to be supported. I need to do some 
> simple tests to see what does and doesn't work.
> 
> I have been using icarus for the time being and it is working well.

Ok. If that's on the same machine as aldec, than that's really strange.
BTW, is aldec very expensive?

> BTW, I added signed number support to the toVerilog generation. Not sure 
> I did it the best way but so far it is working.
> 
> Also, found and fixed a problem with the Verilog signal names when two 
> similar modules are instantiated from the same module. I was getting 
> conflicting signals names. For example:
> 
> M0 = mult(x,a,b)
> M1 = mult(x1,a1,b1)
> 
> It used M0 in both cases for the base for the signal names.
> 
> Should I send you the myhdl files I have modified for your review?

Definitely - this would be a great help. (If it's easier for you,
you can just tar up a whole directory.)

I am on vacation from june 15-22, so feedback will not
be immediate.

> I have had some time the last week or so to test drive myhdl and am 
> enthused about  the possibility of combining Python with logic 
> generation and testing. So far so good.
> 
> Just figured out and started using unittests. They are great, thanks for 
> the introduction to them in the myhdl manual.

Now that you mention it :-)

I also think that unittests are a great tool that can be very useful
in hardware design, as in software. However, the emerging opinion
is that the way it's implemented in Python doesn't fully realize the
potential. It's more of a re-implementation of what exists in other
(less powerful) languages. Basically, the point is that things could
and should be much easier for a Python unit test user. I basically
agree with this viewpoint (having used unit tests a lot).

There is work going on on a powerful alternative called py.test.
I haven't checked the status recently and haven't tried it yet.
However, I know what the goal is. Creating unit tests setups would
be much less restrictive - for example, it would be perfectly possible
to simply use functions instead of (sub)classes and methods. Also,
most tests would simply be done using the Python assert statement.
This would be simpler and more powerful at the same. (For this
purpose, the treatment of 'assert' would be slightly modified from
standard Python.)

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: MyHDL / ModelSim cosim

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

Jan,

I agree about the hard debugging. I did check and the docs say that the 
functions that are used are said to be supported. I need to do some 
simple tests to see what does and doesn't work.

I have been using icarus for the time being and it is working well.

BTW, I added signed number support to the toVerilog generation. Not sure 
I did it the best way but so far it is working.

Also, found and fixed a problem with the Verilog signal names when two 
similar modules are instantiated from the same module. I was getting 
conflicting signals names. For example:

M0 = mult(x,a,b)
M1 = mult(x1,a1,b1)

It used M0 in both cases for the base for the signal names.

Should I send you the myhdl files I have modified for your review?

I have had some time the last week or so to test drive myhdl and am 
enthused about  the possibility of combining Python with logic 
generation and testing. So far so good.

Just figured out and started using unittests. They are great, thanks for 
the introduction to them in the myhdl manual.

Tom




Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>> Hi,
>>
>> I was attempting to connect myhdl to Aldec Riviera, which usually is 
>> similar to ModelSim.
>>
>> I've got everything compiled and the it runs OK with the Icarus vpi 
>> interface, but I don't get the inputs of my dut initialized or 
>> stimulated.
>>
>> Did you have to do anything to the Icarus myhdl code to get further 
>> with ModelSim?
>>
>> Any thoughts on how to troubleshoot this?
>
>
> Some hard debugging sessions, I fear :-)
>
> Without access to the tool, I cannot help much, but
> here are some preliminary thoughts anyway:
>
> Are you sure their VPI implementation is complete? In
> particular, is vpi_put_value on a reg supported?
> I remember having seen docs on a tool - don't remember
> if it was Aldec - where this wasn't supported, although
> they claimed VPI support. Also, it seems they have other
> (proprietary) ways to couple to C models, which they
> may give priority.
>
> Regards, Jan
>

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Hi,
> 
> I was attempting to connect myhdl to Aldec Riviera, which usually is 
> similar to ModelSim.
> 
> I've got everything compiled and the it runs OK with the Icarus vpi 
> interface, but I don't get the inputs of my dut initialized or stimulated.
> 
> Did you have to do anything to the Icarus myhdl code to get further with 
> ModelSim?
> 
> Any thoughts on how to troubleshoot this?

Some hard debugging sessions, I fear :-)

Without access to the tool, I cannot help much, but
here are some preliminary thoughts anyway:

Are you sure their VPI implementation is complete? In
particular, is vpi_put_value on a reg supported?
I remember having seen docs on a tool - don't remember
if it was Aldec - where this wasn't supported, although
they claimed VPI support. Also, it seems they have other
(proprietary) ways to couple to C models, which they
may give priority.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] MyHDL / ModelSim cosim

[David B. <dav...@fr...>]

Hi Tom,

For me it worked out of the box. I just followed the manual and the examp=
les
given by Jan, so except that I don't have any usefull advice...

Regards,

David.



Selon Tom Dillon <td...@di...>:

> Hi,
>
> I was attempting to connect myhdl to Aldec Riviera, which usually is
> similar to ModelSim.
>
> I've got everything compiled and the it runs OK with the Icarus vpi
> interface, but I don't get the inputs of my dut initialized or stimulat=
ed.
>
> Did you have to do anything to the Icarus myhdl code to get further wit=
h
> ModelSim?
>
> Any thoughts on how to troubleshoot this?
>
> Thanks, Tom
>
>
> David Brochart wrote:
>
> >Jan,
> >
> >I tried using one of the PLI C code you published for Icarus and runni=
ng it
> with
> >ModelSim. It works fine except that VSIM application gets bigger and b=
igger
> in
> >the system, as if there was a memory leakage. I didn't notice it at th=
e
> >beginning but for very long simulations, which contain a lot of I/F si=
gnals
> >between MyHDL and ModelSim (around 300), ModelSim just crashes.
> >Have you noticed it with Icarus or CVER too? Any clue about the cause =
of it?
> >Also, you said some time ago that you were able to use a ModelSim lice=
nse.
> Have
> >you made some progress? Do you plan to release a VHDL PLI for using My=
HDL
> with
> >ModelSim in the near future?
> >
> >Regards,
> >
> >David.
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by Oracle Space Sweepstakes
> >Want to be the first software developer in space?
> >Enter now for the Oracle Space Sweepstakes!
> >http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dclick
> >_______________________________________________
> >myhdl-list mailing list
> >myh...@li...
> >https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q=
22005
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>