Re: [microblaze-uclinux] FSL_M_FULL

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Adrian,

Adrian Wee Chin Mun wrote:

> 	I am working on hardware linked to the microblaze with FSL ports.
> The FSL Slave interface on my hardware seems to be working fine and the FSL
> Master interface also works in most cases. However, I seem to be facing a
> problem when the buffer on the FSL slave interface on the microblaze gets
> filled up.

[SNIP]

> Which is a non BRAM implementation with a 16x32 buffer. Everything works
> fine as long as the buffer on the microblaze FSL slave is not full. However
> once it is full, it seems to hang my hardware. I have designed the hardware
> to mimic exactly the response from the datasheet (handles FSL_M_FULL) and I
> have tested it for many cases by asserting the FSL_M_FULL with ModelSim and
> it behaves predictably on simulation. However it doesn't seem to work on the
> FPGA.

Isn't this the intended behaviour?  Once the FSL buffer fills
(FSM_M_FULL asserted), then the master must block until the slave
(MicroBlaze in your case) reads from the other end.

Or, do you mean that if the FIFO ever fills, even after MicroBlaze reads
some data out, your core never recovers?

I vaguely recall some discussion once that the FSL timing diagrams in
the microblaze reference guide are not strictly correct.  So, you might
have correctly implemented an incorrect specification.  For the FSL
peripherals I've made before, I've always taken an existing working one,
used that to get the FSL front end interfaces, then put my logic in
behind.  Maybe you can try the same.

Also, I think the XPS Peripheral import wizard supports FSL these days,
might be another approach to try.

Regards,

John

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/