Design Con 2015
Breaking News
Blog

ESIstream vs. JESD204B for Ultra-High-Speed Chip-Chip Communications

NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
Max The Magnificent
User Rank
Blogger
Re: Don't see the point
Max The Magnificent   12/17/2014 6:20:15 PM
NO RATINGS
@kdahlgren: I actually defined the SerialLite III protocol as well as the original 8B/10B Aurora protocol so I'm very familiar with the trade-offs.

I remember being briefed on the Aurora protocol by the folks at Xilinx a year or two ago -- I remember it sounding very interesting -- it's a pleasure to meet the person who defined it.

I'm afraid you are far more knowledgeable than I -- we will have to wait for the folks from e2v to explain everything in excruciating detail (much like my dear old mom telling one of her stories :-)

kdahlgren
User Rank
Rookie
Re: Don't see the point
kdahlgren   12/17/2014 6:14:56 PM
NO RATINGS
Hi Clive

64/67 is DC balanced. That's what the extra bit (when compared with 64/66) buys you.

I actually defined the SerialLite III protocol as well as the original 8B/10B Aurora protocol so I'm very familiar with the trade-offs.

I have to tell you that the savings in PCS logic that you will get by going to a totally non-standard line coding scheme will be minimal to non-existant when you consider what you will lose by not being able to leverage the infrastructure in modern high speed serial transceivers.

Also in terms of being "top heavy". The amount of logic needed to implement the PCS for a streaming data interface is dwarfed by the amount of logic needed to process that data.


So I still don't get it.

Just my 2 cents ;-)

Max The Magnificent
User Rank
Blogger
Re: Don't see the point
Max The Magnificent   12/17/2014 6:01:43 PM
NO RATINGS
@kdahlgren: Sorry I guess I should have been more explicit...

No worries -- I agree that 64/66 and 64/67 are more efficient that 14/16, but maybe they push the limits of DC balancing and clock recovery at the speeds e2v's guys are working at.

Also, it may be that their implementations are designed to satisfy a number of use-cases thereby making them "top-heavy" with regard to the amonut of digital logic required.

But I'm not an expert here -- I've emailed the folks at e2v and asked them to chime in -- I'm assuming they are all tucked up in their beds at the moment (or dabncing the night away at a night club) -- we shall see what they have to say in the morning :-)

kdahlgren
User Rank
Rookie
Re: Don't see the point
kdahlgren   12/17/2014 5:56:26 PM
NO RATINGS
Sorry I guess I should have been more explicit:

64/66 and 64/67 are also more efficient line coding schemes than 14b/16b

These are also widely supported encoding schemes. 14b/16b is not.

Max The Magnificent
User Rank
Blogger
Re: Don't see the point
Max The Magnificent   12/17/2014 5:34:37 PM
NO RATINGS
@kdahlgren: ...If you want to create a lower latency streaming interface in an FPGA to transport streaming data there are already alternatives...

I think that one big point I raised in this blog is that it's not just a cas eof creating a low-latency streaming interface -- as you say, there are already a number of alternatives -- the problem is that the existing solutions are "top heavy" with regard to complexity and the amount of digital logic that is required to implement them as cores on custom SoCs created using silicon-germanium substrates.

If the e2v designers could have used JESD204B -- or any of the other "standard" protocols -- they woudl have happily done so. The point is that -- due to several factors (including wanting to mimimize the digital logic and requiring mind-boggling sampling speeds and data throughput) -- they decided they had to create their own.

Now, since they have created their own protocol, they would like others to join the party, which is why they are making everything open source -- including the VHDL to implement softcores on FPGAs (where these soft cores will of cource utilize the existing hard serial I/F cores). This protocol isn't applicable to everyone -- but it may well be of interest to someone designing custom SoCs for extreme situations.

But I'll ask the folks at e2v to make their own comments tomorrow (it's late evening in the UK as I pen these words).

kdahlgren
User Rank
Rookie
Don't see the point
kdahlgren   12/17/2014 5:00:17 PM
NO RATINGS
I'm not sur e why anyone would consider this as an option.

1) There are lots of standard data converters out there that use JESD204. So unless you want to create your own custom devices, this is not an option.

2) If you want to create a lower latency streaming interface in an FPGA to transport streaming data there are already alternatives that are more efficient than 14b/16b. This includes Aurora 64/66 from Xilinx and the 64/67 based SerialLite III from Altera.

Most Recent Comments
Flash Poll
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week