03:45 <Snoop31232> hello

12:25 <d1b2> <stefandeml> Hello every one, super interesting project and thanks for all the effort! quick question: how well could it be used as a logic analzyer? Like how much samples could be stored on device and fast can they be streamed to PC out the box? Is there planned support for Salea Logic? Thanks!

12:27 <stefandeml> Hello every one,

12:27 <stefandeml> super interesting project and thanks for all the effort!

12:27 <stefandeml> quick question: how well could it be used as a logic analzyer?

12:27 <stefandeml> Like how much samples could be stored on device and fast can they be streamed to PC out the box?

12:27 <stefandeml> Is there planned support for Salea Logic?

12:27 <stefandeml> Thanks!

13:08 <d1b2> <icb> Saleae's software is only meant to be used with their hardware. The logic analyzer applet writes VCD files that you can read with PulseView https://sigrok.org/wiki/PulseView and other open source software. The applet doesn't store samples on device, so is limited by USB throughput

13:08 <d1b2> <DX-MON> there is already the analyzer applet (glasgow run analyzer -h for more) which supports logic analysis and capture

13:11 <d1b2> <DX-MON> tbqh.. I suspect Glasgow's applet is more powerful than Saleae's analysers, or at least as powerful.. if nothing else than because you can extend the applet to do any kind of decode and triggering you like and you can use VCD viewers such as PulseView and GTKWave to apply any decoders you like.. not just the ones a company thought of for you, but any the community has written - or you are prepared to write and integrate into these tools.

13:48 <d1b2> <stefandeml> thanks for getting back! that looks promising. Just ordered one to play around 🙂 So I guess there is no plan to add any kind of flash which would allow storage of samples on device?

13:57 <d1b2> <DX-MON> there is flash on the board.. however that's for firmware and being able to sore a bitstream for the FPGA in case, for example, you want your Glasgow to boot as a tester for some thing and you don't want/need the PC connection so it can spit out some test sequence or test pattern and be quick-use used offline

13:58 <d1b2> <DX-MON> the two devices are labled "FX2MEM" and "ICE_MEM" fwiw

14:00 <d1b2> <DX-MON> usually, the "ICE_MEM" flash is empty though.

14:07 <d1b2> <icb> A RAM expansion board is being considered (scroll back in the channel history to see the discussion) that could buffer samples during bursts of activity. The FPGA also has a small amount of BRAM that could be used to buffer a small number of samples

14:55 <tomtastic> I think the Saleae stream their captures also, rather than storing anything in flash.

17:12 <kmc> DX-MON: for the record Saleae's software supports analysis plugins too https://support.saleae.com/saleae-api-and-sdk/protocol-analyzer-sdk

17:12 <d1b2> <DX-MON> til

17:12 <kmc> and they actually provide source for many (all?) of the bundled analyzers

17:12 <kmc> i've never tried to write one so I don't know how hard it is

17:13 <d1b2> <DX-MON> lots of thread-sync.. looks.. unpleasant but not unexpected

17:13 <d1b2> <DX-MON> also already spotted some really bad code in their USB analyser V_V

17:13 <d1b2> <TiltMeSenpai> oh no saelae

17:14 <d1b2> <DX-MON> definition-without-initialisation stuff

17:14 <d1b2> <TiltMeSenpai> I tried to write an LPC decoder at one point and

17:14 <d1b2> <TiltMeSenpai> not a good experience, their api documentation is pretty much "read existing decoders"

17:15 <d1b2> <TiltMeSenpai> combined with the fact that decoders are in C++, so a bug just crashes the program, not the most pleasant time

17:15 <d1b2> <DX-MON> oh.. even better.. definition of a variable in a way which actively pessimises it to be forced to the stack when it could have been registers and could even possibly been dead-code analysed out

17:15 <d1b2> <DX-MON> I'll.. close that before it drives me mad

17:16 <kmc> lol

17:16 <d1b2> <DX-MON> The decoders being written in C++ isn't itself a problem.. you can write good C++ that is hard to if not impossible to crash if you use the stdlib properly.. however.. what I've read so far there is not good C++

17:17 <d1b2> <DX-MON> it's C++ that's "good enough" to make a product while papering over the crimes they're committing

17:17 <d1b2> <TiltMeSenpai> well I have no doubt a more skilled c++ programmer would have less of a problem with them written in C++, but I barely count as competent

17:17 <d1b2> <DX-MON> ie, brittle

17:17 <d1b2> <TiltMeSenpai> I

17:17 <d1b2> <TiltMeSenpai> I'm aware of the syntax and sometimes write programs that don't crash

17:18 <d1b2> <DX-MON> heh, fair.. you should come watch my streams sometime as I write a lot of C++ and I aim for them to be educational

17:20 <kmc> stefandeml: your question about streaming samples to flash makes me wonder how hard it would be to attach a SATA drive to a Glasgow :)

17:21 <kmc> probably not that hard, since it's only 2 differential pairs

17:21 <d1b2> <DX-MON> probably doable via the LVDS header and a SERDES on an add-on board.. but I imagine it wouldn't be particularly fun to do

17:21 <kmc> yeah

17:21 <kmc> I guess the FPGA clock is too slow to do it directly

17:21 <d1b2> <DX-MON> it's "only" 2 diff pairs.. but they are rather fast at 1.5 or 3GHz IIRC

17:21 <d1b2> <DX-MON> (for gen 2, 3GiB/s, and gen 3 6GiB/s respectively)

17:21 <kmc> and there's no serdes built into the iCE40?

17:22 <d1b2> <DX-MON> if there is.. I don't recall it being exposed on the LVDS header.. and even then I wouldn't be surprised if it's not quite fast enough

17:23 <modwizcode> I was trying to nail down the actual signalling rates for SATA but it seems it's faster than GbE and whitequark already mentioned that that's not possible.

17:23 <mwk> 1.5gbps

17:23 <mwk> and yeah, not possible to directly interface

17:24 <d1b2> <DX-MON> yay, I did remember it correctly ^_^

17:24 <mwk> just stream to the host and let it save stuff to sata

17:24 <d1b2> <DX-MON> you can probably do it by LVDS signalling over 8 pairs in each direction to a SERDES.. because that's an effective data rate divide of 8

17:25 <d1b2> <DX-MON> but yeah.. stream to host.. easier, better

17:25 <d1b2> <TiltMeSenpai> I think the ice40's have a gearbox but not a full blown serdes

17:25 <d1b2> <TiltMeSenpai> like the ecp5 serdes also has rx cdr and stuff

17:25 <modwizcode> I can't keep lattice's product catalog straight

17:25 <d1b2> <TiltMeSenpai> also the ice40 gearbox wouldn't be anywhere close enough to handle 1.5gbps

17:25 <modwizcode> it's weird to me to see a device without any serdes peripherals

17:27 <d1b2> <TiltMeSenpai> or looking at the nmigen code, maybe ice40 only has ddr?

17:27 <mwk> nmigen has patchy support for xdr primitives either way, so don't trust it

17:36 <modwizcode> I couldn't find any docs on the Lattice site that implied any support beyond DDR primitives

17:39 <d1b2> <daveshah> Yeah only DDR is supported

22:24 <electronic_eel> just showed my glasgow to a friend and noticed that we do not have a url with more info on the pcb

22:24 <electronic_eel> googling yielded the city first

22:25 <electronic_eel> so how about putting a url on the back?

22:25 <electronic_eel> probably a github shortener

22:43 <electronic_eel> what i did was i gave them the pcb "here, you can solve your problem with it" and watched what they did and what problems they encountered

22:44 <electronic_eel> took them some unnecessary time finding the glasgow github page with the install instructions. this is what i'd like to improve with the url on the silkscreen

22:45 <electronic_eel> installing the python stuff and using it went well afterwards

22:53 <uberushaximus> https://git.io/JtvvZ ?

23:01 <electronic_eel> yeah, something like that

23:52 <kmc> could have a QR code as well

23:53 <kmc> wonder how much it would cost to buy glasgow.io

23:55 <d1b2> <Attie> esden registered glasgow-embedded.org, and aiui plans to transfer to whitequark after the cs campaign... would be my vote I think.