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