-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kasli SI/Remote EEMs #14
Comments
From @hartytp on April 17, 2018 9:31 First up, a 50cm IDC supplied by technosystem going directly from EEM0 to EEM1:
This looks really good, we have a 3ns clear window with no errors in 3e8 bits transmitted. |
From @jordens on April 17, 2018 9:44 Ok. The code is lacking a lot of clock domain crossings. And it is ignoring ISI. Both will bite you sooner or later. But yeah. It depends on what you are going to measure now.and the conclusions you are drawing. |
From @hartytp on April 17, 2018 10:1 Still get a decent eye with a 1m SCSI cable, but it's down to sub ns by the time I go through a 10m cable. |
From @hartytp on April 17, 2018 12:7
Which ones? The crucial one is the CDC on the looped back data input. But, I'm using the idealy to ensure that the data inputs meet setup/hold on the rtio clock, so no cdc is needed. There are also no CDCs on most of the CSRs, but I'm only reading from them when their values are static, so again CDCs aren't needed.
What do you mean here? Do you mean because I'm using a counter instead of a PRBS? Or, do you mean because I only have traffic in one direction in the cabling? Anyway, this isn't supposed to be a definitive test of everything possible. But, I think it does give a good indication of what kind of things are likely to work and what won't. |
From @jordens on April 17, 2018 12:17 No. rio and the kernel CPU are different domains. The CSRs need CDCs (or be in the kernel CPU CD). Have a look at how we transfer the rtio_counter from rio to the kernel (and what happens when we failed to do so for a replica). |
From @hartytp on April 17, 2018 12:28
ACK. In general, yes. I know the code isn't documented, but if you look at the experiment I'm running, there is only 1 CSR that actually needs a CDC and that's the output_en CSR, which has a CDC. All the other CSRs are only read out when they are static, and so don't need a CDC.
ACK. A PRBS would be better, but IIRC there is a decent density of transitions on the various lines with a 7-bit counter. This should show up any really major SI issues, which is all I'm trying to do here. Beyond that it's hard to test like this, since the results are likely to be so dependent on the quality of the SCSI cable, the exact use case etc. Out of curiosity, is there any plan to move the PRBS generator from the JESD stack to somewhere like misoc as a general-purpose core? |
From @jordens on April 17, 2018 12:40 ACK. I overlooked that you are stopping the logic. But it's a bit more complicated. If the JESD PRBS can be made generic then it can move to misoc IMHO. But there is already a LFSR in misoc. And there is XORSHIFT in redpid. And redpid has another LFSR. |
From @hartytp on April 17, 2018 12:54
Yes, but don't forget there is an IDELAY2E on that input, which I'm using to ensure it meets S/H, so there should be no metastability issues.
ACK. |
From @hartytp on April 17, 2018 12:54 Anyway, if I wrote this again from scratch I'd do it differently; it was partially a learning exercise. |
From @hartytp on April 17, 2018 14:14 hmmm...there was a factor of 2 error in my tap width calculation. So, the eye above is actually only about 1.5ns. Here is the eye for 125MHz DDR with the following configuration: Kasli EEM0 -> 30cm IDC -> VHDCI_carrier -> 10m SCSI cable -> VHDCI_CARRIER -> 30cm IDC -> Kasli EEM1
The eye where the error rate is < 1e-8 is only 2 taps, so about 150ps. I'd interpret that as meaning that 125MHz DDR down a 10m SCSI won't work with Kasli driving (might be better with beefier MLVDS drivers). |
When there is such demand, we can add tiny IDC-IDC adapter with high current LVDS drivers. The direction would need to be controlled by the I2C. |
From @hartytp on April 17, 2018 14:37 Oops...the design I posted didn't have an ODDR on the synchronization line (out_en) which was messing up the timing! Fixed that and retook the above data with a 10m SCSI cable. I had to swap the IDCs for shorter (about 10cm) ones to move the data into the range of the IDELAY. Eye scan is:
So, that actually looks fine. Okay, provisionally, 125MHz DDR with 10m SCSI cables can be made to work in at least some circumstances if one's careful... New design pushed, experiment is https://hastebin.com/jopededibe.py |
From @hartytp on April 17, 2018 15:19 30cm IDC between EEM0 and EEM1 with the new design:
|
From @hartytp on April 17, 2018 15:20 Okay, that's all I plan to do for now, so closing. tl;dr SI seems very good with 30cm IDCs. With 10m SCSI cables, we get an eye that's something like 1.5ns-2ns wide. |
From @hartytp on April 17, 2018 9:24
I thought there was already an issue for this, but I can't find it now :(
Copied from original issue: sinara-hw/sinara#543
The text was updated successfully, but these errors were encountered: