genii has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
mmicko has quit [Quit: leaving]
mmicko has joined ##openfpga
Bob_Dole has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 250 seconds]
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
_whitelogger has joined ##openfpga
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
dj_pi has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 260 seconds]
ClausPillow has quit [Ping timeout: 252 seconds]
futarisIRCcloud has joined ##openfpga
CounterPillow has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
dx has quit [Ping timeout: 264 seconds]
CounterPillow is now known as ClausPillow
dx has joined ##openfpga
Bike_ has quit [Quit: Lost terminal]
Flea86 has joined ##openfpga
rohitksingh_work has joined ##openfpga
Miyu has quit [Ping timeout: 244 seconds]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
_whitenotifier has quit [Remote host closed the connection]
catplant has quit [Quit: WeeChat 2.2]
_whitenotifier has joined ##openfpga
<_whitenotifier>
[Glasgow] whitequark commented on commit 775fdc0388aa360a7ed9915ed8dc9fcd0eaa3202 - https://git.io/fpF3F
catplant has joined ##openfpga
azonenberg_work has quit [Ping timeout: 250 seconds]
azonenberg_work has joined ##openfpga
catplant is now known as catdemon
GuzTech has joined ##openfpga
m4ssi has joined ##openfpga
GuzTech has quit [Quit: Leaving]
GuzTech has joined ##openfpga
<TD-Linux>
reddit was a mistkae
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
s_frit has quit [Remote host closed the connection]
catdemon has quit [Ping timeout: 252 seconds]
s_frit has joined ##openfpga
<tnt>
"was" ?
<swetland>
ahaha
Bob_Dole has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
<jn__>
in the sense that it *was* created
<tnt>
and there for a second I had hoped it was over.
<swetland>
I am moderately amused by the seething "nothing's good enough, all foss is shit and never will be useful" guy
<swetland>
just because it's funny to watch people be so committed to being so very wrong
<daveshah>
There's a particularly annoying "this one use case that 0.001% people have will never be solved by FOSS tools --> FOSS tools are useless"
<daveshah>
Which is obviously stupid
<daveshah>
0.001% of people buy Intel C/C++, but most are happy with g++/clang
<swetland>
I've spent a career using gcc instead of paying $7500/seat for ARM's compilers
<whitequark>
>
<whitequark>
You’re looking down on DSLs on top of Verilog to write RTL. Are you seriously saying that you are using the pure thing and that you don’t have an additional layer at your company? Can you be my competitor please?
<whitequark>
gold.
<swetland>
and we shipped a few billion phones that way. and I don't believe cupertino ever used ARM's toolchain, but even if so they've long since shifted to llvm
<swetland>
whitequark: I regret I had only one upvote to give that reply
<swetland>
I also think all the folks (how many of them are employees one wonders) obsessed over the economics for fpga companies fail to take into account the value and economics for their customers
<swetland>
because I'm sure vendors love exclusivity but as a customer I know I love portability and multiple source options and integration
<daveshah>
The whole "you'll never figure out the timing model" thing is stupid too
<daveshah>
For the most part it's just a case of some simple linear algebra
<azonenberg_work>
daveshah: i reverse engineered the auntie anne's pretzel recipe with gauss-jordan elimination
<azonenberg_work>
in one night with my ex, a copy of the nutrition facts from their website
<azonenberg_work>
and some info from the USDA on nutrition content of each ingredient
<daveshah>
lmao
<azonenberg_work>
it ended up being an equation of 4 variables in 4 unknowns with a bit of rounding error
<tnt>
I always found the best way to prove something's possible is not to argue with naysayer, but to actually do it ... so /me goes back to coding :p
<daveshah>
Yes, other than correcting the odd factual error I haven't bothered arguing the philosophical/economic ones#
<daveshah>
Mostly the "you'll never figure out the transceivers", which is so annoying because I have
<azonenberg_work>
lol
<azonenberg_work>
people told me fpga bitstream was impossible
<azonenberg_work>
then i went and did it
<azonenberg_work>
And published my findings at a conference
<whitequark>
tnt: in my case it's amusing because i've often have already done that
<whitequark>
tnt: like some guy on twitter ercently tried to argue that rust is a toy that will never be possible to use with real embedded
<whitequark>
well guess what bitch
<tnt>
:)
<swetland>
I really wish modern languages were a bit less obsessive about bespoke packaging systems and a little better about library layering
<swetland>
but burn one bridge at a time, I guess ^^
<whitequark>
i mean, i think they would be if distro packaging systems weren't so uniformly terrible
<whitequark>
have you tried to package anything for dpkg?
<azonenberg_work>
i use cpack
<whitequark>
it's distinctly reminiscent of kafka
<swetland>
oh that's a whole 'nother can of worms
<azonenberg_work>
i'll never get into the debian repos this way
<azonenberg_work>
but it works
<whitequark>
cpack is ok for "i'm an ISV" use case
<azonenberg_work>
(they wont let you use any package generators, you MUST write raw dpkg configs)
<whitequark>
i mean, cpack's generator is kinda terrible
<swetland>
I just mean that I would like to be able to drive compilers/linkers from make and *not* be obligated to push everything through some very opinionated packaging system
<whitequark>
swetland: pretty sure every existing language lets you do that
<swetland>
or cmake or jam or ninja or whatever
<whitequark>
like, rust and ocaml definitely let you
<whitequark>
in case of ocaml though? this is INCREDIBLY painful to do due to the fact that ocamldep (-MMD) is *mandatory* and has to be *precise*
<swetland>
the docs push you pretty hard toward crates and such, and figuring out how to build stuff directly has been somewhat obscure the last couple times I've looked
<whitequark>
so if you hate yourself (and there are plenty of people who hate themselves) you can drive it from shell scripts even
<whitequark>
but the user experience is shit
<whitequark>
yes
<whitequark>
this happens because the user experience of this is shit.
<whitequark>
90% of such bespoke makefiles do not handle cross compilation, for example
<whitequark>
I know because I wrote opam-cross-{android,windows,ios}
<whitequark>
and I had to patch every single one of them, usually with three different patches
<azonenberg_work>
meanwhile Splash, if i ever get it working, will ONLY be cross compilation
<whitequark>
well guess what, screw you and your shitty makefiles
<azonenberg_work>
you can cross compile for your native platform, if you so choose
<azonenberg_work>
But you need to specify a triplet to get a binary, period
<whitequark>
i do not want to deal with your shitty bespoke build system ever period
<swetland>
people who build large systems have different needs than people building applications. being able to integrate with system specific build systems (especially if say your large system is not entirely of one specific language) is a nice thing
<whitequark>
at least, with cargo, i only have to suffer once
<whitequark>
cargo has that as one of the explicit milestone goals
<azonenberg_work>
swetland: yeah that was the goal splash was intended to solve
<whitequark>
i think it's not entirely there
<whitequark>
however, do note that firefox is a major consumer of rust libraries that has this problem
<whitequark>
so mozilla has a direct incentive to fix it
<azonenberg_work>
i wanted parallel building, caching, and good cross language dependency tracking for (at minimum) c/c++, (system)verilog, and assembly
<swetland>
I also just am weirded out by the insane level of base dependencies these things bring in
<swetland>
full network/crypto/https/etc stack, 50-100 external package deps... at least that's just for cargo itself, not for the actual compiler
<whitequark>
that's very reasonable
<swetland>
I admit that I built operating systems for a living, which is not the typical use case
<whitequark>
package management is a hard problem, it is natural that you need a lot of dependencies to handle it well
<swetland>
and I am a bit obsessive about trying to keep system deps as an inverted triangle with very little at the point besides the core toolchain
<whitequark>
and *specifically* openssl is nothing but pain
<whitequark>
i've last hit a bullshit openssl bug caused by an interaction between distros, openssl upstream, and cargo packages, uhh, a week ago?
<whitequark>
and it took me hours to diagnose and fix it
<swetland>
and to be fair, I have no complaint about there being a friendly/easy package-y system and that being the default workflow that getting started guides and such prefer and encourage
<whitequark>
on windows at least cargo links to tlswhatever which is reasonably sane, though it comes with its own issues
<whitequark>
like cargo plain out breaking on windows 7 that can't handle sha-512 or something
<swetland>
I just wish that there was a little time devoted to documenting the tool flow under the hood for folks wanting to integrate into different systems
<swetland>
regarding "embedded", has the situation changed regarding library layering? the last couple times I've tried it seems like either you use "bare metal" rust and you get basically nothing from the standard libraries, or you need a pretty extensive libc (once had to be glibc, ugh) to stack the mid-level stdlibs on top of
<swetland>
which starts to be a pretty large pile of software if you're looking at little MCUs or the like
<whitequark>
swetland: there's a sort of embedded stdlib now taking shape
<whitequark>
though i was talking about the fact that i wrote a TCP/IP stack for MCUs with Rust
<whitequark>
and, well, yeah, tell me how Rust can't do that
<swetland>
ahaha, indeed
Miyu has joined ##openfpga
<swetland>
yay, embedded/light/stacked stdlib. that's the main feature I've been looking for before investing more time/effort. I'd like to be able to use as much of the regular/idiomatic language as possible without having to reinvent chunks of the stdlib when aiming for small targets.
<whitequark>
so, there is a "light" built-in stdlib, it is called libcore.
<whitequark>
it has nothing that allocates, but you have fairly advanced things
<whitequark>
like utf-8 support and various data structures and algorithms
<whitequark>
on top of that you have liballoc, which only adds a requirement for a heap
<whitequark>
that recently went stable
<whitequark>
iirc?
<swetland>
I'll have to take a look. been a while since I last poked at rust
<whitequark>
and people also write MCU-specific libraries, there is code for abstracting away SPI etc
<swetland>
It's been one of those "some potential here, maybe next time" things
<whitequark>
yeah I've been using it for embedded for, uh, probably years at this point?
<whitequark>
extensively
<swetland>
I'm an old fart and 30ish years of relying on C makes it often faster to just keep using it for small stuff, but I do feel like we're overdue for a nextgen systems language and rust seems like it might work out. C++ just keeps getting crazier.
Miyu has quit [Ping timeout: 245 seconds]
<whitequark>
yeah, I understand that
<swetland>
okay, citing 1000-person-years of vivado development may be the new funniest thing in that thread
* azonenberg_work
suspects that f/oss fpga tools will never include an "IP integrator"
<azonenberg_work>
and is entirely OK with that
<swetland>
holy shit vivado IPI is the most horrible thing ever
<azonenberg_work>
lol
<swetland>
I spent a week or two trying to figure out how to make that workflow work and play nice with revision control and ended up ditching all of it and just writing a Go program to generate wrappers around the PS7 hard macro
<azonenberg_work>
incidentally, i did the same for antikernel
<azonenberg_work>
i created a DSL to define the nodes in the NoC
<azonenberg_work>
it would assign them to addresses, create mappings in the name server table, and create routers
<swetland>
I was on a ooh, systemverilog new and shiny kick
<azonenberg_work>
never would i ever want a gui for that
<swetland>
so I threw together sv interfaces for AXI which were pretty easy to work with and wrapped that around the PS7 programatically and off it went
<swetland>
and "wiring" up the top level with sv interfaces meant the underlying verilog was actually human readable
<swetland>
which I dunno if you ever looked at the goop ipi generates...
<whitequark>
azonenberg_work: re IP integrator: that already exists I think
<whitequark>
some weird GUI thing
<whitequark>
scanlime played with it a bit
<whitequark>
and there's also fusesoc...
<swetland>
later in the project we hired a "real" digital designer to augment and eventually take over and he was utterly blown away by the fact that I was driving all the xilinx tooling from makefiles... had no idea you could do that... apparently pushed a lot of buttons in GUIs in his previous jobs
<azonenberg_work>
whitequark: that is the name
<azonenberg_work>
vivado ip integrator
<azonenberg_work>
swetland: my old ise flow was driven by shell scripts autogenerated from a C++ parallel build system
<azonenberg_work>
vivado i just use the gui because i havent had time to sit down and rewrite everything the way i want it yet
<azonenberg_work>
too busy making sure my lab has walls and floors and a ceiling
<whitequark>
azonenberg_work: no I mean the open-source equivalent of it
<azonenberg_work>
oh
<whitequark>
i dont recall the name
<swetland>
I actually think there's a place for something *like* IPI, but for one thing you're really want it to be vendor/toolchain agnostic, and well documented under the hood
<swetland>
like the idea of having a way of describing various interconnects (axi, wishbone, etc) and modules that can work with 'em, and how to instantiate bridges/crossbars/cdc-crossing-fifos/etc, so you can snap stuff together seems sane enough
<swetland>
you just want it built by somebody competent and neutral
<zkms>
whitequark: icestudio?
<azonenberg_work>
swetland: i would also make it driven by a domain specific HDL
<azonenberg_work>
i..e one that works at the bus level and cant do RTL
<azonenberg_work>
just ports and parameterized modules
<azonenberg_work>
certianly not graphical
<azonenberg_work>
and not a giant pile of XML
* swetland
nods
<azonenberg_work>
human authorable text languages are much more diffable
<azonenberg_work>
which is a big deal if you're doing code reviews
<azonenberg_work>
(you are, right?)
<azonenberg_work>
x:po
<azonenberg_work>
:p *
<swetland>
XML has the advantage of being inefficient for both human and computer parsing
<azonenberg_work>
exactly
<azonenberg_work>
json is much more human readable but even so, i think something else would be better for this
<azonenberg_work>
i'm wondering about a strict subset of systemverilog maybe
<azonenberg_work>
that removes all of the rtl stuff but keeps the same syntax
<azonenberg_work>
then maybe adds some keywords for declaring types of bus or something
<swetland>
perhaps. you only get module definitions
<azonenberg_work>
exactly, structural only
<swetland>
and interface defs
<azonenberg_work>
side note, i basically dont use interfaces because vivado's support is so bad
<whitequark>
zkms: yes!
<azonenberg_work>
instead i hack and use a struct in and a struct out
<swetland>
the biggest problem with v/sv for snap-together components is you cannot parameterize the actual nets going in/out
<azonenberg_work>
this is awful but works, and you can create arrays of them
<azonenberg_work>
vivado refuses to synth arrays of interfaces last i checked
<whitequark>
(whispers) or you could just use migen
<whitequark>
like. literally just use migen for ipi
<whitequark>
this is the problem migen was designed to solve
<zkms>
i want to try migen or another one of those thingies that lives above verilog
<zkms>
i only know verilog ;;
<azonenberg_work>
whitequark: no sneks allowed in my fpgas :p
<swetland>
what are the deps for migen? just python?
<whitequark>
swetland: yes
<whitequark>
azonenberg_work: why not? it's not any worse than verilog itself, for sure
<swetland>
I'm always wary of systems-built-on-python having run into python fragility in the past (awesome fast for protyping, pain in the butt to maintain)...
<whitequark>
swetland: so, there's nmigen
<swetland>
but especially as it's like pulling teeth to get vendors and others to support reasonable sv features...
<whitequark>
and i'm... literally a professional programming language designer, working hard to avoid python fragility
<whitequark>
when making nmigen
<swetland>
something higher level to generate verilog does have an appeal
<azonenberg_work>
biggest reason? i hate writing python
<whitequark>
if you encounter any fragility in nmigen? please file a bug, i take these things extremely seriously
<azonenberg_work>
:p
* swetland
nods
<whitequark>
azonenberg_work: ok i cant argue with that
<whitequark>
azonenberg_work: i also detest python, but less than i detest writing verilog
<oeuf>
clearly the answer is to write vhdl
* oeuf
hides
* whitequark
stabs oeuf
<swetland>
I have never run into any vhdl proponents (apart from that guy in that reddit thread)
* azonenberg_work
hides behind systemverilog
<azonenberg_work>
swetland: you havent spent much time in ##fpga
<swetland>
I hear it's more of an east coast thing
<azonenberg_work>
MatthiasM is a huge fan of it
<azonenberg_work>
does Germany count as east coast? :p
<whitequark>
i know a russian guy who really loves ada
<azonenberg_work>
I learned verilog while in school in NY but the school taught VHDL
<whitequark>
well, knew
<azonenberg_work>
i switched to verilog as fast as i could
<whitequark>
he made an rtos for arm in ada
<swetland>
well I'm sure Europe has its own preferences, but as a product of the US public education system I may be hard pressed to find it on a map
<whitequark>
lmao
<swetland>
I figure I can find Germany by looking for the Amiga democoders
<oeuf>
whitequark: Ada is nice for its time tbh
<whitequark>
yes
<whitequark>
but the FOSS tooling is nonexistent, for one
<whitequark>
(no, gnat is not ... a ... thing ... you can use)
<oeuf>
I am very aware that GNAT is crap
<whitequark>
also i really hate how bsdl is stringly typed
<whitequark>
it's nominally ada based but most of the interesting information is stuck in string literals.
<oeuf>
...
<oeuf>
WHYYYYYYYYYYYYYYY
<whitequark>
so you have to parse ada AND parse its weird sublanguage
<whitequark>
incredible
<mwk>
isn't it nominally vhdl based?
<mwk>
might... be the same thing
<whitequark>
which is an ada subset?
<mwk>
um what
<oeuf>
well, was initially based on an Ada 83 subset
<mwk>
really?
<whitequark>
yes
<oeuf>
but Ada diverged, and so did VHDL
<whitequark>
ah
<oeuf>
afaict they added lots of weird weird crud on the VHDL side
<whitequark>
that's HDL designers for you
<oeuf>
but still, you have all the fancy generics and can spawn types as much as you want, and you stringly-type things?????
<whitequark>
"lots of weird crud" is like a rite of passage
<mwk>
as in, I can actually write a SoC in VHDL and compile it with ada compiler and run it?
<whitequark>
no
* oeuf
slaps HDL designers with a trout
<whitequark>
it's a syntactic subset i think
<oeuf>
no, but you have all the generics system that comes from 83
<swetland>
I think we can count our blessings that there wasn't a more clunky scripting language than TCL around when they all settled on TCL
<oeuf>
with compile-time bignum rationals \o/
* azonenberg_work
replaces oeuf's trout with a half-ton tuna
<azonenberg_work>
that's more appropriate
<oeuf>
azonenberg_work: but then I can't lift the tuna
<whitequark>
swetland: like... ant's xml programming language?
<swetland>
oh gods
<whitequark>
hahahahaha
<oeuf>
also um it's 6 past noon
<oeuf>
maybe i should consider going to work
<whitequark>
i can *totally* see xilinx using something like that
<whitequark>
it's enterprise!
<mwk>
oh gods everything is horrible.
<oeuf>
or out of bed at least
<swetland>
well vivado is *full* of xml
<whitequark>
actually i'm pretty sure diamond actually uses that
<swetland>
and ipi
<whitequark>
well not ant exactly
<swetland>
so there's this unholy fusion of xml and tcl going on
<mwk>
diamond is the lattice's turd, right?
<azonenberg_work>
oeuf: you're supposed to swing it like a wrecking ball
<whitequark>
yes
<azonenberg_work>
so everything goes flying
<swetland>
with the added bonus that it takes frakkin forever to start up because java
<whitequark>
of course it has java in it.
<whitequark>
of course.
* mwk
ponders
<whitequark>
does it shell out to tcl, too?
<oeuf>
azonenberg_work: but wait, whitequark is an HDL designer now, I don't want to slap her with fish
<swetland>
what did you think those engineers were doing for those 1000-person-years of coding?
<azonenberg_work>
oeuf: i meant vhdl designers
<whitequark>
oeuf: i've seen worse
<mwk>
did they actually make a tcl interpreter in java... oh hell, why not
* oeuf
feeds the trout to whitequark and her cats
<azonenberg_work>
like, the designers of vhdl
<swetland>
I mean they clearly weren't implementing useful features
<azonenberg_work>
swetland: i'm kidna surprised the xilinx design database format isn't xml with one bit per tag
<whitequark>
swetland: lmao
<whitequark>
azonenberg_work: please don't give them ideas
<whitequark>
it takes enough disk space alredy
<azonenberg_work>
swetland: waiting for vivado, duh
<whitequark>
"waiting for vivado" like in "waiting for godot"
<azonenberg_work>
whitequark: i was only half joking
<swetland>
whitequark: are you familiar with COLADA?
<whitequark>
actually thats pretty accurate for ultrascale
<azonenberg_work>
youve seen the greenpak and jed formats right?
<whitequark>
azonenberg_work: greenpak yeah
<swetland>
xml interchange format for 3d visual goop, heavily used in the fx industry
<whitequark>
jed yes i think? but it's one bit per character
<whitequark>
so it's ok?
<azonenberg_work>
yeah, ish
<azonenberg_work>
lol
<swetland>
think 3d meshes represented as double precision fp in text in quoted lists in xml
<whitequark>
i mean, just gzip it if you care
<whitequark>
swetland: oh god thats horrifying
<whitequark>
and yes, i have seen it
<oeuf>
also it pings me
<whitequark>
and then erased it from my memory
<whitequark>
and now i have to know about it again
<whitequark>
thanks i hate it
* oeuf
pets whitequark
<swetland>
I'm personally convinced COLADA is a trojan horse invented by sales engineers in the Network Attached Storage industry to justify sales of high end SAN gear
<whitequark>
ahaha
<whitequark>
wait
<whitequark>
do they at least compress it?
<whitequark>
or is it ... just ... xml
<swetland>
I honestly don't know
<swetland>
it's one of those things I try to know very little about
<azonenberg_work>
whitequark: considering how many high end san vendors advertise transparent compression and deduplication
<swetland>
because whenever I learn more, it's just more awful
<mwk>
it's for the best
<azonenberg_work>
their customers are clearly extremely wasteful of data
<azonenberg_work>
whitequark: well the worst part about jed is how it's used
<azonenberg_work>
its supposed to be raw data you can program a chip with
<azonenberg_work>
but at least for coolrunner it's virtually addressed
<whitequark>
oh yeah
<azonenberg_work>
you have to convert those to physical addresses, and the conversion uses a database stored as a tab separted file of ascii integers
<azonenberg_work>
i can procedurally generate that permutation in a fraction of the time it takes to parse the dump
<whitequark>
what.
<whitequark>
WHAT.
<whitequark>
how do i unlearn that.
<mwk>
oh yeah, that...
<azonenberg_work>
incidentally, all third party programmers that i know of require you copy this file from an ise install, or illegally distribute the copyrighted db file, or have a license from xilinx to distribute it
<azonenberg_work>
i can do the same permutation without ever copying that file by procedurally mapping
<azonenberg_work>
and my procedural implementation actually is readable and makes sense given the chip structure
<azonenberg_work>
vs being columns of numbers with no rhyme or reason obvious
<whitequark>
swetland: pulseview
<swetland>
does it understand trace files (eg, is it a useful alternative to gtkwave)?
<whitequark>
yes and no
<whitequark>
it can't deal with bit vectors
<swetland>
ah found a file format list which includes vcd
<swetland>
doh
<whitequark>
i've complained about it and there are plans to fix it
<whitequark>
"someday"
<swetland>
it looks very pretty
<whitequark>
however, you can definitely use it to e.g. debug your USB core
<whitequark>
with the protocol decoders
<whitequark>
it's slightly slower thang gtkwave. uses mipmaps but a less powerful version
<whitequark>
and it's pretty good overall
<swetland>
wow look at all those protocol decoders
<whitequark>
yeah it has a fuckton of decoders
<whitequark>
mostof them can be used in many ways
<azonenberg_work>
it doesnt even have 100base-TX last i checked
<whitequark>
e.g. you can run the SPI flash decoder and extract a eeprom file
<swetland>
okay this goes on the list of nifty tools
<swetland>
oh cute
<whitequark>
or you can run the UART decoder and tell it to print the text to your terminal
<azonenberg_work>
it cant do eye diagrams, it's not fast enough to do high bandwidth captures
<azonenberg_work>
(many kWFM/s)
<whitequark>
azonenberg_work: most people dont need any of that
<azonenberg_work>
it's not suitable for replacing a dso or la
<azonenberg_work>
Which is what i want :p
<whitequark>
it is definitely suitable for replacing an la
<whitequark>
dso, nope
<whitequark>
not that it ever intended to replace dso
<azonenberg_work>
well, mso
<whitequark>
right
<swetland>
when I was hacking on zynq I wrote an FTDI serial command decoder to JTAG and then a JTAG to ARM DEBUG decoder and then extracted all the register writes the xilinx tools used to program zqyn
<whitequark>
it's a pure la
<swetland>
that was fun
<azonenberg_work>
swetland: lol
<azonenberg_work>
i may need to talk to you about that
<azonenberg_work>
i tried to bring up jtag on a zynq a while ago
<whitequark>
swetland: yeah so sigrok/pulseview already includes a jtag and swd decoders
<azonenberg_work>
i was able to walk the debug APB and figure out what was going on with the various IPs, print out all the coresight roms and such
<azonenberg_work>
no i mean your findings, not the tool
<azonenberg_work>
anyway what i was NOT able to do was actually touch anything over jtag that was interesting
<azonenberg_work>
i couldnt read or write ram or sfrs, in particular
<azonenberg_work>
i expected the ahb bus to give me that
<azonenberg_work>
ocm, dram, sfr, whatever i tried i got errors
<swetland>
the tool is probably the most concrete form of my notes on all this that exists at the moment
<azonenberg_work>
did you go that far?
<azonenberg_work>
being able to debug a zynq from nothing?
<azonenberg_work>
i know my adi/coresight logic is solid because it works just fine on a stm32
<azonenberg_work>
so if i have bugs they're subtle ones
<azonenberg_work>
that debugging or poking registers on a cortex-m4 don't hit
<swetland>
the tool doesn't do a lot, but it can basically reset the zynq core and poke at registers
<azonenberg_work>
you were able to mess with sfrs?
<swetland>
it also is able to push bitstreams down to the -7 fabric
<azonenberg_work>
thats more than i got on zynq
<azonenberg_work>
that's easy, i have support for that in jtaghal
<azonenberg_work>
its just like a normal artix
<swetland>
yup
<azonenberg_work>
not like spartan6 where, until a year or two ago
<azonenberg_work>
you had to find bugs in the datasheet and infer what was meant, not what was said
<azonenberg_work>
because ug380 had errors in it :p
<swetland>
so what the tool (jtag.c in source) can do is: reset soc, shoot image down to 0, take soc out of reset pause both cores and dump regs and reset everything
<azonenberg_work>
ok
<azonenberg_work>
thats more than i got
<azonenberg_work>
i think
<swetland>
we used it for lk bringup on zynq
<azonenberg_work>
but resetting cores and dumping CPU registers is doable over APB entirely
<azonenberg_work>
did you not try using AHB for anything?
<azonenberg_work>
it's the other mem-ap i had trouble with
<azonenberg_work>
it is possible i have bugs accessing nonzero index mem-ap's
<azonenberg_work>
thats on the list of things to investigate when i have time to get back to this
<swetland>
the download-to-0 is hitting the onboard sram
<azonenberg_work>
oh ok
<swetland>
so I'm pretty sure I'm managing to get outside of the cpu/debug complex
<azonenberg_work>
if you are writing to ocm, that's further than i got
<azonenberg_work>
thats the other AP
<azonenberg_work>
which i wasnt able to get working
<swetland>
I last touched this in '14 so I'm a little fuzzy on the details
<swetland>
$ echo -n crc8 | sha256sum | awk '{ print $1; }' | sed 's/\([a-z0-9][a-z0-9]\)/\1\n/g' | sh -c '( while read a ; do b="$a$b" ; done ; echo $b )'
<swetland>
I expect there's a much less awkward way of doing that
<plaes>
swetland: please also specify LC_ALL=C
<plaes>
a-z is not full alphabet in some locales
rohitksingh_wor1 has joined ##openfpga
egg|work|egg has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 250 seconds]
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<swetland>
does sha256sum generate hex digits with non-ascii-plane a-f in other locales? (had never considered that)
<plaes>
ah.. a-f should be fine
<whitequark>
or just [abcdef]
<whitequark>
it's not that long
<whitequark>
also I think 0-9 sometimes includes non-ASCII numerals to...
<cr1901_modern>
Is [a-f] and [abcdef] different?
<whitequark>
yes
<egg|work|egg>
whitequark: wouldn't it be \d that includes stuff other than 0 through 9?
<whitequark>
a-f uses collation
<whitequark>
egg|work|egg: I thought so
<whitequark>
but apparently some regex engines map 0-9 to \d ?!
<egg|work|egg>
AAAAAAAAA
<whitequark>
i'm not entirely sure
<egg|work|egg>
AAAAAAAAAAAAAAAAAAAAAA
<swetland>
mind you this is not something I intend to *ship*
<egg|work|egg>
A𝐀𝐴𝑨𝖠𝗔𝘈𝘼𝒜𝓐𝔄𝕬𝙰𝔸
<swetland>
just a quick hack to reverse some test vectors for some crc8 generation and checking
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<cr1901_modern>
yeeesh
pie__ has quit [Remote host closed the connection]
Miyu has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
genii has joined ##openfpga
Laksen has joined ##openfpga
GuzTech has quit [Quit: Leaving]
dj_pi has joined ##openfpga
egg|work|egg has quit [Ping timeout: 256 seconds]
egg|work|egg has joined ##openfpga
catdemon has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
<unixb0y>
Hi guys
<unixb0y>
I don’t know if this is the right place to ask but I’m wondering whether I can “receive” a signal that comes from a microcontroller with my FPGA’s “Pmod” ports.
<sensille>
you can
<unixb0y>
Do i have to connect ground too then?
<whitequark>
yes
<unixb0y>
Ok 👌🏼
<sensille>
ground between microcontroller and fpga. and make sure the levels are compatible
<unixb0y>
Ground to ground, 3.3V GPIO output to FPGA Input
<sensille>
5V from the MCU wouldn't be good
<unixb0y>
👍🏼
<unixb0y>
It’s 3.3V logic :)
<unixb0y>
Thanks !
dj_pi has joined ##openfpga
<TD-Linux>
backlog tl;dr but suffice it to say I <3 what you all are doing :)
catdemon has quit [Ping timeout: 252 seconds]
emeb has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Remote host closed the connection]
jcreedon has joined ##openfpga
_whitenotifier has quit [Remote host closed the connection]