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

[Haitao Z. <ha...@gm...>]

Guenter,

What I meant by keeping track is that you have to put all the logic
circuits of interest in a list and hand them over to whatever
processing routine. Remember your "def"s are only for Python and
Python does not know anything about  the HDL you are using on top of
it, so the user instead of the tool needs to keep track of all his
stuff explicitly.

For memory I suggest the following design flow:
Because of my ASIC background I will always handle memory myself
(remember all that fancy features Xilinx give you do not all easily
translate into an ASIC flow. You want to rely as little on a specific
vendor as possible which means don't use features if you can avoid
them). This is what I would do: partition design into
Logic+Memory+TestBench. When doing Python/HDL behavioral sim, just
simulate all memories in test bench. Memory can be simulated with
either a simple array or a dictionary (esp. when it is sparse). Also
when using a dictionay you automatically get flagged on access before
initialization (key error raised by the dictionary). When you are
ready to implement everything in Verilog, create an additional
hiearchy: top=3D (logic, memory). In top you can instantiate the
translated module of logic and also instantiate all your memory
blocks. This last step can be easily customized and automated with
simple text processing (hint: print statements). While I do not
exactly use myHDL, this strategy has worked out well for me.

Hope this helps all who are struggling with memory translations.

Haitao

On 7/28/05, G=FCnter Dannoritzer <dan...@we...> wrote:
> Hello,
>=20
> Tom Dillon wrote:
>=20
> ...
>=20
>=20
> >
> > 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] <=3D data_in;
> >
> >    always @(posedge read_clock)
> >        data_out <=3D mem[addr_read];
> >
> > Tom
>=20
> I tried to implement a dual-port RAM with synchronous read. The Xilinx
> XST manual provides a Verilog template for that. Basically if the XST
> finds a Verilog construct in the form of that template, it will
> implement it as a dual-port RAM.
>=20
> Following is the Verilog code for a dual-port RAM with synchronous read
> (read through).
>=20
> module raminfr (clk, we, a, dpra, di, spo, dpo);
> input clk;
> input we;
> input [4:0] a;
> input [4:0] dpra;
> input [3:0] di;
> output [3:0] spo;
> output [3:0] dpo;
>=20
> reg [3:0] ram [31:0];
> reg [4:0] read_a;
> reg [4:0] read_dpra;
>=20
> always @(posedge clk) begin
>=20
>   if (we)
>     ram[a] <=3D di;
>     read_a <=3D a;
>     read_dpra <=3D dpra;
>   end
>=20
>   assign spo =3D ram[read_a];
>   assign dpo =3D ram[read_dpra];
>=20
> endmodule
>=20
>=20
> Now I tried to implement that in myhdl so that toVerilog would create
> the respective Verilog.
>=20
> My show stopper was that I did not really know how to implement the
> assign statement. I searched through the mailing list archive and found
> a post from March 2nd of this year with the subject "syntax sugar?" from
> Haitao Zhang.
>=20
> He wrote:
>=20
> > assign a =3D expr
> >
> > In myhdl one has to do
> > def assign_blk():
> >     while 1:
> >         yield signals in expr
> >         a.next =3D expr
> >
> > or:
> > def assign_blk():
> >     def blk():
> >         a.next =3D expr
> >     return always_comb(blk)
> >
> > AND one needs to keep track of all the generators:
> > assign_blk_list.append(assign_blk())
>=20
> First that looked simple, just implement it as combinatorial logic, but
> then there is that comment about needing to keep track of the generators
> that I did not understand. Maybe somebody can give me some explanation
> about why I need to keep track of the generators? Does it not work as a
> combinatorial logic implementation by itself?
>=20
> I tried to go on, without considering the assign statement for now and
> ran into another issue with the two read_* registers.
>=20
> Below is my myhdl code. When doing it as below I have the problem, that
> toVerilog specifies the registers inside the always statement. I
> commented about that already yesterday with the memory array. I tried to
> avoid that by explicit initializing the python variables outside the
> while loop, which is now commented out. But that only brought me a type
> mismatch error message, probably because I am passing a signal to the
> dp_ram_py() function.
>=20
>=20
> def dp_ram_py(clk, we, addr, di, spo, dp_addr, dpo):
>=20
>   memL =3D [intbv(0)[d_width:] for i in range(a_width^2)]
>=20
>   #read_addr =3D intbv(0)[a_width:]
>   #read_dp_addr =3D intbv(0)[a_width:]
>=20
>   while 1:
>     yield posedge(clk)
>=20
>     if we:
>       memL[int(addr.val)][:] =3D di.val
>=20
>     read_addr =3D addr
>     read_dp_addr =3D dp_addr
>=20
>     spo.next =3D memL[int(read_addr.val)]
>     dpo.next =3D memL[int(read_dp_addr.val)]
>=20
>=20
>=20
> I would appreciate any help how to solve that.
>=20
> Thanks in advance.
>=20
> Guenter
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO Septem=
ber
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>