Multiple CPU or Nios II?

[Altera_Forum]

I'm working on a project that requires data to be read into a NIOS out of on chip FIFO. The data is then processed and stored onto a CF card. 

 My problem is that their doesn't seem to be enough time to read the data processes it and then store it to the compact flash and therefore I loose data.   now the options that I know about are  1) increase the write speed to the CF by changing the mode that the CF runs in.  2) I can create a second CPU internal to the SOPC builder document. this CPU would be used exclusively to read the FIFO and store the data into a dual port on chip memory.  3) i can create a second SOPC block that controls the reading from the FIFO, processing, and writing to CF.  which option would allow for the most flexibility of hardware. Make the smallest amount of code. And be the simplest to implement in the FPGA.  my hardware is a Cyclone 1C20 Industrial temp speed grade 7 running at 50Mhz  Thanks  SteveM

[Altera_Forum]

--- Quote Start ---  originally posted by stephenm@Apr 17 2006, 09:14 AM 2)  i can create a second cpu internal to the sopc builder document.  this cpu would be used exclusively to read the fifo and store the data into a dual port on chip memory.  <div align='right'><{post_snapback}> (index.php?act=findpost&pid=14434)  --- quote end ---    --- Quote End ---    Hi Stephen,  One idea you may want to consider is rather than a second CPU to just copy data is to use a DMA with flow control which allows a slave port (your FIFO) to manage the flow of data to simple "unintelligent" masters like a DMA with some simple handshaking signals.  In that way the transfer of data from the FIFO is managed by an independet dma engine allowing the data to be buffered into a dual-port memory whenever the FIFO starts to get full (but this brings up the issue of what is the purpose of the FIFO if it overflows too often - I think a fifo is only useful to help manage "bursts" of data not as a storage area for a contant flow of data). This should free up your Nios to focus on processing data and transfering it to compact flash. There are probaby a few other areas in your "data processing" that could also be speed up with some hardware processing components using more DMAs or just the Nios shuffling data around the system.  Here are some references you can look at: DMA component: http://www.altera.com/literature/hb/nios2/n2cpu_nii51006.pdf (http://www.altera.com/literature/hb/nios2/n2cpu_nii51006.pdf)  For details on flow control see the Avalon Interface Specifications (Ch 6): http://www.altera.com/literature/manual/mnl_avalon_spec.pdf (http://www.altera.com/literature/manual/mnl_avalon_spec.pdf)  Hope this idea helps  Regards, -ATJ

[Altera_Forum]

If the DMA does not work for you or it is too complex, you can still implement a multiprocessor Nios II system. 

 For example, as you said, you can use a dual ported onchip ram (or a tightly coupled memory) to exchange data between the CPUs.   On the software side, you have a few options, like: - Altera HAL: using a mailbox for the communication; - ERIKA Enterprise: using a modification of the FIFO message passing example available at the end of the erika enterprise literature page (http://www.evidence.eu.com/nios2/literature.asp).  or you can try ucLinux, although it has a much larger footprint than the previous ones and I do not know which kind of support it gives to multicore designs...  bye  Paolo

[Altera_Forum]

Thanks for the ideas guys.  

 Right now though I am looking into my first idea of increasing the speed of writing to the CF card.   I went into the PTF file for the CF interface to adjust the timing for the card   and changed             Read_Wait_States = "530ns";            Write_Wait_States = "500ns";            Setup_Time = "70ns";            Hold_Time = "30ns";  to              Read_Wait_States = "140ns";            Write_Wait_States = "120ns";            Setup_Time = "30ns";            Hold_Time = "10ns";  and saw very little difference in write speed to the Flash Card (SLCF2GBJI). the speed was approximately 800kb/s. Then for completeness of testing I slipped in a sandisk CF card (SDCFBI-2048-201-80) and ran the same test. I received drastically better speeds of approximately 1.8 MB/s. I rechecked my numbers, reran the tests, and had 2 other engineers verify my results and methods.   I checked the data sheets in which both say they can preform in mode 4 and the timings that are given in the data sheets are exactly the same as those in the CF.org specifications ver 3.0.  My first question is how do I convert "cycle time" and "-IORD/-IOWR" timing etc from the spec to the "Read_Wait_States" etc of the ptf file in nios   My second question is why would I be getting such different answers for two supposedly identical cards?  Thank you for your time  Steve

[Altera_Forum]

--- Quote Start ---  originally posted by stephenm@Apr 24 2006, 01:25 PM my first question is how do i convert "cycle time" and "-iord/-iowr" timing etc from the spec to  the "read_wait_states" etc of the ptf file in nios   my second question is why would i be getting such different answers for two supposedly identical cards?  <div align='right'><{post_snapback}> (index.php?act=findpost&pid=14621)  --- quote end ---    --- Quote End ---     Hi StephenM,  In general I wouldn&#39;t edit the PTF unless is it absolutly necessary and I know what I&#39;m modiflying. For the timing parameters in the PTF these I believe are part of the interface timing with the CFI memory. See the data sheet on the CFI component: http://www.altera.com/literature/hb/nios2/n2cpu_nii51013.pdf (http://www.altera.com/literature/hb/nios2/n2cpu_nii51013.pdf)  Look at page 2-4 - Timing Tab.  If you open the CFI component and click on the Timing tab this will allow you to define the timing parameter for the CFI component and give you the timing waveform relationships for read and write cycles with respect to your system clock.  The set-up, hold and waitstates "cycles" are a function of the CFI memory timing specs and the system clock speed. As the CFI memory timing and the system clock speeds are fixed numbers - I would expect to see roughly the same performance throught the CFI interfacec. The SOPC Builder tool will figure out the number of system clock "cycles" to meet the CFI memory&#39;s set-up, hold and waitstates.  By editing the PTF directly, I can&#39;t be sure if you are still operating within the CFI memory data sheet timing specs.   Also without any details on how you performed the data throughput tests I can&#39;t be sure why the two cards show different timing numbers (and that you could be operating out of the CFI memory timing specs).  I hope this helps.  Regards, ATJ

[Altera_Forum]

Thanks for the reply The CFI or Common Flash Interface is diferent than what I am useing. I am useing the CF or CompactFlash Interface. I can see where I proably steered you wrong and I appologize. 

 how it was tested was useing a buffer created in software and continously looped through a section of code to write data out to the CF card. this loop counted the number of bytes that it wrote. before it enters the loop it outputs the time and when it exits it outputs the time. then we just calculate bytes per second.  i agree that this is a crude way of figureing it out but it meets our needs for now.   I didnt write the software just the hardware so I don&#39;t know exactly what is going on in software.  well any other Ideas on how I can make sure to set the correct PIO modes for the Compact Flash interface?   thanks Steve

[Altera_Forum]

The CF interface from Altera is basic and rigid. It works only in PIO 0 and TrueIDE. 

If you want a real ATA interface and work with greater PIO modes, you need another way than tricking the Altera core. I needed big performance in writing on a CF as well, and I adapted the Wishbone OCIDEC core for avalon. It is simple to implement, I just mapped the avalon signals directly to the wishbone signals. I got inspired by the ocidec driver for linux to write the initialization code in my software. Feel free to contact me by mail if you want details.  Regards

[Altera_Forum]

Please note it takes time to copy buffer by CPU, so you should use mmap() in uClinux/Linux.