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

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

Haitao,

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

Thanks, now I understand. So I can use the combinatorial logic to
resemble the assign statement, just have to have two defs, one for the
memory part and one for the assign statement. Actually three, like one
top that ties them together.


> 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

This is the nice part about the approach I am doing. I actually coding
the memory in Verilog in a generic way. So it can be simulated and
actually implemented with many tools. Following the template given by
Xilinx, I have the benefit that XST will pick that code up and turn it
into block RAM. The code will work with any other tool as well, just
might not trigger that specific function as it does for XST.


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

Splitting up like that is a good idea for the time being and I will
probably do it that way for now. I hope I can finally do the memory
right out of myhdl. The disadvantage of the splitting method is, that
you need to model the memory two times. One time for simulation, which
granted, is not that big of a model. But then you have again the
implementation.

The advantage of being able to model it in myhdl and convert it to
Verilog and in future maybe to VHDL is that you only have to model it
one time. If changes are necessary, you only have to do them in the test
bench and in the myhdl modeling. The rest follows automatically from
that. So I can make an automated verification flow, were I generate my
Verilog for example, use the test bench I used already for the myhdl
model and do co-verification to make sure the generated Verilog is
working, then run the implementation and generate a post-place+route
simulation file and use the test bench again to check that.

I think myhdl can help here to save work steps in the design flow that
are otherwise necessary.

Guenter