jhenderson Site Admin
Joined: 07 Mar 2006 Posts: 1178 Location: So. Cal. USA
|
Posted: Wed Mar 29, 2006 9:07 am Post subject: Sbc6713e FAQ |
|
|
Ethernet Port Operation
How is the TCP/IP address to the onboard Ethernet port set?
DHCP-assignment is the default. However, a Windows applet is provided to allow static IP configuration.
Can it be set to a static address or does it need DHCP?
See above.
Is there a Utility or Applet to configure the Ethernet MAC address to an IP address?
The MAC address is a derivative of the board serial number plus Innovative Corps’s assigned MAC base address.
Are there any additional registers that are user configurable through an applet? This would be useful for us to set authentication code and identify Master/Slave numbering.
There are no other dedicated registers. But, I see no reason why you couldn’t store ID information in flash within your own applet, and retreive it in a manner similar to our applet to achive your goals.
Is there any trouble if an Ethernet optical link is established between the Host and DSP through third party transceivers?
This has never been tried, but no problems are anticipated.
When will the 1Gbit Ethernet be available? Does the DM642 processor need to be replaced to achieve this?
There are no plans to migrate the SBC6713 to 1Gb ethernet at this time. A new SBC product is contemplated which would incorporate Gb ethernet, but release is not yet scheduled.
Would this successor product based on a floating-point processor?
No, it will be based on a newly-announced fixed-point device.
How is the communication between the Host PC and DSP is implemented over the Ethernet?
A socket is established to permit transfer of binary data. Two data formats are supported: Messages and Blocks. Messages are small, four-word structures intended to communicate command and control info. Blocks are arbitrarily-large blobs which can contain any sort of information, implicitly agreed-upon by sender and receiver. Often, blocks are preceeded by a message which describes the contents and nature of a subsequently-received data block.
On the DSP side what is the implementation method?
Identical and symmetric to the Host.
Do these Sockets use single or multiple UDP/IP ports? What are they?
They are standard TCP/IP sockets. The Host side library is implemented atop the excellent ACE public domain library. See web for details.
For DSPHost transfers, does the C6713 processor actually place the data on the Ethernet port? Or does it give a data pointer, data length to the DM642 Ethernet processor to transmit the data?
Application programs on the C6713 submit a pointer and length to the supplied ethernet driver. EDMA is used to send this data buffer to the DM642, which in turn sends it to the Host.
I had noticed using EDMA for block copy causes problems to the CPU access to EMIF and to lesser extent Internal memory. This is a problem for AD/DA ISRs that need to be serviced every 10 micro second in some of our applications. Do you have any example that does Host I/O 32KB every 100 mil sec while servicing AD/DA interrupts every 10 or so micro-sec? Have you come across similar problems? If so, how did you remedy it?
CPU activity always assumes highest priority on the C6713. This means that EDMA accesses can be delayed in the context of CPU-initiated EMIF activity. This can be an insurmountable problem if buffering is unavailble at the hardware level within data acquisition applications. However, within servo applications, this behaviour is actually preferred, since EDMA operations are less critical than CPU activities in that context.
Does the Host communication make use of C6713 EDMA? If so, what kind of effect would it have on the interrupts of the C6713 DSP?
The C6713 ethernet driver uses two DSP interrupts. However, one of these is a “hidden” GPIO interrupt, so three standard EINT interrupts remain uncommitted.
How is the Host-DSP communication implemented? Is there some kind of notification to the User applications that the data from Host available to be read?
C6713 applications make a blocking call to the ethernet driver Get() function, typically within a dedicated background thread. Get will return when a message or block is available.
Is there any polling function to check if the data is available to be read before making a blocking call, Get()?
No. But, I’ve never found it necessary. Since multitasking is available, there is no problem performing blocking calls. A call to Get can be aborted, if necessary.
How is the DSP-Host communication implemented? Is there some kind of notification/Windows Message to the User Host applications that the data from DSP available to be read?
PC applications make a blocking call the ethernet driver Recv() method, typically within a dedicated background thread. Recv will return when a message or block is available.
Is there any polling function to check if the data is available to be read before making a blocking call, Recv()?
No, but same comments as above.
The Host<>DSP data transfers vary in length among different UD applications from 1024 KB to 512000 KB, that need to be done in single pass. Is there any limitation that prevents these types of transfers?
No
Is there a Host API call to read data from a specific C6713 SDRAM address range? This is needed for DSP debug information logging.
No. Such a capability would require augmentation of the DM642 application. But this functionality could be added relatively easily.
Ideally, We would like to stream real-time data from each input while controlling at sample rates of 50 KHz or Higher? What would be the limitation to do so, if any?
Obviously, the sophistication of the servo algorithm and the amount of data will ultimately govern the performance of the system. I can’t answer without more information.
ADC & DAC modules
Please give us more specific answers to all the items bellow if we chose SD-Ultra Performance Audio I/O Module that allows HW sample rates from 2K to 96 K Hz sample rates and has 24-bit resolution.
Also, what EXT_INT of C6713 used for the AD/DA modules? Are they McBSP_x_TXorRX?
By default, EINT4 and EINT5 are used. But this is SW programmable.
If so, when two Omnibus modules are used for 8 inputs, will there be two McBSP interrupts?
McBSP interrupts are uncommitted, and still available in conjunction with Omnibus.
The hardware must allow sample rate settings from minimum of 5000 (preferably 1000) Hz to 100000 Hz.
The 5396 ADC minimum sample rate is 2 kHz.
What is the resolution for Sample Rate Clock setting?
.01 Hz via the DDS.
Lower sample rates from 128 Hz to the minimum Hardware sample rate must be supported through software with filtering. The ADC samples must be available at the software rate.
This is achievable in application code.
What are group delays for ADC and DAC each?
34/Fs for the ADC. 27.2/Fs for DAC
Do the DACs have any programmable hardware low pass filters? This may be necessary for sample rates of < 20 KHz.
The SD module has a programmable de-emphasis filter.
The ADC and DAC parts must run at exactly the same clock rates.
This is typical, and preserves a DSP interrupt for other use.
The total number of boards to use sync clock is listed at 16. Is it 16 DSP boards? Or is it 16 Omnibus modules?
16 baseboards or up to 32 modules.
I need 8-12 ADCs per DSP board, but no more than 2 DACs on the Master and no more than 2 DACs on the Slaves.
This configuration could be arranged during production.
There is no provision for synchronizing multiple SD modules on the same or different boards. This may disallow it’s use in your application
What is the noise floor for the ADCs?
Module-dependent. However, typically we achieve performance within 3 to 5dB of A/D manufacturer data sheets
Typically -115dB down, 0dBfs
What is the true dynamic range for ADCs and DACs?
ENOB is module-dependent. But it is ~14 for a 16-bit converter and ~18 for a 24-bit converter.
What are ADC and DAC offsets and DAC THD?
Module-dependent.
I can have these measured again, if other aspects of the design are ok.
Is there a DSP API for block reads from ADCs and writes to DACs through EDMA?
Yes. Streaming drivers are supplied.
FPDP
In our application, the FPDP needs the following desired modifications.
Can the FPDP as is, be used for communication between the boards in Master-Slave configuration?
Communication between a single master and slave is supported. No multi-drop.
Both MasterSlaves and SlavesMaster make use of the 32-bit transfers. Up to 7 (or higher) slaves should be allowed in multi-drop mode using 6 total reserved lines on two FPDP ports. 3 or 4 of the lines to address the slaves 1(001)-7(111) and 0 means no slave is to be active. Is there any problem electrically to do so in the current hardware design?
Not supported in current firmware.
If the firmware upgraded to support this functionality, what kind of electrical problems you would foresee? Specifically when all the Slaves have to use their TX port, connected to a Master’s RX port (although only one slave at a time can transfer the data)?
I recommend another approach. In that scheme, the FPDP wires are reassigned to implement indepenent 8-bit busses for transmission and reception between the master and each slave. This avoids the problems of multi-drop and provides sufficient, low-latency bandwidth for your application.
Master-Slaves port/connector should be in multi-drop broadcast mode. The reserved lines on this connector should be used for addressing the slaves for Slave-Master transfers.
Not supported in current firmware.
Can the firmware easily be upgraded to support this? Does the board need physical modifications too?
Field-reprogrammable logic changes only, for above scheme.
Slaves-Master port/connector should be in multi-drop mode. The Master software does the arbitration which slave can send the data to the Master. The Slaves-Master connector should one of the 3 reserved lines for software handshake that a slave is currently sending the data to the Master.
Not supported in current firmware
Can the firmware easily be upgraded to support this? Does the board need physical modifications too?
Field-reprogrammable logic changes only, for above scheme.
What is the current physical depth on the receive FIFOs of the FPDP? 8K deep & 32-bit wide is desirable.
256 words
Is there a register to indicate the FIFO data depth?
Not supported in current firmware
Can the firmware easily be upgraded to support this? Does the board need physical modifications too?
Field-reprogrammable logic changes only required.
Processor
The DSP programs OUT files need to be loaded on the fly.
Is there an API call to connect to a board and load an OUT file?
Yes
Is there any safeguard to prevent a board being taken over by a PC while the board is in use by a different PC? Any safeguard to two different applications on the same Host competing to take control of the same board?
No. Application responsibility.
Typically only one application program should be able to Open/ Close/ Download Program at a time. But other Applications and PCs on a Network should be able to communicate for additional Data transfers.
No such restriction in current libraries.
Is there some kind of notification on the Host as well as on the DSP when the Ethernet link is broken or disconnected?
No
Is there a DSP API to make use of RS232 port? Example operations: Open, Close, Configure the port and send/receive data. How is the ‘Data available to be read’ notified to the user program (Is there is HWI or SWI)?
Interrupt-driven C6713 driver provided.
Which EXTINT of the C6713 is used?
EINT7, by default, but programmable in SW.
The current processor clock speed is at 300 MHz for the C6713. Does the hardware have a provision to support faster C6713 processors when they are available?
EMIF utilizes dedicated 75 MHz clock. CPU clock speed can be increased independently without ill-effect.
External SDRAM/FLASH
We need more SDRAM. The size must be 128 MB instead of 32 MB. Does the current hardware require any modifications to do this?
Not supported in current PCB layout. This can readily be modified on a custom basis.
The 300 MHz, C6713 processor has 3.3 ns internal cycle time. The EMIF is listed at 75 MHz and 13.3 ns. What are actual SDRAM Write & Read times for the C6713 CPU?
EDMA and CPU can perform zero-wait-state block reads and writes at EMIF clock rate. Random I/O is somewhat slower, but cache is very effective.
How is 2 MB FLASH used?
Partitioned to contain logic images, DM642 code and up to 1 MB for user application
What are the Read & Write times for the FLASH? How much of the FLASH is available for DSP end-user applications?
14 uS/write. 1 MB
What is the starting address on C6713 memory map?
0x80000000.
Is the 16 MB SDRAM shared between C6713 and DM642? Is this memory mapped on CE1 while the 32 MB SDRAM mapped on CE0 of C6713?
DM642 has it’s own 32 MB RAM.
What is done to the C6713’s 2 McBSPs & 2 McASPs (audio serial ports) in the hardware? Are they brought out as headers?
The ‘C6713’s on-chip serial ports (McBSP) are pinned out to connectors JP15 (port 0) and JP13 (port 1) for use with external hardware. The serial ports are also connected to the OMNIBUS sites for use with modules. Omnibus module 0 has McBSP port 0 and module 1 has McBSP port 1.
What is done to McASPs?
Sorry, should have typed McASPs above.
Is there a hardware register to indicate the clock speed of the C6713? Or is it always presumed to be 300 MHz?
The CPU speed may be determined using a SW function.
Is there DSP API for onboard external Timers/Counters? How many pins are brought out of the board, if any?
API functions provide complete control over all internal and external timers. All timer I/O appear on connectors.
C6713 Internal Memory
Does the Innovative DSP Library take away any internal memory?
Applications control the use of memory. Best performance is achieved through dedication of 64KB for cache, rest for code/data.
We'd like to use of this memory fully for 64 KB L2 cache and 128 KB for program/data. Is the 4-way L2 cache configured in CDB file or reconfigured during the run time due to Interrupt Vector table?
Configured via CDB
Does the DSP API need any reserved SDRAM memory for special internal operations? Or is it completely available for user programs? If used by the DSP API, does part of the SDRAM need to be non-cacheable?
Typical DSP programs with full library support consume ~400KB of memory. Any code org’d to SDRAM should be cached for best performance. All other RAM is uncommitted
Is there DSP API for the 32-bit digital I/O? Can these lines be configured IN/OUT in combination?
API is provided. Direction-programmable in banks of 8-bits.
What was the release date of SBC6713e? How many clients are using it? Any references?
Released to production ten months ago. Approximately fourty users presently. Contact Mike Goldin mgoldin@ucsd.edu. [/i]
ADC & DAC modules
We want “same” clock for all A/D and D/A conversions; not just set at same Fs. I guess that you have some thoughts about how to achieve this. This is vital to us. Also , we would like 1K – 100K sampling rate range.
There is no provision for synchronizing multiple SD modules on the same or different boards. This may disallow it’s use in your application
Here are a couple of possibilities.
Our AD16 input only-module supports sixteen, 16-bit A/Ds, all of which may be externally synchronized. This could be combined with some SAR D/A module, such as an A4D4 or A16D2 which support non-overclocked software or timer conversion. This requires no NRE, but is more expensive.
Alternately, we could engineer a custom, 24-bit module which features modern A/Ds and D/As and an external sync. This will be lowest cost, but requires more NRE expense.
Another alternative is to populate the module sites with two A4D4 modules, each board supporting eight SAR analog I/O. Synchronization is not a problem, since the module is not overclocked. This will be more expensive and has lower channel count, but no NRE is required.
We can discuss other variations also.
The FPDP needs the following desired modifications: Can the FPDP as is, be used for communication between the boards in Master/Slave configuration?
Communication between a single master and slave is supported. No multi-drop.
What is Min overhead time delay using FPDP Bd to Bd ?
Words can be sent into the FIFO at max Omnibus rate of approx 6 MHz ~= 0.16uS/word. This rate could be sustained on the default 32-bit FPDP bus. If we adopt my proposed 8-bit star bus, we’d need to clock the bus at >= 24 Mhz to sustain this rate. Should be no problem.
What about changes in this fifo size?
Logic could support larger FIFOs, up to 1k if necessary. In my proposed scheme, numerous smaller FIFOs would be implemented on each end of the star network between all boards in the system.
External SDRAM/FLASH: .The size must be 128 MB instead of 32 MB. Does the current hardware require any modifications to do this?
Not supported in current PCB layout.
Our M6713 product already supports 128 MB SDRAM. We could readily change the SBC6713e to accommodate for you. Similarly with EEPROM, larger sizes are available. If we enter an OEM agreement with you, we would not charge NRE for these changes, since they could be made backward compatible with existing design. |
|