00:53 <cr1901_modern> azonenberg rqou: Well, I tried looking for JTAG pins on a hard drive I own today (the pinouts on WD drives are known); it didn't work lol. If I wanted to do a full-blown scan, that would be 38 28AWG wires I'd have to solder, check for continuity, and then somehow attach to a micro w/ copious I/O. Surprised I even got 6 side-to-side soldered w/o causing a short. Ahhh well

00:54 <cr1901_modern> I wonder why the known pins didn't work; would help if I had an oscilloscope and/or logic analyzer

00:59 <ZipCPU|Laptop> Ever thought about turning a spare FPGA into a logic analyzer?

01:11 <cr1901_modern> ZipCPU|Laptop: Sssssssshhhhhhh!

01:12 <ZipCPU|Laptop> Well, ok, your call ...

01:12 <cr1901_modern> (Yes, I've done that a few times actually. I end up debugging them more than I spend time actually using them

01:14 <cr1901_modern> ZipCPU|Laptop: Serious followup ^

01:15 <ZipCPU|Laptop> Seriously?

01:15 <ZipCPU|Laptop> Would you rather know of where you could find a working logic analyzer that you could just download and plop into a design and use?

01:16 <ZipCPU|Laptop> (They're not that hard to build, I use them in my designs all the time, I've made my designs open source, etc, etc.)

01:16 <Zorix> saleae is kind of nice.. too bad its all closed and expensive as hell

01:17 <cr1901_modern> I mean, I don't think the problem is the gateware, but between the FPGA I/O and the signal I'm measuring, either the probes/cable don't pick it up or there's a reflection (b/c I have to improvise shoddily)

01:17 <ZipCPU|Laptop> That would make more sense.

01:18 <ZipCPU|Laptop> FYI: I spent much of June blogging about how to build such an open source analyzer at zipcpu.com.

01:18 <ZipCPU|Laptop> All of the code and examples are open source.

01:18 <ZipCPU|Laptop> Indeed, they make for my only LGPL project--I usually use GPL.

01:20 <jn__> ZipCPU|Laptop: have you seen this? https://blackmesalabs.wordpress.com/2016/10/24/sump2-96-msps-logic-analyzer-for-22/

01:21 <cr1901_modern> Somebody in this room has designed an FPGA logic analyzer (I think it was felix_); good front end makes a big difference, and well, just stick the signal directly into an FPGA pin with only a clamp isn't a great front end

01:21 <cr1901_modern> felix_: Do you remember a conversation of this sort (designing a good LA frontend)?

01:21 <ZipCPU|Laptop> jn__: No I haven't. I'm looking forward to reading it.

01:22 <ZipCPU|Laptop> Someone recently gave me a nice analyzer, with front end, from dangerous prototypes, but I couldn't find the FPGA source posted anywhere.

01:22 <jn__> ZipCPU|Laptop: not sure how detailed the blog post is, this was just a project that was presented at clifford's openfpga table at 33c3

01:22 <ZipCPU|Laptop> The buffers on the front end looked usable tho ...

01:23 <ZipCPU|Laptop> jn__: A small iCE FPGA configured as a logic analyzer would make a good clifford presentation.

01:25 <ZipCPU|Laptop> There is something to be said about a high speed LA, and my iCE work only gets up to about 40MHz. Still ...

01:26 <cr1901_modern> I got ZPU onto an ice40hx1k with about 4kB of RAM for a program

01:26 <cr1901_modern> but it's only ~29MHz... not sure why

01:26 <rqou> zpu sucks

01:27 <cr1901_modern> But it fits

01:27 <rqou> try navre?

01:27 <ZipCPU|Laptop> Yeah ... I was working on getting (wait for it ...) the ZipCPU up and running on an iCE40x8k. It fits, timing says it should run at 40MHz.

01:27 <jn__> this https://en.wikipedia.org/wiki/ZPU_(microprocessor)?

01:27 <cr1901_modern> jn__: Yea, it's a stack machine. Therefore it's slow

01:28 <ZipCPU|Laptop> The ZipCPU is a full 32-bit register machine, with two 16x register sets.

01:28 <ZipCPU|Laptop> Much more of a traditional architecture.

01:29 <cr1901_modern> rqou: I forgot about navre :P. That'll most probably work

01:29 <jn__> the J1 core (targeted at forth) was a nice read, but it's also my only exposure to stack machines so far

01:30 <cr1901_modern> rqou: Oh wait, according to opencores, no interrupt support

01:31 <rqou> i think someone other than sb0 added it afterwards

01:31 <rqou> don't know if it works

01:32 <awygle> curious, what does everyone use as a development environment when working on open-source HDL?

01:33 <rqou> sublime text?

01:33 <rqou> i don't normally use IDEs for anything at all

01:34 <ZipCPU|Laptop> Hello, awygle. My preferred development environment is "make" + "vim".

01:34 <cr1901_modern> Atom plus makefile. Or Atom plus custom build file if Migen

01:34 <ZipCPU|Laptop> Other tools I use include verilator and gtkwave.

01:35 <ZipCPU|Laptop> Beyond that, when I can I use the yosys toolchain, otherwise whatever (proprietary) toolchain comes with the chip I'm using.

01:37 <awygle> cool, thanks all

01:39 <awygle> ZipCPU|Laptop: i enjoyed your recent blog post on verilator. i'm still using iverilog, but i can see now why i might want to use verilator despite it seeming more complex on the surface

01:40 <ZipCPU|Laptop> Thank you, awygle! Hopefully the post, or even some of the examples that use Verilator, have helped to make it feel a touch less complex on the surface as well.

01:42 <cr1901_modern> rqou: Fwiw, I agree ZPU sucks (or at least is highly outdated). Just wanted to experiment

01:46 <awygle> ZipCPU|Laptop: somewhat. i think the main thing pushing me towards iverilog right now is that verilator is not sufficiently "automatic", and nothing i'm doing is yet complex enough for the added features to feel like a value add

01:47 <ZipCPU|Laptop> I can understand that.

01:47 <ZipCPU|Laptop> But ... complexity builds over timer.

01:48 <ZipCPU|Laptop> s/timer/time/

01:48 <awygle> oh absolutely, thus "yet"

01:49 <ZipCPU|Laptop> awygle: Did you see the article about the actual FPGA design process?

01:53 <awygle> ZipCPU|Laptop: you mean http://zipcpu.com/blog/2017/06/02/design-process.html ? i hadn't until now, no

01:53 <ZipCPU|Laptop> Yes, that one. I put it together after spending some time counseling a young FPGA designer who was ... struggling to get his final design working.

01:54 <ZipCPU|Laptop> It sort of forms the motivation behind a lot of what I have posted.

01:54 <ZipCPU|Laptop> Incidentally, the student came back and wrote a response for me later, describing some of his experiences.

01:55 <pointfree> jn__, cr1901_modern: There is some work on superscalar stack machines. Not sure that stack machines are necessarily slow or there just hasn't been as much work done on making them fast.

01:55 <pointfree> https://www.reddit.com/r/Forth/comments/58li6l/investigating_opportunities_for_instructionlevel/ https://www-users.cs.york.ac.uk/chrisb/

01:56 <awygle> ZipCPU|Laptop: I'm reading the student's response now

01:58 <awygle> i find myself wondering how much of it comes from the "fpga" element and how much from the "student"

01:58 <pointfree> also, http://fpgacpu.ca/stack/Second-Generation_Stack_Computer_Architecture.pdf

01:58 <rqou> i did a whole bunch of fpga "design" (of "homework" complexity) by going "hmm, signal <x> is changing in pipeline stage <y> but should be in <z>, adjust it"

01:58 <awygle> in the sense that even though i'm pretty new to fpga work, i feel like i've had many parallel experiences in PCB and C firmware work

01:58 <rqou> which is basically printf-debugging

01:59 <jn__> pointfree: i did not expect that

01:59 <jn__> pointfree: interesting.

01:59 <rqou> that design process also doesn't have steps such as "use formal verification"

01:59 <rqou> i guess nobody except clifford and "real asic companies" do that?

01:59 <awygle> rqou: speaking of things that aren't mentioned in the classroom lol

02:00 <rqou> oh yeah i was never taught formal

02:00 <awygle> all i ever learned about formal methods in school was "this is a fundamentally impossible task"

02:00 <awygle> which... isn't true

02:00 <awygle> except it kind of is

02:00 <awygle> depends on where you draw the boundaries i guess

02:01 <ZipCPU|Laptop> I do a lot of printf-based debugging. It's just ... too easy not to.

02:01 <ZipCPU|Laptop> The trick is ... getting an FPGA design to the point where you can do that. And I'm not just discussing components of an FPGA design either.

02:01 <awygle> currently trying to figure out how to get started with formal verification, clifford's presentations are pretty good for "how" but not so much "when" or "what"

02:03 <ZipCPU|Laptop> Yeah ... I've watched and enjoyed clifford's presentations as well, just ... I'm not sure where I'd start.

03:25 <cr1901_modern> His presentations don't help me answer the question: "What do I want to prove?"

03:27 <cr1901_modern> Well I want to prove that "the right outputs appear given arbitrary internal state* and given the correct input" XD

03:27 <cr1901_modern> *Except for state which is explicitly incompatible with said inputs/outputs.

03:28 <cr1901_modern> It would also be nice is the correct outputs results from incorrect inputs, to bastardize Babbage

03:46 <qu1j0t3> Babbadook

12:52 <felix_> cr1901_modern: yes, iirc we had some conversation about that

12:58 <felix_> clifford: this week i'm in vienna (currently sitting in the office of the apertus project) and i was discussing with herbert about things and we had the topic of artix7 reverse engineering; if you have some time and are interested in talking about and maybe even have a look at things, we'd like to meet with you

13:00 <clifford> felix_, how long are you in vienna?

13:01 <pie__> whitequark, know anz good quantum information science books_

13:04 <felix_> clifford: my flight home is on saturday; herbert says that friday would be a good day for the meeting

13:04 <whitequark> pie__: no

13:07 <clifford> ok. where? what time?

13:11 <felix_> clifford: at the apertus office (amescon) or somewhere else? maybe in the afternoon?

13:15 <clifford> The roof office in Witzelsbergergasse? Fine with me. Is 14:00 okay?

13:15 <felix_> yep, that office. 14:00 is good

13:15 <felix_> then friday 14:00 here

13:16 <clifford> okay. see you guys there

13:28 <qu1j0t3> pie__: that's a good question for Quadrescence if he were ever online

13:28 <pie__> oh.

16:52 <rqou> whitequark: (from your twitter RT) why is a missing newline at the end of a file allowed to spawn nasal demons rather than being implementation defined or an error?

16:53 <whitequark> rqou: because C is fucked up

16:54 <whitequark> more serious answer: because text files are defined to end with \n, and some vendor's compiler probably segfaulted encountering a source file that doesn't

16:55 <rqou> that's dumb

16:56 <rqou> i'd be pretty funny to write a maliciously compliant c compiler that replaces your entire program with pong or whatever whenever it encounters one of these "really silly" UBs

16:57 <whitequark> um

16:57 <whitequark> gcc 1.17?

16:57 <whitequark> it ran nethack upon encountering any #pragma

16:57 <rqou> lol i didn't know about that

16:57 <whitequark> that's IDB though

16:59 <rqou> "The characters ‘, \, “, //, or /* occur in the sequence between the < and > delimiters, or the characters ‘, \, //, or /* occur in the sequence between the ” delimiters, in a header name preprocessing token"

16:59 <rqou> why is this UB?

16:59 <rqou> wtf C

17:00 <rqou> also wtf linux i guess because ' and " and \ really can exist in filenames