On 3/4/07, Simon <[EMAIL PROTECTED]> wrote:
On 2/27/07, Simon <[EMAIL PROTECTED]> wrote:
> Also, there's an absolute path in that file for the $readmemh call
> that I forgot about. Using a relative path has its own problems, but
> that can be worked around in the scripts that run the test code,
> rather than requiring a symlink from /home/admin/trunk to the source
> tree. See the short attachment.
>
On second thought, wouldn't it make more sense to keep simulation code
separate from the synthesizable code in general? In this specific
case, it would let the test code read data from whatever directory it
wants.
There are a number of different kinds of Verilog code blocks we'd
write, including:
(1) Simulation prototypes of something we want to synthesize
(2) Synthesizable version of (1)
(3) Test harnesses specifically for (1) and (2)
(4) Library code that's generally useful for all sorts of different situations
In general, for a specific block, like the video controller, I'd like
to keep (1), (2), and (3) in basically the same place, although it may
be sensible in many cases to have subdirectories that contain these
different pieces. I think this would keep things coherent. Related
items go together, and you can think of the pieces as a project unto
themselves.
But we also will want to collect a library of generally useful things,
and that would go somewhere else, I guess.
Don't worry about the attachment, it was just to illustrate what I was
talking about. I didn't want to inline it, what with Gmail's text
wrapping. When you have time, I can send a bigger diff with all of my
changes so far.
I'm getting further behind on things, unfortulately, so your patch is
slipping further down my list of emails. This is why I'd like to give
you write access. What are the general nature of your changes?
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Favorite book: The Design of Everyday Things, Donald A. Norman, ISBN
0-465-06710-7
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
