OPENCORES.ORG

>


Hello,

         Take a look at the FFR16 Core. It has two modules, one processes 
the ATA-ATAPI protocol and the other the FAT volume.
         Its purpose is to read files stored into the IDE device. The first 
one can be used independently.
         Benefits : Really small area needed, easy to adapt (soft. part), 
WB compatible.
         Drawbacks : Target FPGAs. The code is prepared for read (i know 
that other OpenCores users have done
         the "write" version).

         Although it doesn´t macth your needs the code of the ATA protocol 
processing is commented into the source files
         and it could be helpful.

         Armando,


At 03:26 20/01/2004 +0100, you wrote:
> >
> > Hello,
> >
> > I am needing an IDE controller for my current SOC design and have been
> > looking at the Opencores OCIDEC core.  I am unfamiliar with IDE
> > communication so I hope I don't ask a stupid question.
>There are no stupid questions, only stupid answers.
>
> > We are needing to talk to 1.8" or 2.5" hard drives.  All of the drives
> > we are looking at support the ATA (2-5) standards.
> >
> > First question:
> > Is there verilog rtl code available for the OCIDEC-3 core?
>No
>
> > I found the
> > VHDL version, but cannot find the verilog version.  This core seems
>the
> > best fit our target application, but I don't have time to convert the
> > VHDL to verilog.
> >
> > Second question:
> > If there is no verilog version of the OCIDEC-3, will the OCIDEC-1 or 2
> > talk to hard drives, or are they just able to talk to Compact Flash /
>PC
> > cards?
>They can (and do) talk to harddisks. It's merely the other way around.
>CF/PCCards can use the same protocol as harddisks.
>PIO means Progammed IO, or in normal language: the CPU needs to take
>care of the IO; moving the data from/to the device. If you need to
>process a lot of data this can be quite a burden. However you can create
>your own dma engine that handles this task for the CPU. To the DMA
>controller it would appear is if it is talking to a FIFO.
>Note that this is not the same as IDE-DMA modes!!
>
>Work is in progress to create a newer, more flexible version of the
>OCIDEC cores. This will be a one in all core, instead of having
>increasingly complex cores (as is the case with OCIDEC-1,2,3) you simply
>enable the options you need (and disable what you don't need).
>PIO modes are working fine (and tested in hardware).
>DMA modes are still under development.
>If you can live with the beta-status of this core send me an email and I
>will send you the files.
>
>Richard
>
> > My intuition tells me that I could make the OCIDEC-1 or 2 work,
> > we just give up the DMA capability of the harddrive?  Obviously this
> > would increase the CPU overhead to access the harddrive, but we can
>live
> > with this.  Basically, I need to know if we can talk to a current
> > harddrive using PIO transfers only, ignoring the DMA between the IDE
> > controller and the drive.  PIO Mode 4 @ 16.6MB/s is plenty fast for
>what
> > we need to do.  We just need to be able to read/write to the drive.
> >
> > Thanks,
> > Jeff Hanoch
> >
> > _______________________________________________
> > http://www.opencores.org/mailman/listinfo/cores
>
>
>_______________________________________________
>http://www.opencores.org/mailman/listinfo/cores

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

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@b...
Ald. de Urquijo s/n             Tel.: 34 - 94 - 601 73 04
48013 BILBAO (SPAIN)    Fax.: 34 - 94 - 601 42 59
URL : http://det.bi.ehu.es/~apert
----------------------------------------------------------------------------------------------------------------------