On 2007-12-09, Timothy Normand Miller wrote:
> Petter,
>
> I had some more caffeine and looked over your oga1hq_io.v file. It's
> exactly what I had in mind and nicely organized. Excellent job!
Thanks, but I also think you made some excellent points with the code in
your previous post:
1. You do reads purely combinatorially. That way the HQ memory stage
can register it, and we avoid muxing it into the output. I think there
is enough time within the HQ memory stage for this, and that we should
avoid incurring delay after it's output, since that can spill into more
critical parts due forwarding. I guess we won't know before we try, but
what does your intuition say?
2. As you point out, we don't need separate outputs for each external
unit, only two ports and individual binary lines. That should save a
fair amount of logic. This also means we can collapse most of the
non-trigger port addresses, which reduces muxing for writes. I'd have
to look closer at what can be shared.
So, if you agree, I'd try to rewrite more like your suggestion and see
what simplification we can make.
> There were a few minor tweaks I made. I'm sure I didn't get
> everything, and you'll want to diff it yourself in case I neglect to
> mention some change I made. Also, I was thinking about what you said
> about making the address spaces overlap. Some passive reads and
> writes might be combined, but without a clear signal as to whether a
> read or write is going on, we could cause problems. For instance, if
> the programmer assumes that the address port won't be altered by
> anything else, some read to the corresponding address could put
> garbage into that register, causing bugs. It may be best to keep the
> address separate. Having separate read/write flags would do the same,
> but that's no different from using an additional address bit.
I'd say we just define these as symbolic constants in the assembler and
declare each as either read or write and any other use to be undefined.
If we want a port (like a self-incrementing address) to be both readable
and writeable we'll make sure the address is the same for both
directions.
> I added reset logic. The dequeue signal has to come out a cycle
> earlier (its assertion causes the next data to appear on the next
> cycle). I put in some perhaps unnecessary checks against full for
> writes; see the comment. I added byte enable flags for writes. I
> added auto-increment for write addresses. (Hmmm... a side-effect we
> have to document carefully!)
Yes, it looks good. I didn't think we needed reset, but of course, when
adding incrementing address and the conditional reset of enq/deq, it
becomes stateful.
BTW, your previous post did address all my questions. The question
about dispatching between {read, write} was exactly about splitting up
the code in separate read and write blocks.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
