Which FGPA/tool for this project? - Page 1
Forum section: electronics / general

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 21, 2017, 05:09:33 pm
content: Long time ago I did program a somewhat limited algorithm to locate the position of a magnet in space. Now I'd like to go further and port it to an FPGA.I'm currently using a PSOC 5LP running at 67MHz(cortex M3).The algorithm makes heavy use of 16-bit fixed point multiplications and sums for speed purposes, because I have multiple 4x4 matrix multiplications, jacobians, determinants, cosines, sines.... For example trygonometric functions are calculated by taylor series, to avoid slow floating point functions.-All I have is programmed in C-Project hardware has only one LCD and 4 I2C magnetometers (although it could be 8 )-I had little experience with Quartus long time ago and didn't like it, besides that I have no idea of the fpga world-Don't care about the cost of the FPGA or hw dev tools, but would like to keep the software tools free or to a minimum, and easy to learn. I need fast architecture and easy programming not lots of features.- I need something that has like 5-10 times the processing speed of this Psoc 5.

author: legacy
author_rank: Super Contributor
timestamp: September 21, 2017, 06:53:09 pm
content: PIC32, or an MPU with Cordic in hw may accelerate better than a softcore in fgpa, especially on the software side.

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 05:49:34 am
content: Quote from: legacy on September 21, 2017, 06:53:09 pmSorry for not being specific enough. Since I want fast execution I'll have to implement the algorithm in hard-core. Easiest would be of course to use a very fast MPU but I'm not sure that would be enough. Even 300-400Mhz could turn out slow.

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 06:10:04 am
content: Quote from: blueskull on September 22, 2017, 05:53:56 amWhat is the cost of the software dev tools for the blackfin family?

author: Ice-Tea
author_rank: Super Contributor
timestamp: September 22, 2017, 06:52:23 am
content: By processing speed you mean CPU power? And you want to keep the FPGA fabric around?In that case, perhaps a Samartfusion 2 may do the trick (I know, I mentioned these before, yes I like them a lot).

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 07:01:00 am
content: Quote from: Ice-Tea on September 22, 2017, 06:52:23 amSuggestion appreciated, didn't know about this platform. And the cost of the software tools is...?

author: Ice-Tea
author_rank: Super Contributor
timestamp: September 22, 2017, 07:07:12 am
content: They changed it recently, but if I understand correctly: as with many vendors, there's a free version that will work fine unless you get the big a** devices.

author: Ice-Tea
author_rank: Super Contributor
timestamp: September 22, 2017, 07:11:35 am
content: Sure? Because I got some quotes for Smartfusion 1 a few years ago and they were preyy damn low.

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 07:12:11 am
content: Quote from: blueskull on September 22, 2017, 07:05:40 amThe application that I'm targeting is not cost sensitive. If it makes the job 30€ a piece is ok.

author: rs20
author_rank: Super Contributor
timestamp: September 22, 2017, 07:14:50 am
content: Sounds like you could take your complicated equations and fit some approximations that are off by 1ppm but require dramatically fewer computations?

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 07:21:05 am
content: Quote from: rs20 on September 22, 2017, 07:14:50 amNope, its not an equation that gives an exact result. It is a math intensive iterative algorithm that minimizes the error of the output. Right now I'm simplifying things by restricting the magnet to be perpendicular to the plane.

author: Marco
author_rank: Super Contributor
timestamp: September 22, 2017, 08:14:58 am
content: Cortex m7 should have plenty of power if you switch to floating point.

author: technix
author_rank: Super Contributor
timestamp: September 22, 2017, 11:30:10 am
content: If space and power allows, a Raspberry Pi 3? That thing packs a quad-core Cortex-A53 and a GPU.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 22, 2017, 01:30:44 pm
content: If your algorithm performs a long consecutive chain of calculations, FPGA is not the best choice. FPGA is good at doing things in parallel. For example, it may have a number of DSP blocks which all can do multiplication at the same time - say 100 multiplications at once. This gives FPGA tremendous speed compared to CPU. For consecutive algorithms, people often built their own CPUs (so called softcores) with FPGA fabric and then them for processing. Such approach doesn't take full advantage of FPGA parallelism. If that's what you want to do, you probably will be better off with a real CPU.

author: daqq
author_rank: Super Contributor
timestamp: September 22, 2017, 01:46:51 pm
content: I too believe an FPGA is not the right choice for this kind of thing. There are various ARMs out there that have LOADs of computational power, even fairly small ones can have DPS instructions and you can tweak your algorithms for more efficient usage. There are also fun ways to get around the nasty functions - you mentioned you are replacing your trigonometry with a Taylor series - with 16 bit math you can easily replace any such calculations with a look up table (sin/cos asin/acos share the same table), essentially removing any waiting. 16bit input x 16bit result is 128k of RAM/FLASH - less if you look at it properly (sinus being symmetrical).You mentioned the number crunching is pretty complex - as a rough benchmark could it run at sufficient speed on a Raspberry pi?

author: kakabouras
author_rank: Newbie
timestamp: September 22, 2017, 01:49:19 pm
content: A possible option could be the Texas Instruments TMS320F2837xD series MCUs.These beasts feature dual core processors running at 200MHz plus :- Dual floating point units.- Dual trigonometric math units.- Dual Viterbi/complex math units.- Dual processors optimized for implementing control loops.All the extra processing units run independently and concurrently with the main processors.Of course such an approach assumes an extra care for the software design in order to take advantage of the MCU features.Prices for the chips fall within the range of 17 to 25 USD ea for quantities of 1k.Development boards are around 200 USD ( if my memory serves me well ).The development software tools are free.However it should be noted that the learning curve is very steep due to the complexity of the chips.

author: Scrts
author_rank: Frequent Contributor
timestamp: September 22, 2017, 03:00:44 pm
content: Isn't I2C will be the bottle neck if fast DSP is used here?

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 04:11:18 pm
content: Quote from: Scrts on September 22, 2017, 03:00:44 pmThe ultimate bottleneck are the magnetic sensors. They are slow and the faster they go the more noise you get. One of the models I use is the LSM303D, 25-50Hz is the fastest for usable data. This was a few years back, maybe there is something radically better now.Quote from: kakabouras on September 22, 2017, 01:49:19 pmKnow that kind of solution. As you mention it takes effort to cram everything nicely in there, I did that kind of effort when I was younger and now I don't see the point when Mhzs are widely available and cheap now.Quote from: daqq on September 22, 2017, 01:46:51 pmI don't know yet. The algorithm I have programmed is a simplified version. The general algorithm considers the magnet at any position, I use Euler angles to make rotations and it gets computational intensive when you have to search the whole space.Quote from: NorthGuy on September 22, 2017, 01:30:44 pmTrue. But its part sequential part parallel. The iterations for minimization of course have to be done in series. But 4x4 matrix inverses, jacobians or sines could be hardwired, that amounts to a LOT of 16-bit multiplies.I'll research the Blackfin and the Smartfusion solutions a bit more.

author: rstofer
author_rank: Super Contributor
timestamp: September 22, 2017, 04:26:44 pm
content: Quote from: Scrts on September 22, 2017, 03:00:44 pmYou would think...5 times a 67 MHz chip is not hard to do. The Raspberry PI 3 has a quad core running at 1.2 GHz. But how do you get down to the hardware?The last couple of days I have been looking at Ultibo (www.ultibo.org) as it is based on FreePascal and provides the tools to talk directly to the hardware without a formal OS getting in the middle. In addition, the thread unit allows for manually scheduling the 4 cores. Ultibo is free... The slope of the learning curve will approach infinity, I think. There is just so much stuff to learn.There are probably other ways to do this with the RPi. Basically, you want to get Linux out of the way (if it is necessary) and write straight to hardware.There are other processors with similar features that aren't locked into the RPi design. This may make more SPI channels available or perhaps DMA would be easier to use, etc. The Broadcom chips seem to be locked in secrecy.Any time you are doing multiply-add, you should be thinking of DSP. The Blackfin 537 is a 600 MHz chip designed specifically for DSP as is the Sharc. I was using the GCC toolchain quite effectively and it's free. uCLinux runs on the chip as it doesn't require an MMU.http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/bf537-ezlite.html#eb-overviewIf you can arrange your algorithm as parallel operations or some kind of pipelined arrangement, the FPGA can be VERY fast. The problem then becomes latency. Do the pipelined stages, with their associated delay, impact the speed requirements? You get one result each clock but it may be the result of a sample taken 10 clocks before. OTOH, the clock might turn out to be pretty fast. Many FPGAs can run at 200 MHz and the high dollar chips can run MUCH faster.On the FPGA, you read all sensors in parallel. You can have as many SPI channels as your package pins permit. And they can be FAST! It's simple to add a FIFO buffer for each sensor channel.In terms of FPGAs, I can only discuss what I know and that's Xilinx and 'very little'. I am coming to terms with Vivado and the Artix 7 chips are pretty nice. Digilent's Nexys 4 DDR board (expensive) uses a HUGE chip with gobs of BlockRam. The Arty board uses a much smaller chip but it's still pretty useful.If you have a need for bulk memory, the Nexys 4 DDR board is pretty nice because Digilent supplies a component to make the DDR look like static RAM. This eliminates the need to endlessly study timing diagrams or use a Xilinx IP core. I haven't used this component. I have used the Xilinx IP with their Microblaze softcore and it works well.

author: technix
author_rank: Super Contributor
timestamp: September 22, 2017, 05:30:34 pm
content: If you can tolerate some latency you can use an ESP8266/ESP32/Raspberry Pi Zero W to stream the data off the system to a Wi-Fi network, to be processed using a laptop, a desktop PC, a gaming PC with one or two high-end GPUs, a server with a lot of high power x86 cores, or some cloud service like Amazon EC2. I don't think your calculations can hog up an 8-core Ryzen 7 and two GeForce GTX 1080 Ti's.

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 05:51:11 pm
content: Quote from: technix on September 22, 2017, 05:30:34 pmLatency I can tolerate. However the system must be light, portable, self-contained and battery operated Sorry I can't disclose the application I've thought of

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 22, 2017, 05:57:37 pm
content: Quote from: rstofer on September 22, 2017, 04:26:44 pmThat's actually a pretty small FPGA. Take a look at this truly huge one... And don't choke on the price (yes, it actually is $76,000 for one chip.)https://www.digikey.com/product-detail/en/xilinx-inc/XCVU440-3FLGA2892E/XCVU440-3FLGA2892E-ND/7604556

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 06:01:46 pm
content: This is another setup I made using 8 magnetometer boards. I placed 2 perpendicular 3d magnetometers (Honeywell IIRC) at each corner.Just something I wanted to try.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 22, 2017, 06:23:11 pm
content: How fast does it actually need to be ? I'd imagine it's limited by mechanics and the speed of the sensors.Unless you want to do it as a learning excercise, it's going to be a lot easier to do in software on an MCU or DSP than an FPGA, and you should explore that before assuming FPGA will be necessary.

author: rstofer
author_rank: Super Contributor
timestamp: September 22, 2017, 06:45:47 pm
content: Just working up floating point in an FPGA could be a major undertaking even if a core could be found. Verification comes to mind. The GCC libraries have been around for years and years being used on millions of applications with no apparent issues.Yes, if an MCU has the capability that is absolutely the way to go. A specialized DSP type MCU like the Blackfin or Sparc would probably be better than a general purpose MCU but it may not be required. Megaflops are pretty easy to buy.If the app needs to be portable and battery powered, I might consider a laptop or notebook. I imagine my Microsoft Surface Book has enough horsepower: Dual core, 4 threads, 2.6 GHz - that should cover it. Even with Win 10 in the way. The sensors are SLOW!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 22, 2017, 06:56:28 pm
content: As a quick & easy reality check, it would probably worth getting your code running on a RasPi & see where you're at speed-wise.

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 07:03:00 pm
content: A fast MCU would be the best solution I agree. I need around 5-10 readings/sec, something that provides human interactivity. A laptop is too big and heavy, any laptop.

author: Marco
author_rank: Super Contributor
timestamp: September 22, 2017, 07:56:22 pm
content: Between 3x the clockspeed, dual issue and the instruction count reduction from going floating point I'd be surprised if a STM32F7 wouldn't get you your desired speedup.

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 22, 2017, 08:03:49 pm
content: Quote from: Marco on September 22, 2017, 07:56:22 pmI'll take a look. Also people seem happy with Atollic

author: technix
author_rank: Super Contributor
timestamp: September 23, 2017, 03:05:05 am
content: Quote from: MasterTech on September 22, 2017, 05:51:11 pmJust stream it off to a server on the cloud for the number crunching then.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 23, 2017, 05:32:38 am
content: Quote from: MasterTech on September 22, 2017, 08:03:49 pmIf you don't mind that it's as slow as molasses in the winter.

author: forrestc
author_rank: Unknown
timestamp: September 23, 2017, 07:09:35 am
content: Quote from: MasterTech on September 21, 2017, 05:09:33 pmI agree with others that perhaps a fast core processor might be the best option, however, a few things others haven't mentioned specifically about FPGA's follow:Note: I haven't done much real work with a FPGA, so these are just things I've picked up knowing about somewhere along the way:1) There are C to HDL (aka fpga) compilers. These will take something C like and interpret convert it to something like verilog or VHDL. Not sure how well they work, I do know that for some you have to write in a 'special' way. Seehttps://www.xilinx.com/video/hardware/getting-started-vivado-high-level-synthesis.htmlas an example - just the first one I found.2) For at least some of the functions you're talking about, there are cores out there (aka chunks of HDL code) which do a lot of the math functions you are talking about. In particular XILINX has CORDIC IP which does a lot of the trig functions. Others probably have similar or more or different.3) You may want to look at the math projects at opencores.org

author: legacy
author_rank: Super Contributor
timestamp: September 23, 2017, 10:27:32 am
content: Quote from: forrestc on September 23, 2017, 07:09:35 amyeah, the best advice ever (sarcasm)

author: rstofer
author_rank: Super Contributor
timestamp: September 23, 2017, 10:09:41 pm
content: At Ultibo's gitgub, there is an example where a CPU is dedicated to a single task and the remaining 3 CPUs do whatever (RPi 3 in my case).At the culmination of the example there is a simple assembly language loop to increment a value in memory while a task running elsewhere displays the iterations per second. How about 603 MILLION loops per second? Sure, there is only an increment register and a memory write per loop but that's a LOT of loops!Other Pascal loops are down around 7 MILLION per second which still might be sufficient.And the RPi3 has floating point support.https://github.com/ultibohub/Examples/tree/master/Advanced/DedicatedCPU/RPi2I don't pretend to understand what is going on. There's a lot to learn...

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 24, 2017, 05:38:50 am
content: Assembly code is somewhere I don't want to go. It is a nightmare and the algorithm I'm handling sometimes fries my head.Back in 1998 I did program a receiver-transmitter for a Direct Sequence Spread spectrum modulation in a TM3240C54x. I happen to have found the code of it. There is the taylor series for cos(x), sin(x), cos(4x), sin(4x), I used since theres is not enough memory for a look-up table and if you use 8-bits for that, the noise is too high for the demod operations.The receiver used a complex I-Q demodulating loopCode:.title "Receptor DS-SS".mmregs;memory mapped registers.setsect ".text", 0x200,0;Inicio del codigo ejecutable.setsect "vectors", 0x180,0;Inicio del espacio para vectores.setsect ".data", 0x2000,0;-----definiciÛn de constantesflag_rcv .set 0x0001; flag que se§aliza la recepci¢n de un datokv.set 0x0002; constante del VCOphi.set 0x4F35; frecuencia discreta central del VCO; phi=2*pi*fc*Ts (1.4Khz)n_taps.set 15; numero de taps del filtro paso bajo del lazobuff_length .set 15*9; longitud del buffer para el c¢digo PN; usado en la rutina acq.umbral_iq .set17100; umbral para la rutina acq..copy "const.dat" ; Copia la secciÛn de constantes..sect "vectors".copy "vectors1.asm";-----inicio del programa principal.text; secciÛn de programastart:intm=1; no permito interrupciones.call AC01INIT; configura el conversor A/D.pmst = #01a0h; processor mode status registersp = #27fah; init stack pointerimr = #240h; unmask TDM RINT and HPIINT(host port interface)intm = 0 ; globally enable all interruptssxm = 1; ExtensiÛn de signo activada.*(flags)=#0AR0 = #1; importante para las instrucciones MAC.inicioTC=bitf(*(flags),flag_rcv); barrera -> se espera hasta quenopif (NTC) goto inicio; podamos procesar otro dato*(flags) ^= #flag_rcv; pone a cero el flag de recibidoT = *(samplerx); T = muestra recibidanopA = T * *(vcocout); multiplica la entrada por la salida; del oscilador I.*(f_data1) = hi(A); introduce la salida del; multiplicador en el filtro IT = *(samplerx)nopA = T * *(vcosout); multiplica la entrada por la salida; del oscilador Q.*(f_data2) = hi(A); introduce la salida del; multiplicador en el filtro Qcall filtrar; funci¢n de filtrado(I/Q)A = *(lp1); Toma la salida del filtro I*(b_2) = A; y la introduce en buff2.A = *(lp2); Toma la salida del filtro Q*(b_3) = A; y la introduce en buff3.call acq1; rutinas que filtran con el cÛdigo PN local.call acq2*(update) = #0xffff; Desactiva la seÒal de actualizaciÛn.A = *(filt_out1); Suma en mÛdulo las salidas de los filtrosA = |A|; que dan la correlaciÛn.B = AA = *(filt_out2)A = |A|A = A + B*(i2q2) = AA = A - #umbral_iq; comprueba el umbral.nopif (ALT) goto no_updatenop*(update) = #0x5000; seÒaliza la actualizaciÛn de la salida de los; bloques acq1 y acq2.no_update T = *(ultimo1); T = salida del bloque acq1.A = T * #0x7fffB = *(ultimo2) * hi(A)call vcoT = *(ultimo2)*(sampletx) = Tgoto iniciofiltrar:push(AR0); guarda AR0 en la pila; filtro 1AR0 = #f_data1_endA = #0repeat (#(n_taps-1))macd(*AR0-,h0,A)*(lp1) = hi(A); filtro 2AR0 = #f_data2_endA = #0repeat (#(n_taps-1))macd(*AR0-,h0,A)*(lp2) = hi(A)AR0 = pop(); recupera AR0 de la pilareturn_enablevco:;realiza la funci¢n del VCOpush(AR3)AR3 = #vcomemA = B << -6; entrada en BT = #kvA = T * hi(A)A = A + #phi; A = phiA = A + dbl(*AR3);A = phi + entrada del VCO + valor de vcomem anteriorcall modpi;reduce 'A' a modulo pidbl(*AR3) = A;guarda 'A' en 'vcomem'A = A<<-2;desplazamiento a la derecha;para dividir por cuatro el argumento*(cosarg) = A*(sinarg) = Acall cosenocall senoAR3 = pop()return_enablemodpi:;reduce a modulo pi la variable 'vcomem'push(AR1)push(AR2)AR1 = #dospiAR2 = #pi*(camsig) = #0if (AGEQ) goto loop1*(camsig) = #1A = |A|loop1B = AB = B - dbl(*AR2)nopnopif (BLEQ) goto fin;goto fin si -pi<= B <=piA = A - dbl(*AR1);si B esta fuera del rango resta 2*pi a 'A'.goto loop1finTC= (*(camsig)==#1)nopnopif (TC) execute(1);si cambiÈ el signo al principio,A=-A;volver a cambiar.AR2=pop()AR1=pop()return_enablecoseno: ;calcula cos(4x) a partir de cos(x);Necesario ya que el argumento de la funci¢n cos() es vcomem;dividido por 4.call cosA = *(cresult) * *(cresult)A = A -#0x7fff <<16A = T * hi(A)nopnopA = T * hi(A)A = A << -13A = A + #0x7fff*(vcocout) = Areturn_enableseno:;calcula el sen(4x) a partir de sin(x).call sinA = #0A = *(cresult) * *(cresult)nopA = A << 1A = A - #0x7fff << 16T = *(cresult)A = T * hi(A)nopnopT = *(sresult)A = T * hi(A)A = A << -14*(vcosout) = Areturn_enablecos:;calcula el coseno con la serie de Taylor;argumento cosarg entre -1 rad y 1 rad.push(AR2)push(AR3)push(AR4)AR2 = #cosargAR3 = #c_coffsAR4 = #C_1A = *AR2+ * *AR2+*AR2 = hi(A)|| B = *AR4<<16 ;A = B - *AR2+ * *AR3+A = T * hi(A)*AR2 = hi(A)A = B - *AR2- * *AR3+B = *AR2+ * hi(A)*AR2 = hi(B)|| B = *AR4<<16A = B - *AR2- * *AR3+A = A <<-1A = -AB = *AR2+ * hi(A)B = B + *AR4 <<16*AR2=hi(B)AR4 = pop()AR3 = pop()AR2 = pop()return_enablesin:; calcula en seno con la serie de Taylor; argumento sinarg entre (-1 rad y 1 rad).push(AR2)push(AR3)push(AR4)AR2 = #sinargAR3 = #s_coffsAR4 = #C_1A = *AR2+ * *AR2+*AR2 = hi(A)|| B = *AR4<<16 ;A = B - *AR2+ * *AR3+A = T * hi(A)*AR2 = hi(A)A = B - *AR2- * *AR3+B = *AR2+ * hi(A)*AR2 = hi(B)|| B = *AR4<<16A = B - *AR2- * *AR3+B = *AR2+ * hi(A)*AR2 = hi(B)|| B = *AR4<<16 ;A = B - *AR2- * *AR3+B = *(sinarg) * hi(A)*(sresult) = hi(B)AR4 = pop()AR3 = pop()AR2 = pop()return_enableacq1:;rutina que correla con la secuencia PN local.push(AR1);guarda en la pila AR1AR1 = #b_2end;retrasa las muestras de buff2repeat(#(buff_length-1))delay(*AR1-)A = #0repeat(#(buff_length-1)) ;calcula el producto de la entrada y del;c¢digo local est·ticomacp(*AR1+, #b_1, A)*(filt_out1) = hi(A)A = *(update)A = A - #0x9nopnopif (ALT) goto end_acq1nopT = *(filt_out1)*(ultimo1) = Tend_acq1AR1 = pop()return_enableacq2:;rutina que correla con la secuencia PN local.push(AR1);guarda en la pila AR1AR1 = #b_3end;retrasa las muestras de buff2repeat(#(buff_length-1))delay(*AR1-)A = #0repeat(#(buff_length-1)) ;calcula el producto de la entrada y del;cÛdigo local est·tico.macp(*AR1+, #b_1, A)*(filt_out2) = hi(A)A = *(update)nopnopif (ALT) goto end_acq2T = *(filt_out2)*(ultimo2) = Tend_acq2AR1 = pop()return_enabletransmit:B=trcv*(samplerx)=B*(sampletx) &= #0xfffc;elimina los bits de control.A=*(sampletx)tdxr=A*(flags) |= #flag_rcv;seÒalizar que se ha recibido un datoreturn_enable.copy "ac01ini1.asm";configuraciÛn del conversor A/D..end

author: tggzzz
author_rank: Super Contributor
timestamp: September 24, 2017, 07:10:39 am
content: Consider using one of thesehttps://www.digikey.com/en/product-highlight/x/xmos/startkitwhich can be regarded as being halfway to being an FPGAFor a miserly £12 you get:8*100MIPs 32-bit cores, with some instructions specialised for DSPboardstransparentlydaisy-chainable if you need more corescontinue to program in C/C++free development environment, Eclipse/LLVM/gdbexcellent flexible, fast, low latency FPGA-like I/OUSB commsOther processors in the family go up to 4000MIPs, but not on that dev board.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 24, 2017, 08:51:49 am
content: Quote from: tggzzz on September 24, 2017, 07:10:39 amMight be a solution, but would need the algorithm to be pipelined to make good use of all cores.The OP is only looking for 5-10x the performance of a 67MHz Cortex M3.It would make the most sense to try conventional MCU or DSP options before going to anything more exotic. It shouldn't take more than a day to get the code and I2C sensors running on a RasPi ( or similar) even if you'd never used Linux before. That would immediately give some definite numbers for speed and power consumption to inform decisions on which way to go.Until that gets done there is little point spending time thinking about anything more exotic.

author: tggzzz
author_rank: Super Contributor
timestamp: September 24, 2017, 11:13:49 am
content: Quote from: mikeselectricstuff on September 24, 2017, 08:51:49 amI suspect that many navigation applications have some low-level noise-filtering grunt work, plus some "higher level" integration algorithms. I noted that there were several sensors, and guessed that the one-core-per-peripheral doing a lot of grunt work might be useful.In addition, pure C doesn't have very useful DSP arithmetic modes, e.g. saturating arithmetic. Since the xCORE devices are aimed at DSP, their facilities might avoid losing performance when running C DSP. But I haven't investigated that, so it would be up to the OP to check my presumptions.Without knowing the algorithm, it is impossible to say more.QuoteAgreed. The xCORE devices areverynice w.r.t. preciseguaranteedtiming and w.r.t. bit-banged IO.

author: rstofer
author_rank: Super Contributor
timestamp: September 24, 2017, 01:35:14 pm
content: Quote from: MasterTech on September 24, 2017, 05:38:50 amOf course not! But several million Pascal loops per second seems pretty impressive when you consider the slow rate coming from the sensors.The idea of a dedicated 1.2 GHz processor with floating point just seems impressive. The other 3 processors can deal with grabbing data and doing whatever with the output while the dedicated processor does nothing but crunch numbers.

author: rstofer
author_rank: Super Contributor
timestamp: September 24, 2017, 06:12:41 pm
content: I decided to write a little Pascal program to see how the RPi3 handled floating point. To my surprise, with the Free Pascal compiler, 64 bit is the default for type Real. That's nice because the A53 processor defines 32 (check this) pairs of 32 bit registers to hold the values (d0..d31 are the reg names). I haven't been able to find the answer on how many clocks it takes to perform a multiply but it can't be many because the processor, overall, is rated in the 2+ GFlop range.It seems ARM doesn't produce timing specs for instructions on some processors because it gets swamped by outside factors like memory access, cache hits, and so on.The processor also does short vector processing. I didn't research this but it could be useful.

author: tggzzz
author_rank: Super Contributor
timestamp: September 24, 2017, 06:29:38 pm
content: Quote from: rstofer on September 24, 2017, 06:12:41 pmDo you know ofanycurrent processors that have decent performance and do have such timing specs?The only ones I'm aware of are the xCORE processors, which avoid needing interrupts and don't have caches.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: September 24, 2017, 09:58:54 pm
content: Quote from: tggzzz on September 24, 2017, 06:29:38 pmThe Texas Instruments AM3358 or 3359 in the beaglebone series have 2 PRU units which run at 200Mhz and are deterministic if I recall correctly. Not surprising as they target the same type of problems that xCORE or propeller cpus are intended for.

author: tggzzz
author_rank: Super Contributor
timestamp: September 24, 2017, 11:10:39 pm
content: Quote from: chickenHeadKnob on September 24, 2017, 09:58:54 pmAquickscan of the TI AM335x shows the ARM-A8 has cache (of course), the PRU-ICSS have interrupts and 120(!) registers and 12k shared RAM and "limited" peripherals. I haven't assessed the effects those features have in practical systems, but they are orange flags I would want to investigate. The tools do codeprofiling, which is an orange flag.The PRU-ICSS appear, in some subtle ways, appear to be regarded as bolt-ons to the ARM-A8. I'd prefer it to be the other way around!In the past there have been many many asymmetric multicore processors, and the programming environment has always been an afterthought. Given that, I'm not entirely surprised there's little prominence given to how you program the hard real time parts, and the communications with the other cores. That's a shame, because the best hardware is useless without decent programming environments. I haven't spotted any instruction timings, nor part of the IDE thatpredictsworst-case timing - pointers would be welcome.OTOH, the xCORE processors are symmetrical and have an excellent programming environment: xC which is based on Communicating Sequential Processes (also included in Go and Rust, apparently).

author: rstofer
author_rank: Super Contributor
timestamp: September 24, 2017, 11:57:44 pm
content: Quote from: tggzzz on September 24, 2017, 06:29:38 pmNo, but given that these are register to register operations, it should be possible to determine how many cycles it takes to add or multiply. Add is complicated due to alignment and would probably be omitted or bounded. I can't see any reason ARM couldn't describe the number of clocks required to multiply to reals.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 25, 2017, 12:30:41 am
content: Quote from: rstofer on September 23, 2017, 10:09:41 pmMy old Sandy Bridge does about 2 billion Pascal loops per second with Delphi (fetching a value from a long array).Code:for i := 0 to N-1 do beginBuf := char(WorkBuf);end;

author: tggzzz
author_rank: Super Contributor
timestamp: September 25, 2017, 07:24:03 am
content: Quote from: rstofer on September 24, 2017, 11:57:44 pmWhatguaranteesthe variables are kept in registers? They probably are, but compiler optimisation algorithms are notoriously fickle and, um, "heuristic".If the system performance issolelydependent on such an inner-loop, then fine. However in most systems detailed timing is dependent on other factors, e.g. interrupts, memory accesses in other parts of the codebase, etc, etc.Floating point arithmetic performance is more or less impossible to guarantee, especially if IEEE754 is involved. Not only can operations be short-circuited, but operations involving denorm number are often notoriously slow - they often require fixups in software. What happens is very implementation dependent, and therefore highly non-portable.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 25, 2017, 08:21:36 am
content: Quote from: tggzzz on September 25, 2017, 07:24:03 amIn principle you can use theregisterqualifier to tell the compiler which variables to optimise most, but how successful this is (or if you can even tell what it has done) will depend on the compiler

author: tggzzz
author_rank: Super Contributor
timestamp: September 25, 2017, 08:42:11 am
content: Quote from: mikeselectricstuff on September 25, 2017, 08:21:36 amMy understanding is that all non-trivial compilers have ignored the "register" hint for at least 30 years!

author: Someone
author_rank: Super Contributor
timestamp: September 25, 2017, 09:47:36 am
content: Quote from: tggzzz on September 25, 2017, 08:42:11 amThere are many compliers targeting embedded targets that strictly follow the C register keyword, especially when you want to mix C and assembly knowing the critical instructions and data.

author: legacy
author_rank: Super Contributor
timestamp: September 25, 2017, 09:53:25 am
content: Quote from: tggzzz on September 24, 2017, 11:10:39 pmWhich ones?

author: tggzzz
author_rank: Super Contributor
timestamp: September 25, 2017, 11:05:53 am
content: Quote from: legacy on September 25, 2017, 09:53:25 amThe ones that spring instantly to mind are Cell, Parallela, and - arguably - things like Zynq.Perhaps it would help if I noted some things thatIregard as indicating programming being an afterthought:interprocessor comms where the correctness of the implementation depends on the compiler version and compiler flagsinterprocessor comms which is part of a library, especially if the correctness cannot be checked by a compilerinterprocessor comms which can occur without the compiler being able to detect it, especially data structures shared between processorsinterprocessor comms based on RPC and/or semaphoresnot having parallel programming abstractions at a higher level than a programming language; design patterns help, but more formality is very helpfula language where the defaults enable operations that, while safe in a single flow of control environment, can allow subtle rare misbehaviour in a parallel processing environmentditto tools that concentrate on single flow of control behaviour, and don't highlight what's happening in a parallel environmenta belief that language deficiencies can becovered upameliorated by the use of librariesstarting from single flow of control, and thinking it can be expanded to parallel processing. That's why there is an "impedance mismatch" between MCUs and FPGAs (and C/VHDL) which embedded programmers struggle to appreciate. People have been trying fordecadesto bridge that gap, with only very limited successNo, that list isn't exhaustive.No, nothing meets everything on that list, but a few environments are significantly better than the herd.

author: nctnico
author_rank: Super Contributor
timestamp: September 25, 2017, 11:32:12 am
content: Why should the compiler be involved with the correctness of how a multiprocessor system works? That is a (typical) task of an OS!

author: tggzzz
author_rank: Super Contributor
timestamp: September 25, 2017, 12:14:49 pm
content: Quote from: nctnico on September 25, 2017, 11:32:12 amA language and its compiler's task is to define what's in a user's processes. An OS's task is to execute user processes. The presence (or absence) of an OS is orthogonal to parallel processing.The issues w.r.t. parallelism and languages is very broad; new ways of thinking and implementing are necessary. One well-known example is recasting your thinking in terms of map-reduce algorithms. Others are Communicating Sequential Processes (CSP) and tuple-based systems such as Linda; Lamport also had fundamental insights.CSP maps neatly onto many different implementations, from hardware, through embedded software (single or multiprocessor), to distributed systems - in whatever language happens to be convenient.The concept and tools are still being developed, but some concepts have stood the test of time over the decades. It is well worth understanding their key features andwhypeople keep returning to them.(There is an ancillary question: if they are so good, why aren't they in ubiquitous use? Simple: Moore's "law" has dominated progress for half a century, but now that it is running out of steam people are having to confront developing parallel systems).

author: legacy
author_rank: Super Contributor
timestamp: September 25, 2017, 12:40:16 pm
content: Quote from: nctnico on September 25, 2017, 11:32:12 amwhy do you think we can't safely write lib-thread in C?

author: tggzzz
author_rank: Super Contributor
timestamp: September 25, 2017, 02:32:49 pm
content: Quote from: legacy on September 25, 2017, 12:40:16 pmTouché!I'm told that the latest C standard contains such revolutionary concepts as, gasp, a memory model. Of course who knows when the firstcompletecompiler will arrive, and that's of little comfort to those that still have to use C89 or whatever. ISTR it took ~5yearsfor the first complete C99 (?C99++) compiler to appear. I certainly remember a triumphant commercial to that effect somewhere around 2004/05.

author: legacy
author_rank: Super Contributor
timestamp: September 25, 2017, 03:32:35 pm
content: Quote from: tggzzz on September 25, 2017, 02:32:49 pmYup, if you have time and can give an eye on SGI documentation; it's written that they modified the common C language by adding a special pre and post processor and tons of #pragmaSGI systems were an example of multiCPUs system, starting from 2 CPUs to 4CPUs per motherboard, to 128CPUs per rack system connected trough NUMAlink.

author: rstofer
author_rank: Super Contributor
timestamp: September 25, 2017, 10:44:20 pm
content: Quote from: tggzzz on September 25, 2017, 07:24:03 amThe RPi uses a Cortex A-53 RISC processor so all variables ARE in registers before they are operated on, even if only temporarily. Typically, the compiler loads a register with a value from memory, loads another if necessary and then does the math operation on the registers leaving the result in some register. The compiler may then emit code to store the result back to memory.My interest is how long it takes to do a floating point multiply AFTER the values are loaded into registers. This eliminates memory accesses and, given the dedicated CPU, there won't be any interrupts (they are disabled for the dedicated core in the example).I guess I should quite whining and sniveling and just write a bit more code into the demo program. Just enough ASM to load the registers and then loop on multiply while incrementing a counter. One of the other cores will pick up the loop count and print the value every second. That's what the existing code is doing but it is only incrementing an integer.

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2017, 08:40:53 am
content: Quote from: rstofer on September 25, 2017, 10:44:20 pmYou definition excludes the unresolvable timing problems found in applications in most processors, i.e. memory/cache accesses and interrupts.Now you have stated that, it is valid, but not very useful.In contrast, the xCORE tools easilypredict without executingthat (on a first generation XS1 device) a "float" multiply takes 1.032us max (0.408us min), and a "double" multiply takes 2.632us max (0.560 min). Don't forget that's per core, and there can be many cores executing simultaneously!

author: rstofer
author_rank: Super Contributor
timestamp: September 26, 2017, 01:26:52 pm
content: Quote from: tggzzz on September 26, 2017, 08:40:53 amMy only interest is in seeing how many FLOPS I can get from a dedicated core running in a tight loop - hopefully with no cache misses. This number would only be valid in the very specific case of a dedicated CPU but with 32 sets of floating point registers, a lot of math can be done without going to memory. And, of course, it would only be for a 64 bit multiply. Just a bit of a benchmark, I suppose.The idea is to compare the FLOPS against the 60 MHz processor the OP is using. There's quite a bit of horsepower in a RPi 3b.

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2017, 04:43:39 pm
content: Quote from: rstofer on September 26, 2017, 01:26:52 pmIt helps if the memory accesses are all single-cycle, of course.Are you interested in floating point (FLOPS) or integer (64-bit) arithmetic? Integer arithmetic in C is faster, of course - partly because it ignores all conditions that are the least bit awkward.

author: rstofer
author_rank: Super Contributor
timestamp: September 26, 2017, 05:07:28 pm
content: Quote from: tggzzz on September 26, 2017, 04:43:39 pmI'm looking at whether the RPi is a candidate for the OP's desired speed-up of a 67 MHz single core, software floating point processor. It's not important to me but I was curious about things in general:What's Ultibo all about?How does the threading system work?If I had an application, how do I dedicate a CPU to a particular task?What kind of single CPU floating point performance could I expect?Given the multitude of FP registers, is this perhaps an ideal platform for quad copter control/navigation?Or, given the complexity, is it overkill?So, really, it's just for giggles...But it's pretty clear that the RPi with hardware floating point, 4 cores and 1.2 GHz clock (per core) should be adequate for the required speed-up. If, in fact, the OP even uses FP.Truth be known, just porting the code and running under Linux would probably meet the requirements. Except for the part where Linux lack any semblance of hard real-time capability.

author: technix
author_rank: Super Contributor
timestamp: September 26, 2017, 05:31:15 pm
content: Quote from: rstofer on September 26, 2017, 05:07:28 pmActually in Linux you can set up the kernel and systemd never to schedule any process or route any interrupts to specific cores unless specifically told to. This way you can shove the Linux kernel onto one or two dedicated cores and have all the remaining cores dedicated to your code. This way you get the convenience of Linux kernel and tools without losing too much real time performance.

author: rstofer
author_rank: Super Contributor
timestamp: September 26, 2017, 07:19:14 pm
content: Quote from: technix on September 26, 2017, 05:31:15 pmI didn't know that! I'll have to do some research...Given 4 CPUs, the system should be fine running on 3 and leaving one for the time critical stuff.I guess I really need to understand how messages are passed back and forth.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 26, 2017, 07:26:21 pm
content: Quote from: rstofer on September 26, 2017, 07:19:14 pmEven though this is a separate core, it still has shared memory access for both data and program. So, the "dedicated" core is unlikely to be completely unaffected, even in terms of average performance.

author: technix
author_rank: Super Contributor
timestamp: September 26, 2017, 07:41:40 pm
content: Quote from: NorthGuy on September 26, 2017, 07:26:21 pmYou can code with cache lines in mind and minimize syscalls (as it triggers instruction cache flushes) you can make your code stay in the cache in the most time.

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2017, 08:46:00 pm
content: Quote from: technix on September 26, 2017, 05:31:15 pmHow can you do it without hacking the kernel?

author: Marco
author_rank: Super Contributor
timestamp: September 26, 2017, 08:56:41 pm
content: This doesn't get you hard real time, the kernel itself is significantly single threaded. So the moment your code has to do I/O you can hit some huge latency spike again.

author: technix
author_rank: Super Contributor
timestamp: September 27, 2017, 12:02:04 am
content: Quote from: legacy on September 26, 2017, 08:46:00 pmYou can pass it some command line arguments for that. People uses this type of core isolation to prepare the Pi to run KVM-backed virtual machines, and you can just isolate the cores but skip the KVM.

author: technix
author_rank: Super Contributor
timestamp: September 27, 2017, 12:04:37 am
content: Quote from: Marco on September 26, 2017, 08:56:41 pmIf you can live without interrupts (only polling) you can implement the drivers directly in user mode operating on /dev/mem.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 27, 2017, 01:00:51 am
content: Quote from: technix on September 27, 2017, 12:04:37 amAnd if you can live without Linux ... you get all this plus lots of freed up resources

author: rstofer
author_rank: Super Contributor
timestamp: September 27, 2017, 01:03:52 am
content: Quote from: NorthGuy on September 27, 2017, 01:00:51 amThus my interest in Ultibo - it allows me to blow off Linux for a much lighter kernel. Yes, there is still a kernel including a scheduler and various other bits and pieces left behind but it is mostly out of the way (AFAICT).

author: technix
author_rank: Super Contributor
timestamp: September 27, 2017, 02:41:15 am
content: Quote from: NorthGuy on September 27, 2017, 01:00:51 amBut what do you lose? At least you still have access to standard POSIX stuff and IPC on Linux, and through the use of user-mode IPC (shared memory etc) you can split the priorities into RT-intense (dedicated cores) and non-RT (share cores with the kernel) parts.

author: legacy
author_rank: Super Contributor
timestamp: September 27, 2017, 08:22:27 am
content: Quote from: technix on September 27, 2017, 12:02:04 amkernel 2.6.* you have to hack in a way that looks like RTAIkernel 3.* keeps getting better, but it's practically like the abovekernel >=4.* ... oh, there is something really really interesting here

author: technix
author_rank: Super Contributor
timestamp: September 27, 2017, 09:23:21 am
content: Quote from: rstofer on September 27, 2017, 01:03:52 amWell you lose a good selection of features.You can spawn two processes: one running on dedicated cores doing hard RT stuff, another monitor program making syscalls for it. The hard RT process and the monitor communicates through shared memory (which does not incur syscall overhead) When the hard RT program need something from the kernel it pings the monitor using the shared memory, the monitor issues the syscalls for it and even preprocess the data before throwing it into the shared memory region for the hard RT process. This way you get both an almost hard RT environment and full Linux support.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 27, 2017, 06:34:56 pm
content: Quote from: technix on September 27, 2017, 02:41:15 amYou lose (in no particular order):- fast boot times- quite a bit of memory- some of the speed- a little of reliability- almost all predictability- most of the real time control

author: PartialDischarge
author_rank: Super Contributor
timestamp: September 28, 2017, 01:51:59 pm
content: Quote from: cleaningOut on September 28, 2017, 09:59:54 amOk, please find me a 3D fluxgate sensor that occupies less than 1 or 2 cm3. For this application 3 axes are needed at each point

author: DeanoC
author_rank: Newbie
timestamp: October 02, 2017, 09:54:38 am
content: Most of the chips based on mobile soc also have a GPU.I'd imagine the rpi0w gpu has enough gpu performance to make it worth thinking about. Last time I checked its all ASM based (don't think theres an OpenCL port to the broadcom society) but its 12+ cores, dedicated read caches etc.The nice thing of course, is that you can write the app for just the CPU on a rpi0w board and then offload calculations to the gpu if you need more speed.

author: technix
author_rank: Super Contributor
timestamp: October 03, 2017, 01:33:33 am
content: Or if you intend to you a more common GPU with proper OpenCL/CUDA you can try a nVidia Jetson kit. This way you can develop on your GTX 1080 Ti to polish the algorithm, then drop the CUDA or OpenCL code onto Jetson’s Maxwell-class GPU.

author: technix
author_rank: Super Contributor
timestamp: October 03, 2017, 03:32:48 am
content: Quote from: blueskull on October 03, 2017, 02:14:37 amI don’t think Jetson is getting out of hands, and it is Hetson that is going into the project. The VC4 used in Pi isn’t that programmable without Broadcom unobtainium tools. Jetson packs a few Maxwell-class GPU cores that runs the easily accessible CUDA and OpenCL tools.The GTX 1080 Ti runs the same CUDA and OpenCL. Hence it is used for faster development and algorithm optimization.

author: technix
author_rank: Super Contributor
timestamp: October 04, 2017, 02:04:32 am
content: Quote from: blueskull on October 03, 2017, 03:37:25 amDepending on the real time requirement, you cannot load the system beyond a certain point without losing responsiveness.Also did I mention tools? Good luck getting Broadcom tools for VideoCore IV.