Hyfsat snabb lagring till MCU/FPGA projekt
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Kraftigare CPU/FPGA måste du nog ha oavsett - att köra över 20 MByte/s gör att en seriesnöre måste skaka väldigt fort oavsett. mao. inte läge för bit-banging.
SD-konsortiet har lossa lite på sina hemligheter i en förenklad spec med
https://www.sdcard.org/downloads/pls/index.html
men i praktiken innebär det ändå att du är beroende av färdiga chip.
Vägen över SPI är helt enkelt för långsamt och stöder max 25/50 MHz klockhastighet (vilket ger max ca 2.5/5 MByte/s i burst - i praktiken mycket lägre än så då många lyckats inte med mer än 14-18 MHz på klockan eller så pga. timingbekymmer (och också reflexer i ledningarna så fort det är minsta lilla längd mellan kort och det som läser av iom. att de är ej är impedansmatchad och terminerande system)
Även om du körde 8 st SD-minnen parallellt med 8 separat dataledare så skulle inte kapaciteter räcka om det skulle gå via SPI
Skall man få sprutt på SD så måste man använda de proprietära protokollen och anpassade host-chip som ansluter mot SD-minnet med kortas möjliga ledare, där de dels går ned till 1.8 Volt i signalnivå och skickar data på uppåtgående flank och ny data på nedåtgående flank på klockan - ja förutom att det är på 4 'lanes' parallellt och frekvens uppemot 208 MHz på klockan för de snabbaste sd-minnena ...
förmodligen blir det att försöka hitta en SoC-krets på ungefär samma sätt som RPI gör (där överföringen verkar vara USB2 även internt mot CPU) - men kanske snabbare än USB2-varianten.
SD-konsortiet har lossa lite på sina hemligheter i en förenklad spec med
https://www.sdcard.org/downloads/pls/index.html
men i praktiken innebär det ändå att du är beroende av färdiga chip.
Vägen över SPI är helt enkelt för långsamt och stöder max 25/50 MHz klockhastighet (vilket ger max ca 2.5/5 MByte/s i burst - i praktiken mycket lägre än så då många lyckats inte med mer än 14-18 MHz på klockan eller så pga. timingbekymmer (och också reflexer i ledningarna så fort det är minsta lilla längd mellan kort och det som läser av iom. att de är ej är impedansmatchad och terminerande system)
Även om du körde 8 st SD-minnen parallellt med 8 separat dataledare så skulle inte kapaciteter räcka om det skulle gå via SPI
Skall man få sprutt på SD så måste man använda de proprietära protokollen och anpassade host-chip som ansluter mot SD-minnet med kortas möjliga ledare, där de dels går ned till 1.8 Volt i signalnivå och skickar data på uppåtgående flank och ny data på nedåtgående flank på klockan - ja förutom att det är på 4 'lanes' parallellt och frekvens uppemot 208 MHz på klockan för de snabbaste sd-minnena ...
förmodligen blir det att försöka hitta en SoC-krets på ungefär samma sätt som RPI gör (där överföringen verkar vara USB2 även internt mot CPU) - men kanske snabbare än USB2-varianten.
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Ska man hålla sig till rimliga klockhastigheter för en MCU så tror jag man är så illa tvungen att ha en med tillräckligt många pinnar för att kunna klocka ut åtminstone en byte i taget (parallellt alltså).
20 MB/s blir ju 160 Mbit/s om du kör seriellt, och du lär väl behöva minst en handfull instruktion för varje bit som ska petas ut (vilket gör att klockhastigheten antagligen måste upp i över 500 MHz).
20 MB/s blir ju 160 Mbit/s om du kör seriellt, och du lär väl behöva minst en handfull instruktion för varje bit som ska petas ut (vilket gör att klockhastigheten antagligen måste upp i över 500 MHz).
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Nja, om nan skall ha max klockhastighet, så QDI, dvs 4 datasignaler + klocka, dok är denna variant hemlig, så man vet inte hur man gör, såvida man inte är medlem i konsortsiet.xxargs skrev:Kraftigare CPU/FPGA måste du nog ha oavsett - att köra över 20 MByte/s gör att en seriesnöre måste skaka väldigt fort oavsett. mao. inte läge för bit-banging.
SD-konsortiet har lossa lite på sina hemligheter i en förenklad spec med
https://www.sdcard.org/downloads/pls/index.html
men i praktiken innebär det ändå att du är beroende av färdiga chip.
Vägen över SPI är helt enkelt för långsamt och stöder max 25/50 MHz klockhastighet (vilket ger max ca 2.5/5 MByte/s i burst - i praktiken mycket lägre än så då många lyckats inte med mer än 14-18 MHz på klockan eller så pga. timingbekymmer (och också reflexer i ledningarna så fort det är minsta lilla längd mellan kort och det som läser av iom. att de är ej är impedansmatchad och terminerande system)
Även om du körde 8 st SD-minnen parallellt med 8 separat dataledare så skulle inte kapaciteter räcka om det skulle gå via SPI
Skall man få sprutt på SD så måste man använda de proprietära protokollen och anpassade host-chip som ansluter mot SD-minnet med kortas möjliga ledare, där de dels går ned till 1.8 Volt i signalnivå och skickar data på uppåtgående flank och ny data på nedåtgående flank på klockan - ja förutom att det är på 4 'lanes' parallellt och frekvens uppemot 208 MHz på klockan för de snabbaste sd-minnena ...
förmodligen blir det att försöka hitta en SoC-krets på ungefär samma sätt som RPI gör (där överföringen verkar vara USB2 även internt mot CPU) - men kanske snabbare än USB2-varianten.
RASPIn kör QDI mot SD-kortet, och inte USB eller nått sånt.
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Sen finns ju UFS med som kommer runt hörnet, men det kommer kräva en kontroller för det.
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Jag kör ju mest STM32 eller fpga i mina projekt och då är 20 MB/s inte så högt, speciellt inte för en fpga.
TomasL, QDI är det vad ST kallar QUADSPI?
MaDa, UFS? Vad är det?
TomasL, QDI är det vad ST kallar QUADSPI?
MaDa, UFS? Vad är det?
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Sd-consortiet har sin egna standard - det liknar SPI men är det inte, för de högre hastigheterna så skickar man ny data per flank på klockan - det tror jag inte ingår i de mer generella SPI-standarderna.
Provade och läste och skrev på en gammal Rasp-PI B1 och det verkar som att man skyffla runt 24-25 MB/s
på dess USB2-gränssnit mot snabb USB-sticka (Sandisk Extreme USB 3, skrivningen var dock ryckigare - vet inte var flaskhasen var - har inte verifierat mot snurrdisk ännu)
På en klass 10 SDHC-minne var läshastigheten 17 MB/s (vet inte om det är mediat eller gränssnittet som flaskar) vilket tyder på att QDI används så det inte finns en chans att SPI-läsningen på en enda ledare skulle kunna producera den överföringskapaciteten SPI-gränssnittet i SD-världen kan bara vara 25MHz eller 50 MHz på sin klocka.
Hur viktigt är att skrivningen är jämn inte stallar/stocka sig emellanåt? - jag tror att det är detta som kommer vara ett aber och det gäller att ha stor överkapacitet i gränssnittet för att 'hinna ifatt' och förstås tillräckligt med buffert för att mellanlagra när det går trögt på lagringsmediet eller i dess gränssnitt.
Skall man titta på överföring med mer garanterad hastighet så är inte USB speciellt kul iom. att det är paketorienterat och inte kretskopplat utan då är det 1394 och dess efterföljare där man kan garantera hastighet på annat sätt.
Provade och läste och skrev på en gammal Rasp-PI B1 och det verkar som att man skyffla runt 24-25 MB/s
på dess USB2-gränssnit mot snabb USB-sticka (Sandisk Extreme USB 3, skrivningen var dock ryckigare - vet inte var flaskhasen var - har inte verifierat mot snurrdisk ännu)
På en klass 10 SDHC-minne var läshastigheten 17 MB/s (vet inte om det är mediat eller gränssnittet som flaskar) vilket tyder på att QDI används så det inte finns en chans att SPI-läsningen på en enda ledare skulle kunna producera den överföringskapaciteten SPI-gränssnittet i SD-världen kan bara vara 25MHz eller 50 MHz på sin klocka.
Hur viktigt är att skrivningen är jämn inte stallar/stocka sig emellanåt? - jag tror att det är detta som kommer vara ett aber och det gäller att ha stor överkapacitet i gränssnittet för att 'hinna ifatt' och förstås tillräckligt med buffert för att mellanlagra när det går trögt på lagringsmediet eller i dess gränssnitt.
Skall man titta på överföring med mer garanterad hastighet så är inte USB speciellt kul iom. att det är paketorienterat och inte kretskopplat utan då är det 1394 och dess efterföljare där man kan garantera hastighet på annat sätt.
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Gigabit-NIC är inte aktuellt? Då kunde du skicka datan till en vanlig PC och låta den lösa lagringen.
Skicka tex UDP och koppla punkt-till-punkt. Paketen bygger man enkelt i en FPGA, det enda "kompicerade" är checksumman.
Skicka tex UDP och koppla punkt-till-punkt. Paketen bygger man enkelt i en FPGA, det enda "kompicerade" är checksumman.
Re: Hyfsat snabb lagring till MCU/FPGA projekt
UFS är en "ersättare" till SD som lovar ännu rejält högre hastigheter, ungefär som en SSD i en dator, men kräver en kontroller precis som SATA. Inget man bit-bangar.Andax skrev:MaDa, UFS? Vad är det?
Re: Hyfsat snabb lagring till MCU/FPGA projekt
Odruid kör med emmc minnen.
Tror att det är delvis open source så det borde vara relativt smidigt att hitta info om det.
Kanske kan vara något. Vet dock inget själv om hur interfacet ser ut.
—Per
Tror att det är delvis open source så det borde vara relativt smidigt att hitta info om det.
Kanske kan vara något. Vet dock inget själv om hur interfacet ser ut.
—Per