dsPIC33A: new 32bit DSP!

[marcov]

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.

And 2 cycle branch, like the dspic33c MP slave processor. So they must have sped up flash tremendously beyond the older (dspic,pic32mk) parts at 40MHz (2x 20MHz?) to obtain a single cycle 200MHz processor.

There are also bad things, only 64k mem in the initial parts, and dspicC style timers are a bit a of a let down. I would have preferred E style timers + OCs.  If you use OCs a lot, you run out of timers quickly on the C (or at least I did in my first experiments). Even if you can use two 16-bit timers per peripheral running of the REFCLK to increase range.

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

DsPIC 16-bit instructions are 24-bit wide.

[NorthGuy]

There are also bad things, only 64k mem in the initial parts, and dspicC style timers are a bit a of a let down. I would have preferred E style timers + OCs.  If you use OCs a lot, you run out of timers quickly on the C (or at least I did in my first experiments). Even if you can use two 16-bit timers per peripheral running of the REFCLK to increase range.

I like CCP timers better, but there must be lots of them. Most PIC32M have 8 of them or more, but only four here

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

DsPIC 16-bit instructions are 24-bit wide.

No. Older dsPIC33 used to have 24-bit wide instructions. dsPIC33A has 32-bit wide instructions. But they also have short 16-bit wide instructions, which I think must be paired - that is you can fit two instructions in a single 32-bit wide slot. But it doesn't look like they execute simultaneously. The docs have very little info on that.

[marcov]

I like CCP timers better, but there must be lots of them. Most PIC32M have 8 of them or more, but only four here

Even 8 of them are only 16 16-bit timers.

The dspic33e MU 8xx series has 9 16-bit timers and 16 16-bit OC for a  total 25 16-bit timers.

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

DsPIC 16-bit instructions are 24-bit wide.

No. Older dsPIC33 used to have 24-bit wide instructions. dsPIC33A has 32-bit wide instructions. But they also have short 16-bit wide instructions, which I think must be paired - that is you can fit two instructions in a single 32-bit wide slot. But it doesn't look like they execute simultaneously. The docs have very little info on that.

I assumed that to remain the same because I took the compatibility with 16-bit in the family sheet as binary compatibility and to imply that 24-bit width would stay.   A shorter 16-bit instruction set would not be compatible, as it wouldn't be able to use 16-bit operands, requiring it to subdivide into multiple instructions.

Anyway I only saw the summary family sheet, and the chinese datasheet for the smaller controller type.

[NorthGuy]

I assumed that to remain the same because I took the compatibility with 16-bit in the family sheet as binary compatibility and to imply that 24-bit width would stay.   A shorter 16-bit instruction set would not be compatible, as it wouldn't be able to use 16-bit operands, requiring it to subdivide.

I think they meant it to be compatible at the assembler level. They have the same assembler mneumonics which, by default, operate on 16-bit operands. For 32-bit operands you need to add .L (that is ADD.L instead of ADD), so in theory, anything written in assembler should work without modifications. There's no binary compatibility though.

[marcov]

I think they meant it to be compatible at the assembler level. They have the same assembler mneumonics which, by default, operate on 16-bit operands. For 32-bit operands you need to add .L (that is ADD.L instead of ADD), so in theory, anything written in assembler should work without modifications. There's no binary compatibility though.

See my previous post. You can't put a 16-bit immediate value (address, register value) into a 16-bit instruction, unless they are macros that code for multiple instructions.

[NorthGuy]

See my previous post. You can't put a 16-bit immediate value (address, register value) into a 16-bit instruction, unless they are macros that code for multiple instructions.

I don't understand your communication. They're 32-bit devices. Instructions are 32-bit long. But some of the instructions are half-width - 16-bit long. Apparently, the instructions using 16-bit literals will be 32-bit long. So what?

[marcov]

See my previous post. You can't put a 16-bit immediate value (address, register value) into a 16-bit instruction, unless they are macros that code for multiple instructions.

I don't understand your communication. They're 32-bit devices. Instructions are 32-bit long. But some of the instructions are half-width - 16-bit long. Apparently, the instructions using 16-bit literals will be 32-bit long. So what?

Probably I was still thinking too much along compatibility lines.   Btw, have you read anything about SFR access penalties?

[NorthGuy]

Btw, have you read anything about SFR access penalties?

No. I tried to find something about SFR, but only found readsfr instruction which is undocumented and may be has nothing to do with SFRs. May be the SFR access is fast, or may be they just omitted this.

Also, I've read about jumps and path prediction. Jump times seem a little bit too good to be true.

[marcov]

Also, I've read about jumps and path prediction. Jump times seem a little bit too good to be true.

Yes, 2 cycles at 200Mhz. But maybe that is the limitation on (prefetch) performance of the core itself only, without the realities of the the attached flash subsystem.  Then it only is the same as dspic33c when running from RAM.

The 120MHz of the pic32mk sounded good at first too :-)

[glenenglish]

ADI SHARC has zero cycle cost branches.....
(and executed the instruction following the branch/ had delay slots) .

But, agreed a very different architecture.  SHARC executed from dual port RAM, and had separate I and D RAM, and dual ported so DMA  and peripheral background transactions didnt hurt it.
Sort of like I guess modern day I and D  L1 cache that was also dual ported.... a mega byte of it

[coppice]

ADI SHARC has zero cycle cost branches.....
(and executed the instruction following the branch/ had delay slots) .

Most serious DSPs have had zero cycle branches.

[rich t]

> The 120MHz of the pic32mk sounded good at first too :-)

If you use the GPK or MCM flavor, it's pretty good -- very few errata bugs.  (The earlier versions were a bit of a minefield.)

It's still MIPS, which is not really designed to be an embedded system -- interrupts are slow, but the full set of shadow registers (one per interrupt level) helps.

microMIPS (16-bit instructions) helps significantly as well -- to the tune of 20% performance improvement.

I have the ADCs running easily to 20 Msps (but I have to throttle back to 18.18 Msps to be able to do concurrent digital capture and waveform generation, as I run out of DMA bandwidth).

I will have to learn about this new part!

PIC32MK/GPK ADC code is here: https://github.com/rtestardi/StickOS2/blob/main/cpustick/scope.c

[JPortici]

Page searcheable, but currently not active

https://www.microchip.com/en-us/product/dsPIC33AK128MC106
https://www.microchip.com/wwwproducts/productds/dsPIC33AK128MC106

I expect it to be up in a few hours

the DFP has some interesting information (many new interrupt types, many new configuration word options)

[LM2023]

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

it's not explictly written in the available documentation, but it seems they are using a decoding strategy a lot like RISC-V (i.e. the first 16bit word fetched contains enough information to know long the complete instruction is).

See in the dsPIC33A programmer's reference manual:

• At "6.1 Instruction Bit Map" they describe how instruction encoding size is deduced by looking up the top 8 bit of the first 16bit word fetched
• In section 4, the condition branch descriptions have no mention of alignment requirements when performing the "just skip next instruction" trick and it is shown how it deduces the next instruction size:
  

  If (condition) then {
          If slit20 = 1 then
                  skip next (16-bit) instruction
          Else if (slit20 = 2 && next_op[31] = 1) then
                  skip next (32-bit) instruction
          Else
                  (PC+4) + 2*slit20 → PC
  }

Putting these two piece of information together, it seems that 32bit-long instruction don't need to be aligned to 4 byte boundaries.

[NorthGuy]

Putting these two piece of information together, it seems that 32bit-long instruction don't need to be aligned to 4 byte boundaries.

Apparently, if you have a mix of 16-bit-long and 32-bit-long instructions you need to be able to detect the size of upcoming instructions. But it tells nothing about 32-bit instruction alignment.

But they do have a NEOP instruction:

"No Operation is performed. This instruction will also consume no execution time. It can be regarded as a means to pad a 16-bit instruction (to use a 32-bit word) when the instruction cannot be paired with another 16-bit instruction (to maintain alignment)".

which hints that the 16-bit instructions might be a need to be paired.

A lot of text in the Reference Manual is copied and pasted from the manual from older 16-bit dsPIC33 manual and thus is plainly wrong. So, it's very hard to draw any conclusions.

[Howardlong]

We played with the MX/MZ extensively during the "RetroBSD" project era (2010-2016 perhaps) and never had any issues afaik. There were some issues with ADC in MZ, but otherwise the chips were rock solid. And only mcus with continuous 128kB/512kB of sram, none of the arms had it..

I have also extensively used the PIC32MX/MZ. The MX was very stable and I had no major issues with either the core or the peripherals. Many of the peripherals didn't have as many features/options as some of the peripherals on NXP and ST Cortex-M parts, but they were easy to understand, solid, and got the job done. The MZ was a disappointment at first with its large list of errata, but they did fix a lot of them in the EF iteration. Did they ever fix the ADC issues? I gave up on the part not long after the EF came out.

Yes, it was the PIC32MZ EC family was complete crap, and the entire family has been NRND for some time now. I wasted about 18 months hanging on for Microchip to fix/workaround the PIC32MZ EC device's USP of high speed simultaneous sampling ADCs. They released a series of hacks that never solved the problem, degrading the ADC performance at every turn. It turned out I was wasting my time, and a product ended up in the trash as a result.

The PIC32MZ EF introduced a couple of years later does have decent high speed simultaneous sampling ADCs, a peripheral since also introduced into the PIC32MK family too... although unlike the PIC32MZ EF family, the PIC32MK family has no USB HS, making the MK useless for continuous high speed data acquisition purposes.

The EF threw in a a single precision FPU too.

If you want simultaneous sampling high speed DAQ over USB HS, ISTBC, but the only single-chip solution I'm aware of that can achieve this is the PIC32MZ EF.

[Howardlong]

This must be close now, EV74H48A dsPIC33A Curiosity evaluation board is showing as shipping on 26 July. I've taken a punt.

https://www.microchipdirect.com/dev-tools/EV74H48A

I can't see any individual chip availability though.

What concerns me is that we had a similar scenario during the infamous PIC32MZ EC family failure, with a preliminary announcement and leaks, followed by long delays, and then... well, it wasn't great.

Perhaps they're waiting for Masters this year.

By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

[uer166]

By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

easy: it is offensive as a noun, not as an adjective:

"noun; a man who has people working for him, especially servants or slaves."
"adjective; having or showing very great skill or proficiency."

[JPortici]

This must be close now, EV74H48A dsPIC33A Curiosity evaluation board is showing as shipping on 26 July. I've taken a punt.

https://www.microchipdirect.com/dev-tools/EV74H48A

I can't see any individual chip availability though.

What concerns me is that we had a similar scenario during the infamous PIC32MZ EC family failure, with a preliminary announcement and leaks, followed by long delays, and then... well, it wasn't great.

Perhaps they're waiting for Masters this year.

By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

well there were talks about 32bit dsPIC happening "soon" in late 2019 so i think they were thoroughly evaluated. same for dsPIC with mid power mosfet driver and they actually happened in the meantime
by the way are you coming to this year's europe masters? thinking aobut going again, it was a blast that year

By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

silly you! that's not the plural of master! that's for masters' degree

[Howardlong]

by the way are you coming to this year's europe masters? thinking aobut going again, it was a blast that year

Nope, I've never been to any of the Masters conferences. Not my thing really, although I am sure you can leverage out a lot more information than I can get out my crystal ball and rudimentary telepathy skills.

Meanwhile I noticed initial release DFPs today for the dsPIC33A.

Before you get excited, the links in the DFP update go nowhere of interest, either a 404 or a generic page of nothing.

[NorthGuy]

that's not the plural of master! that's for masters' degree

I think it mimics Master's golf tournament in Augusta National. Therefore Masters here means Professionals as opposed to Amateurs.

[jnk0le]

By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

Simple. In recent years russia did undergo budget cuts on some of their ideological subversion programs. Therefore you can spot oversights like this.

[coppice]

By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

Simple. In recent years russia did undergo budget cuts on some of their ideological subversion programs. Therefore you can spot oversights like this.

Also, not everyone just rolls over and succumbs to this kind of master baiting.

[Howardlong]

This must be close now, EV74H48A dsPIC33A Curiosity evaluation board is showing as shipping on 26 July. I've taken a punt.

https://www.microchipdirect.com/dev-tools/EV74H48A

Well it arrived today... just don't make the same mistake I did: order one of the MCU DIM modules EV18H47A and/or EV02G02A too, otherwise you have a paperweight, and not a very heavy one either.

Edit: additional part numbers I ordered are EV68M17A and EV67K87A. Not sure how I managed to mess up those part numbers originally.

[NorthGuy]

New document has appeared - a migration guide. It explains few things. Instruction times are definitely subject to instruction bus wait and SFR wait. SFRs have various access time and may run 1:1, 1:2, 1:4 to system clock. The instruction clock is the same as the oscillator (was 2:1). Does it mean that simultaneous read/write in the same instruction will require 2 cycles? 2kb (512 instructions) cache for instruction flash fetches. How fast is it without cache? Can cache be controlled? Can execute from RAM for faster execution. But is it subject to bus contention with data fetches? Overall it looks like predictability was sacrificed for faster CPU clock.

Other than that lots of improvements, practically everywhere.