azonenberg_work has quit [Ping timeout: 252 seconds]
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 245 seconds]
[X-Scale] is now known as X-Scale
<sorear>
How is this not needlessly complicated
<kc8apf>
sorear: oh, we haven't even got there yet
<shapr>
gets worse?
<kc8apf>
If you want an idea, look at the list of commands available in Table 5-25 of UG470
<kc8apf>
partial reconfig is built on a set of really low-level operations
<kc8apf>
pretty sure MFW gets used for compressed bitstreams
<kc8apf>
haven't dug into that yet
<kc8apf>
config mem layout is really three independent data buses that each use their own indexing for columns within a row
<sorear>
The whole address registers selecting address registers selecting address registers thing is DNS over HTTPS levels of painfully indirect
<kc8apf>
I get why the packet format exists. With all the different ways of loading a config, they needed a protocol to unify them at
<kc8apf>
config mem is separate from that because of how the chip is organized
<kc8apf>
config mem is scattered across the part while the configuration registers are in the programming tile
<kc8apf>
also, a lot of this is iterations of extending a protocol
<kc8apf>
spartan6 looks almost exactly the same except with a different word size
<kc8apf>
spartan3, same
<kc8apf>
whoops. skipped a detail
<sorear>
4 and 5 never happened?
<kc8apf>
not that I know of
<rqou>
they were virtex parts instead
azonenberg_work has joined ##openfpga
<shapr>
azonenberg_work: you have strange work hours
<azonenberg_work>
shapr: i'm on my way home
<azonenberg_work>
But this is my work computer
<shapr>
oh right, west coast
<shapr>
It's about 9pm here
<azonenberg_work>
(Just got onto the ferry)
<azonenberg_work>
kc8apf: so i see you dont know what that undoc'd register 0 is either
<azonenberg_work>
interestingly enough ISE-generated bitstreams, at least for the ISE-supported devices, appear to lack it
<azonenberg_work>
So it might not be strictly necessary? or maybe they just never patched ise? :P
<azonenberg_work>
register 13 with value0*
<azonenberg_work>
awygle: ping
<azonenberg_work>
awygle: gonna join our work party / hackathon this weekend?
<awygle>
azonenberg_work: since I already have a place to live can I just join the hackathon? :-P
<awygle>
I'll probably join. Have to figure out how to get to Kitsap...
azonenberg_work has quit [Ping timeout: 245 seconds]
<rqou>
awygle: I mean, im driving up
<rqou>
i just have to figure out how to schedule it such that I'm not driving for 14 continuous hours
<rqou>
hence the attempt to convince pointfree or someone to tag along
<rqou>
hmm actually
<awygle>
rqou: I have a car I've just never been to Kitsap. I suspect it involves a ferry
<rqou>
i should see if diamondman wants to tag along
ZipCPU|ztop has quit [Ping timeout: 252 seconds]
<kc8apf>
azonenberg: I've got a lot of experiments I want to try with omitting packets. I suspect Vivado is just does a set pattern instead of a minimal set.
<sorear>
“vtr advantages: smaller bitstreams”
<rqou>
xc2par advantages: more aggressive packing than ISE (at least by default)
<rqou>
disadvantages: maybe bricks your chip :P
<rqou>
(note: probably does not actually brick your chip, unlike azonenberg :P )
<rqou>
actually
<rqou>
hmm
<rqou>
xc2par _may_ degrade your io cells
<rqou>
this will be fixed
<rqou>
azonenberg: what happens if you set the io bank voltage to "low" but supply 3.3V? does this degrade the output buffer?
noobineer has quit [Ping timeout: 260 seconds]
<benreynwar>
What is xc2par? Is there a summary anywhere of all the stuff you've got going on in openfpga?
<whitequark>
this doesn't do what you think it does
<whitequark>
it generates quite a bit more than one instruction between write of I2CS and read of I2DAT
<whitequark>
in fact the only way to reliably generate a STOP without any trailing SCL pulses that I found is to use autopointers
<whitequark>
I'm not sure how the Cypress library does it, but based on quick look at the disassembly, it does not use this trick
ZipCPU|ztop has joined ##openfpga
ZipCPU|ztop has quit [Remote host closed the connection]
futarisIRCcloud has joined ##openfpga
<cr1901_modern>
whitequark: Just for my info, is it in spec that I2C resends the data while STOP isn't generated?
<cr1901_modern>
Or I could be proactive and actually look it up...
zino has quit [Ping timeout: 264 seconds]
rohitksingh_work has joined ##openfpga
<awygle>
whitequark: do you have a readily available mechanism to measure glasgow power consumption?
<rqou>
DMMs? :P
<awygle>
well yeah but you gotta wire it in there somehow
<awygle>
i don't currently have a usb breakout or a stripped usb cable or anything
<rqou>
heh i have/had a bunch of cut usb cables for various tests like this :P
<awygle>
and apparently my soldering iron tip is shit :p
<rqou>
buy a new one?
<awygle>
i did it's just not here yet
<rqou>
heh
<rqou>
i can just run off to Fry's Electronics and buy one :P
<rqou>
amazing, a brick-and-mortar retailer that is actually useful :P
Bike has quit [Quit: Lost terminal]
<awygle>
the nearest fry's is like.... in renton i think
<awygle>
... that's far away i promise
<awygle>
there's a local electronics shop that could help me but they're basically open the hours that i work
<awygle>
society is badly arranged
<rqou>
lol
<azonenberg>
rqou: if you set voltage to low and say 3.3V
<azonenberg>
and apply 3.3V*
<azonenberg>
yes you probably are slowly frying the iobs
<azonenberg>
IOSTANDARD anyone?
<rqou>
not supported yet :P
<rqou>
also, ISE can have this problem too so it's not entirely xc2par's fault :P
<rqou>
azonenberg: did we ever figure out how we were going to test sstl/hstl?
<rqou>
oh lol i just noticed my 1000th tweet on birbsite is a crude joke
<rqou>
oh well
<awygle>
a bad crude joke :p
<rqou>
i didn't even come up with it :P
<rqou>
i heard it first from sb0 :P :P
<awygle>
i have done the iostandard thing the other way around
<awygle>
supply 1.8v but say LVCMOS33
<awygle>
it wrecked the timing margin and caused all sorts of badness
<azonenberg>
yeah but it survived
<awygle>
well yes, it was undervolted not overvolted
<awygle>
and who knows what it did to service life
scrts has quit [Ping timeout: 245 seconds]
<rqou>
azonenberg: do you know of a quick and easy way to generate SVF files?
<rqou>
apparently "bring your own programming algorithm" isn't very user friendly
<azonenberg>
awygle: yay party
<awygle>
hanging out with cats at parties
<rqou>
party?
<azonenberg>
The work party
<rqou>
yours or awygle's?
<awygle>
na it's a song
<rqou>
oh lol
<awygle>
i'm in a very reference-oriented frame of mind today
<awygle>
i keep telling people that being meguca is suffering
<rqou>
hey awygle you haven't posted catpix in a while :P
<awygle>
although if you end up in redmond i will happily introduce you to my cats
<rqou>
kitty! :P
* rqou
should acquire a cat :P
<awygle>
when you start your mysterious new job you will be able to afford one, and a place to hosue it
X-Scale has quit [Ping timeout: 248 seconds]
<azonenberg>
rqou: no i dont
<azonenberg>
i basically dont do svf at all
<azonenberg>
the only reason to use it is REing other people's programming algorithms or talking to stupid ATE
<rqou>
ok, how do you want to fix the "bring your own programming algorithm" problem?
<rqou>
for people who don't want to use/port jtaghal?
<azonenberg>
Tell them to use jtaghal? :p
<rqou>
but jtaghal doesn't support e.g. digilent dongles
<rqou>
the whole "bring your own hardware" part is also kinda bad
<rqou>
azonenberg: jtaghal also can't read a crbit :P
<rqou>
or program a 128/256/384/512
azonenberg has quit [Ping timeout: 240 seconds]
<awygle>
azonenberg: glasgow's ADC and 5V inputs have limited ESD protection, 2.5 kV and 2 kV respectively. do you think that's OK with the cap on those lines (12 nF and 4.8 uF respectively)?
<rqou>
i've always just ignored esd protection :P
<rqou>
just slap on a "caution ESD sensitive" symbol/sticker :P :P
<awygle>
rqou: which is why i didn't ask you :P
openfpga-bb has quit [Ping timeout: 240 seconds]
<rqou>
uh oh
<awygle>
although azonenberg probably either ignores ESD or goes completely insane
<rqou>
did azonenberg just reboot his router?
openfpga-bb has joined ##openfpga
<awygle>
eyy bb
azonenberg has joined ##openfpga
<awygle>
azonenberg: glasgow's ADC and 5V inputs have limited ESD protection, 2.5 kV and 2 kV respectively. do you think that's OK with the cap on those lines (12 nF and 4.8 uF respectively)?
<azonenberg>
awygle: hmmm
<azonenberg>
rqou: um
<azonenberg>
yes it does
<azonenberg>
jtaghal supports digilent's API
<azonenberg>
you just have to install their blob
<rqou>
wtf
<rqou>
blobs
<azonenberg>
well there is no one api
<rqou>
overall we need to fix the "bring your own hardware and programming algorithm" problem
<azonenberg>
i support ftdi-based digilent stuff (most of the recent stuff) using either the ftdi or digilent apis
<azonenberg>
the PIC etc based stuff i only support their blob
<azonenberg>
as the protocol is undocumented
<rqou>
didn't diamondman figure it out?
<azonenberg>
and i wasnt going to RE it if there was a freeware, though blob, api that worked just fine
<azonenberg>
i thought he was looking at the xilinx platform cable
<azonenberg>
not the digilent stuff
<azonenberg>
In any case, my end goal for this is to build starshipraider
<azonenberg>
And use that as my sole jtag adapter for everything
<azonenberg>
And forget about all other ways to jtag because its far superior
<rqou>
um, i still want "potato-quality mode"
<rqou>
for when you want something cheap AF
<azonenberg>
i'll keep support for other APIs because some devkits have it integrated and don't have a discrete jtag port
<azonenberg>
But i wont have it be the primary
<azonenberg>
and you clearly arent the target customer for jtaghal, or any of my tools
<azonenberg>
i dont do cheap
<azonenberg>
i do things right
<azonenberg>
and i refuse to cut corners in the interests of cost
<rqou>
oh btw azonenberg thoughts on me sending xc2par into hackaday tips?
<rqou>
any objections?
<azonenberg>
Go for it
<azonenberg>
just make sure you cite me :)
<awygle>
lol
<azonenberg>
awygle: anyway, the best way to get to my new place is to take the ferry to bainbridge and then just drive down highway 305 and over the bridge to poulsbo
<awygle>
"over the river and through the woods" as it were
<azonenberg>
The only direct ferries to mainland kitsap go to kingston and bremerton which are like 25 miles north and south respectively
<azonenberg>
Both are also more like 1-hour rides vs the ~30 minute bainbridge ride
<azonenberg>
We'll coordinate more once the weekend gets closer
<azonenberg>
and figure out dates/times, who's coming when, etc
<awygle>
yup
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
And how much pizza to order :P
<awygle>
haha
<awygle>
ok now solve my esd problem :P
<azonenberg>
So, the human body model for ESD
<azonenberg>
has the charge on only 100 pF of capacitance
<awygle>
right. so tiny cap munch nasty pulse.
<azonenberg>
So if you dump that into a 100x larger cap
<rqou>
awygle: go and visit "that crazy iranian guy" and borrow his esd simulator :P
<azonenberg>
your 10 kV pulse is 100V, which the ESD diodes should eat easily
<azonenberg>
Better question is if parasitic L on the cap would prevent it from eating a pulse that fast
<azonenberg>
but i think you're safe
<awygle>
how fast is the HBM pulse? does it specify?
<rqou>
azonenberg: why aren't ESD models just defined with coulombs?
<azonenberg>
Because that isnt a test prcoedure
<azonenberg>
awygle: 1500 ohm series resistor
<azonenberg>
the procedure is literally, 100 pF at specified voltage
<azonenberg>
1500 ohms from there to DUT pin
<azonenberg>
see if it dies
<rqou>
O_o
<awygle>
oh that's like
<awygle>
not fast at all
<rqou>
that's a lot dumber than i expected
<awygle>
not worried about L in that cacse
<awygle>
*case
<azonenberg>
they're literally modeling the capacitance and ESR of an average human
<azonenberg>
in a very simple lumped model
<awygle>
that's why CDM is so much harder
<azonenberg>
then you have the "charged device model" and "machine model"
<azonenberg>
which use different parametrs
<awygle>
i can't remember which is worse, CDM or MM
<awygle>
i usually see HBM and CDM spec'd
<openfpga-github>
[Glasgow] awygle commented on issue #59: The LDO has 2 kV ESD tolerance, the ADC has 2.5 kV (on the pins in question, under the human body model). The LDO rail has 4.7 uF of capacitance, and the ADC has 12 nF before the input pin. Given that the human body model specifies 200 pF of capacitance, we have an effective 250 kV of tolerance, which should be plenty.... https://github.com/whitequark/Glasgow/is
<rqou>
azonenberg: ok, HaD email sent
<rqou>
ah crap, i forgot to CC you
<rqou>
i did mention your name though
<openfpga-github>
[Glasgow] awygle commented on issue #50: I put a hard short on one VIO port and did not pop the fuse. I measured a peak of 350 mA and 280 mA steady state (without the short and with the I/O toggling at 15 MHz I was seeing 77 mA). I put a hard short on the other port as well and managed to pop it. That suggests to me that we're close to being able to tolerate two full shorts on the I/O banks, and that dropp
<awygle>
whitequark: did analysis on open rev B tickets. will do mods tomorrow after hearing your thoughts.
<awygle>
my recommendation is change the ldo and also do the usb protection ic
<rqou>
hmm, for one of the few times ever i actually want a printed data book
<rqou>
(TDK EPCOS)
<rqou>
also nobody seems to really use "i'm a n00b use DCM pl0x" anymore
bitd has joined ##openfpga
scrts has joined ##openfpga
<rqou>
herp derp i am a good electrical engineer
<rqou>
power loss in wires is RMS current, not peak current
<rqou>
duh
<rqou>
anyways, i seem? to have a working design?
<rqou>
oh i just realized why my design seems to work :P
<rqou>
apparently i'm awful at mechE intuition
<rqou>
my magnetics are huge
<tnt>
whitequark: btw, are the 'auto detect' buffers you use on the glasgow well behaved on bus like I2C that rely pull-ups ?
<rqou>
ugh core losses suck
<tnt>
rqou: what are you designing ?
<tnt>
(just curious :p)
<rqou>
400V flyback for those crazy nixie displays whitequark nerdsniped everybody with
<rqou>
but this type of SMPS basically always needs custom magnetics
<tnt>
Ah yeah, the nixie 'pixel arrays' right ?
<rqou>
yeah
<rqou>
a bunch of people bough one because "oh cool"
<tnt>
hehe :)
<rqou>
and then realized "wait, SMPS design is teh hardz" :P
<rqou>
there is a project on hackaday.io but afaict it's underspecced
<rqou>
unfortunately trying to also squeeze out efficiency is really hard
<rqou>
e.g. the naive series resistors wastes like 40% of the total power
<rqou>
afaict my flyback also wastes like 3W
<rqou>
engineering constraints are teh hardz :P
<rqou>
oh yeah this 3W is in the magnetics only
<rqou>
not including switching losses
<rqou>
everything is teh hardz
<rqou>
now i'm really really impressed at those 90+% efficiency PSUs
<tnt>
yeah, smps are hard.
<tnt>
probably one of the reason in a lot of gears the power supply is subcontracted to a specialized company :p
<rqou>
yeah but then i don't get to learn it :P
<rqou>
also i'm kinda doing the opposite of what most other people are doing
<tnt>
of course.
<rqou>
most other people are trying to do 400V (because PFC) -> 12V
<rqou>
not 12V -> 400V
<tnt>
just reverse it :)
<tnt>
doesn't work like that ?
<rqou>
yeah i tried to math it and it doesn't seem to quite work like that
<rqou>
(i did take power electronics btw, so i get to basically apply what i learned in class)
<rqou>
current plan is to just be lame, operate in DCM, and use a microcontroller to implement the feedback law
<rqou>
meanwhile m-labs has a fun SMPS like this and apparently it "just" uses PID control in a microcontroller
<rqou>
i asked whitequark "is this CCM or DCM? RHP zero?" and the answer was "don't know" :P :P
<tnt>
tbh, I'm not sure what those are either :p CCM .. Constant Current Mode ? DCM ... Direct Curent Mode ? RHP ... Really Huge Powersupply ?
<rqou>
continuous conduction mode vs discontinuous conduction mode
<rqou>
and right-half-plane zero
<tnt>
ok :) I'm less dumb than 5 min agao now.
<rqou>
and i need to remind myself that not everybody has seen the same $FANCY_SCHOOL acronym soup :P
<tnt>
Well I'm sure they're common if you're into power supply, but in that domain I'm barely good enough to follow the datasheet of the buck converters I use.
<rqou>
yeah CCM/DCM is pretty common in the "SMPS" universe
<rqou>
"RHP zero" is from the "feedback controls" universe
Miyu has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 240 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
genii has joined ##openfpga
X-Scale has joined ##openfpga
rohitksingh has joined ##openfpga
m_w has joined ##openfpga
<whitequark>
tnt: no, of course not, they don't work on any bus that has a pullup of smaller than 100k or so
<whitequark>
or pulldown
<whitequark>
they have far higher bandwidth than the level shifters that do require pullups though
<florolf>
re "doing smps control in an uC": the HRTIM block in the stm32f334 is really nifty for that
<openfpga-github>
[Glasgow] awygle commented on issue #50: Yeah, the dropout's not ideal. The alternative is to rely on the USB protection IC. The bummer with that is that it will probably brown out the FX2 and cause the device to flap on the user's PC. The LDO will stop this further downstream. https://github.com/whitequark/Glasgow/issues/50#issuecomment-391062459
<whitequark>
billions of 555s are being made each year
<shapr>
556s?
<rqou>
nowadays 8-bit MCUs can be even cheaper and require fewer external components
<whitequark>
but then you need to program an MCU
<azonenberg>
or a greenpak? /me hides
<whitequark>
lol
<shapr>
I'd argue the 555 is a great way to get started with feedback loops, etc
<rqou>
while (1) { pin_on(); sleep(); pin_off(); sleep(); }
<rqou>
done :P
<whitequark>
you need a programmer, and a toolchain, and a computer
<whitequark>
with a 555? nah
<rqou>
but cost? power?
<azonenberg>
Cheapest 555 i see on digikey is 9.8 cents in qty 5000 or $0.37 in single units
<rqou>
555s are bipolar aren't they?
<whitequark>
also you can power 555 with 15V
<shapr>
There are overhead costs associated with mcu/fpga, etc
<rqou>
heh ok
<whitequark>
try that with an MCU
<whitequark>
also a 555 will be manufactured forever
<whitequark>
MCUs go obsolete
<shapr>
My software dev coworkers can drive a 555, but don't know anything embedded dev or HDLs
<azonenberg>
The slg46140 is $0.50 in low volume and i dont see bulk discounts listed on distributors (have to ask i guess?)
<azonenberg>
But you have to consider cost of passives
<azonenberg>
and difficulty sourcing MLCCs :P
<awygle>
the additional touch in assembly for programming MCUs probably materially affects unit volumes
<shapr>
Also most of us probably can't write software that uses less than a meg of ram :-P
<awygle>
err, unit economics rather
<azonenberg>
Plus increased assembly / pcb area costs for the 555 supporting parts
<shapr>
touch in assembly?
<azonenberg>
shapr: lolol
<awygle>
shapr: it's an additional pre- or post-assembly process
<awygle>
anytime you add another process step you increase unit cost
<whitequark>
pre-assembly for greenpak
<shapr>
oh, I wasn't sure if you meant writing assembly language
<whitequark>
actually greenpaks are a real pain in the ass to program
<whitequark>
also, don't forget that dips can reduce assembly cost
<whitequark>
because students are often cheaper than pnp machines
<awygle>
ah, no, although software development also adds cost because you have to pay a software engineer lol
<rqou>
hmm so an attiny10 is $0.34 in quantity 1
<rqou>
but it doesn't scale down nearly as much in larger volumes
<shapr>
I've seen generic breakout boards for SMD chips that support a bunch of different pin pitches, is there something like that that also includes spaces for a bunch of components?
<awygle>
that's up front though, not ongoing so i wasn't counting it
<whitequark>
that can only be programmed in assembly too
<rqou>
that's at least an improvement on the power front
<whitequark>
8-bump DSBGA lol
<awygle>
in a DSBGA package too, if you hate yourself :p
<rqou>
wtf
<rqou>
also loloo "Industry's Fastest Astable Frequency of 3 MHz"
<rqou>
1.5V minimum voltage
<shapr>
oh, DS is die size in DSBGA, yikes
<rqou>
but still goes up to 15V
<Ultrasauce>
i was dicking around with vco designs a few weeks ago until i came to the conclusion that i really wanted an integrated pair of comparators and SR latch
<rqou>
what have we done?! :P
<Ultrasauce>
and guess what
<rqou>
lol
<shapr>
Wow, DSBGA is *tiny*
<rqou>
the future is weird :P
<azonenberg>
shapr: lol
<rqou>
i wonder what 80s engineers would have thought about CMOS 555s in 2018?
<azonenberg>
rqou: cmos 555s in wlcsp you mean? :p
<rqou>
yeah
<azonenberg>
whitequark: greenpaks are meant to be used in high volume designs
<azonenberg>
where you buy a whole reel pre-programmed
<azonenberg>
Then they're not bad for one-offs
<azonenberg>
it's low volume where they fall short
<azonenberg>
If you're buying them in qty 3000 i dont even think they charge for programming
<rqou>
yeah, that programmer/devkit thing definitely isn't robust enough to sit on an assembly line :P
<shapr>
For that LMC555, 1.5mm square is DSBGA, as compared to 5.3mm by 3.4mm in the next largest package, VSSOP
<awygle>
yup
<awygle>
CSPs are amazing and horrifying
<awygle>
i finally removed the short on the 0.4mm ice40LM board btw. gotta try that out.
<shapr>
my team gets an intern, maybe I should convince them to learn FPGA dev
<shapr>
oh, that's what wlcsp means
<rqou>
btw i love how far we've come from commodore trying to replace bipolar with MOS and hitting speed issues to "oh yeah, please replace everything with CMOS because power"
<awygle>
"wait wait stop what are you doing the CMOS is too small it's not low power any more wait nooooo"
<rqou>
lol
<jn__>
and thus Netburst was created
<awygle>
why do i always end up with stupid problems
<awygle>
along the lines of "uncheck all these checkboxes and recheck them and your problem magically goes away"
<azonenberg>
awygle: we had one of those with our dispatch system for SAR
<azonenberg>
all of the new trainees mysteriously weren't getting paged for incidents
Miyu has joined ##openfpga
<azonenberg>
They went into the system admin page, hit edit on the list of notification numbers
<azonenberg>
saved without making any changes
<azonenberg>
and now it works :p
hackkitten has quit [Ping timeout: 265 seconds]
<awygle>
it seems i _always_ get these issues for whatever reason
rohitksingh has quit [Quit: Leaving.]
<tnt>
Is there some open-source CPU optimized for the ice40, something super-small (like the picoblaze was/is for xilinx for instance) ?
<jn__>
tnt: picorv32 maybe
<awygle>
afaik there's nothing specifically optimized for ice40. but picorv32 is certainly small and tested on ice40.
<jn__>
tnt: a RISC-V 32 implementation made by Clifford Wolf, so it certainly runs on ice40
<tnt>
~2000 iCE40 LUTs from what I read. That's still almost half a UP5k :(
digshadow has quit [Ping timeout: 252 seconds]
<sorear>
There was a good thread on hw-dev a while ago on how nobody has made a plausible competitor to microblaze or lm32
<tnt>
tbh, I'm not looking for a 32b cpu at all ... I'd be perfectly happy with an 8 bit or 16 bit one.
<tnt>
nor am I looking for one with a C compiler. Assembly is fine.
<awygle>
oh hello lm32. time to update my priors on "nothing optimized for ice40" i guess.
<tnt>
awygle: I don't think the lm32 or lm8 targer the ice40, they're made for the other series from lattice, not the silicon blue chips.
<awygle>
mm
<awygle>
fair enough
<cr1901_modern>
tnt is correct. In fact, lm32 actually doesn't really work on ice40 at present (I'm looking into it)
digshadow has joined ##openfpga
<mnr>
Hello everybody, can somebody perhaps provide me with some layman-compatible clues about how far the artix-7 bitstream reverse engineering efforts have come? I have tried to find some layman-compatible explanation on http://prjxray.readthedocs.io and https://symbiflow.github.io/, but I have problems extracting a high-level picture from the information there. AIUI, basic LUT configuration is known, BRAM
<mnr>
configuration is known as well, but I/O tile configuration hasn't been decoded yet. Is that correct?
<kc8apf>
more or less
<kc8apf>
there's still work to understand all of the BRAM configuration bits. IOBs are completely unknown, as are CMTs and DSPs
<whitequark>
CMT?
<kc8apf>
clock management tile
<whitequark>
ahh
<kc8apf>
PLLs, MCMMs
<mnr>
kc8apf: thanks
<kc8apf>
mnr: wish to help or wanting to use the toolchain
<mnr>
kc8apf: I'm a complete FPGA newbie, currently playing around on an iCE40 with yosys&co. I'm somewhat active in RISC-V development on the software side of things and had been talking to some hardware people about RISC-V implementations with supervisor mode support on FPGAs. The general comment was "iCE40 is too small, a medium-size artix-7 would probably be large enough", so I was interested how the state
<mnr>
of things is on the way to a free toolchain for the artix-7.
<kc8apf>
ah, ok
<kc8apf>
most of the people working on artix-7 have shifted to getting a timing-based place-and-route working for ice40
<sorear>
I maintain that an actually FPGA-optimized core with supervisor support could easily fit on ice40
<whitequark>
why would you want that?
<whitequark>
it's really slow
<mnr>
whitequark: building a free CPU design with free software to run free software on it is an interesting concept from a philosophical point of view, even if the result is slow.
<sorear>
Rocket runs on FPGAs by accident only
<mnr>
sorear: inhowfar "by accident"?
<tnt>
kc8apf: can't wait for the result of that :)
<kc8apf>
hmm. arachne-pnr outputs ice40 ascii bitstream format. vpr doesn't really have an output format. I heard mention that xc2par uses verilog attributes to specify locations. What's a good format for expressing a fully placed and routed design?
<whitequark>
mnr: I'm talking about a RISC-V with supervisor support specifically
<whitequark>
it gives you nothing
<whitequark>
also, most RISC-V implementations run horribly on FPGAs
<awygle>
kc8apf: as far as i'm aware there really isn't one. you can write a post-place BLIF from arachne...
<mnr>
whitequark: well, supervisor mode support (and of course enough RAM, which is a topic for itself) makes the difference betwwen a pure microcontroller and something able to run a POSIXish OS.
<cr1901_modern>
I'm not sure I know _any_ ice40 dev board w/ enough (SD)RAM to run a *nix
<cr1901_modern>
doesn't mean it couldn't be done, but...
<whitequark>
what's the point of running a POSIXish OS at something like 5 MIPS?
<sorear>
use fdpic :p
<kc8apf>
I guess that's a reasonable place to start. Means I'll need to figure out routing.
<whitequark>
also, what's the fundamental benefit of having a free CPU design that runs on a non-free FPGA?
<mnr>
cr1901_modern: that's true, although somebody has married an iCE40 with HyperRAM chips, i.e. pseudo-static DRAM.
<awygle>
i think maybe EDIF is supposed to support this, but afaict nobody like, does it
<cr1901_modern>
whitequark: Well, I'd _personally_ be curious to see if a *nix was responsive for light tasks at 5 MIPS. I guess I could take a CPU emulator w/ adjustable speed and just tweak that tho.
<cr1901_modern>
Slowest I've tried so far is 50MHz 486
<whitequark>
cr1901_modern: yes. or look at that one project that emulated a full-blown ARM on an ATmega
<sorear>
ORCA is more like 50, although it has other problems
<whitequark>
that was more like 0.5 MIPS IIRC but you can just multiply everything by 10
<mnr>
cr1901_modern: Well, call me old-fashioned, but I have been running NetBSD on 25MHz MIPS R3000 for quite a while.
<cr1901_modern>
Yea I know that project, that's not what I had in mind
<cr1901_modern>
(Mainly b/c I find it horrifying :P)
<whitequark>
sorear: ORCA runs at 50 MIPS on iCE40?
<cr1901_modern>
mnr: The 50 MHz 486 is running NetBSD current (as of Sep 2017) w/ 20MB RAM. It works acceptably. I can even compile code w/ gcc on it (slow as hell), and ssh into it.
<sorear>
whitequark: that is my understanding
<whitequark>
no caches?
<whitequark>
where did you get the 50 MIPS number?
<sorear>
Their documentation
<whitequark>
I don't see a single reference to Lattice in the README
<cr1901_modern>
Oh Good God this is even more horrifying than I remember; they bitbang a DRAM controller
<qu1j0t3>
haha
<mnr>
whitequark: regarding the benefit of a free CPU design on a non-free FPGA: it's one step further down the chain - similar to the free software development in the past, which also has started with free userland applications built by non-free compilers over free tools and compilers to free operating systems and free firmware. Going to a free CPU design albeit on a non-free FPGA is another step in the same
<mnr>
direction.
<shapr>
one day we'll all be using whitequark's OSHW FPGA
<whitequark>
free software has clear benefits, free CPU designs running on slow non-free FPGAs have essentially zero
<whitequark>
free CPU designs running POSIX OSes on slow non-free FPGAs , that is
<whitequark>
free software won because it was much better. there's nothing much better about the setup above
<cr1901_modern>
I admit I jumped on the ice40 bandwagon. The truth is, aside from yosys, I haven't really taken advantage of any ice40 internal info in any of my designs. Neither have had the need, nor the time to really grok the docs
<kc8apf>
awygle: EDIF is a kitchen sink of a spec
* mnr
needs to get off now, again many thanks for your help.
<cr1901_modern>
So in effect "it's FOSS" hasn't really applied to me; icecube is tolerable too (though I have no plans to support it in Migen).
<awygle>
kc8apf: yeah, which is why it's so patchily supported. there's probably something in STEP too :p
<whitequark>
I've never even run icecube
<whitequark>
I have no time for that stuff
<shapr>
AGPL FPGA kickstarter?
<whitequark>
0BSD FPGA kickstarter, maybe
<awygle>
i've run icecube to do the fuzzing stuff for the lm
<awygle>
but not for any other reason
<shapr>
what's that cern hardware license?
<whitequark>
fuck that license
<gruetzkopf>
i'd expect such a big organisation to get their shit together, but noo
<awygle>
i expect big organizations to have their shit all over the place, as far from together as it is possible to get
<qu1j0t3>
maybe the truth is in the middle!
tinyfpga has quit [Ping timeout: 265 seconds]
<shapr>
it's a miracle that anything works at all?
tinyfpga has joined ##openfpga
Bike has quit [Ping timeout: 260 seconds]
<rqou>
kc8apf: not sure what you want exactly but the xc2par project does technically have a "post-PAR netlist" file that it can read/write
<kc8apf>
how do you encode routing info?
<kc8apf>
I understand LOC attributes for placement
<rqou>
it's an automagic serde_json blob of the internal data structures :P
<kc8apf>
arg
<rqou>
and no, generating your own isn't fully supported because you can violate all the invariants
bitd has quit [Remote host closed the connection]
<rqou>
but still, all the internal data structures derive Serialize/Deserialize, have fun :P
<kc8apf>
hard pass
<rqou>
this is actually great for development/testing
<q3k>
use protobufs ~
<rqou>
no
<awygle>
use Cap'n proto
<q3k>
use SOAP
<awygle>
Use CoAP
<kc8apf>
use CORBA
<q3k>
use jsonnet
<awygle>
use Swagger
<q3k>
use Apache Thrift
<rqou>
use java binary serialization :P
<q3k>
use pickle
<awygle>
use Apache Thrust
<rqou>
free 0-days for everybody!
<q3k>
use php serialize()
<awygle>
use eval()
<q3k>
use `gdb -x`
<rqou>
use an existing 0-day to write the data you want into the appropriate memory
Morn_ has quit [Remote host closed the connection]
Bike has joined ##openfpga
flaviusb has quit [Quit: Leaving.]
Miyu is now known as hackkitten
<awygle>
i am always surprised not to see more use of, for lack of a better word, "restricted types" in rust. types that are "just like" another type, "except" they have additional invariants. maybe i'm not looking in the right places...
<rqou>
try using Ada :P
<rqou>
and have fun blowing people up with your code
<awygle>
idk it just seems like a really useful pattern to me