Author Topic: DL1608 Architecture Notes  (Read 7058 times)

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
DL1608 Architecture Notes
« on: January 12, 2014, 11:03:37 PM »
A  word about the DL's architecture and possible improvements that would appear to be possible considering the components before I forget all this. I'll try not to be too techie but some can't be helped.
The diagram on pg. 162 of the manual is really just an old analog interpretation of the software that runs the DL. The only actual hardware shown on the diagram are the preamps in the lower left corner (16 channels worth). The others are the 10 output drivers on the top of the page (L/R , phones (stereo), aux's (1-6). The one D/A converter on the main board (more on the analog section) handles 2 out of 10 outputs and the two CS5368  handle the 16 inputs. All the rest of the block diagram is software logic to create the data flow. Since I didn't take the analog section appart I have no way of knowing what D/A are used for the rest but most likely it's the same part.  These are all 216 kHz parts quite capable of a 192 kHz audio stream.
Let's start with the A/D converters Cirrus Logic CS5368. A 8 channel A/D converter capable of 216 kHz of audio data per channel and there are two of them so the DL can process 16 channels of up to at least 192 kHz of 24 bit data with these chips. It's currently doing 48 kHz. There may be speed-bumps down the road to prevent this but we'll see.
 Since there are no software VC on the preamps a true DCA can not be obtained but a software implemented one can take the values off the A/D converters and based on DCA groups change the values to simulate a DCA. Time for digitally controlled Onyx pre's.
 Next stop the processing (Polarity, HPF, Gate, Compressor, EQ) computations are handled by the Sharc DSP from Analog Devices ADSP21488 a 400 MHz part. The bulk of the routines are most likely AD canned routines for this part. There is no reason why the processing order can't be changed or made more flexible.
 All the data flow is handled by the Blackfin ADSP BF516 ARM Processor the control and heart of the DL it is also a 400 MHz part. The Sharc is more of a coprocessor doing number crunching. The two are in fact purposely designed to play these rolls. Running them is most likely the ucosII or III operating system from Micrium . I can't imagine Mackie taking anything but the easy way out. Lets look at the possible speed bumps.
The Sharc and number cruncher has a tremendous processing capability with i/o that has yet to be used by the current DL code. It's a dual core DSP processor with no less than 65 DMA controllers, 28 Serial interfaces of various types, a 10/100 Ethernet controller (why Mackie included a separate controller SMCA 8710A for this remains a mystery) , MMC, SD and ATA disk controller, FFT, FIR and IIR accelerators. Hardware support for up to 32 ring buffers and stack support as well. Did I forget to mention that it can handle 32 bit floating point, extended 40 bit FP and fixed point 32 bit math and VISA and has support for S/PDIF and PCM. Some of these clearly can't be use by the existing hardware implementation. I don't see a SD slot or any other peripheral connections to take advantage of this or a S/PDIF connector. RTA's certainly a implementable function as is the well debated recording capability. Sending 16 channels of already existing data to the iPad over the pseudo USB via a DMA channel won't stress anything. So is the Sharc at it's limits? Not according to the European Loud GM a former techie who stated that the system is at about 25% of capacity. He has access to way more info than I have.
 Lets move on to the Blackfin. The heart of the DL and the main traffic cop. It handles allocation of resources, communications with the iPad, network and directs the data streams. Doesn't sound like much but its well equipped to handle the tasks. Is it at it's limits? Hardly. So what is keeping this hardware from providing all that it can give? Mackie marketing or code? You decide.

Update: Turns out that my first guess on the OS was right and the DL is run by uClinux. The cost of ucos must have been too much for Mackie.
« Last Edit: June 03, 2014, 02:59:01 PM by WK154 »
When in doubt KISS

RoadRanger

  • SysGod
  • Counselor
  • Master
  • *****
  • Location: NE CT USA
  • Posts: 1781
  • "Wherever you go, There you are"
    • Cacophony Forums
Re: DL1608 Architecture Notes
« Reply #1 on: January 12, 2014, 11:26:45 PM »
All the data flow is handled by the Blackfin ADSP BF516 ARM Processor the control and heart of the DL it is also a 400 MHz part. The Sharc is more of a coprocessor doing number crunching. The two are in fact purposely designed to play these rolls. Running them is most likely the ucosII or III operating system from Micrium.
Kinda funny, the product I'm working on at the moment has a 50MHz ARM M0 clocked at 8 MHz, that's plenty for it as the 6 channels of A/D are only being sampled at 100Hz and the DSP is just 6 or 12 dB/oct LP. It runs in "standby looking for an 'on' keypress" mode at 32 KHz on a few microamps, I think the battery pack is good for three months in standby. I also remember when uCos came out as a free OS published in "Embedded Systems" magazine if I remember correctly. My OS's are loosely based on it although I always skip the pre-emption stuff for efficiency.
« Last Edit: January 13, 2014, 12:36:36 AM by RoadRanger »

RoadRanger

  • SysGod
  • Counselor
  • Master
  • *****
  • Location: NE CT USA
  • Posts: 1781
  • "Wherever you go, There you are"
    • Cacophony Forums
Re: DL1608 Architecture Notes
« Reply #2 on: January 12, 2014, 11:34:15 PM »
[...] Sharc DSP from Analog Devices ADSP21488 a 400 MHz part. The bulk of the routines are most likely AD canned routines for this part. There is no reason why the processing order can't be changed or made more flexible.
I suspect they either don't have an on-staff DSP guy or that he's busy with other products - they have made some suspect statements in the past like the inability to do multitrack with this hardware or that it would be hard to split up the DSP functional blocks. Child's play to any competent DSP guy. As you know any "off the street" programmer can do ARM and iPAD stuff but there is a shortage of DSP guys and they are expensive. They should hire me (or you?) and as a bonus get us to shut up LOL .
« Last Edit: January 12, 2014, 11:36:41 PM by RoadRanger »

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: DL1608 Architecture Notes
« Reply #3 on: January 13, 2014, 12:22:28 AM »
RR I doubt they could afford either of us and I for one would turn the place upside down. >:D
When in doubt KISS

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: DL1608 Architecture Notes
« Reply #4 on: January 13, 2014, 08:39:01 AM »
Just as an aside the X32 uses a prior generation Sharc running at 266 MHz two of them. You do have 40 inputs to process instead of 16. It also doesn't have an Ethernet controller and  can do all kinds of processing as demonstrated. The reason for the separate Ethernet  controller on the DL may have been for just the same reason that the new generation Sharc may not have been available when Mackie started but then they switched to the newer part as it became available and did not design out the separate controller. P.S. I'm surprised your 50 MHz ARM runs down at 8 Mhz without problems, a static design?
When in doubt KISS

RoadRanger

  • SysGod
  • Counselor
  • Master
  • *****
  • Location: NE CT USA
  • Posts: 1781
  • "Wherever you go, There you are"
    • Cacophony Forums
Re: DL1608 Architecture Notes
« Reply #5 on: January 13, 2014, 09:02:16 PM »
I'm surprised your 50 MHz ARM runs down at 8 Mhz without problems, a static design?
Maybe I was unclear that I'm running code at 32KHz when it is "off" so 8MHz is no prob. It's a Nuvoton M0 .

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: DL1608 Architecture Notes
« Reply #6 on: January 13, 2014, 11:09:36 PM »
I'm surprised your 50 MHz ARM runs down at 8 Mhz without problems, a static design?
Maybe I was unclear that I'm running code at 32KHz when it is "off" so 8MHz is no prob. It's a Nuvoton M0 .
Got it I looked at the NUC501. Boy what we could have done with that in my days. Cute little thing with lots of power saving stuff. Like the ASS and IRS registers. >:D
When in doubt KISS

RoadRanger

  • SysGod
  • Counselor
  • Master
  • *****
  • Location: NE CT USA
  • Posts: 1781
  • "Wherever you go, There you are"
    • Cacophony Forums
Re: DL1608 Architecture Notes
« Reply #7 on: January 13, 2014, 11:26:19 PM »
Got it I looked at the NUC501. Boy what we could have done with that in my days. Cute little thing with lots of power saving stuff. Like the ASS and IRS registers. >:D
Beats the hell out of an 8748 that didn't even have a subtraction instruction if I remember correctly x( . The NUC doesn't have hardware divide but one can multiply and shift to simulate that close enough with all them bits available ;D .

Three programmer's one-upmanship:

"I had to program in Assembler back in my days"
"Assembler? I had to use Zeros and Ones back in my days"
"Ones? You had Ones? We didn't have Ones back in my days"

 ;D

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: DL1608 Architecture Notes
« Reply #8 on: January 14, 2014, 12:30:39 AM »
You got it easy 32 bits. I used to have to complement and add 8 bits at a time on a POS not the DL a Point Of Sales register. Boot code yeah we toggled that in on a front panel. Back in College I ran a AIDS station that's Assistance In Debugging Station as a ACM VP. Boy you got to watch those acronyms. :)
« Last Edit: January 14, 2014, 12:36:50 AM by WK154 »
When in doubt KISS

RoadRanger

  • SysGod
  • Counselor
  • Master
  • *****
  • Location: NE CT USA
  • Posts: 1781
  • "Wherever you go, There you are"
    • Cacophony Forums
Re: DL1608 Architecture Notes
« Reply #9 on: January 14, 2014, 12:48:23 AM »
You got it easy 32 bits. I used to have to complement and add 8 bits at a time on a POS not the DL a Point Of Sales register.
That's what I was just saying about the 8748 (8048 w/eprom) that I used in a few products.

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: DL1608 Architecture Notes
« Reply #10 on: January 14, 2014, 12:55:09 AM »
I skipped that one and went from the 8008 to the LSI-11 (DEC) and 6800 but I get it. :thu:
« Last Edit: January 14, 2014, 12:57:05 AM by WK154 »
When in doubt KISS

RoadRanger

  • SysGod
  • Counselor
  • Master
  • *****
  • Location: NE CT USA
  • Posts: 1781
  • "Wherever you go, There you are"
    • Cacophony Forums
Re: DL1608 Architecture Notes
« Reply #11 on: January 14, 2014, 01:07:40 AM »
I skipped that one and went from the 8008 to the LSI-11 (DEC) and 6800 but I get it. :thu:
Oh yah, did a lot with those LSI-11, mostly data acquisition. Did up a little boot ROM that let them load programs from the "big" PDP-11 (w/ a couple big arse 5 MB disk drives?) we had via their current loop serial ports and send the data back the same way. Those "balanced" current loops worked OK for 1000 feet or more over telephone pairs!

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: DL1608 Architecture Notes
« Reply #12 on: January 14, 2014, 02:45:09 AM »
Yep I'll never forget those current loops the cause of one of my trips to Oak Ridge National Labs in the heart of Tennessee. Siemens had sold a SRS1(X-ray Florescence Spectrometer)  and one of my Logic controllers to them so I got a call from one of their bright Engineer saying that it wasn't working. The computer was 4000 ft from the equipment and it wouldn't communicate and he used the best cable. Well that trip I'll never forget. From Newark to Atlanta and off to Oak Ridge on a Goonie bird (DC3 for those to young). Yup we had a stewardess and no doors, metal bucket seats but seat belts. The pilot announced that he was going to make a few stops on the way and if nothing else drop off some mail. Well needless to say we took a few passes at some of the runway's but the fog was a little thick and hanging in the treetops. Mailbag bombs away. We missed a few stops but did get to the destination. Coffee, Tea and help me but a nice view of the tree tops. The boring part was that the Engineer used shielded twisted pair so nothing would interfere with the signal. We couldn't see the equipment (probably a little hot, Plutonium anyone) but unshielded did the trick along with the uneventful trip back to Atlanta.
When in doubt KISS