emeb has quit [Quit: Leaving.]
emeb_mac has quit [Ping timeout: 272 seconds]
Degi has quit [Ping timeout: 256 seconds]
emeb_mac has joined ##openfpga
Degi has joined ##openfpga
Bike has quit [Quit: leaving]
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined ##openfpga
m4ssi has joined ##openfpga
mwk has quit [Ping timeout: 244 seconds]
m4ssi has quit [Remote host closed the connection]
genii has quit [Quit: See you soon.]
mumptai has joined ##openfpga
OmniMancer has joined ##openfpga
OmniMancer has quit [Client Quit]
OmniMancer has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<ktemkin> so: "free-running" the ECP5 serdes / skipping clock recovery
<ktemkin> I've been told this isn't possible
<daveshah> I feel like I saw a bypass option for this
<ktemkin> there's a bypass for encoding
<ktemkin> but it -looks- like you can likely force it to never clock recover and thus stay locked to refclk
<ktemkin> via control register 9
<daveshah> Yeah I think reg 9 is what I was thinking of
<daveshah> Never actually tried it though
<ktemkin> (in conversation elsewhere earlier, I suggested that if we could trick it to stay in loss-of-lock, we'd be able to bypass clock recovery; and miek pointed that option out; so credit to his superior reading ability)
<ktemkin> anyone want to tell me reasons this is a stupid idea? >.>
mwk has joined ##openfpga
hitomi2504 has joined ##openfpga
<ktemkin> ah, hell, right, I need to fuzz out the fc2dco_floop parameter; and for that I need a proper "send in that blasted code" Diamond license
<daveshah> Is it a Verilog parameter at all
<daveshah> Or just one of the ones that you only access via the bus?
<ktemkin> I might be misremembering; I was looking at lattice internals for my gsoc student's PCIe stuff all day
<ktemkin> but accessing it through the SCI is easier than doing all that anyway
<azonenberg> ktemkin: i'm looking at doing exactly this on kintex7, cant speak to ecp5 but at least some serdes IP have the ability to do that
<daveshah> Yeah I've done it on k7 too to make a 1 bit dac
<daveshah> *adc
<azonenberg> xilinx calls it "lock to reference" or i think "CDR hold"
<azonenberg> I'm going to be using it on MAXWELL to oversample inputs for a logic analyzer
<ktemkin> mossmann nerdsniped me into getting it working for 1-bit ADC purposes =P
<ktemkin> by which I mean he said someone authoritative-sounding told him it was impossible about a year ago, and the "there has to be a way" caught up with me today when I was looking at SerDes config to help debug Degi's PCIe work
<daveshah> What I did on the k7 was to capture it into a buffer and then run a long FFT on it (off the FPGA as it was just a proof of concept)
<daveshah> I was actually able to see the spectrum of a nearby WiFi transmitter, with an LNA and antenna feeding the SERDED
<daveshah> *SERDES
<azonenberg> daveshah: nice
<ktemkin> nice -- that's very close to the application, here
<daveshah> It did need quite a bit of gain, I wasn't far off the point where things started oscillating
<ktemkin> I mean, it turns out having -some- RF frontend helps a little bit when capturing RF =P
<ktemkin> dunno if you've seen ossmann's quince work; but very similar idea
<daveshah> No, I haven't
<daveshah> Yeah that seems very similar
<ktemkin> I just have to not get drawn into the application once I try this SERDES proof-of-concept; since I'm already way off-road from what I'm Supposed To Be Doing (TM) >.>
mossmann has quit [Ping timeout: 246 seconds]
nats` has quit [Read error: Connection reset by peer]
nats` has joined ##openfpga
mossmann has joined ##openfpga
Asu has joined ##openfpga
<Degi> I mean up to 2.5 GHz and maybe a bit more should be possible with the serdes. Maybe even build a 1 bit camera with multiple of them.
u0m3 has quit [Remote host closed the connection]
u0m3 has joined ##openfpga
u0m3 has quit [Remote host closed the connection]
clever has quit [Ping timeout: 256 seconds]
u0m3 has joined ##openfpga
clever has joined ##openfpga
clever has joined ##openfpga
u0m3 has quit [Remote host closed the connection]
u0m3 has joined ##openfpga
Bike has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined ##openfpga
nickjohnson has quit []
nickjohnson has joined ##openfpga
ziga has quit [Ping timeout: 264 seconds]
ziga has joined ##openfpga
lambda has quit [Ping timeout: 256 seconds]
lambda has joined ##openfpga
emeb_mac has joined ##openfpga
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
hitomi2504 has quit [Quit: Nettalk6 - www.ntalk.de]
genii has joined ##openfpga
lexano has quit [Ping timeout: 240 seconds]
lexano has joined ##openfpga
ironsteel has joined ##openfpga
GenTooMan has quit [Ping timeout: 260 seconds]
lexano has quit [Ping timeout: 260 seconds]
lexano has joined ##openfpga
xtro has joined ##openfpga
pointfree has quit []
OmniMancer has quit [Quit: Leaving.]
pointfree has joined ##openfpga
Richard_Simmons has joined ##openfpga
GenTooMan has joined ##openfpga
ironsteel has quit [Ping timeout: 272 seconds]
Bob_Dole has quit [Ping timeout: 260 seconds]
lexano has quit [Read error: Connection reset by peer]
lexano has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Client Quit]
Asu has joined ##openfpga
Asu has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asuu has joined ##openfpga
xtro has quit [Quit: Lost terminal]
Asuu has quit [Quit: Konversation terminated!]
genii has quit [Quit: See you soon.]
<SpaceCoaster> I am seeing slow performance with lxterm when uploading using an FT2232. https://github.com/enjoy-digital/litex/issues/561
<SpaceCoaster> azonenberg: I have a vague memory that you had various issues with USB before you switched to Ethernet everywhere.
<SpaceCoaster> Is the 60 packets per second reasonable when the other end sends and ACK?
xtro has joined ##openfpga
<kc8apf> if it's small packets, you might need to adjust some settings. I documented this for an ECU cable I sell: https://www.mxshift.com/assets/usb_m8/usb_m8_users_guide.pdf
<kc8apf> Windows defaults are setup for fairly large transfers and unidirectional streams. Small cmd/response patterns are very slow until you tweak those knobs.
sgstair_ has joined ##openfpga
Bird|otherbox has quit [Remote host closed the connection]
Bird|ghosted has joined ##openfpga
<SpaceCoaster> Thanks, that is interesting but I am using Mac OS X Mojave. I wonder if the FT2232 has tuning knobs somewhere.
<kc8apf> oh, the issue you linked mentioned Windows
sgstair has quit [Ping timeout: 272 seconds]
<kc8apf> macOS's FTDI driver used to have a long delay in it.
<SpaceCoaster> Yeah, my comments were at the end. The original commenter disabled CRC and is happy now.
<kc8apf> no knobs that I know of
<SpaceCoaster> FTDI have a program which runs under wine for tweaking the chip. Not sure if it has anything useful for this. Might try some of the other UART chips just for fun.
<SpaceCoaster> Anyway thanks for confirming that what I am seeing is plausible.
<kc8apf> the chip doesn't have much tuning relevant to data throughput. Drivers do some odd things
<SpaceCoaster> You can tune a piano but you can’t tuna fish (or a UART on OS X).
<SpaceCoaster> kc8apf: is it ok to link to your doc for Windows users on the github issue?
<kc8apf> sure.