dsPIC33A: new 32bit DSP!

[hans]

PIC32 CPU has nothing in common with dsPIC33. PIC32 uses MIPS, which is one of the first load-store architectures, similar to ARM, but even more RISC-y. It's practically extinct now. RISC-V is, sort of, a newer improved version of MIPS. dsPIC33 is not RISC. It has cycle accurate and very reach command set which lets you create very fast and fully predictable command sequences, for example very fast ISRs. As I understand, dsPIC33A's CPU are going to be more like dsPIC33.

Yep, on the dsPIC and PIC24 I used, the peripherals reside in 0000h .. 0800h.
Many ALU instructions can do reg<=>reg, or wreg<=>memory file (0000h..1FFFh). The latter looks a bit more like 8-bit PICs, but it can be very powerful. This is one of the advantages from a very flat bus hierarchy, where the CPU, RAM and peripherals are on a single data bus. Contrast this to modern ARM parts with AHB/APB bridges/switches, which does allow CPUs to run real fast, also introduces a lot of delay.

Perhaps one point where it starts to break down is when you use object orientated code. The register file address is hard-coded, so a load-store still has to be used if anything is behind a pointer. For example, if you want to write a generic SpiTxRx() function with a pointer to the SPI hardware address. Would this be perhaps why they don't want C++ on 16-bit PICs? Because it's very easy to have everything in a program behind some indirect address...

It would be kind of awesome if they would allow indirect addressing mode on ALU operations, as it looks like the bus implementation can already support it for fixed registerfile addresses. But I suppose there weren't enough bits to squueze this in the current 24-bit instruction format.

[NorthGuy]

The register file address is hard-coded, so a load-store still has to be used if anything is behind a pointer. For example, if you want to write a generic SpiTxRx() function with a pointer to the SPI hardware address.

Actually, indirect addressing gives you even more flexibity. Say:

Code: [Select]

mov #SPIBUF,w2 // address of SPI register in w2

...

// write 8 bytes from a buffer at w1 to SPI
repeat #7
mov.b [w1++],[w2]

...

// read 8 bytes from the SPI to the buffer at w1
repeat #7
mov.b [w2],[w1++]


[mtwieg]

Different market segments: lots of bigger TMS320 variants are used in drive inverters and large DSMPSs (think double or triple digit kW). dsPIC simply was too small for those applications until this variant which could take part of the market share of TI.

Agreed on this.

imagine an MCU that doesn't know what a byte is!

I get that a lot of people choke on this, but I find that baffling. In my experience the vast majority of my variables are 32b (floats, pointers, etc) with some 16b (ints). Having addressable bytes would maybe save a few percent in terms of RAM usage, but it would come at the cost of data page size being cut in half, or a reduction in max clock frequency. Honestly I'd probably be better off if it only addressed 32b words. If your application is spending most of its time printing and parsing strings then yeah byte addessing helps a lot more, but then why would you use a DSP/DSC for that??

Of course the core doesn't matter as much as peripherals, but I ASSUME Microchip did a good job with ADC/timer/core integration which is the actual value-add. Like, I don't even care about high resolution delay-line timers that are all the rage, rather just give me true 200MHz flexible timers that can have many set/reset sources and that operate tightly with ADCs and the core to process the samples.

Yeah for general DCDC converters the utility of <5ns resolution pwm is debatable, even when operating at GaN frequencies. For my application (somewhat like a class D amplifier) it is absolutely necessary, and I wish more chips had such features.

[uer166]

Yeah for general DCDC converters the utility of <5ns resolution pwm is debatable, even when operating at GaN frequencies. For my application (somewhat like a class D amplifier) it is absolutely necessary, and I wish more chips had such features.

Biggest annoyance here is that the resolution doesn't result in response time: if the timers *responded* in <5ns, that would be a game changer! I can see a class D audio-esque stuff needing extra resolution though.

[hans]

The register file address is hard-coded, so a load-store still has to be used if anything is behind a pointer. For example, if you want to write a generic SpiTxRx() function with a pointer to the SPI hardware address.

Actually, indirect addressing gives you even more flexibity. Say:

[..]

Actually I was thinking more of BSET and BTSC instructions. Those only work on register file operands, whereas it seems the underlying architecture has no problem with performing a read-modify-write monotonically in 2 clock cycles (16MIPS=32MHz).
If you want to use a pointer to SPICON, you'll still revert to a load-store kind of structure. Checking for a bit high and then clearing it takes 2 instructions on this architecture, whereas on load-store architectures it can easily take 5-6. But, as I said, it cannot support indirect addressing, so better no use OOP code structures.

But probably for high reliability code, people are not really interested in using that anyway. They don't want a null pointer dereference to screw up a 1kW BLDC motor

edit: @NorthGuy: not going to break up the thread any further, but you're right. Doh! I don't know where my mind was when thinking about this.

[NorthGuy]

Actually I was thinking more of BSET and BTSC instructions.

These can be done indirectly too, a la

Code: [Select]

bset [w3++],#6 // sets the 6-th bit in the word pointed to by w3 and then increments w3
btst [w4],#3 // tests the 3-rd bit in the word pointed to by w4

Can even address single bits indirectly:

Code: [Select]

btst [w4],w5 // tests the bit in the word pointed to by w4, the number of the bit is in w5

You can also test and set bits in memory with a single instruction (but not indirectly):

Code: [Select]

btsts SOMETHIG,#4 // test bit #4 in memory and then set it to 1


[glenenglish]

-----
Northguy, yes I agree  dispic33 16b - they were genuine real DSPs. They were an excellent option to large pin count SHARC- really they were the ONLY option.  Fantastic instruction set.  Most of my world up to 2005 was SHARC. and often a 21065 was way way too much of a overkill. Not to mention the dspic was loaded with useful peripherals (sharc not)
I had some early experience with early PI32MX etc and vowed never to touch them again.

M7 and cache. yes beware. direct calculation or say  approximation can be faster than a LUT (in case of cache miss....)
I agree, they're not DSPs, but if you need general purpose grunt and a bit of DSP, I think they are excellent.

What are people using now when they need a true DSP?
TI came out with a range of DSCs but they were not true DSP (zeor overhead looping, circular buffer, simultaneous dual operand fetch).
The dual operand fetch per cycle is a problem for most microprocessor architectures.
M4 can't do this, but M7 can do this, and, relies on unrolling loops and the pipeline pickign it up early

[glenenglish]

I was thinking a bit more and read the datasheet again on the old dspic33.

What I remember now- these DSPs like their ancestors (TMS320, 56k, 21xx) , were easy to write good hand coded optimized assembler.
-WYSIWIG. What you wrote in ASM was how to executed.

With the M7 etc, the multiple execution units and pipelines - this requires in depth knowledge of the how many instruction you can have in the air, and data hazards and pipeline stalls.

I spend alot more time optimizing M7 code for DSP because I need to have the machine in my head. But clock for clock it does as well as a true DSP for most ops  (but more code- since loops need unrolling in some cases)

M4 cannot do dual load store, but  M7 can do dual load/store + ALU ops per clock.
so M7 is much more like a DSP. Of course the dsPIC doesnt have cache side effects,

[jnk0le]

Code: [Select]

// write 8 bytes from a buffer at w1 to SPI
repeat #7
mov.b [w1++],[w2]

...

// read 8 bytes from the SPI to the buffer at w1
repeat #7
mov.b [w2],[w1++]

Those repeat single instructions are quite usefull and nice (like 1 cycle per FIR tap without need for 2nd data bus on c2000), but they often make uninterruptible sequences, so end up not being used at all because it adds irq jitter/latency.

M4 cannot do dual load store, but  M7 can do dual load/store + ALU ops per clock.
so M7 is much more like a DSP. Of course the dsPIC doesnt have cache side effects,

From my testing, it cannot dual issue load/store double with anything, though The FPU is bad enough to benefit from such scheduling.
https://github.com/jnk0le/random/tree/master/pipeline%20cycle%20test#cortex-m7

[NorthGuy]

Code: [Select]

// write 8 bytes from a buffer at w1 to SPI
repeat #7
mov.b [w1++],[w2]

...

// read 8 bytes from the SPI to the buffer at w1
repeat #7
mov.b [w2],[w1++]

Those repeat single instructions are quite usefull and nice (like 1 cycle per FIR tap without need for 2nd data bus on c2000), but they often make uninterruptible sequences, so end up not being used at all because it adds irq jitter/latency.

This is not true. They're all intrruptible. Nothing can change the interrupt latency (aside of disabling interrupts on purpose). Moreover, there are several IRQ levels, and lower priority interrupts, no matter at what stage of processing they are, do not affect the latency of higher priority interrupts.

These chips were created for emdedded work and therefore they're completely deterministic.

[jnk0le]

[...]
Those repeat single instructions are quite usefull and nice (like 1 cycle per FIR tap without need for 2nd data bus on c2000), but they often make uninterruptible sequences, so end up not being used at all because it adds irq jitter/latency.

This is not true. They're all intrruptible. Nothing can change the interrupt latency (aside of disabling interrupts on purpose). Moreover, there are several IRQ levels, and lower priority interrupts, no matter at what stage of processing they are, do not affect the latency of higher priority interrupts.

These chips were created for emdedded work and therefore they're completely deterministic.

dsPIC (16bit one) indeed has a sane design and can be used to full potential without sacrificing irq handling.
Meanwhile other DSP architectures (e.g. 56k or c2000) were not that lucky. (C2000 RPT is not interruptible even by DMA transfers)

[mtwieg]

dsPIC (16bit one) indeed has a sane design and can be used to full potential without sacrificing irq handling.
Meanwhile other DSP architectures (e.g. 56k or c2000) were not that lucky. (C2000 RPT is not interruptible even by DMA transfers)

Can confirm the C2000 RPT instruction can't be interrupted by ISRs. Not sure about DMA. One of my biggest gripes with C2000 is that its DMA is crippled (can't access most peripherals, can't access shared memories between processors, etc) so I actually don't utilize it much.

I always found the RPT instruction strange. Obviously it's faster than looping with a branch, but does it work differently from simply repeating the same opcode n times? If not then it just saves a bit of code size?

[coppice]

dsPIC (16bit one) indeed has a sane design and can be used to full potential without sacrificing irq handling.

The dsPIC design had a lot of merit, but couldn't overcome its great enemy - MicroChip's management.

[NorthGuy]

C2000 RPT is not interruptible even by DMA transfers

dsPIC has problems with DMA too.

Earlier models had dedicated dual-access DMA memory, so DMA and CPU worked independently of each other. Thus, not only CPU was deterministic, but DMA was deterministic as well. However, DMA was not universal and was restricted to specific periphery.

In newer models, DMA is working through the common bus with CPU (where CPU has higher priority), which is common for load-store architectures (such as ARM). But unlike load-store architectures, dsPIC33 CPU can put very high pressure on memory. For example, if you're doing 64-tap FIR filter, you can do it in 64 cycles, but there will be not a single bus cycle left for DMA, so DMA may starve - if you're receiving 20 MHz SPI at the same time, there may be bytes lost. In addition, DMA is built in such a way that you cannot use built-in FIFOs in peripheral modules when they're handled with DMA. You can give higher priority to DMA to fix this, but then the CPU is no longer deterministic. Therefore, if you want CPU to be deterministic, you can only do slow things through DMA. Hopefully, they will fix that in dsPIC33A.

[jnk0le]

I always found the RPT instruction strange. Obviously it's faster than looping with a branch, but does it work differently from simply repeating the same opcode n times? If not then it just saves a bit of code size?

It frees up the program bus so those dual memory operand instructions can recycle that for loading data and execute 1 per cycle without the need for 2nd data bus.

[LM2023]

There is new documentation about dsPIC33A on microchip's website:
https://www.microchip.com/en-us/search?searchQuery=dsPIC33A&category=ALL&fq=start%3D0%26rows%3D10

There is the "dsPIC33A Programmer's Reference Manual" and also the brief on the dsPIC33AK128MC106 family.

The new core has 16 32-bit working registers and 32 32-bit single precision registers (that can be "paired" as 16 64-bit double precision registers), with also two 72-bit accumulators for fixed point arithmetic dsp instructions.

It is compatible with dsPIC33 "16-bit" instruction set, so if you just need a faster dsPIC33 and keep most of the already developed code it can be done.

About the dsPIC33AK128MC106 family, available in packages with 28/36/48/64 pin,  8/16 KB of ram, 32/64/128 KB of flash memory
Clock frequency up to 200MHz and  AEC-Q100 Rev. G Grade 1 certification (temperature range -40..+125 °C), with Grade 0 (-40 .. +150 °C) and ASIL B/C planned.

[uer166]

Peripheral set is okay, but a bit disappointing: it's still quite a small device. The 40MSPS 2x ADCs are nice, but only for quite niche applications. I'd still prefer say 6x slower ADCs. Overall a STM32G4 still has way more analog integration, timers, and interconnects.

[JPortici]

PTG compensates that, as it is quite flexible, but also really complex.
I'm disappointed by the lack of big packages 

I really hoped for a really big do-it-all like the dsPIC33EP MU series

[uer166]

PTG compensates that, as it is quite flexible, but also really complex.

How so? I can run 6 half-bridges with an HRTIM on a G4 with another half dozen PWMs on other timers available, but it's not clear to me how same cane be achieved here.

[JPortici]

PTG compensates that, as it is quite flexible, but also really complex.

How so? I can run 6 half-bridges with an HRTIM on a G4 with another half dozen PWMs on other timers available, but it's not clear to me how same cane be achieved here.

My remark on PTG was about the interconnects! If there are not enough PWM there are not enough PWM, period.

see my remark about a BIG do-it-all. dsPIC33MU has 3 HSPWM, 16 output compare/pwm, 16 input capture. plus many timers, uart, etc... and freaking USB. I don't understand why microchip doesn't put usb on dsPIC anymore. I have to use 24MHz PIC24 (which is usually plenty, but not when i have 6-8 SENT to interface to, plus all the rest for analog IO)
This first part is plainly disappointing for me.. but for its intended application is probably the cake: microchip's peripherals, a fast low latency core... i guess four wheeled robot or industrial computer or something like that? They went all in to put specialized encored interface..

[glenenglish]

I like it   !  great size mul and saturating accumulator.

and it also has some FP capability for when you really need to do a little FP and dont want it costing 200 cycles each op.

The dual 40 MHz ADCs looks good, I can see some ham radio opportunities there.
Cant find any AC specifications, like full power BW and ENOB ?

(vaguely excited)

[jnk0le]

No dual MAC, for q15, seems to be a bit weird decision in 32bit DSP.

[PCB.Wiz]

There are part codes for larger parts DSPIC33AK512MP, that may have more features ?

It's not bad - 1.25ns PWM granularity and 1.6GHz PLLs and good FIFOs on the comms channels.

[NorthGuy]

The periphery seems roughly the same as with dsPIC33C, except for 40 Msps ADCs (the fasterst they had in dsPIC33C was 3.5 Msps, but it had multiple independent sampling cores). They don't have any specifics yet, so it's hard to tell.

Aside of FP stuff, the ISA seems to be a carbon copy of dsPIC33C with instructions extended to 32-bit which removes lots of limitations. There are also many 16-bit instructions which I think can be freely intermixed with 32-bit ones as in Thumb2 or microMIPS.

[NorthGuy]

Or may be 16-bit instructions must be paired to maintain 32-bit alignment. The docs are not clear about this.