Re: [microblaze-uclinux] FSL_M_FULL

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Adrian,

Try Xilinx app note 529 - design files are provided:

http://direct.xilinx.com/bvdocs/appnotes/xapp529.pdf

John

Adrian Wee Chin Mun wrote:
> Hi John/Jonathan,
> 
> 
>>Or, do you mean that if the FIFO ever fills, even after MicroBlaze reads
>>some data out, your core never recovers?
> 
> 
> 	That appears to be the case. Once the FIFO fills and FSL_M_FULL
> asserts, my hardware core never recovers. Last night I spent some time
> modifying the FSL Master interface on my core to use more relaxed timing but
> it is still not working. 
> 	I think getting a prior working implementation might be a good idea
> since I implemented mine solely based on the datasheets. Perhaps you guys
> can recommend an available implementation that is simple to observe the
> functionality? That would be helpful :)
> 
> Thanks
> Adrian
> 
> 
> 
> -----Original Message-----
> From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
> [mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] On Behalf Of John Williams
> Sent: Wednesday, 1 February 2006 9:00 AM
> To: microblaze-uclinux@xxxxxxxxxxxxxx
> Subject: Re: [microblaze-uclinux] FSL_M_FULL
> 
> 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/
> 
> 
> ___________________________
> 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/

___________________________
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/