Closed marmeladapk closed 6 years ago
It does not matter if traces are routed in the middle or not. The open edge of the board forms slot antenna and irradiates EMI. That's why we place vias at the board edges that short all ground planes and form some kind of Faraday cage for internal layers.
@jordens
Rotating SATA connector is harder than I thought. It's both too close to the edge and to the JTAG connector. Moving JTAG down would require rerouting GTP pairs (and many more signals) and is not optimal. Rotating it would create problems with P12V0 distribution and also requires rerouting. Since you said to pass if it's troublesome, I'm going to defer it to next revision.
I found better heatsink
It has dimension of FPGA and is self-adhesive (previous one was smaller than FPGA).
So long as the glue is tough enough to survive lab usage (e.g. being nocked by all those ribbon cables) that looks perfect!
@marmeladapk all ACK. Then we are good to go.
I pushed RC2. Please check if shielding vias aren't too close to board edge.
@marmeladapk Thanks for uploading the R2C release along with the change notes. That's really helpful and exactly how I think this should be done!
All looks great on the schematic now, and I'd be happy to close this and send it off for manufacture. Good job.
One thing though, I'd really like to close all outstanding Kasli issues, including #317. So, could you either add that info to the schematic and close the issue, or let's agree that this info isn't important and close the issue.
IIRC we also said that if we use a balun as input, we want a DC-isolated one
Well, I'm still not keen on this. As discussed before, I don't think that the high isolation voltage afforded by the DC-isolated balun is useful, and it will mangle the rising edges of any clocks we feed through, as it only passes the fundamental of a 150MHz clock. This will make the clock's noise immunity much worse, as we can't feed in signals with fast rising edges.
I also object to using a different balun/isolation method here to everywhere else in Sinara. It's one more datasheet for users to have to look at, and it gives the user the impression that there is somethign special about this input. IMHO, unless there is a real need to do something different here, it would be much better to just stick with the solution that we've used everywhere else and tested carefully. (Not to mention that sticking with the current solution avoids having to do extra work).
But, that said, it's your board and your call...
Assuming the TC2-1TX+ is pin-compatible with the current balun, it looks okay to me (apart from the crap frequency cut-off).
@jordens Also, if you want to change the balun to improve the isolation voltage then other changes are needed as well:
Do we really want to go to that effort at this late stage in the design? It's not so hard, but there are a few ways of screwing things up, so I'd prefer to stick with our current balun situation, which we have tested elsewhere (e.g. clocker) and know should work...
@hartytp (1) The 5, 10 or 100 MHz outputs from reference source we would be using is sinusoidal. There is no point in accommodating for what we won't use. (2) In cases where Kasli is DRTIO master, I don't see anyone inputting a clock other than sinusoidal or other than 5/10/100 MHz. As you say, 150 MHz and 125 MHz are rare. (3) The previous balun has a crap lower frequency cut of as well. 5 MHz is not such an uncommon reference frequency. And loosing SNR there is so much worse than at 100 MHz because of the lower frequency. (4) I feel zero obligation to follow the Sayma clock input designs. It's an illusion that we are doing that (no squaring up chip, different PLL, different bandwidth, different application). The Urukul output stages already use a different Balun (I am fine with copying that design. It goes to higher frequencies but it's a different footprint). The Sayma design is neither known to be a good choice -- certainly no testing at all at low frequencies or with a narrow band PLL -- nor do we have the data to support the claim that the TLT is better noise-wise. (5) Remember that the typical PLL bandwidth of the Si5324 is 5-10 Hz. I have my doubts that you will see any relevant phase noise difference when using 150 MHz. At 5-10 Hz bandwidth there will be other effects dominating.
Clocker is tested already?
Clocker is tested already?
I haven't tested the version @gkasprow built yet, but we have something essentially identical, which we've been using for quite a while and have tested very carefully (this is what was used for a lot of the phase noise plots I've posted so far).
Anyway, I don't feel strongly enough to argue with you about this. Since you're the one pushing for it, just make sure you review all changes carefully it doesn't break anything...
It goes to higher frequencies but it's a different footprint
Oh, and I don't care too much about changing the footprint. I do not want to support multiple population versions for this, so let's just pick a balun and get it working.
On the breakdown I would keep the capacitors on the shield as they are now and also don't make an island. I am not trying to protect against discharge into the SMA shield, the case, the panel, SFP cage, 12V outer barrel. I am more worried about the signal path into the Si5324.
@hartytp You can also populate the TC2-72T+. With 700 MHz that's more than the required 4V/ns bandwidth the ADCLK would want. But since the is not the ADCLK948 and we don't have any data about how the Si5324 reacts to diffferent slew rates and how its 5 Hz PLL sees that, I don't see the point.
Ok. @marmeladapk Then please change the transformer TR1 to TC2-1TX+ for my boards. No changes to the layout required. Just that this transformer is rotated 180 degrees.
SN74AVC2T245 datasheet says to "Tie any unused input and output ports directly to ground."
@gkasprow recommended me 10 mm spacing. I'll move vias closer to the middle to also connect with top and bottom ground polygons.
Other changes will have to wait till Sunday at least. I need to catch up with few things on my uni. Try not to change the specification after Sunday, since I feel like I'm trying to hit a moving target. ;)
@jordens Could you update top post with these last things you and @hartytp discussed? So it's clear which changes do you want to be implemented.
I'd really like to close all outstanding Kasli issues, including #317
@hartytp I'll complete it, but after board is finalised.
@marmeladapk all ACK, done and top post updated.
TR1 to TC2-1TX+ for my boards
Let's do this for all boards then. I want to minimize the number of population variants floating around for this hardware.
@marmeladapk I saw your note on the XADC issues. Are you using vivado with JTAG to access the XADC directly or do you have gateware that you are using to access it?
we use Vivado, I also observed such effect. But after some time it started working.
I am not overly excited to see the I2C bus and the UART scattered over the banks on the FPGA. The various SFP control lines would have been better candidates for scattering. But I think this is OK for now (@sbourdeauducq could you confirm?)
I2C and UART are low-speed signals, and they are using the most regular FPGA IO (no clock-capable pins etc.). So there shouldn't be an issue with scattering them.
@marmeladapk "The XADC also has an on-chip reference option which is selected by connecting VREFP and VREFN to ADCGND": replace C49 with a 0R. (added to top post).
@jordens I connected it without a jumper. C49 was in 0201 case, our jumpers are 0402, there's no way I could fit that under FPGA.
@marmeladapk thanks.
@jordens If I just flip TC2-1TX+ by 180 deg. then output will be swapped (_P line with _N line). Do we care? I can connect CLK_IN to pin 4 if we want to avoid that.
(up - current balun, down, TC2-1TX+ rotaded 180 deg.)
@marmeladapk Correct (well observed!). The swapped polarity doesn't hurt me but if you want (and for the perfectionists inside us) swapping the connection on the primary (6-4) is nicer.
I finished, but I'll upload documentation from my home computer, as here I've got some issues with generating it (new Altium... ).
@jordens @hartytp I released rc3. Unless you have any objection I'd like to send it to the manufacturer.
@marmeladapk thanks! Give me an hour to check it.
@marmeladapk looks beautiful. If I had to nit pick, I'd probably suggest adding a PN for that clock balun on the schematic. Otherwise, no comments here apart from send it off! Great work!
@marmeladapk Good to go! Send it!
Whooo!
@hartytp I'll fix schematics in the final version.
Note to self: I unmasked thermal vias.
As a part of one of my projects on uni I wrote code that controls all parameters of Si5324. It abstracts all the registers stuff, allows to set desired input clock and output frequency (but only on one output). It finds right divider values so you don't need to use DSPLLsim for this but it does so using brute force method. In all cases I tested it found right values in <0.5 second (even with odd frequencies like 192.3 MHz). Do you want me to upload it for later use?
@marmeladapk ask @jordens
Integrate it into the code I posted before.
@jordens V1.1 arrived yesterday. Unfortunately pyftdi resets all other outputs when using I2C, so we have to fall back to bitbang. :/
@marmeladapk You mean it messes with the other channels? Yes. I have seen that too. Or do you mean it resets the other pins on the second channel? That should and can be fixed in pyftdi as well. In both cases, could you file a bug with pyftdi if there isn't one yet?
Anyway, bitbanging I2C is just fine.
@jordens @hartytp Unless anyone has any objections to schematics, I'd like to publish v1.1 and upload board files.
Go for it.
:+1:
v1.1 is released, so I'll go ahead and close this.
To be changed for rev1.1