<azonenberg_work>
Then extrapolating from that measured value to another geometry of the same material
<jhol>
so VTR has some demo XML that has some guestimate values for a 28nm process - which is what the ice40, so I figured I could use the C value, and then scale the R value to get the propagation time that matches the values that icebox has
<azonenberg_work>
well R and C will both scale with a longer wire
<azonenberg_work>
Looking at the vtr code directly though
<azonenberg_work>
Honestly, results might be easier if you set C=1 for everything
<azonenberg_work>
and had R be delay units :p
<jhol>
yeah - makes sense
<clifford>
jhol, never used VPR so far (still on my todo list), but for some primitives (switches, etc.) you can specify absolute delay values. I
<jhol>
yeah
<clifford>
I'd try setting R=0 (which should give you a delay of 0) and model delay using things like switch Tdel
<azonenberg_work>
That's an option too i guess
<azonenberg_work>
Btw i have been away from openfpga stuff for a few weeks due to other things going on, but planning to spend a while hacking on things next month
<jhol>
yeah I find VTR XML slightly cumbersome to model with
<jhol>
some things are trivial to express in XML
<jhol>
some things cause my brain to hurt
<clifford>
re. R and C values: The R values along the path add up, and the 1/C for all driven components add up.
<jhol>
yup
<clifford>
So it's (R1+R2+R3+...)*1/(1/C1 + 1/C2 + 1/C3 + ...)
<azonenberg_work>
I'm going to be meeting up with whitequark for a couple of weekend hackathons to try and bang out most of the remaining greenpak4 stuff
<clifford>
From what I've seen so far (reading docs, not really used it) it's not really designed to be used with real architectures. It's a nice playground for P&R algorithms but for real hardware one would likely need to manually add some additional features to the C code.
<jhol>
yes indeed
<azonenberg_work>
clifford: yeah that was my understnading too
<azonenberg_work>
but that's what we're all here for :p
<jhol>
an example being that you can only set the size of a block in terms of it's height - but not it's width
<clifford>
especially on the top-level grid side it seems to be insufficient to support real-world stuff like iCE40.
<jhol>
so good luck if you have a block where width!=1
<azonenberg_work>
Well, we may have to write our own PARs for real arches
<azonenberg_work>
Not like we haven't done this before
<jhol>
I think ice40 can be supported - just about
<jhol>
except for the "extra" blocks
<azonenberg_work>
clifford: How hard do you think it'd be to extend something like arachne to a more complex arch like 7 series?
<jhol>
azonenberg_work: forget it
<jhol>
I tried doing some prep work for it
<azonenberg_work>
jhol: And how would vpr handle it?
<jhol>
it would need rewriting
<azonenberg_work>
Are we better off doing a full rewrite?
<clifford>
My guess would be (not checked the code) that VPR reads the XML and then flattens the grid anyways. So I guess it should not be too hard to fix this kind of stuff..
<azonenberg_work>
i mean we will have to tweak anything
<azonenberg_work>
only question is, how heavily
<jhol>
azonenberg_work: so I spend a month refactoring apnr in the summer to see what could be done
<clifford>
If my guess is right, a good solution might be to simply add a feature for a "manual grid" where you just place each and every cell individually.
<jhol>
at the moment the ice40 is completely hard-coded intoit
<jhol>
I concluced that it needs to gain a architecture-XML feature like VTR has
<jhol>
- a way to soft-define architectures
<azonenberg_work>
jhol: fwiw i am going to be doing a bunch of work on the coolrunners at some point over the coming weeks-to-months as well
<jhol>
\o/
<jhol>
so cool
<azonenberg_work>
i want to get back to the xc2c32a project
<clifford>
(I guess that would be equivalent to having a 1x1 grid and using a lot of hierarchy in that one block. :)
<azonenberg_work>
i have a bunch of various stuff floating around
<azonenberg_work>
but need to combine it cleanly and refactor a LOT
<jhol>
so looking at the VTR code - it's not a very clean code-base
<jhol>
and I'm not sure how responsive they'd be to some ##openfpga blitzkreig on the code-base
<clifford>
jhol, but afaik is should yield pretty good results even for larger devices.
<jhol>
but it could be improved
<azonenberg_work>
jhol: speaking of clean code (or lack thereof)
<azonenberg_work>
If you have any thoughts on the arch etc i'd love to hear
<jhol>
maybe you could connect it to OpenOCD
<azonenberg_work>
Being able to bridge the two is definitely on the longer term TODO
<azonenberg_work>
My focus is mostly on low-level ops, i'm not trying to make gdb bridges etc necessarily
<azonenberg_work>
But i want to be able to do things like talk to USER* instructions on a xilinx part after loading a bitfile
<azonenberg_work>
And be able to work directly with a bit and not a svf
<azonenberg_work>
I have that much working
<azonenberg_work>
What i want to do at some point is refactor a lot of the coolrunner code to reflect my new understanding of the device microstructure
<azonenberg_work>
it will be a lot cleaner with less magic numbers
<azonenberg_work>
So basically...
<azonenberg_work>
coolrunner devices use the jedec JED file format for the bitstreams
<azonenberg_work>
This is supposed to be something you can directly burn to a device
<azonenberg_work>
But xilinx being xilinx, they didn't do that
<azonenberg_work>
the JED file is using virtual addressing
<azonenberg_work>
And the chip has to be burned with physical addressing
<azonenberg_work>
The translation right now is hard-coded (for the xc2c32a)
<azonenberg_work>
and i think i support the 64, never bothered to do the rest
<azonenberg_work>
the newly cleaned up code is going to use a procedural permutation based on the actual device structure
<azonenberg_work>
should be way more readable
<jhol>
yeah it would be cool to get a more general version of xc3sprog
<azonenberg_work>
and extensible to larger devices
<azonenberg_work>
jtaghal is not just an xc3sprog replacment
<azonenberg_work>
it's meant for interactive debug on fpga designs
<azonenberg_work>
thats what i used it for heavily on antikernel
<jhol>
clifford: I think if VTR is going to be used, the XML language will need some improvement. but if VTR is not going to be used e.g. someone does a arachne-pnr II, it will still need some kind of architecture description language
<jhol>
it would be cool to see a growing git repository of FPGA structure data in this format, from all these FPGA reverse engineering projects going on
<azonenberg_work>
jtaghal plus the antikernel debug bridge code (which i am currently in the process of de-convolving from the jtaghal repo, it belongs in the antikernel code) lets me get a packet-based interface directly to arbitrary IP cores on the device
<clifford>
jhol, if my guess is right that they just flatten the description anyways, then the XML arch description for VPR might as well be a pre-flattened intermediate format that's been generated from something else. At least that could be useful for experimenting with different architecture description languages.
<azonenberg_work>
clifford: I think there will, long term, have to be at least 2 separate arch formats
<azonenberg_work>
one for 2D fabrics and one for crossbar-based stuff like coolrunner and greenpak
<azonenberg_work>
as those are fundamentally different interconnects with totally different par algorithms etc
<jhol>
yup
<jhol>
clifford: did you get a chance to test the ice40 kernel driver yet?
<jhol>
no stress if not
<azonenberg_work>
diamondman: btw
<azonenberg_work>
what is the status of your work on the xilinx platform cable?
<azonenberg_work>
in particular the DLC10
<clifford>
jhol, no. it is on my todo list, but that list is overflowing ever since I'm back from california because I didn't work on anything on that list for almost two weeks..
<jhol>
yeah I figured that might be the case
tecepe has quit [Ping timeout: 244 seconds]
<azonenberg_work>
clifford: yeah my list is going to get nuts
<azonenberg_work>
i'm about to go to hong kong for 3 weeks
<azonenberg_work>
and then christmas
<azonenberg_work>
so my inboxes will be overflowing with... who knows :p
<jhol>
clifford: can I suggest you just grab the kernel source, and kick off the build
<jhol>
this will save a lot of time if/when you actually want to do the test
<jhol>
it takes ages to clone linux, and ages to build the RPi kernel the first time
digshadow has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
<felix_>
jhol: haven't had time to test the patches; need to get some paid work done. i only have prepared a fresh sdcard with a raspbian for it by now
<jhol>
:) - thanks for doing that much!
<felix_>
if vpr can't be adpted for the artix7, i'd really suggest to write the new codebase in rust and not in c/c++. has some nice features, not too much overhead, more abstraction and more memory safety
<felix_>
clifford: you're also at the 33c3, right? if you want, i'd like to discuss if and how i could help with the artix7
<jhol>
I think there is a big question about governance of VTR
<jhol>
I'm not sure if their interestests are really aligned with ours
<jhol>
- do they care about code quality as much as we need them to?
<felix_>
i don't know; only had a brief look at the project
<azonenberg_work>
yeah because half the reason that we are doing this project
<jhol>
well they currently don't have good enough code quality
<azonenberg_work>
is because the vendor eda tools are terrible :p
<jhol>
- but then can you make a leopard change his spots?
<jhol>
so I'm not sure how they'd feel about a blitzkreig from this little community, coming in and telling them all the ways their project sucks
<jhol>
I want to know how long it to cotton seed to write APNR - it seems to have been a matter of months? if so, perhaps writing a more flexible APNR would not be so bad, and would be a better way forward
<jhol>
*took cotton seed...
digshadow has quit [Ping timeout: 256 seconds]
<felix_>
yeah, writing a good placer isn't trivial. the router is probably a bit easier
<jhol>
I think it would need to be a new project, because I have found cseed is nowhere near responsive enough to incoming patches
<jhol>
I'm don't know much about his situation, but most of what I contributed bit-rotted without any proper feedback
<felix_>
meh
carl0s has joined ##openfpga
tecepe has joined ##openfpga
<clifford>
felix_, yes. I'll be at 33c3. Let's talk.
<jhol>
felix_: I think the point is you don't need to write a "good" placer or anything on the first pass, you just need to set up an clean enough architecture that encompasses the problem with some quick-and-dirty algorithms, leaving the way open for refinement with more advanced code
<felix_>
clifford: sounds good; i'm looking forward to that
<felix_>
jhol: ack
<felix_>
a clean architecture should be the highest priority; otherwise it's probably not really worth the effort
<felix_>
anyway; i have to get some sleep now. good night.
maaku has joined ##openfpga
carl0s has quit [Quit: Leaving]
amclain has quit [Quit: Leaving]
kuldeep has quit [Ping timeout: 250 seconds]
kuldeep has joined ##openfpga
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
<rqou>
housemates need to put our networking equipment on a UPS
<rqou>
tripped the breaker again just now
<rqou>
unfortunately due to the wiring mess there's no good way to get network equipment on the UPS without a huge extension cord
<rqou>
i'm pretty sure the reason we're suddenly having problems is because it's winter and there are space heaters running
<rqou>
azonenberg_work: reading backlog you mentioned that you can't extract parasitics even when given the process parameters?
<rqou>
for my microfab class we used a proprietary tool tsuprem4 to simulate doping and various processing steps on a wafer
<rqou>
is that not sufficient to calculate parasitic information? or does it not work for modern processes?
<rqou>
(of course you don't actually have the parameters needed to feed into a tool such as tsuprem4; this is just out of curiosity)
maaku_ has joined ##openfpga
maaku has quit [Ping timeout: 260 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
maaku_ has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
qu1j0t3 has joined ##openfpga
<azonenberg>
rqou: what i meant is
<azonenberg>
you need to know the parameters :p
<azonenberg>
and while you may be able to predict how e.g. actual doping intensity will vary with beam current for a given implanter
<azonenberg>
you still have to calibrate that tool
<azonenberg>
Because if my experience with SEMs is any hint, the beam current at the source has nothing to do with ions/mm^2 at the wafer surface
<azonenberg>
so many apertures and lenses etc in the way
<azonenberg>
Sure, you can model incremental changes to an existing process
<digshadow>
rqou: just looked at the bonding machine
<digshadow>
doesn't look worht it
<digshadow>
worth
pie_ has joined ##openfpga
<rqou>
hmm why not?
<rqou>
what about the other stuff? (i didn't look too closely)
cr1901_modern has quit [Read error: Connection reset by peer]
Bike has quit [Quit: natural]
LeelooMinai has quit [Quit: No Ping reply in 180 seconds.]
LeelooMinai has joined ##openfpga
mIKEjONE1 has joined ##openfpga
dingbat has quit [Ping timeout: 258 seconds]
mIKEjONES has quit [Ping timeout: 258 seconds]
azonenberg has quit [Ping timeout: 258 seconds]
defparam_ has joined ##openfpga
SuperChickeNES has joined ##openfpga
ChickeNES has quit [Ping timeout: 258 seconds]
defparam has quit [Ping timeout: 258 seconds]
qu1j0t3 has quit [Ping timeout: 258 seconds]
hobbes- has quit [Ping timeout: 258 seconds]
hobbes- has joined ##openfpga
azonenberg has joined ##openfpga
azonenberg has quit [*.net *.split]
dingbat has joined ##openfpga
qu1j0t3 has joined ##openfpga
azonenberg has joined ##openfpga
dingbat has quit [Changing host]
dingbat has joined ##openfpga
openfpga-bb has quit [Ping timeout: 244 seconds]
openfpga-bb has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
maaku has quit [Quit: No Ping reply in 180 seconds.]
<rqou>
i just learned that the sony ps2 architecture is even more insane than i originally thought
maaku has joined ##openfpga
<rqou>
late model ps2s have a ppc cpu emulating a mips r3000 that is supposed to be the io coprocessor and ps1 back-compat processor
<rqou>
(the magic google term is "DECKARD")
<rqou>
so (late) PS2s have mips, ppc, and the custom vu processors all with different ISAs
cr1901_modern has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 258 seconds]
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 244 seconds]
<kristianpaul>
f1 instances, fpga instances in aws :p
<qu1j0t3>
:)
tecepe has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
amclain has joined ##openfpga
SuperChickeNES has quit [Quit: ZNC 1.6.1 - http://znc.in]
* felix_
wonders if the fpga bitstreams are getting sanitized before getting loaded in the fpga
<jhol>
I'd love to reverse engineer the ultrascale+ if only dev boards were not so damn expensive
<jhol>
(and I didn't have a 5 month old baby to look after)
<defparam_>
"Dedicated PCIe x16 interface to the CPU"... "The FPGAs are dedicated to the instance and are isolated for use in multi-tenant environments"... I wonder what mitagations they have for DMA attacks.. IOMMU?
<felix_>
artix7 is imho a much more interesting target at the beginning, since the chips are also rather fast but ways cheaper. and having understood the artix7 will really help to understand the bigger and newer series
<felix_>
probably iommu
<jhol>
yes I agree - and I suspect previous and future generations of Xilinx devices are going to have a lot in common also
<defparam_>
"In addition to building applications and services for your own use, you will be able to package them up for sale and reuse in AWS Marketplace." - looks like they are creating a store for IP resell
pie_ has quit [Ping timeout: 258 seconds]
<kristianpaul>
they are just plugging fancy fpga boards in their current hw
<kristianpaul>
dedicate instances most likely
<kristianpaul>
but having xilinx ide in a AMI is not that bad..
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
m_w has joined ##openfpga
<azonenberg>
jhol: i can almost guarantee that the 7 series are basically all the same
<azonenberg>
just maybe more routing resources in the bigger devices
<azonenberg>
the higher end*
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
X-Scale has quit [Ping timeout: 244 seconds]
<felix_>
yeah, i'd also suspect that the whole 7 series is made from the same parametrizable building blocks, but the kintex and virtex devices have more routing ressources
<azonenberg>
Yes, almost certainly
<azonenberg>
I would expect the bitstream layout will have some blocks mirrored left-right etc for electrical reasons
<azonenberg>
the two slices in a CLB likely have different layouts as well b/c a CLB seems like the actual base block of layout according to what i've seen of other devices
<azonenberg>
well, CLB + switch box
<felix_>
it seems that there are mainly two kinds of switch boxes and the're probably mirrored
<felix_>
yes
jhol has quit [Quit: Coyote finally caught me]
jhol has joined ##openfpga
<openfpga-github>
[yosys] azonenberg pushed 12 new commits to master: https://git.io/v137B
<openfpga-github>
yosys/master 277f478 oldtopman: Added optional flag for linking curses with readline.
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou>
waiting for someone to use it to discover a chipset bug and pwn the system :P
<rqou>
azonenberg?
<pie_>
hrhr
<pie_>
well i wonder how much recon you could do with only software access?
<pie_>
idk, i saw some really oly thing a while back i have no idea what im talking about, and i doubt theyd make something like this possible, but maybe you could have it jtag itself? :P
<pie_>
though i suppose for devs to be able to use the platform well theyd have to give out hardware documentation
<rqou>
the fpga almost certainly isn't connected to the pcie jtag pins, that's too easy :P
<rqou>
no, i was saying that someone should find a silicon bug somewhere in the chipset iommu logic or similar
<pie_>
*old
<pie_>
ah i see
<azonenberg>
rqou: lol that would be fun
<rqou>
i've never looked into the details, but i assume that pcie has a nice number of footguns
<azonenberg>
I know it allows arbitrary DMA but if you do passthrough that may be virtualized by the iommu
<azonenberg>
Definitely curious about how to pwn a host with ti
<azonenberg>
it*
<pie_>
at the least it would be a look into the whole fpga integrated computer thing