RE: [oc] compactflash/PCCARD-Interface

[Armando Astarloa <jtpascua@bi.ehu.es>]

>>>>
>>>>> > I've done a Core that attachs a Compact Flash to a Wishbone
>>>>> > interface
>>>>> > reading the first file (FAT16) that have been saved on the CF.
>>>>> > It uses two Picoblazes (one for ATAPI-SECTOR PROCESS. and
>>>>> > the other for  FAT16 processing) so it�s directly available for
>>>>> > Xilinx devices (now running on a Spartan II). It is very efficient
>>>>> > in terms
>>>>> > Armando
>>>>>
>>>>>could you please post this full project somewhere, its quite interesting,
>>>>>and yes using multiply PicoBlazes does save area sometimes :)
>>>>
>>>>Ok, i'll request place for this project at OpenCores.
>>>
>>>I see that are already a compactflash interface project currently open 
>>>in OC web
>>
>>Yes, but the Core i proposed its not only an interface. It processes 
>>ATAPI protocol for
>>LBA sector reading and also the FAT16 volumes (cluster tracking, MBR, etc.).
>
>But is less implement it in software.
>
>The OCIDEC core are a ATA controller, you can use it for interface ATA 
>devices, in compactflash/PCCARD-Interface.
>

Hello Marcos,

  The OCIDEC Core is a powerful Core that permits the attachment of 
different IDE devices and also those who have
  DMA capablilities. But it requires a CPU at the Wishbone side in order to 
process the ATAPI protocol and also, as in the
  application that i've proposed, the task of fat16 processing 
(multiplications,divisions, etc...). So as said in the OCIDEC datasheet
  some software functions will be needed, and of course, having a power CPU 
in the SoC or SoPC the use of this Core will be a good solution.

  Compact Flash devices are relative slow (and they don't admit DMA 
transfers) so the use of Programmable State Machine as
  KCPSM is a interesting trade-off between Hardware and Software in these 
kinds of applications. In this case for example less
  than 300 Spartan II slices has been needed (and two Block Rams for each 
KCPSM) and the maximum running speed is about 80Mhz.
  Using this approach if some "software" loops (multiplications, etc.) seem 
to be slow, is easy to extract them and implement
  in "Hardware" (But as seen in practice thats not needed). But my 
intention is to have an independent Core that no requires another CPU, this 
will permit the easy use of it with Master DMA which will take the data of 
the file (Why not MP3, BMP...?) from this Core and put it into a
high speed processing Core (yes, a hardware one!).

  Armando


>>>>Armando
>>
>>
>>--
>>To unsubscribe from cores mailing list please visit 
>>http://www.opencores.org/mailinglists.shtml
>
>
>--
>To unsubscribe from cores mailing list please visit 
>http://www.opencores.org/mailinglists.shtml

---------------------------------------------------------------------------------------------------------------------- 

Armando Astarloa Cu�llar - Universidad del Pais Vasco UPV/EHU
Tecnolog�a Electr�nica
Departamento de Electr�nica y Telecomunicaciones
Escuela Superior de Ingenieros - Email: jtpascua@bi.ehu.es
Ald. de Urquijo s/n Tel.: 34 - 94 - 601 73 04
48013 BILBAO (SPAIN) Fax.: 34 - 94 - 601 42 59
----------------------------------------------------------------------------------------------------------------------


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml