danfoster has quit [Remote host closed the connection]
futarisIRCcloud has joined #scopehal
<azonenberg>
OK so
<azonenberg>
AFE is now hooked up to my scope directly in 50 ohm mode
<azonenberg>
DC coupled 50 ohm so there is going to be some common mode error i think
<azonenberg>
With the input disabled, at the output I measured -2.5 mV DC offset error and 2 mV p-p of noise (with my scope sampling at 20 Gsps, no band limiting)
<azonenberg>
if i band limit my scope to 200 MHz, i get only 700 uV of noise
<azonenberg>
This is also fake differential, real diff will be better, and there is nontrivial contribution from my scope when the gain is up this high
<azonenberg>
When i enable the input buffer, i have 340 mV p-p at the input and 18.8 mV p-p at minimum gain
<azonenberg>
Offset seems to work all the way through to the end of the AFE
<azonenberg>
Let me turn gain up and see what happens
<azonenberg>
ok gain is now at unity in the VGA, which should be -4 dB after factoring in the input attenuator. I have 48 mV p-p on the output which sounds a little low?
<azonenberg>
waveform looks great though, dont get me wrong
<azonenberg>
VGA gain set to +4 which should be unity, i measure 74 mV p-p at the output
<azonenberg>
so i either mathed wrong or we have loss creeping in from somewhere
<azonenberg>
but it's a beautiful squarewave with a 3.85 ns rise time which gives ~91 MHz bandwidth from the 0.35/RT approximation
<azonenberg>
When i set VGA gain to 17 dB i get pretty close to unity gain on the output
<azonenberg>
This may be due to the 50 ohm loading to ground on the scope output, i haven't tested what the actual voltage we get when driving the HMCAD1520 board is yet
<azonenberg>
Confirmed, proper 900 mV Vcm on the HMCAD board
<azonenberg>
There still does seem to be some loss creeping in from somewhere?
<azonenberg>
At +16 dB gain i get what looks to be pretty much unity gain wrt the input
<azonenberg>
output is a lot less pretty than the direct sma because i'm using the long alligator grounds for this test
<azonenberg>
I think at this point i'm going to say the MCU code is done enough, switch over to FPGA code
<azonenberg>
temporarily bang up a quick and dirty driver that collects a bunch of samples then spits them out UDP packets
<azonenberg>
(since TCP isn't finished)
<azonenberg>
just to get some actual waveforms onto my PC and look at them
<azonenberg>
so i just realized i can't test the ADC at 1 Gsps
<azonenberg>
i don't have any integralsticks with a -2 speed FPGA on them
_whitelogger has joined #scopehal
<electronic_eel>
are the speedgrades real for xilinx or is it just marketing?
<monochroma>
they are very real
<electronic_eel>
do they do actual binning for speed? that tends to be expensive, so many companies just mark them differently
<electronic_eel>
or is there some logic that does bitstream locking?
<electronic_eel>
like you can't load a bitstream that was built for another speedgrade?
<monochroma>
iirc it's based on die location on the wafer
<electronic_eel>
ah, so there are some factors in the production process that make some locations on the wafer worse and others better
<electronic_eel>
then they don't have to bin them, just pick them based on location
<monochroma>
yeah i can't remember if they do full bin testing or not, azonenberg would know
<azonenberg>
Lattice, at least, definitely does full speed binning
<azonenberg>
they even talk about how they do it
<azonenberg>
basically build a ring oscillator using as many different copies of a given resource (say lut) as you can, then measure frequency
<azonenberg>
either globally or within one region of the die
<azonenberg>
in xilinx at least there is no logic that does locking, you cannot query speed grade via jtag or anything
<azonenberg>
the only way to get the speed grade is to look at the laser marking
<azonenberg>
It would not surprise me to hear that if there's a shortage of -1 speed parts they might down-mark some -2's or something, but for the most part they are definitely different
<electronic_eel>
ugh, if the speed grades are real then this is a open door for the remarking fraudsters
<azonenberg>
This is why i only buy fpgas from authorized dealers
<azonenberg>
with 7 series and newer at least, there is a 2d barcoded serial number or similar on each fpga package
<azonenberg>
you can scan it with a mobile app they provide to get more information about that chip
<azonenberg>
e.g. lot number, date code, speed grade, etc
<azonenberg>
this might provide a little more assurance?
<azonenberg>
but honestly i just buy from digikey or avnet and problem solved
<electronic_eel>
a fraudster could buy like 20 or 50 of the original ics, scan their barcodes and print them on the fakes
<azonenberg>
yes that is very much a threat
<azonenberg>
hence "a little more"
<azonenberg>
the only way to really be sure of your supply chain is to know it end to end
<electronic_eel>
why don't they have a small otp region on the ic and put that stuff in there?
<azonenberg>
they do have efuses. For whatever reason the speed grade isn't in there
<electronic_eel>
speed grade and serial no, that would be enough
<azonenberg>
or even a seirial you could query to find speed grade in some database
<azonenberg>
i guess the theory is by that point the chip is already on a board
<electronic_eel>
don't they have some fancy bitstream locking where you crypt the bitstream just for this specific fpga?
<azonenberg>
and its too late?
<azonenberg>
Yes
<azonenberg>
you can burn a key into efuse, or store in battery backed sram
<azonenberg>
then encrypt a bitstream with that key
<azonenberg>
You provide the key, it's not fused at the factory etc
<azonenberg>
just an aes key you program yourself
<electronic_eel>
so the efuse region is big enough for a key? then there should be plenty of space for a serial and speedgrade
<azonenberg>
there is already a unique serial number
<azonenberg>
Not sure why no speed grade
<electronic_eel>
can you use that serial no to check for speed grade on their website?
<electronic_eel>
that would be easy to implement
<electronic_eel>
for them
<azonenberg>
To my knowledge the device dna cannot be used to look up speed grade
<azonenberg>
another annoying quirk... the DNA is now 64 bits long
<azonenberg>
but spartan/virtex6 had 57 bit serials
<monochroma>
:o
<azonenberg>
in order to maintain easy compatibility for design porting, i guess, the on die readable version of the DNA is truncated to 57 bits
<azonenberg>
i.e. up to 32 devices may have the same DNA, it's no longer a guaranteed unique ID
<azonenberg>
you can read the full version via jtag
<azonenberg>
but at least in 7 series there's no way to read the full id from on die
<azonenberg>
i really wish they had implemented a bitstream setting to say compatibility mode or full mode
<lain>
azonenberg: 64-57 is 7 bits, wouldn't it be up to 128 devices sharing the same id?
<azonenberg>
IIRC two of those bits have constant values
<lain>
ahh
asd has joined #scopehal
asd has quit [Remote host closed the connection]
<azonenberg>
ok, preliminary results from my bitstream that should have turned brought the HMCAD1520 out of reset and made it start spitting out data (which i can't yet actually PROCESS)
<azonenberg>
The ADC is unresponsive. It has a clock in, power is good, but neither FCLK nor LCLK are toggling. Unsure if bad register settings, power-down or reset weren't correctly cleared
<azonenberg>
or maybe fpga constraint bug and i'm sending signals out the wrong pins
<azonenberg>
Haven't debugged at all yet
<lain>
azonenberg: you can get the full DNA from jtag, can you access that on-die?
<azonenberg>
I was afraid you'd ask
<lain>
ehehe
<lain>
ICAPE2?
<azonenberg>
Not... exactly
<azonenberg>
The ICAP does not provide access. it's not in the config register space
<lain>
board-level jtag loopback?
<azonenberg>
You have to read it via a separate JTAG IR value
<azonenberg>
xilinx actually has an appnote, for zynq i believe
<azonenberg>
describing how to read the full DNA by connecting GPIOs to your own jtag
<lain>
actually
<lain>
from fabric, there's BSCANE2
<lain>
is that not suitable? :o
<electronic_eel>
ugh
<lain>
errr oh right, that's just for USER1/USER2
<lain>
USER[1:4] ***
<azonenberg>
No, BSCANE2 is a slave that allows you to drive TDO and read TDI/TMS/TCK when USERx is selected
<azonenberg>
You cannot drive TDI/TMS/TC
<azonenberg>
TCK*
<electronic_eel>
that much trouble because they just forgot that this is a important feature and didn't implement a flag for it
<azonenberg>
lol yes
<lain>
typical xilinx :|
<azonenberg>
anyway, I've got a few things to take care of for a customer and will probably be going to sleep shortly. But still good progress on the AFE front today i think
<azonenberg>
Hmmm
<azonenberg>
it helps if you don't leave power-down asserted after initializing the ADC
<azonenberg>
well
<azonenberg>
that did SOMETHING different :p
<azonenberg>
the board now draws enough current to trip the rather conservative 500 mA limit i had set on the bench supply and shut down :p
<azonenberg>
So right now with AFE configured and operational, ADC in power-down state, integralstick running
<azonenberg>
integralstick blank*
<azonenberg>
AFE is pulling 212 mA @ 12V, integralstick + ADC is pulling 340 mA @ 5V
<azonenberg>
883 mA @ 5V with ADC powered up
<azonenberg>
Drops to 600 mA after configuration
<azonenberg>
ok this will have to be debugged when i'm more awake
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Ekho has quit [Quit: An alternate universe was just created where I didn't leave. But here, I left you. I'm sorry.]
Ekho has joined #scopehal
<Degi>
Hm sure it cant run at 1 GS/s tho? Like did you test it? The ECP says it isnt rated for that either but it can do quite a bunch more
<Degi>
Re: HMCAD register: There is a lot to configure before it will work
<Degi>
Can you send a picture of the top of the AFE board? Do you have pictures of the trace when you connected it straight to the scope?
<Degi>
Do you have R30 and R31 placed?
futarisIRCcloud has joined #scopehal
<Degi>
If you have R32 and R33 placed I think we get Vout=0.15875 Vin
<Degi>
Actually we have 0.21 at output
<Degi>
SO Vshifted_P and _N should be 0.25 Vin if R30 and R31 placed, U6 and surrounding reduces to 0.15875 if R32 and R33 placed
<Degi>
Did you reset the HMCAD by writing a SPI register which resets it? (0x00 bit 0 to 1 i think)
<azonenberg>
I expected to at least get a clock out with minimal config
<azonenberg>
It will fail timing, it's likely to work at room temp
<azonenberg>
i might try that at some point
<azonenberg>
but i should also just build an integralstick with a faster fpga at some point
<Degi>
Like whats the usual clock speed its supposed to run at?
<azonenberg>
950 is max io speed
<Degi>
yeh
<Degi>
Meh 50 more isnt gonnam atter
<azonenberg>
i have all of the series resistors you mentioned populated afaik
<azonenberg>
as far as reset on the HMCAD...
<Degi>
Then output should be 0.15875 input when VGA is unity gain (Vin=Vout)
<azonenberg>
rst_n 0 then 1
<azonenberg>
pd 1 then 0
<azonenberg>
0x31 -> 0x0001
<azonenberg>
0x3a -> 0x0022 which is wrong, should be 0202
<azonenberg>
then same to 0x3b
<azonenberg>
That's it
<azonenberg>
i expected that to at least be enough to get a clock out
<Degi>
Did you probe with a scope?
<azonenberg>
yes i scope probed clock out
<azonenberg>
and all the data lines
<azonenberg>
none were toggling, i think at least some had dc offsets that i'd expect from idle lvds
<Degi>
Did you write 0x00 to 0001?
<azonenberg>
no i did a hardware reset
<Degi>
Did you do power down?
<azonenberg>
i didn't touch 0x00 at all
<azonenberg>
(11:24:19) azonenberg: rst_n 0 then 1
<azonenberg>
(11:24:23) azonenberg: pd 1 then 0
<Degi>
Cycle PD or write 0200 to 0F and then 0000
<Degi>
Ah yes
<Degi>
Hm but the RST went back to 0 after that right?
<azonenberg>
no why would it? it's active low
<Degi>
Nah wait its inverted
<azonenberg>
oh thats interesting
<azonenberg>
powerdown must be selected after or during a change of operating mode>
<azonenberg>
default is quad channel mode, i selected single
<azonenberg>
so that's something
<azonenberg>
Another shapeways shipment came in
<azonenberg>
one of those eevblog post probe holders which actually feels pretty good, too bad it doesn't fit the new probe shells. But I think we could easily make a compatible design that fits
<azonenberg>
So might be worth looking into in the future
<azonenberg>
(in glass filled nylon)
<azonenberg>
also two variants of the old probe shell in various SLS nylon materials. Both ended up somewhat or completely clogged with powder
<azonenberg>
So basically it confirms that shapeways's normal SLS process is unsuitable for this part
<azonenberg>
MJF works well, idk if different cleaning process or smaller/less sticky powder or what, but i've never had residue problems
<azonenberg>
the SLS process seems to not handle high aspect ratio holes well even if they meet the minimum hole size requirement
<azonenberg>
Which is good info to have for future projects
<azonenberg>
also lovely, my new DMM has *not* shipped
<azonenberg>
my newly cal'd*
<azonenberg>
apparently paperwork error, i called the credit card number into the corporate office but the lab that actually has physical custody of the equipment never got the payment confirmation so they never shipped it to me
<azonenberg>
Lovely
<Degi>
Oof
<azonenberg>
If things go well it should ship out today and i should have it tomorrow or friday
<azonenberg>
VNA is scheduled to arrive friday as well
<azonenberg>
Also i think we will need to cal offset at multiple points, probably each gain setting
<azonenberg>
Because offset error in the input/offset amplifier will be amplified by the gain stage
<Degi>
yeh
<Degi>
Hmm did you do any more work on the HMCAD?
<azonenberg>
No, i have work to do for $dayjob
<Degi>
ok
<azonenberg>
If you have time and want to sit down and draw up a list of non-default reg settings you think i need, that would be nice
<azonenberg>
my test setup is using IN1 as the sole input and will be running at 625 Msps in 8-bit mode just for initial sanity checking
<azonenberg>
as well as timing and info of any resets
<azonenberg>
degi: ok so i'm sitting down with the ADC board right now
<azonenberg>
i have a jtag spi master bitstream set up so i can poke registers easily from the PC
<azonenberg>
right now it's pulling 408 mA, PD is 1, RST is 0
<azonenberg>
Bring RST high, no difference in behavior
<Degi>
Thats kinda a lot of current for doing nothing
<azonenberg>
this is the whole thing including the integralstick
<Degi>
Ahh
<azonenberg>
on the 5V rail
<azonenberg>
i dont have a meter on just the adc
<azonenberg>
also it includes the clock oscillators and mux etc
<azonenberg>
anyway.... so reset cycle, powerdown cycle
<azonenberg>
now RST=1, PD=0, 848 mA
<azonenberg>
now i need to send some init commands
<azonenberg>
oh wait i forgot to break out spi CS# in my test bitstream
<azonenberg>
brb :p
<Degi>
Hmm I think I should figure out how to communicate over JTAG besides loading a bitstream on the fpga
<azonenberg>
i'm using the xilinx VIO ip
<azonenberg>
which is super handy
<Degi>
Hm neat
<Degi>
Do you have like a xilinx program on the host PCß
<Degi>
?
<azonenberg>
yeah i just use the vivado hardware manager
<azonenberg>
it talks to the logic analyzer etc too
<azonenberg>
i keep meaning to RE the jtag protocol so i can use scopehal with their LA IP
<azonenberg>
havent had a chance
<Degi>
I mean I could probably hack something together with openocd lol
<azonenberg>
well the issue is that the jtag register set for their LA and VIO is undocumented
<azonenberg>
vivado is the only supported way to talk to it
<azonenberg>
so you have to either write your own fpga-side code or reverse theirs, or both
<Degi>
For some reason the FTDI chip on the ECP5 EVN board doesnt seem to output any serial signals while the same chip on the SiFive board does do that. I think they might be configured differently
<Degi>
The ECP5 has a JTAG hard IP which breaks out the signals
<Degi>
Hm yeah I guess the xilinx does that too
<azonenberg>
Xilinx's jtag hard IP defines four instructions USER1...USER4 for you to use for custom logic
<azonenberg>
their debug code uses some of those
<Degi>
Now my solution is to stick the SiFive board onto the Arduino header of the ECP5 board as a serial interface... :(
<Degi>
Holy particulate matter, more than 100 µg/m³ for PM2.5 and PM10 when I got home
<azonenberg>
o_O
<azonenberg>
ok so... new bitstream loaded
<azonenberg>
Reset and powerdown cycle done
<azonenberg>
Write 0x31 = 1
<Degi>
Hm and I guess reset and power down are asserted for more than 20 ns?
<azonenberg>
I see 468 MHz on LCLK, 78 MHz on FCLK
<azonenberg>
yeah i'm bitbanging from the gui :p
<Degi>
lol k
<Degi>
Woo
<azonenberg>
that's with 625 MHz input
<Degi>
Thats good
<azonenberg>
so i guess next step is going to be to script up some of the preliminary reset stuff etc
<Degi>
So what didnt work before?
<azonenberg>
Not sure
<Degi>
Hm yes
<azonenberg>
Can you come up with a full set of registers i need to write to configure in 8 bit single channel on lane 1?
<Degi>
wait a sec
<Degi>
Hmm I think 0x31, 0x3A, 0x3B,
<azonenberg>
(and values)
<Degi>
Wait a sec
<azonenberg>
no rush, i have some other code to write to set this up
<azonenberg>
And i need a powerdown cycle after writing 0x31 right?
<Degi>
Unsure? gotta ty
<Degi>
+try
<Degi>
Wait a sec
<Degi>
Yes
<Degi>
lvds_output_mode in 0x53 and the whole of 0x31 requires PD cycle
<Degi>
Basically connect all ADC inputs to IN1, set clock divider to 1, set output to 8 bits, set to single channel 12 bit mode (which can do 1 GS/s on 8 bits)
<azonenberg>
how do you set 12 vs 8 bit mode?
<Degi>
"When 8-bit LvDs mode is used, the LsBs are truncated and the data output will have 8-bit resolution. see HMCAD1511 and HMCAD1510 for detailed description." Maybe we can get 12 bits at higher sample rates too lol
<Degi>
By setting output bit width
<azonenberg>
interesting
<azonenberg>
so the converter is always in 8 bit mode?
<azonenberg>
in 12 bit*
<Degi>
Weird right
<azonenberg>
it just truncates sometimes?
<Degi>
Apparently??
<Degi>
You can set it to 14 bits too
<azonenberg>
yeah thats a different mode
<Degi>
So the output can have 8, 12, 14, 16, dual 8 bits. I wonder what happens when we configure "do not use" bits there?
<Degi>
Wait
<Degi>
0x56 needs to be 0008 I think
<Degi>
And 0x30 to 00FF if you wanna
<Degi>
And you can do reset and PD over SPI too if you wanna lol
<Degi>
Lol you can change ADC core currrent
<Degi>
And 0x50 to 0030 if we wanna use the VCM pin sometime, then it has 700 µA drive strength for 20 mV change
<azonenberg>
We'll worry about that later, i dont need VCM right now
<Degi>
Besides what I mentioned above, set 0x56 to 0008 and you should be good to go
<Degi>
If your FPGA doesnt receive stuff, set 0x11 to 0777, 0666, 0555, 0444, in that order, advance by 1 if it still doesnt receive data. That increases the drive strength from 3.5 mA to 4.5, 5.5, 6.5, 7.5
<azonenberg>
ok now using 770 - 840 mA. let me see what things look like
<Degi>
Current looks okay
<azonenberg>
Clocks aren't toggling now
<Degi>
Huh
<Degi>
Did you apply PD again?
<azonenberg>
i wonder if i need more time around reset/powerdown cycles
<Degi>
And did you set 0x56 I think without that it may bug out
<azonenberg>
yeah i did
<azonenberg>
sec, i just increased the clock divider for my microcode
<azonenberg>
it's just a canned sequence of writes
<Degi>
At least reset is toggled on during powerdown cyle
<azonenberg>
this is temporary, in the final system i think we will have the mcu control adc config
<Degi>
Hm sure that reset doestn reset SPI stuff too?
<Degi>
Ah now you have reset at 1 from 164 to 180
<azonenberg>
yeah
<azonenberg>
but right now the adc is connected to the fpga, the micro on the integralstick isnt being used at all, and the micro on the AFE is doing most of the work
<Degi>
Hm so does the FPGA configure the ADC ?
<azonenberg>
Right now? yes
<azonenberg>
in the final system? no
<azonenberg>
in the final system to keep things organized, all of the spi buses, resets, control signals, etc will be driven by the stm32f777
<azonenberg>
and the fpga will be purely datapath
<azonenberg>
we may have to notify the fpga of various events like changing adc bus width
<azonenberg>
but it won't be actually doing any of the reconfig around that
<azonenberg>
it will just be a "fyi the adc bus is now 8 bit"
<Degi>
Does the ADC do something
<azonenberg>
Newest bitstream is compiled and loaded. 865 mA ish. FCLK and LCLK aren't toggling
<azonenberg>
it would help if i didnt have more errors in my code
<Degi>
:/ at least it uses more electricity
<azonenberg>
L197 should be 193
<azonenberg>
L197 should be 1023*
<Degi>
Lol is that the clock divider
<azonenberg>
yes
<azonenberg>
well not clock divider per se, more like a delay counter between microcode events
<azonenberg>
its just an enable
<azonenberg>
but yes, it never actually triggers anything :p
<Degi>
Well as long as the SPI is below 20 MHz and the reset and pd are above 20 ns it should be fine
<azonenberg>
is there anything in the docs about time from reset/pd being cleared to further spi writes?
<azonenberg>
spi clock is divide by 10 from a 100 MHz clock, so 10 MHz
<azonenberg>
reset/pd pulses are divide by 1024(one microcode tick) from 100 MHz
<azonenberg>
so... plenty long
<azonenberg>
and the bug was that the divider was checking for an impossible condition, a 10-bit counter never hits 1024 :p
<Degi>
Idk? I think PD doesnt affect SPI
<azonenberg>
i would still like to see that sort of thing documented :(
<Degi>
Start up time from PD is 15 µs
<Degi>
But that shouldnt affet spi
<Degi>
Hm maybe try waiting 20 µs after a reset or so
<Degi>
And what does regwr do?
<azonenberg>
see up on 97-143
<Degi>
0x53 sets 8 bit mode, 0x56 sets startup time to work at 1000 MHz
<Degi>
0x30 reduces jitter
<Degi>
Uhm you may wanna set regwr to 1'b1 for the SPI writes
<azonenberg>
That... would help
<Degi>
lol
<azonenberg>
Rebuilding
<Degi>
Anyways that doesnt rly explain why it didnt output anything... idk
<azonenberg>
well SOMETHING changed
<azonenberg>
now it's pulling 580 mA
<azonenberg>
with this bitstream
<Degi>
Oops?
<Degi>
Did it go boom ?
<Degi>
That is quite a reduction
<azonenberg>
no i think the register writes actually took
<Degi>
I would have expected the current to increase because the jitter ctrl was set to 88
<Degi>
*8
<azonenberg>
78.125 MHz on FCLK, 312.5 MHz on LCLK
<Degi>
Can you switch to a GHz
<azonenberg>
i see what looks like LVDS data coming out too
<azonenberg>
I'm going to keep it at 625 Msps for the moment
<azonenberg>
in 8-bit mode, and just see what happens
<azonenberg>
this is alive enough i think i can start writing capture code
<azonenberg>
also found a bug in the afe firmware
<azonenberg>
Cx:OFFS? doesnt print the minus sign on negative numbers
<Degi>
Hm by my understanding of the datasheet just toggling reset and pd should churn out samples by itself
<azonenberg>
well that's apparently not true
<azonenberg>
at least one of those register writes is critical
<Degi>
:/
<Degi>
Well it works now
<Degi>
CAn you git push
<azonenberg>
Sure
<azonenberg>
i have the AFE on and i see... stuff... coming out of the LVDS lines that looks a bit funny
<azonenberg>
might want to bump the drive strength
<azonenberg>
is it low by default?
<Degi>
3.5 mA
<Degi>
<Degi> If your FPGA doesnt receive stuff, set 0x11 to 0777, 0666, 0555, 0444, in that order, advance by 1 if it still doesnt receive data. That increases the drive strength from 3.5 mA to 4.5, 5.5, 6.5, 7.5
<Degi>
What kinda funny
<azonenberg>
well this is just based on me scoping the diffpairs at the ADC side
<azonenberg>
i havent looked at what the fpga sees yet
<azonenberg>
it's not clean edges or even close
<Degi>
Hows your probe loading like
<azonenberg>
even the clocks look a bit odd. This was with the tetris
<azonenberg>
i havent tried one of the pico probes yet that was gonna be next step
<Degi>
Can u send a pic
<Degi>
See page 26 of HMCAD1520 datasheet
<azonenberg>
This looks like it might just be oshpark's pcb not being well impedance matched
<azonenberg>
unsure if it's going to be a problem
<Degi>
Oh also are you getting noisy data out?
<azonenberg>
This is FCLK
<Degi>
Idk turn on termination on the HMCAD if it is, I think FPGA termination should suffie