<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
<cr1901_modern>
I wonder why the known pins didn't work; would help if I had an oscilloscope and/or logic analyzer
<ZipCPU|Laptop>
Ever thought about turning a spare FPGA into a logic analyzer?
<cr1901_modern>
ZipCPU|Laptop: Sssssssshhhhhhh!
<ZipCPU|Laptop>
Well, ok, your call ...
<cr1901_modern>
(Yes, I've done that a few times actually. I end up debugging them more than I spend time actually using them
<cr1901_modern>
ZipCPU|Laptop: Serious followup ^
<ZipCPU|Laptop>
Seriously?
<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?
<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.)
<Zorix>
saleae is kind of nice.. too bad its all closed and expensive as hell
<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)
<ZipCPU|Laptop>
That would make more sense.
<ZipCPU|Laptop>
FYI: I spent much of June blogging about how to build such an open source analyzer at zipcpu.com.
<ZipCPU|Laptop>
All of the code and examples are open source.
<ZipCPU|Laptop>
Indeed, they make for my only LGPL project--I usually use GPL.
<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
<cr1901_modern>
felix_: Do you remember a conversation of this sort (designing a good LA frontend)?
<ZipCPU|Laptop>
jn__: No I haven't. I'm looking forward to reading it.
<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.
<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
<ZipCPU|Laptop>
The buffers on the front end looked usable tho ...
<ZipCPU|Laptop>
jn__: A small iCE FPGA configured as a logic analyzer would make a good clifford presentation.
<ZipCPU|Laptop>
There is something to be said about a high speed LA, and my iCE work only gets up to about 40MHz. Still ...
<cr1901_modern>
I got ZPU onto an ice40hx1k with about 4kB of RAM for a program
<cr1901_modern>
but it's only ~29MHz... not sure why
<rqou>
zpu sucks
<cr1901_modern>
But it fits
<rqou>
try navre?
<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.
<cr1901_modern>
jn__: Yea, it's a stack machine. Therefore it's slow
<ZipCPU|Laptop>
The ZipCPU is a full 32-bit register machine, with two 16x register sets.
<ZipCPU|Laptop>
Much more of a traditional architecture.
<cr1901_modern>
rqou: I forgot about navre :P. That'll most probably work
<jn__>
the J1 core (targeted at forth) was a nice read, but it's also my only exposure to stack machines so far
<cr1901_modern>
rqou: Oh wait, according to opencores, no interrupt support
<rqou>
i think someone other than sb0 added it afterwards
<rqou>
don't know if it works
<awygle>
curious, what does everyone use as a development environment when working on open-source HDL?
<rqou>
sublime text?
<rqou>
i don't normally use IDEs for anything at all
<ZipCPU|Laptop>
Hello, awygle. My preferred development environment is "make" + "vim".
<cr1901_modern>
Atom plus makefile. Or Atom plus custom build file if Migen
<ZipCPU|Laptop>
Other tools I use include verilator and gtkwave.
<ZipCPU|Laptop>
Beyond that, when I can I use the yosys toolchain, otherwise whatever (proprietary) toolchain comes with the chip I'm using.
<awygle>
cool, thanks all
<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
<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.
<cr1901_modern>
rqou: Fwiw, I agree ZPU sucks (or at least is highly outdated). Just wanted to experiment
<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
<ZipCPU|Laptop>
I can understand that.
<ZipCPU|Laptop>
But ... complexity builds over timer.
<ZipCPU|Laptop>
s/timer/time/
<awygle>
oh absolutely, thus "yet"
<ZipCPU|Laptop>
awygle: Did you see the article about the actual FPGA design process?
<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.
<ZipCPU|Laptop>
It sort of forms the motivation behind a lot of what I have posted.
<ZipCPU|Laptop>
Incidentally, the student came back and wrote a response for me later, describing some of his experiences.
<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.
<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"
<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
<rqou>
which is basically printf-debugging
<jn__>
pointfree: i did not expect that
<jn__>
pointfree: interesting.
<rqou>
that design process also doesn't have steps such as "use formal verification"
<rqou>
i guess nobody except clifford and "real asic companies" do that?
<awygle>
rqou: speaking of things that aren't mentioned in the classroom lol
<rqou>
oh yeah i was never taught formal
<awygle>
all i ever learned about formal methods in school was "this is a fundamentally impossible task"
<awygle>
which... isn't true
<awygle>
except it kind of is
<awygle>
depends on where you draw the boundaries i guess
<ZipCPU|Laptop>
I do a lot of printf-based debugging. It's just ... too easy not to.
<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.
<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"
<ZipCPU|Laptop>
Yeah ... I've watched and enjoyed clifford's presentations as well, just ... I'm not sure where I'd start.
<cr1901_modern>
His presentations don't help me answer the question: "What do I want to prove?"
<cr1901_modern>
Well I want to prove that "the right outputs appear given arbitrary internal state* and given the correct input" XD
<cr1901_modern>
*Except for state which is explicitly incompatible with said inputs/outputs.
<cr1901_modern>
It would also be nice is the correct outputs results from incorrect inputs, to bastardize Babbage
_whitelogger has joined ##openfpga
<qu1j0t3>
Babbadook
eduardo_ has joined ##openfpga
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)]
eduardo__ has quit [Ping timeout: 260 seconds]
laintree has joined ##openfpga
laintoo__ has quit [Ping timeout: 240 seconds]
pie__ has quit [Ping timeout: 255 seconds]
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
pie__ has joined ##openfpga
Hootch has joined ##openfpga
clifford has joined ##openfpga
seu has joined ##openfpga
<felix_>
cr1901_modern: yes, iirc we had some conversation about that
<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
<clifford>
felix_, how long are you in vienna?
<pie__>
whitequark, know anz good quantum information science books_
<felix_>
clifford: my flight home is on saturday; herbert says that friday would be a good day for the meeting
<whitequark>
pie__: no
<clifford>
ok. where? what time?
<felix_>
clifford: at the apertus office (amescon) or somewhere else? maybe in the afternoon?
<clifford>
The roof office in Witzelsbergergasse? Fine with me. Is 14:00 okay?
<felix_>
yep, that office. 14:00 is good
<felix_>
then friday 14:00 here
<clifford>
okay. see you guys there
<qu1j0t3>
pie__: that's a good question for Quadrescence if he were ever online
<pie__>
oh.
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
pie__ has quit [Ping timeout: 276 seconds]
pie__ has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
X-Scale has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
amclain has joined ##openfpga
pie_ has joined ##openfpga
m_w has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
azonenberg_work has quit [Ping timeout: 246 seconds]
<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?
<whitequark>
rqou: because C is fucked up
<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
<rqou>
that's dumb
<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
<whitequark>
um
<whitequark>
gcc 1.17?
<whitequark>
it ran nethack upon encountering any #pragma
<rqou>
lol i didn't know about that
<whitequark>
that's IDB though
<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"
<rqou>
why is this UB?
<rqou>
wtf C
philpem has joined ##openfpga
<rqou>
also wtf linux i guess because ' and " and \ really can exist in filenames
Zarutian has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow1 has joined ##openfpga
pie_ has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
azonenberg_work has quit [Ping timeout: 258 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
digshadow1 has quit [Quit: Leaving.]
zino has quit [Ping timeout: 255 seconds]
philpem has quit [Ping timeout: 246 seconds]
philpem has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
Hootch has quit [Ping timeout: 260 seconds]
azonenberg_work has joined ##openfpga
mifune has quit [Ping timeout: 248 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
oeuf has joined ##openfpga
uovo has quit [Ping timeout: 240 seconds]
mifune has quit [Ping timeout: 240 seconds]
promach__ has joined ##openfpga
promach__ has quit [Remote host closed the connection]
digshadow has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 276 seconds]
azonenberg_work has quit [Ping timeout: 240 seconds]