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

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

I disagree with that approach to use memories on the Verilog side by=20
bringing them up to the test bench level. Our designs use many memories=20
and that would be way too tedious.

If it was too difficult to implement, I would much prefer a black box=20
approach that would leave the memories at the same place in the hierarchy=
.

This would not make MyHDL specific to Xilinx by any means, as everything=20
needed for different architectures can be handled in MyHDL as long as we=20
have the ability to turn a list into a Verilog 2D array.

Our synthesis tool, Mentor Precision, will take the same Verilog memory=20
structures and infer them and target them to any FPGA technology.=20
Depending on the structures available in the target technology, dictates=20
how well it does. Worst case you will use a lot of registers.

Even Xilinx XST can handle this these days. I would not limit MyHDL by=20
the ASIC flows that exist today.

We will need the black box support before long which would solve the=20
ASIC flow.

Tom





Haitao Zhang wrote:

>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:
> =20
>
>>Hello,
>>
>>Tom Dillon wrote:
>>
>>...
>>
>>
>>   =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.
>>
>>Following is the Verilog code for a dual-port RAM with synchronous read
>>(read through).
>>
>>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;
>>
>>reg [3:0] ram [31:0];
>>reg [4:0] read_a;
>>reg [4:0] read_dpra;
>>
>>always @(posedge clk) begin
>>
>>  if (we)
>>    ram[a] <=3D di;
>>    read_a <=3D a;
>>    read_dpra <=3D dpra;
>>  end
>>
>>  assign spo =3D ram[read_a];
>>  assign dpo =3D ram[read_dpra];
>>
>>endmodule
>>
>>
>>Now I tried to implement that in myhdl so that toVerilog would create
>>the respective Verilog.
>>
>>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?" fro=
m
>>Haitao Zhang.
>>
>>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 generator=
s
>>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?
>>
>>I tried to go on, without considering the assign statement for now and
>>ran into another issue with the two read_* registers.
>>
>>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 t=
o
>>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.
>>
>>
>>def dp_ram_py(clk, we, addr, di, spo, dp_addr, dpo):
>>
>>  memL =3D [intbv(0)[d_width:] for i in range(a_width^2)]
>>
>>  #read_addr =3D intbv(0)[a_width:]
>>  #read_dp_addr =3D intbv(0)[a_width:]
>>
>>  while 1:
>>    yield posedge(clk)
>>
>>    if we:
>>      memL[int(addr.val)][:] =3D di.val
>>
>>    read_addr =3D addr
>>    read_dp_addr =3D dp_addr
>>
>>    spo.next =3D memL[int(read_addr.val)]
>>    dpo.next =3D memL[int(read_dp_addr.val)]
>>
>>
>>
>>I would appreciate any help how to solve that.
>>
>>Thanks in advance.
>>
>>Guenter
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO Sept=
ember
>>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
>>_______________________________________________
>>myhdl-list mailing list
>>myh...@li...
>>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>   =20
>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO Septe=
mber
>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
> =20
>