Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20773 Discussions

Bus LVDS on Arria 10 with Hardware Deserialiser

TomCarpenter
Novice
763 Views

I'm trying to implement Bus-LVDS to communicate between a Cyclone IV and an Arria 10 device. For the Cyclone IV, I use the altlvds cores which are software serialisers, so no issue there.

For the Arria 10 device, there is no software SERDES IP available from Intel. Because the differential IO buffers don't support output enables, I've had to implement a software serialiser for transmit, using a combination of a DDIO block, and an Psuedo-Differential transmit buffer, with SSTL1.8V II as the IO standard.

For receive I would like to use the hardware DPA derialiser block to improve the receive timing margins. For this I am using an instance of the altera_lvds core. When the receive LVDS core is used alone, everything works fine. However if I try and connect the same pad to the Psuedo-Diff transmitter, Quartus will get part way through the fitting stage and then pop up with a window saying "Quartus Crashed" with the following message:

 

Problem Details
Error:
Internal Error: Sub-system: U2B2_CDB, File: /quartus/db/u2b2/u2b2_nf_io48tile_config_creator_module.cpp, Line: 10552
An io_lvdsio_buf_x2 cannot connect an to IO_SERDES_DPA if it connects to an additional primitives
Processors in use: 2
Stack Trace:
0x12ca01: U2B2_NF_IO48TILE_CONFIG_CREATOR_MODULE::populate_iobuf_children_hierarchy + 0xfd1 (db_u2b2_cdb)
0x12af50: U2B2_NF_IO48TILE_CONFIG_CREATOR_MODULE::populate_config + 0x7c0 (db_u2b2_cdb)
0xdeae4: u2b2_populate_config_fn + 0x174 (db_u2b2_core)
0x4076: PUT_SPMD_JOB_VOID_PTR_IMPL::thread_loop + 0x146 (ccl_put)
0x3f16: PUT_SPMD_JOB_VOID_PTR_IMPL::thread_fn + 0x46 (ccl_put)
0x1484e: msg_thread_wrapper + 0x6e (CCL_MSG)
0x18210: mem_thread_wrapper + 0x70 (ccl_mem)
0x2854: thr_thread_begin + 0xa4 (ccl_thr)
0x17343: BaseThreadInitThunk + 0x13 (KERNEL32)
0x526b0: RtlUserThreadStart + 0x20 (ntdll)

End-trace

Executable: quartus
Comment:
None

System Information
Platform: windows64
OS name: Windows 10
OS version: 10.0

Quartus Prime Information
Address bits: 64
Version: 22.1std.2
Build: 922
Edition: Standard Edition

 

I'm trying to understand whether this is a hardware limitation, or a bug in the Quartus software.

If a bug in quartus, is there a workaround to implement this?

If a hardware limitation, can anyone elighten me as to why this would be - the receive and transmit are surely separate enties, just sharing the same IO pad.

 

Labels (2)
0 Kudos
1 Solution
FvM
Valued Contributor III
712 Views
SERDES IP doesn't seem to be able to connect other IO-standards than plain LVDS RX respectively TX. It's apparently necessary to write your own serdes logic in these cases. No problem as such if you don't run near device speed limits, but surely annoying.

View solution in original post

0 Kudos
5 Replies
AqidAyman_Intel
Employee
721 Views

Hi,


Is it possible to share the .qar file of this project? If yes, please let me know as I will initiate the email for you to send the file.

I will need to reproduce the error from my side to further check on this.


Regards,

Aqid


0 Kudos
FvM
Valued Contributor III
713 Views
SERDES IP doesn't seem to be able to connect other IO-standards than plain LVDS RX respectively TX. It's apparently necessary to write your own serdes logic in these cases. No problem as such if you don't run near device speed limits, but surely annoying.
0 Kudos
TomCarpenter
Novice
458 Views

Yeah, I came to that conclusion.

Ended up rolling out my own soft-SERDES core using half-rate DDIO blocks. Managed to get it to meet timing at the 720Mbps we require. Couple that with some creative dynamic phase shifting of the PLL output clocks should hopefully allow dynamic phase alignment of the receive assuming it works once I get into hardware testing.

0 Kudos
FvM
Valued Contributor III
435 Views
Thanks for confirming. I would be happier if you had found a different solution.
If I was an Intel support engineer, I'd try to find out the nature of limited SERDES connectivity. There are different possibilities:
1. Restriction of hardware connectivity in silicon.
2. Incomplete fitter implementation.
3. Intentional constraint to keep certain specifications

In the latter case there can be a "magic word" to override the constraint, to allow implementations that don't need maximum performance. BLVDS with its reduced speed could be such a case.
0 Kudos
AqidAyman_Intel
Employee
657 Views

As we do not receive any response from you on the previous question/reply/answer that we have provided, please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


0 Kudos
Reply