azonenberg_work has quit [Ping timeout: 246 seconds]
<whitequark>
awygle: AVRs?
<awygle>
whitequark: do you have a particular favorite?
<whitequark>
withstands absurd amounts of abuse, easy to understand architecture, the entire chip description, including ISA and memory programming, fits into a single datasheet
<awygle>
like, imagine you were buying some ICs to just have aroudn
<whitequark>
ohhh
<whitequark>
in that kinda way
<whitequark>
uh hm
<whitequark>
level shifters lol
<whitequark>
that go down to 1V2
<whitequark>
opamps
<whitequark>
comparators
<whitequark>
USB-UARTs but these are obsolete with Glasgow I guess
<whitequark>
SPI ADC/DAC
<whitequark>
SPI NOR memory
<whitequark>
I2C EEPROM
<whitequark>
24c/25c series
<whitequark>
you never know when you need to hook up a bit of memory to something
<whitequark>
digital potentiometers
<whitequark>
shift registers and I/O expanders in general
<awygle>
that's a good list, thanks
<whitequark>
FPGA devboards, duh
<whitequark>
I think that's all I can come up with offhand
<whitequark>
maybe LVDS something
<whitequark>
but that's veering into project-specific territory
kuldeep has quit [Ping timeout: 240 seconds]
<awygle>
those all seem like totally reasonable things to have on hand
<awygle>
i look forward to azonenberg coming in with 100$ 20 Gsps ADCs or something
<awygle>
although he's not actually here, so he'll not see this i suppose
kuldeep has joined ##openfpga
<awygle>
whitequark: i'm making the final tweak to the Rev B (widening the FIFO bus) tomorrow morning (so in ~10 hours). do you want to review it at that point or should i just go to fab?
<whitequark>
awygle: I've already reviewed revB twice and I trust you to make this change successfully
<whitequark>
so, go ahead
<awygle>
cool :)
<whitequark>
oh
<whitequark>
wait, do we even need it?
<whitequark>
we don't have any FIFO glitches anymore
<whitequark>
it was all metastability caused by my shitty gateware
<awygle>
oh really?
<awygle>
okay then
<whitequark>
yeah
<whitequark>
I've worked a lot with the SPI flash on this thunderbolt adapter
<whitequark>
it's an 1M flash and it is excellent at fishing out Glasgow FIFO issues
<whitequark>
haven't seen a single bitflip in days
<whitequark>
speaking of which, sec
<whitequark>
awygle: whee, I reprogrammed the adapter and it still came up
<whitequark>
[ 8837.114160] usb 3-1: Manufacturer: Axxle Inc.
<whitequark>
I've successfully modified the part of firmware covered by CRC
<whitequark>
and indeed the strings are compressed (cc rqou)
<whitequark>
looks like that was one of the changes they made from TPS65982 to -3
Miyu has quit [Ping timeout: 252 seconds]
<zkms>
nice
<zkms>
how are they compressed
<whitequark>
no idea, some sort of uh
<whitequark>
huffman? maybe?
<whitequark>
it is an algorithm that definitely can look behind and insert a chunk
<whitequark>
0x12 means "insert the next character literally"
<whitequark>
0x02 means "insert the character you just inserted"
<whitequark>
ok it's more complicated than that, not really sure
* zkms
nods
<whitequark>
I can give you the fw if you want
azonenberg_work has joined ##openfpga
kuldeep has quit [Ping timeout: 244 seconds]
kuldeep has joined ##openfpga
GuzTech has joined ##openfpga
m4ssi has joined ##openfpga
eddyb has quit [Changing host]
eddyb has joined ##openfpga
eddyb has joined ##openfpga
<azonenberg_work>
awygle: ltc3374 :D
<azonenberg_work>
also grr, starting to play with systemverilog
<azonenberg_work>
interface modports are so constrained
<azonenberg_work>
in particular, there is basically no hierarchy support
<azonenberg_work>
As in, there is no way to say "in mode master i have a foo.rx input and foo.tx output, in mode slave foo.rx is output and foo.tx is input"
<azonenberg_work>
You have to flatten it all out into a single interface
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined ##openfpga
kuldeep has quit [Ping timeout: 260 seconds]
kuldeep has joined ##openfpga
<whitequark>
azonenberg_work: how's swd support in jtaghal?
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
<gruetzkopf>
*yawn* oh you did things
<gruetzkopf>
nice.
<whitequark>
gruetzkopf: do you care to look at the firmware?
<whitequark>
entry point at 0xc0, thumb code
<whitequark>
it's a cortex-m with unidentified peripherals, firmware image at 0x6b000 loaded at address 0 (i think)
mumptai_ has quit [Read error: Connection reset by peer]
mumptai_ has joined ##openfpga
kuldeep has quit [Ping timeout: 260 seconds]
calle__ has joined ##openfpga
kuldeep has joined ##openfpga
mumptai_ has quit [Ping timeout: 245 seconds]
unixb0y has quit [Read error: Connection reset by peer]
rvense has quit [Read error: Connection reset by peer]
rvense has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
kuldeep has quit [Ping timeout: 260 seconds]
kuldeep has joined ##openfpga
Miyu has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
GuzTech has quit [Remote host closed the connection]
m_t has quit [Remote host closed the connection]
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
<awygle>
okay i ordered some glasgows
<azonenberg_work>
whitequark: you mean the FTDI implementation or the API as a whole?
<azonenberg_work>
jtaghal in general is exception based
azonenberg_work has quit [Ping timeout: 260 seconds]
<awygle>
geh. exceptions.
azonenberg_work has joined ##openfpga
<azonenberg_work>
whitequark: trying to add explicit return code checks to some very complex pile of jtag operations involving dozens of operations would make the code a lot more bloated
<azonenberg_work>
So i just throw a try-catch block around the whole thing and handle it in one place
<azonenberg_work>
If you mean the FTDI implementation, i detect the status for error but don't actually do anything about it yet
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
emeb has joined ##openfpga
calle__ has quit [Read error: Connection reset by peer]
calle__ has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
calle__ has quit [Quit: Verlassend]
gruetzkopf has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
gruetzkopf has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
wpwrak has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 260 seconds]
wpwrak has joined ##openfpga
scrts has quit [Ping timeout: 252 seconds]
scrts has joined ##openfpga
azonenberg_work has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
mumptai has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
mumptai has joined ##openfpga
kuldeep has quit [Ping timeout: 260 seconds]
wpwrak has quit [Read error: Connection reset by peer]
<TD-Linux>
interesting though I'd much rather have ecp5
<sorear>
if the new chinese FPGAs are much cheaper per LUT than ecp5, and I can create a situation where there exists documentation I understand, I'm interested
<gruetzkopf>
if the new chinese FPGAs get me 8 transceivers below 20$ im interested ;)
<shapr>
honestly, this channel is just way more fun than ##fpga
<shapr>
sorear: is there a cost per lut graph somewhere?
<shapr>
I couldn't find it this past weekend
<tnt>
Heh, looks like a nice device.
<tnt>
no idea where to buy parts though.
<sorear>
shapr: i don't think so, but we could start to put one together
<sorear>
i understand that part costs depend a lot on *who* you ask and I'm not sure how to square that
<gruetzkopf>
i know that azonenber_g has a trx/$ table
<sorear>
jn__: my problem is that the english part sites don't have them and I don't enough chinese to price them on chinese sites
<sorear>
jn__: i found the datasheet already so I knew the lut#
<esden>
q3k: Finally found the time to submit the issue regarding the timing in nextpnr, let me know if you need any additional information from me. :)
<q3k>
lovely, thank you
<tnt>
esden: btw, what changes are you making to the icebreaker (not mini) compared to the current version ?
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<esden>
tnt: adding a pullup on the ftdi chip so that it does not get stuck when accidentally using minicom and not disabling hardware flow control (yes I got bitten by that and it took me forever to find out that I had hfc on >_<), and changing the buttons to a different version, maybe even adjusting the usb connector footprint to allow for the use of a lower cost version. Nothing major so far. :)
<TD-Linux>
strangely anlogic's own website doesn't have that chip
<awygle>
sorear: i'd just use the digikey/mouser prices, that's what we in this channel will care about
<awygle>
generally
<awygle>
the big problem with LUT/$ (or even LE/$) is that it doesn't capture e.g. fabric speed or block RAM, so it's not likely to be a particularly useful metric. i suppose it can help place you in a bracket though (i.e., should i even bother looking at Arrias or similar)
<azonenberg_work>
sorear: i did at one point have such a chart
<azonenberg_work>
but its way old
<pie__>
azonenberg_work, homecmos wiki is down :p
<azonenberg_work>
i dont think i've touched that in 5+ years
<azonenberg_work>
i dont even remember where it was hosted
mumptai has quit [Quit: Verlassend]
<sorear>
another thing I'm curious about evaluating is pW/active LUT, which most vendors don't seem to even publish
<pie__>
oh ok
mwk has quit [Ping timeout: 244 seconds]
<whitequark>
awygle: sweet
<whitequark>
azonenberg_work: ah ok
<whitequark>
what should I throw when I get an error from DUT?
wpwrak has quit [Read error: Connection reset by peer]
<whitequark>
azonenberg_work: also what's the state of SWD currently?
<azonenberg_work>
Re state of SWD, i have a bunch of un-pushed logic i am working on right now that should get it close to useable but i can't test yet
<azonenberg_work>
the hardware i need to test is ~3 days out
<whitequark>
azonenberg_work: i'll test it today if you push
<whitequark>
and explain how to use it
<azonenberg_work>
I'll see how far i can get
<azonenberg_work>
its definitely not done
<azonenberg_work>
If i dont finish today it might be a little while
<azonenberg_work>
because i am getting my last wisdom tooth pulled at 0900 tomorrow :p
<azonenberg_work>
sorear: because it depends on number of toggles, frequency, etc
<azonenberg_work>
lut power usage is pretty minimal compared to interconnect, ram, and such
<sorear>
:/
mwk has joined ##openfpga
<azonenberg_work>
sorear: xilinx does publish an excel file that you can plug configs into and estimate power usage
<azonenberg_work>
but its too complex to be able to trivially say one hcip uses more or less power than another
<azonenberg_work>
for example spartan6 has several OOMs less static power than 7 series for the same die size
<whitequark>
OOMs?!
<whitequark>
wow
<azonenberg_work>
But 7 series performs quite a bit better on dynamic power
<azonenberg_work>
whitequark: gimme a sec to quote hard numbers
<azonenberg_work>
The fused chips are the worst
<azonenberg_work>
but let's compare the 100K cell (unfused) of each to be fair
<azonenberg_work>
so 7a100t vs 6slx100t
<azonenberg_work>
VCCINT: spartan6 36 mA @ 1.2V, artix7 155 mA @ 1.0V
<azonenberg_work>
VCCO: spartan6 5 mA, artix7 4 mA so basically the same
<azonenberg_work>
VCCAUX: spartan6 9 mA @ 2.5V, artix7 36 mA @ 1.8V
<azonenberg_work>
For the same lut count
<whitequark>
ok that's like one OOM
<azonenberg_work>
Now let's drop to one of the fused chips to show how bad THOSE are
<azonenberg_work>
xc7a15t (fused 50k cell die) vs xc6slx16 (dedicated small die)
<azonenberg_work>
VCCINT: spartan6 6 mA @ 1.2V, artix7 95 mA @ 1.0V
<azonenberg_work>
VCCO: 1-2 mA for both, on par
<azonenberg_work>
VCCAUX: spartan6 3 mA @ 2.5V, artix7 22 mA @ 1.8V
kuldeep has quit [Ping timeout: 244 seconds]
<azonenberg_work>
So maybe not quite as bad as i remembered but... 1-2 OOMs depending on density and whether it's fused *for the same logic capacity*
kuldeep has joined ##openfpga
<whitequark>
ah ok
<sorear>
how do people designing dev boards budget power?
<gruetzkopf>
max current draw of chip
<azonenberg_work>
sorear: When designing PSUs for dev boards or flexible stuff like starshipraider
<azonenberg_work>
i usually estimate the whole chip filled to the brim with a fairly high clock freq
<azonenberg_work>
so say 300 MHz on 90% LUT load, 90% RAM, etc
GenTooMan has joined ##openfpga
<jn__>
TIL: Marvell has bought Cavium, so there's a "Marvell OcteonTX2" now
<awygle>
wow, i spent a bunch of money on glasgow parts lol. fuck this component shortage
Bike has joined ##openfpga
<pie__>
jn__, whats that
futarisIRCcloud has joined ##openfpga
<azonenberg_work>
whitequark: anyway basically right now the swd link layer is implemented but not tested and i still have to do the DP bridge logic
<azonenberg_work>
which is quick in theory but might take time to debug
<azonenberg_work>
i also have to write some probe code to figure out what you're talking to
<whitequark>
azonenberg_work: can you bring it to a state where I can do something useful with it
<whitequark>
even if i have to debug it
<azonenberg_work>
whitequark: Working on it
<azonenberg_work>
what is the part you are trying to use it on?
<whitequark>
azonenberg_work: I don't know
<whitequark>
lol
<azonenberg_work>
(jtaghal needs a better UX for dealing with unknown chips still)
<azonenberg_work>
That is on my TODO list
<whitequark>
TI TPS65983
<whitequark>
this is a Cortex-M???
<whitequark>
with unknown peripherals and unknown specific core
<whitequark>
I know it has NVIC so it's an M
<azonenberg_work>
The original or the B?
<whitequark>
they should be functionally equivalent
<whitequark>
but, probably the original
<azonenberg_work>
ok
<whitequark>
this is the Apple -B revision
<whitequark>
which I think corresponds to TPS65983A
<whitequark>
because to my understanding they mark chips according to their functional location
<azonenberg_work>
Anyway, so for ARM in particular jtaghal should let you access the common arm featureset on basically any arm device out of the box
<whitequark>
so TPS65982 is CD3215A
<whitequark>
ok, excellent
<azonenberg_work>
so memory read/write, halting the CPU, dumping regs, etc
<azonenberg_work>
(the latter 2 assume i have support for the coresight features for that particular CPU)
<azonenberg_work>
SFR access does require i be able to figure out what the chip actually is
<azonenberg_work>
unless you want to poke hex addresses by hand
<azonenberg_work>
64-bit support for arm debug is basically nonexistent at the moment too
<whitequark>
not exactly but i don't know what peripherals it has anyway
<whitequark>
TI probably reused something from Stellaris?
<whitequark>
might not have though
<azonenberg_work>
whitequark: Any chance you'd be able to hook me up with SSH access to a board that is plugged into this chip?
<whitequark>
sure
<azonenberg_work>
Because a lot of "add support for new debug protocols" work involves reading registers and trying to validate your understanding of the hardware
<azonenberg_work>
it's very hard to do blind
<whitequark>
yeah sure
<whitequark>
let me finish SWD support for Glasgow and solder the SWD testpoints
<azonenberg_work>
OK
<whitequark>
should take a hour top
<whitequark>
SWD is surprisingly simple
<azonenberg_work>
It is
<azonenberg_work>
as is JTAG
<azonenberg_work>
but swd is almost simpler
<azonenberg_work>
The fun is the higher level protocol stack :p
<whitequark>
yeah
<azonenberg_work>
Anyway it's 1630 local time, at 1830 i am going to the monthly meeting for SAR which will probably run until ~2030 including travel time
<azonenberg_work>
After that i can do some poking around
<whitequark>
sweet
<whitequark>
i'll be around
<azonenberg_work>
I need to be in a dentists chair by 0845 tomorrow though, so i cant stay up tooo late
<whitequark>
yeah I get it
<whitequark>
azonenberg_work: just to recheck
<whitequark>
driving SWDCLK all the time is fine, right?
<azonenberg_work>
Free running SWDCLK is fine as long as SWDIO is actively driven low during idle periods
<azonenberg_work>
in fact, the spec mandates a *minimum* of eight SWDCLK cycles after a transaction finishes to ensure state propagates fully through clock domain crossings etc
<azonenberg_work>
This can be either idle periods or the start of the next transaction
<whitequark>
right, I've read that
<whitequark>
hm, I think I'll make free running SWDCLK an option
<whitequark>
it's easier to trigger an LA on SWD transactions without it
<azonenberg_work>
Yeah
<azonenberg_work>
My FTDI implementation right now does not free run
<azonenberg_work>
also i just added you to the jtaghal repo so you can add your driver class
<whitequark>
thanks!
<azonenberg_work>
i'll take care of instantiation and hookup, just stick the source/header there
<whitequark>
actually lemme write the driver first
<whitequark>
so you can hook it up meanwhile
<whitequark>
azonenberg_work: remind me of your style? 4 column tabs?
<azonenberg_work>
whitequark: one \t = one indent = 4 columns
<azonenberg_work>
curly braces on their own lines
<whitequark>
wtf why do you use the proprietary ftdi driver
<azonenberg_work>
Because circa 2010 when i implemented what is now the FTDIDriver class (it got refactored a bunch)
<azonenberg_work>
libftdi had bugs that rendered it unusable
<whitequark>
oh
<azonenberg_work>
And i never had time to re-evaluate and see if it was a viable option now
<azonenberg_work>
i think somebody is/was working on a PR to do that
<azonenberg_work>
But right now given how busy i am my focus is on the features that $dayjob pays me to add, or that i need for $sidegig
<whitequark>
azonenberg_work: hm I'm not sure I can implement GetFrequency
<whitequark>
well, no, not that
<whitequark>
either it's hardcoded in the bitstream or it's implemented as a register
<whitequark>
oh I guess I can make it an RO register
<azonenberg_work>
if its hardcoded in the bitstream just provide a query to get it?
<whitequark>
yeah
<azonenberg_work>
I dont have a set call yet in the API anyway
<azonenberg_work>
my ftdi driver is hard coded to 10 MHz because it's "fast enough" and i have no hardware that wont work at 10 :p
<azonenberg_work>
So i never had reason to add it
<azonenberg_work>
The function is largely for informational/status useage anyway, or potentially in a UI that tries to estimate how long loading a bitstream will take or something