Project Target Migration

Overview link

SCI-Compiler provides a Hardware Migration Tool that enables users to convert projects from one target board to another. This tool preserves the design logic while adapting board-specific configurations, I/O mappings, and IP blocks to the new target platform.

The migration tool is accessible through the Home toolbar in the Project group, via the Migrate Hardware button.

Migration Compatibility Matrix link

The following table shows migration compatibility between different board families. Three levels of compatibility are indicated:

Compatibility Table link

Migration Procedure link

Using the Migration Tool link

1. Open the Source Project

   • Open the project you want to migrate in SCI-Compiler

2. Launch Migration Tool

   • Click the Migrate Hardware button in the Project group of the Home toolbar
   • The Hardware Migration Tool dialog will appear

3. Configure Migration Settings

   • Source Project: Automatically filled with the current project path
   • Destination Folder: Select the destination folder for the migrated project
   • Project Name: Enter a name for the migrated project
   • Target Hardware: Select the target board from the dropdown menu

4. Execute Migration

   • Click the Convert button
   • SCI-Compiler will create a new project with adapted configurations

5. Review and Validate

   • Open the migrated project
   • Review all component configurations
   • Check I/O mappings and pin assignments
   • Verify memory-mapped component addresses
   • Test compilation

Platform-Specific Considerations link

Analog Input Channels link

When migrating between boards with different analog capabilities:

• DT1260/R5560/DT5560 → DT5550: The DT5550 family has 4 analog input channels compared to 8 channels on DT1260/R5560/DT5560. Projects using channels 4-7 require redesign or channel reassignment.

• Review Required: Check all AFE (Analog Front End) component configurations and update channel mappings accordingly.

Digital I/O Differences link

• DT1260/R5560/R5560SE/DT5560: Use LEMO connectors for digital I/O
• DT5550/DT5550CIT: Use MCX connectors for digital I/O
• DT5560PET: Has PET-specific I/O configuration

When migrating between these families, verify that:

• Connector types match your cabling requirements
• Signal levels are compatible
• Timing constraints are maintained

FPGA and Vendor Differences link

Critical considerations when migrating between different FPGA vendors:

Xilinx to Intel (or vice versa) link

• IP Block Compatibility: Xilinx-specific IP blocks (e.g., Xilinx Clock Wizard, Xilinx Block RAM) cannot be directly migrated to Intel (Altera) platforms

• V2495 (Intel Cyclone V): Requires replacement of all Xilinx IP with Intel equivalents

• Required Actions:

  1. Remove all vendor-specific IP blocks from the design
  2. Replace with equivalent IP from the target vendor’s library
  3. Reconfigure clocking resources (PLLs, clock managers)
  4. Update memory blocks (Block RAM → M10K/M20K)
  5. Verify timing constraints in the new toolchain

X274X to Other Platforms link

The Caen X274X family has unique architectural differences that make migration challenging:

• Limited Component Support: Many standard SCI-Compiler components may not be available or may require significant modifications

• Custom IP Requirements: X274X-specific IP blocks need complete replacement

• Recommended Approach: Consider the migration as a redesign rather than a direct conversion. Use the original project as a reference and rebuild the logic for the target platform.

Post-Migration Checklist link

After completing a hardware migration, perform these validation steps:

1. Component Review link

• Verify all components are supported on the target platform
• Check that component parameters are within valid ranges
• Confirm memory-mapped components have valid address assignments
• Review RegisterFile.json for address conflicts

2. I/O Configuration link

• Validate pin assignments in Board Configuration
• Check signal directions (input/output)
• Verify unused pins are properly terminated
• Confirm connector types match physical hardware

3. Clock and Timing link

• Review clock domain configurations
• Check PLL/clock manager settings
• Verify timing constraints are met
• Confirm sample rates are achievable on new hardware

4. Memory and Addressing link

• Check MMC address space allocation
• Verify endpoint configurations
• Confirm no address overlaps
• Test register read/write operations

5. Compilation and Testing link

• Perform full firmware compilation
• Review synthesis reports for warnings
• Check resource utilization
• Program FPGA and validate functionality
• Test all I/O channels
• Verify SciSDK communication

Migration Best Practices link

Before Migration link

1. Backup Original Project: Always keep a copy of the original working project

2. Document Custom Configurations: Note any special settings, custom IP, or unique design elements

3. Check Compatibility: Review the compatibility matrix before starting

4. Plan for IP Replacement: Identify vendor-specific IP that will need replacement

During Migration link

1. Use Descriptive Names: Give the migrated project a clear, descriptive name indicating the target platform

2. Incremental Validation: Test components individually after migration rather than waiting until the end

3. Document Changes: Keep notes on what required manual adjustment

After Migration link

1. Functional Testing: Test all features that worked in the original design

2. Performance Validation: Verify that timing and performance metrics are maintained

3. Update Documentation: Update project documentation to reflect the new target platform

Troubleshooting Migration Issues link

Compilation Errors After Migration link

Symptom: Project compiles on original platform but fails on new platform

Possible Causes:

• Vendor-specific IP blocks not replaced
• Resource utilization exceeds target FPGA capacity
• Timing constraints not met on new platform

Solutions:

1. Check compilation log for specific errors
2. Replace any vendor-specific IP
3. Review and adjust timing constraints
4. Consider reducing clock frequencies if timing closure fails

Address Conflicts link

Symptom: RegisterFile shows overlapping address ranges

Possible Causes:

• Different memory map organization on target platform
• New platform has different base addresses

Solutions:

1. Open RegisterFile.json
2. Review all MMC addresses
3. Manually reassign conflicting addresses
4. Recompile and verify

Missing I/O Pins link

Symptom: Board configuration shows missing or unavailable pins

Possible Causes:

• Target board has different I/O configuration
• Pin count mismatch between platforms

Solutions:

1. Review target board pinout in Board Configuration
2. Reassign signals to available pins
3. Update cable connections to match new pinout

Related Documentation link

• Board Configuration - Configure I/O pins and connections
• Memory Mapped Components - Understanding address mapping
• Firmware Compilation - Compiling for different platforms
• FPGA Programming - Programming different target boards

Related Documents link

• Memory Mapped Components
• Firmware Compilation
• Fpga Programming