<tnt>
(pcf file is actually empty atm ... it's just some random tests I'm doing see if I stand a hope of meeting my timing target :p)
<tnt>
path_delay doesn't match the sum of logic and routing.
<whitequark>
daveshah: is there any chance you can take a look at hierarchical designs in nextpnr soon?
<whitequark>
i'm adding them to nmigen right now
<daveshah>
No, not realistically in the near future
<whitequark>
is this hard?
<daveshah>
Probably not. But I've got a long backlog of things that need doing more urgently (e.g. for my master's work)
<whitequark>
ahh ok
<daveshah>
Also the JSON parser is total shit
<daveshah>
Realistically you'd have to throw that away and start again
<sorear>
what does it mean to do place and route hierarchically?
<daveshah>
If nothing else, it's a useful hint to the initial placer
<daveshah>
I do understand Vivado's PnR preserves hierarchy
<daveshah>
I am not actually sure what whitequark wants though, in terms of structures.
<sorear>
so does the final design map each source module into a rectangular subregion or what?
<daveshah>
I don't think it's necessarily like that, unless you manually floorplan. I think by default it would just be a hint
<sorear>
I'm still not following you. how can you hint without a floorplan
<daveshah>
Well it's not a strict floorplan I don't think, more just a guide. I don't know Vivado in enough detail to know what really goes on
<daveshah>
whitequark: Thinking some more the design would probably be flattened by nextpnr pretty early on anyway. So I guess `flatten` immediately before JSON export should do almost the same?
<daveshah>
In that case the .s in the cell names should still communicate the hierarchy well enough to nextpnr
<whitequark>
daveshah: i'm actually interested in floorplanning
<daveshah>
Ultimately nextpnr will work on a flat netlist
<daveshah>
The only thing is that it will have something telling it where cells/wires came from (e.g. an attribute or field)
<whitequark>
hmmm.
<daveshah>
I guess this is still best done in nextpnr than a mod to the `flatten` pass in Yosys though
<whitequark>
so what's the point of all the GUI work in nextpnr if you can't actually floorplan?
<daveshah>
Because we haven't implemented floorplanning yet
<whitequark>
oh, so it's actually planned
<whitequark>
sure
<whitequark>
fine
<daveshah>
We even have some data structures for it already
<sorear>
do you manually assign LUTs/modules to regions, and then P&R runs normally but with extra constraints?
<daveshah>
That is basically how we'd implement it
<daveshah>
In most cases we'd simply assign all Bels in a given rectangle to a region
<daveshah>
However it's a bit more flexible with that do deal with any partial reconfig oddities, etc, that might exist
<azonenberg_work>
daveshah: i am extremely interested in nextpnr support for floorplanning based on hierarchy
<daveshah>
OK, it seems this should move up my priority queue then
<azonenberg_work>
i dont care what the internal data model looks like as long as i have the ability to preserve hierarchy from synthesis until implementationa
<azonenberg_work>
and constrain a given block of hierarchy to part of the chip, etc
<azonenberg_work>
another desirable feature, lower priority, is RPMs
<daveshah>
First thing's first. Does anyone know a JSON parser that is non-shit but can handle 100s of MB of netlist if needed
<azonenberg_work>
like xilinx RLOC
<daveshah>
azonenberg_work: We have full internal support for them already
<azonenberg_work>
including hierarchy?
<azonenberg_work>
like, rloc a module to be three clbs right of you
<daveshah>
no, just relative constraints
<azonenberg_work>
ah ok
<azonenberg_work>
i want to be able to hierarchially compose relative constraints
<azonenberg_work>
For example, create a block of two slices where one is north of the other
<azonenberg_work>
then make an array of four of these east-west
<azonenberg_work>
etc
<daveshah>
Yeah, that's a bit beyond relative constraints atm
<azonenberg_work>
basically what you do is, follow each hierarchial block with an rloc up to the highest rloc'd element
<daveshah>
They were mostly intended for dealing with things like carry chains, LUT muxes/cascade, DSP cascade, etc, internally
<azonenberg_work>
call that the origin then go down again and apply offsets as needed
<daveshah>
Yeah, I'm pretty sure the placer and data structure stuff is fine
<azonenberg_work>
so if i rloc a block of hierarchy to X4Y0
<azonenberg_work>
then X0Y0 in that module should be 4 tiles right of X0Y0 in the parent scope
<azonenberg_work>
etc
<daveshah>
Sooner than this I'll look at decent Python bindings for the relative constraint stuff
<daveshah>
Although not quite as easy as this it should cover many more use cases
<azonenberg_work>
Doing it in HDL would be strongly desirable, esp if compatible with xilinx rloc syntax
<azonenberg_work>
The idea is to be able to compose primitives and tiles to do something like a maximally performance wide crossbar
<azonenberg_work>
performant*
<azonenberg_work>
where you allocate a certain number of columns to routing of data in and out, have the select signal routed on the shortest path, etc
<azonenberg_work>
it should be very nice for big NoCs and fancy datapaths pushing process limits
<azonenberg_work>
jangray did a lot of cool work with this in ISE then had trouble in vivado b/c of xilinx having poor rloc support
<azonenberg_work>
he's now pursuing doing similar work in rapidwright but obviously we need an open solution
<daveshah>
Yes, the idea is that the Python API is there for really funky use cases similar to RapidWright
<daveshah>
But I agree in the long term attributes would be good too
<azonenberg_work>
yeah both would be ideal
<whitequark>
daveshah: there's a ton of good json parsers for c/c++...
<whitequark>
i can look it up
<daveshah>
Thanks
<daveshah>
the main constraint is needing to not choke on fairly large JSON
<whitequark>
daveshah: so what i'll do is look up the best rust json parser
<daveshah>
I'm not sure if Boost ptree is up to that
<whitequark>
and then see which c++ parser beats it
<whitequark>
:P
<zkms>
:3
<whitequark>
it, of course, will have a comparison table.
* whitequark
outsources
<sorear>
which one will have the comparison table?
<whitequark>
the rust one
<sorear>
mm
<tnt>
daveshah: the case in the json I posted is an extreme case, but looking at others, the path_delay and the one computed in the critical part report actually never seem to match.
<daveshah>
Yes, I'm investigating this now. I've found one reason for the problem but it's still not fully fixed
<tnt>
Ah ok tx :)
drawkula has left ##openfpga ["WeeChat 2.3"]
s_frit has quit [Remote host closed the connection]
<tnt>
daveshah: thanks, seems to be more consistent now :) Too bad, I had hoped the fmax was wrong and the crit path was correct :p
<daveshah>
Yeah, the problem was how it backtracks and prints the path
<tnt>
good news is that my critical path has a 6.5 ns delay just because it placed all the logic at the opposite corner from the spram, so that should be somewhat easily reduced.
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh_work has quit [Read error: Connection reset by peer]
<daveshah>
With the new placer --opt-timing is probably redundant too
Miyu has joined ##openfpga
<tnt>
daveshah: I've actually been usiing that branch all along :p well now I'm using crit_placer_lutcascade
<daveshah>
That LUTCascade implementation isn't very good - I would switch back to the main placer branch now as I've added some major speed improvement. LUTCascade is much harder than it looks...
<tnt>
Well I'm not actually using --lutcascade so I think it doesn't do anything right ?
<daveshah>
Oh yeah, that should be fine
<daveshah>
either way, I'd switch back as any fine tuning will be on the crit_driven_placer branch now
rohitksingh has joined ##openfpga
<tnt>
So I'm doing something like : (* ATTR_1=1, ATTR_2=1+i *) SB_LUT4 #(...) x (...); in a generate loop. And somehow only ATTR_2 makes it to the .json/.blif. ATTR_1 disappears.
<daveshah>
Yes, I can reproduce
<daveshah>
happens with separate (* *)s too
<tnt>
Ok, good I'm not dreaming. That's just weird.
<daveshah>
seems to depend on the order of attributes??
<daveshah>
(* ATTR_2=1+j *) (* ATTR_1=1 *) works fine
<tnt>
ah yeah ... but try to have ATTR_1=2+j ...then no order will work.
<tnt>
-dump_ast1 during read_verilog already shows the issue.
<daveshah>
Yeah, it's already lost by append_attr in the parser
genii has joined ##openfpga
* tnt
sucks at yacc
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
<whitequark>
people who do not suck at yacc scare me
<tnt>
lol
<sensille>
:)
dj_pi has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
<cr1901_modern>
https://www.friendlyarm.com/index.php?route=product/product&product_id=241 This may be the first SBC I've seen that breaks out the PCIe bus. Perhaps decent for playing with PCIe cores on FPGAs?
<Bob_Dole>
neat
<Bob_Dole>
The R.Pi's are limited by the GPU, which can only access 1GB of RAM, acting as the host-processor to the ARM core, but why's that one only got 1GB of RAM?
<tnt>
Ok, well except for filing an issue, I don't think I can do much for this bug ... no idea how this thing works.
GuzTech has quit [Quit: Leaving]
<daveshah>
I'm afk right now, I'll have a look when I'm back but I'm not a yacc person either
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
<tnt>
I even have trouble understanding the yydebug output ...
rohitksingh has quit [Remote host closed the connection]
m4ssi has quit [Remote host closed the connection]
<tnt>
daveshah: arf, I see the bug ...
<tnt>
no idea how to fix it though :/
<tnt>
But the idea is that the way attribute are accumulated in a std::map during parsing doesn't support recursion .... but you can have expressions as the value of attributes, and inside those expressions you apparently can have attributes ...
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
catplant has joined ##openfpga
<tnt>
wtf is {* *} ... default attributes ? didn't even know this existed.
<whitequark>
its a yosys extension
<tnt>
Ah ok, that' probably why I'm having trouble finding it in the spec :p
<kc8apf>
tnt: anyway, yes, I do want obsolete FPGA/CPLD/GAL/etc boards
<kc8apf>
ideally dev boards so I can do testing with them
<kc8apf>
but if a board has interesting parts in a useable config (that looks like an linecard for a switch), i'll take it
<tnt>
kc8apf: do you want me to bring that one to congress ? It's definitely not a dev board, but I have a cable to power it and it has jtag. A long time ago I mapped all the FPGA interconnects using jtag bscan.
<kc8apf>
I won't be at congress
<kc8apf>
yes, i'd like to have it
<tnt>
Ah well, I can ship it whereever,
<kc8apf>
maybe esden can bring it back to the US
<tnt>
Ah yeah, good idea.
<tnt>
esden: ^^ ?
<esden>
wha? me? *reading*
<esden>
kc8apf: how dare you not come to the congress! ;)
<esden>
is your dragster not ready for the drive? :P
<kc8apf>
cpresser: i'll gladly take it. Let's see if esden will be my courier
<kc8apf>
hahah
<kc8apf>
I'd have a $1B gas bill
<kc8apf>
Winter holidays are one of the few times I get multiple weeks with my kids
<esden>
depending on how large the thing is...
<esden>
I can then bring it, but unfortunately the times when you were getting two 60lbs bags for free on intercontinental flights are not here any more. :(
<kc8apf>
tnt: cpresser: i'll gladly take both boards. I can pay shipping if needed.
<esden>
tnt: how large is the board you want me to bring for kc8apf ?
<tnt>
esden: well, if you bring 100 icebreaker, I'm assuming you're not planning on bringing them back :p
<esden>
I am contemplating sending them to vienna to clifford and not bring it in my luggage
<esden>
also you obviously don't know my mom... she always sends me with stuff back ...
<tnt>
esden: It's ~ 18cm x 25cm or so.
<tnt>
a bit smaller than a sheet of A4 paper.
<esden>
I should be able to put it between my clothes. It might be expensive and dangerous to ship considering it's size.
<esden>
Just bring it to the congress I will figure something out. :)
<tnt>
Worse case, I can take it back and ship it. It not that expensive, it about 15$ to ship to the US (cheapest/untracked ... but it usually makes it :p)
<tnt>
I
<prpplague>
and $150 to ship back from the US
<tnt>
I'm already bringing 4 other boards to give away to people :p it's christms ... trying to get rid of stuff here.
<tnt>
prpplague: yeah :)
<kc8apf>
last night's reverse engineering meetup had a "closet cleaning" gift exchange
<prpplague>
kc8apf: where was this?
<kc8apf>
Mountain View, CA
<prpplague>
ahh
<tnt>
kc8apf: ahah nice. Would have been useful for me. I found some people interested in some boards / kits, but a bunch will (or already have) end up in the trash :/
f003brv has joined ##openfpga
f003brv has quit [Quit: Page closed]
dj_pi has quit [Ping timeout: 250 seconds]
<tnt>
I need to heat up an ice40 ... any better suggestion than just sticking a big D2PAK diode on it connected to a constant current source ?
<qu1j0t3>
hairdryer? hot air gun?
<tnt>
I need it to be electronically controllable.
<daveshah>
Create a controlled number of short circuits in the bitstream ;)
<cpresser>
only heat up the ice40, or would heating the whole board be okay? temperature range? how fast do you want to heat?
Miyu has quit [Read error: Connection reset by peer]
<tnt>
cpresser: whole board is fine, there is pretty much only the ice40 on there. I guess up to 100C or so.
<tnt>
daveshah: can you actually create internal shorts ?
<cpresser>
reflow oven?
<daveshah>
tnt: I'm pretty sure some of the span wires at least have multiple possible drivers
<tnt>
(1) I don't have a reflow oven (2) the board is going to be wired to a bunch of stuff, so ... no very practical :p
<qu1j0t3>
hot glue some power resistors?
<cpresser>
buy a hotend from a 3d-printer?
<cpresser>
it has a aluminium-block and can be clamped to the back of a chip
<genii>
3D printer bed heater maybe. Not sure most reflow ovens would go down to around that 100C unless there's some board preheating system along with it
<qu1j0t3>
tnt: :)
<qu1j0t3>
tnt: how hot do you need?
<qu1j0t3>
oh 100
<qu1j0t3>
yeah oopsie
<qu1j0t3>
epoxy then!
Miyu has joined ##openfpga
jevinskie has joined ##openfpga
jevinsk__ has quit [Ping timeout: 250 seconds]
<azonenberg_work>
tnt: whats the goal
<azonenberg_work>
timing characterization?
<azonenberg_work>
I built a stack of two Peltier plates with some arctic silver and an x86 CPU heatsink
<tnt>
azonenberg_work: yeah timing.
<azonenberg_work>
That's probably the best option
<azonenberg_work>
also please publish this info somewhere, maybe on the siliconpr0n eda wiki or something
<azonenberg_work>
i want to build an open body of knowledge on fpga timing characterization techniques
<azonenberg_work>
also message monochroma and lain, they built a hacky environmental chamber out of a minifridge, a resistive heater, and some control logic
<tnt>
ok, yeah, I was planning on documenting the results (and process ... since results without how they were obtained are not so useful).
<azonenberg_work>
i started looking into this for greenpak characterization
<azonenberg_work>
but had to pack up my lab before getting anything publishable
<azonenberg_work>
i'm just starting to unpack into the finished half of my new lab (the other half is very much a construction site still)
<mithro>
daveshah: sb0 in #m-labs was asking if the ECP5 supports partial reconfiguration
<daveshah>
mithro: replied there too, unfortunately not
<azonenberg_work>
daveshah: when you say doesnt support
<azonenberg_work>
do you mean you confirmed it doesnt work?
<azonenberg_work>
or they dont officially support it :p
<azonenberg_work>
you can do (somewhat buggy, i didnt investigate much) partial reconfig in coolrunner for crying out loud
Richard_Simmons has joined ##openfpga
<azonenberg_work>
sure, the utility is very limited
<azonenberg_work>
but you can flip bits in pla equations etc no problem
<daveshah>
Although it might be possible to program frames after boot, each frame has too much stuff in and I don't know if config is even latched
<daveshah>
You'd be guaranteed to cause short circuits in the process
<daveshah>
Also each frame has some IO bits in that would get screwed up
<daveshah>
You certainly couldn't just change a LUT init for example
Bob_Dole has quit [Ping timeout: 250 seconds]
<azonenberg_work>
ah ok
<azonenberg_work>
yeah coolrunner parallel-writes an entire row i think
<azonenberg_work>
so shouldnt be any way to create ZIA shorts (i think)
<daveshah>
I don't even know what the command is to program only some frames - just the naming of commands suggests there might be one
<azonenberg_work>
but you'd basically be programming one product term
<azonenberg_work>
1/3 of one macrocell
<azonenberg_work>
and the global routing
<azonenberg_work>
for each of two funciton blocks
<azonenberg_work>
Lol
<daveshah>
One thing I haven't tried is the EBR read or write commands after the device has booted
<daveshah>
I suspect that they wouldn't work either because I doubt the RAM has a third write port just for config
<azonenberg_work>
it might be a mux that takes over from the design
<azonenberg_work>
if you pause the clock it may work
<azonenberg_work>
xilinx had, in some generations of parts, a "capture" feature that would copy dff current values into the "dff init" register
<azonenberg_work>
then you could read back the bitstream and see current bram contents (with clock stopped to avoid metastability issues) and dff values
<mwk>
still has
<mwk>
and "some generations" is basically all of them
<azonenberg_work>
mwk: afaik capture was removed in ultrascale
<azonenberg_work>
idk about 7 series
<azonenberg_work>
6 and before have it
<azonenberg_work>
there isnt really much use IMO except for toolchain debug
<daveshah>
ECP5 doesn't actually have a ff init register of any kind
<daveshah>
Flip-flops are initialised by GSR to their LSR value
<mwk>
oh, ultrascale, heh
<mwk>
well, 7 series still has capture
<daveshah>
I believe you can read out LUT contents in the ECP5 including distributed RAM data
<daveshah>
There's actually an errata that distributed RAM data is erroneously included in the SED CRC calculation
<daveshah>
Meaning you can't use distributed RAM and SED at the same time