mumptai has quit [Remote host closed the connection]
catplant has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 250 seconds]
catplant has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
catplant has joined ##openfpga
catplant has quit [Quit: WeeChat 2.2]
azonenberg_work has quit [Ping timeout: 250 seconds]
catplant has joined ##openfpga
<TD-Linux> is there a a spartan 7 version of hdmi2usb in the works?
<cr1901_modern> TD-Linux: /join #timvideos
<cr1901_modern> and well, in principle, yes. But need video hardware add ons to take advantage of it
<cr1901_modern> AIUI
unixb0y has quit [Ping timeout: 268 seconds]
indy has quit [Read error: No route to host]
unixb0y has joined ##openfpga
indy has joined ##openfpga
azonenberg_work has joined ##openfpga
G33KatWork has quit [Ping timeout: 264 seconds]
G33KatWork has joined ##openfpga
_whitelogger has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
dj_pi has joined ##openfpga
rohitksingh_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
Bike has quit [Quit: Lost terminal]
catplant has quit [Quit: okay but we gotta bike now, be back soon]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 250 seconds]
Bob_Dole has quit [Remote host closed the connection]
<_whitenotifier> [whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fpd8s
<_whitenotifier> [whitequark/Glasgow] marcan fe6073c - revC: fix silkscreen for FB1
catplant has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
dj_pi has joined ##openfpga
azonenberg_work has joined ##openfpga
Bob_Dole has joined ##openfpga
catplant is now known as catdemon
Miyu has quit [Ping timeout: 252 seconds]
dj_pi has quit [Ping timeout: 250 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 264 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 250 seconds]
m4ssi has joined ##openfpga
GuzTech has joined ##openfpga
<tnt> How is max freq computed ? I mean, nextpnr report shows a 20.8 ns critical path and tell me max freq = 39 MHz ...
<daveshah> tnt: can you post the full path report?
rk[ghost] has quit [Quit: leaving]
<daveshah> No idea what's gone wrong. Can you post your json somewhere?
<tnt> nextpnr-ice40 --up5k --package sg48 --json top.json --pcf top-icebreaker.pcf --asc top.asc --freq 40 --opt-timing
<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
<daveshah> Just nothing to actually use them...
<whitequark> oh I see
<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]
s_frit has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
Flea86 has quit [Ping timeout: 250 seconds]
catdemon has quit [Quit: WeeChat 2.2]
Flea86 has joined ##openfpga
<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> tnt: can you see how https://github.com/YosysHQ/nextpnr/pull/171 works?
<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> Happens without generate too.
<daveshah> localparam j = 2;
<daveshah> (* ATTR_1=1 *) (* ATTR_2=1+j *)
<daveshah> SB_LUT4 #(.LUT_INIT(2)) lut_i (.I0(b), .I1(), .I2(), .I3(), .O(r));
<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?
<Bob_Dole> nevermind, https://www.friendlyarm.com/index.php?route=product/product&product_id=225 also has the pcie broke out with more 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
<tnt> (it doesn't crash and fixes my trivial test case ... that's about the extent of testing so far ...)
dj_pi has quit [Ping timeout: 240 seconds]
jevinski_ has joined ##openfpga
jevinski_ has quit [Read error: Connection reset by peer]
jevinsk__ has joined ##openfpga
jevinskie has quit [Ping timeout: 264 seconds]
<tnt> kc8apf: I heard you were looking for obsolete FPGA boards ? is that right or am I misinformed ?
<qu1j0t3> eh i'd probably accept one lol
<tnt> be careful what you ask for, it's really obsolete :p https://imgur.com/a/D3d2LJm
<qu1j0t3> that's... fancy
<daveshah> It can't be that old, it's SMD :P
* qu1j0t3 snerks
<tnt> I was going to say datecode 0765 ... but ... 65th week doesn't quite work :p
<tnt> 0437 maybe
* cpresser has a unused cyclonII board. https://www.terasic.com.tw/attachment/archive/121/image/fig1-cyclone2-staterkit.jpg I can bring it to 35c3, if some1 is interested
<kc8apf> tnt: PCB has a 2004 copyright
dj_pi has joined ##openfpga
<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
<tnt> qu1j0t3: hot glue and heating ?
<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
GenTooMan has joined ##openfpga