On 12/26/05, Pieter Hulshoff <[EMAIL PROTECTED]> wrote:

>
> A reset should be valid for each clock domain, though as with most signals you
> can just transfer it to the proper clock domain using 2 FFs.

Understood.  I'll make sure the design uses sync resets.

>
> > tail0 is where you're writing.
> > tail1 is what you compare against head4 to determine if the fifo is full.
> > tail2 is what you compare against head4 to determine is you're going
> > to be full on the next cycle.
> > tail3 is just a combinatorial 'increment' of tail2.
>
> I understand, but are all those comparison signals needed? I still feel it
> would be enough to use the current pointer for writing, and the next pointer
> for full-checking (meaning 2 copies i.s.o. 4).

Necessary?  No.  Some of these registers can be eliminated and
replaced by combinatorial logic.  That'll just reduce the maximum
clock speed.  For instance, the "full" signal could be based
combinatorially on the current pointer, but that means we have an
output signal that isn't registered, which I try to avoid.

One of my strengths is that my designs favor speed over area.  One of
my weaknesses is that my designs favor speed over area.  :)

>
> Considering that it's late here, I'll probably make mistakes if I do it now,
> but if you don't mind I'd like to have a look at an alternative
> implementation, just for comparison, tomorrow, and send it to this thread.
> It'll also be a good opportunity for me to check how bad my Verilog
> understanding truly is. :)

Go ahead.  opencores.org has some great stuff, and there are fifos in
their PCI core that use gray codes too (but oddly, they convert back
and forth between gray and binary).

I hate reading other people's code.  It's not that they write inferior
code, but that my thought process seems to be incompatible with that
of other hardware designers.  :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to