<d1b2>
<esden> @whitequark I hope the move is going well. 🙂
<whitequark>
it's... going
<d1b2>
<esden> If you tell me which things from the gist or in the README should be updated. nanographs and I are happy to put together a PR to update it.
<whitequark>
it's been almost three months and I still do not have utterly necessary healthcare
<whitequark>
the gist is ok except I would really like to have glasgow pick up the yowasp toolchain instead of telling people to fiddle with binaries
<whitequark>
that would work natively on M1, too
<whitequark>
pip install -e should 100% be added to README
<whitequark>
the .venv folder could live in the glasgow checkout itself
<whitequark>
we would add it to gitignore
<d1b2>
<esden> Ahh ok, good idea!
<d1b2>
<esden> (re healthcare: I hope you get it soon. It is indeed very important. It always takes a bunch of back and forth sorting this kind of stuff when moving countries. Been there. :/)
<d1b2>
<esden> nanographs we should just replace it with crc as wq recommends, I think that is a more robust solution anyways.
<whitequark>
that's not for crcmod, that is a warning for aiohttp
<whitequark>
ideally we would not have a hard dep on aiohttp but that's blocked on a more fundamental rework of the entire applet system
<whitequark>
we'll get there™
<nanographs>
There was another warning for crc, trying to find it again
<nanographs>
Using legacy 'setup.py install' for bitarray, since package 'wheel' is not installed.
<nanographs>
Using legacy 'setup.py install' for crcmod, since package 'wheel' is not installed.
<nanographs>
Using legacy 'setup.py install' for MarkupSafe, since package 'wheel' is not installed.
<nanographs>
This was with running pip install -e .
<whitequark>
aha
<whitequark>
so for some reason, pip does not depend on wheel, despite wheel being the de facto standard for installable packages
<whitequark>
so the first thing you need to do in a new virtualenv is to do pip install -U pip wheel
<whitequark>
for some reason
<nanographs>
Yeah I uninstalled glasgow with pip, then installed wheel, but when I re-ran pip install it just said all of those were already satisfied and did not complain further
<whitequark>
yeah you'd have to recreate the venv to potentially reproduce the failures
<nanographs>
makes sense
<whitequark>
it doesn't (or shouldn't, anyway) make any difference whether you're installing from sdist or wheel
<nanographs>
Good ol structural shouldn't
<whitequark>
yep
<nanographs>
BTW the test instructions in the gist were very helpful
<nanographs>
Out of curiosity, is it likely to cause problems if I use a python version other than 3.7?
<whitequark>
3.6 and older will not work
<nanographs>
?
<nanographs>
Oh i see i read that wrong
<whitequark>
3.11 has some issues with the internal tests, but nothing user-exposed as long as you have new enough Amaranth, IIRC
<nanographs>
Was installing this with my friend and I think she had some issues on her system with 3.11 that she had previously installed the tool chain on
<whitequark>
it's possible, it's not very well tested on 3.11
<whitequark>
@VioletEternity has tested it on 3.11 recently and i think that worked?
jstein has quit [Quit: quit]
<d1b2>
<esden> ohh i have 3.11 on my Intel Mac here... I will give it a try...
<nanographs>
We are both on m1 so could always be something to do with that
<d1b2>
<esden> I have access to an m1 machine too... I should be able to test on there if I ask nicely. 🙂
<nanographs>
Well now that I've got it installed, might as well mention what we are trying to do with glasgow
<nanographs>
Its basiclly drive 2 14 parallel dac and a 14 ADC as fast as possible
<nanographs>
*14 bit
<whitequark>
oh neat
<whitequark>
what is your target?
<whitequark>
I know you said "as fast as possible" but as you get faster this starts to affect the overall system design more and more
<nanographs>
The DACs generating the x-y scan pattern in a SEM, and the ADC digitizing the video signal
<whitequark>
as I'm sure you're aware
<d1b2>
<Darius> cool
<d1b2>
<esden> I can imagine that a lot of the drive can be contained in the FPGA, and then only send the ADC output all the way back to the computer.
<whitequark>
yes
<nanographs>
Yeah, when I say as fast as possible the high end of this application is synchronizing deflectors to electron pulses generated by femtosecond lasers operating in the Ghz range, but that is not where we are starting out
<whitequark>
that would be way out of the range for Glasgow since it uses one of the slowest FPGAs on market
<nanographs>
If we could hit 20 mhz update and sample rate to start with that would be great
<whitequark>
what are the DACs/ADCs?
<nanographs>
Yeah, were not supporting those insane specs to start with. That is just what the people with the most $ to spend on beam control want...
<d1b2>
<esden> that is on the mac with python 3.11
<nanographs>
If we end up using a parallel adc, AD8047
<nanographs>
esden yup saw that error a lot on Friday when we first started trying things
<whitequark>
oh right, yeah, i forgot that @VioletEternity had to hack on her install to get it to run on 3.11
<whitequark>
nanographs: the problem here is that it's a 14 bit DAC (plus one clock bit) and you only have 16 pins on Glasgow
<whitequark>
without additional logic, one glasgow can only drive e.g. two DACs (with two clocks)
<nanographs>
Yeah, we have some logic buffers to flip between the dacs
<whitequark>
AD8047 is an opamp
<nanographs>
Yeah was looking at the wrong line in the list, LTC2246H
<nanographs>
Which is also a parallel ADC, which would mean we are doing read write on the same pins
<whitequark>
hmm, this is still challenging
<nanographs>
Yeah thats why we are not sure if we are going to go with a parallel adc on the first go around
<whitequark>
with a serial ADC you will struggle to meet the 20 Msps target
<nanographs>
We are very aware that eventually we will need more pins than glasgow has, but want to get used to using the fx2 cross bar before we just go spin our own hardware
<whitequark>
20*14 = 280 Mbps, which is above what the glasgow is rated for
<whitequark>
tbf, as much as I feel weird recommending against the use of my own design, I really feel like some of the FPGA+FT601 devboards would serve you better here
<nanographs>
Luckily, we don't need to get all of those bits over usb
<d1b2>
<esden> I would assume that in that application delta transfer could be used instead of transferring full raw bits.
<whitequark>
I will of course help you do what you want, but.
<whitequark>
no, I mean on the level translators
<tpw_rules>
how does FT601 compare to FX3?
<nanographs>
The need for that sampling speed is to be able to distinguish between individual electron events
<d1b2>
<esden> AHH yes
<d1b2>
<xyz> so from what I see in the chat log here, revC2 has issues and people are recommending to build revC1 instead. but should I go with the revC3 from the wip-revC3-hardware branch, or with the latest main branch revC1? additionally, are there any specific requirements for board impedance/stackup/thickness?
<whitequark>
3.3V to 3.3V propagation delay is, hm, 3ns worst
<nanographs>
so when operating in high speed scanning regime, its about reporting back when an electron hits relative to what the scan position is
<d1b2>
<esden> @xyz we are also gettin really close to getting the CS campaign fulfilled, so you could get a Glasgow there too. Unless you want to build one for the experience. 😉
<whitequark>
xyz: we're currently recommending revC2 to self-builders
<whitequark>
tpw_rules: less flexible, much easier to use, cheaper too I think
<d1b2>
<xyz> actually i bought it in the campaign but figured it's never getting delivered, so i'd rather build one myself and have it now
<nanographs>
When it comes time to just shovel bits to the computer, the scan speeds are lower
<d1b2>
<esden> @xyz it will get delivered.
<d1b2>
<xyz> but so, why revC2 over revC3?
<d1b2>
<xyz> that's great, in which case, I'll have a backup one
<nanographs>
Also at moderate high speeds we don't need all 14 bits
<whitequark>
because revC3 is still not in the repo
<nanographs>
Basically there is a spectrum between ultra fast but low bit count, and slow scan but high bit count
<whitequark>
I don't know; that branch is handled by our manufacturing partner (1b2)
<whitequark>
there are some interesting aspects to OSHW when the original design and the manufacturing run are handled by different entities
<d1b2>
<xyz> hmm okay maybe I could compare that against some photos of pcbs on crowdsupply
<whitequark>
or ask esden
<d1b2>
<xyz> well, I'm trying to
<d1b2>
<esden> @xyz There are a few patches that are not pushed yet. And they won't be until we have 100% validated the units we have here, and this will coincide with us shipping glasgows to mouser for CS fulfillment.
<d1b2>
<esden> This will also result in the branch being ready to be merged.
<d1b2>
<xyz> can you share the patches here, or at least some high-level details, with a footnote that they aren't validated yet?
<d1b2>
<esden> the problem is, that there might be things that we don't know about yet., if you build the non valid hardware, you will be a support liability. We do not want too many variants of the hardware in the wild to make support difficult. This is why you should build revC2 instead.
<whitequark>
this whole project is to me to a large extent an experiment to find out if you can do OSHW with a strong support policy without being annihilated by support requests from people doing weird things you never anticipated or were able to prepare for
lxdr has quit [Read error: Connection reset by peer]
<d1b2>
<esden> No it is correct. That said. There is always a chance for "things we don't know"
lxdr has joined #glasgow
<d1b2>
<esden> Although revC2 is still recommended, dragon got that part wrong.
<nanographs>
The kinda crazy thing with the SEM scan generator is what we are going up against in term of competition. The 1mz scan generator costs 12,000 and is just an fpga, 2 dacs, and 1x 4 channel adc
<nanographs>
The 20mhz one is into the 100-200k range
<d1b2>
<esden> And it is recommended due to "it is a stable hardware" and "minimizing variants in the wild"
<whitequark>
1mz?
<nanographs>
1mhz
<d1b2>
<esden> but if I was you @xyz I would just wait for the CS units to ship
<d1b2>
<esden> then you have the hardware fixes, and the final variant
<nanographs>
Yeah, and 1MHz is about as fast as you can go and for 14 bits to matter
<whitequark>
5 MHz and 10 MHz also sound reasonably ok, with a parallel ADC
<whitequark>
10 MHz with a serial 14-bit ADC is really pushing it
<nanographs>
As you start going faster you start to treat the signal more as individual events than a video signal with discrete steps
<d1b2>
<xyz> in the purely theoretical scenario that the boards never come (bus factor etc), will the final revC3 design be published? is there any timeline for that? or are we stuck with revC2 with known issues, for the foreseeable future?
<d1b2>
<esden> It will definitely be published. Independent of the campaign outcome.
<d1b2>
<xyz> ok thanks - I'll just wait for the revC3 to be finalized/etc
<nanographs>
Also thanks for the timing sanity check whitequark
<d1b2>
<esden> @xyz 👍
<nanographs>
It lines up with about what we were expecting for starting with glasgow
<nanographs>
What kinda of delay should we expect when changing the inputs from read to write and back?
<nanographs>
If we go with sharing all of the data pins for the ADC and DACs