01:33 <emeb> OK - got the RPi loading up the UP5k now. Here's what seems to have been happening: The original shell script from Jan Marjanovic uses dd to send the bitstream to /dev/spidev0.0 but doesn't try to set the clock speed so dd just uses the max which seems to be way too high for the FPGA. Looks like anything faster than about 25MHz is too much. That results in the bitstream loading OK, but the NVCM calibration is not read properly.

01:34 <emeb> My C prog w/ the char dev gpio was using a better SPI clock speed but wasn't handling the final dummy clocks properly. Once I got that squared away it works.

18:07 <awygle> Is it true that nextpnr takes its timing estimate into account when running pnr?

18:08 <daveshah> Yes

18:10 <awygle> But it assumes a uniform target for the whole net list?

18:10 <daveshah> No

18:10 <daveshah> it supports per clock constraints

18:10 <awygle> Oh cool!

18:11 <daveshah> what it doesn't really do yet is inter clock constraints tho

18:11 <awygle> Meaning for CDC, or meaning like "this clock is half the speed of that clock"?

18:12 <daveshah> both

18:12 <daveshah> you can't do things like constraining a max delay between delays

18:12 <daveshah> nor can it constrain clocks to be related

18:13 <awygle> I see

18:13 <awygle> Does uhh opentimer (?) support those things?

18:14 <daveshah> no idea

18:26 <azonenberg> daveshah: yeah i think that is one of the last major blockers to me being able to try using the free toolchains for my projects

18:26 <azonenberg> as opposed to trivial experiments

18:26 <azonenberg> i honestly cannot remember the last time i did an fpga project without more than one clock domain

18:30 <whitequark> azonenberg: per-clock constraints, or inter clock constraints?

18:30 <tnt> azonenberg: well it at least reports the delay, so you can do a post-check ... but you can't optimize for it.

18:31 <azonenberg> whitequark: cross clock

18:31 <azonenberg> as well as properly supporting related clocks from PLLs, e.g. single and double rate or something

19:00 <tnt> (and also clock skew / jitter / hold-time)

19:39 <whitequark> i've never actually used a cross clock constraint

19:40 <whitequark> but that's because i wouldn't spend much time on a design that nextpnr can't route

19:40 <whitequark> so it's an inverse problem of yours

19:41 <tnt> can't route ?

19:41 <tnt> I mean, you can do cross clock stuff and next pnr will route it fine ... it might just work/not-work randomly depending on the random place/route result.

19:58 <whitequark> the "so that it works correctly" is implied in "can't route"

19:58 <whitequark> why does everyone in hardware have such painfully low standards for "working" in toolchains...

20:01 <Hoernchen> lol

20:02 <q3k> it-compiles-ship-it: the industry

20:02 <zyp> because the alternatives are worse? :)

20:03 <whitequark> you should pick the lesser of two evils but you shouldn't delude yourself into thinking it's good

20:04 <q3k> to be fair it's not only a hardware industry thing

20:05 <whitequark> true, but it's especially prevalent in hardware

20:05 <whitequark> there isn't anything in software world that is beaten into people to the extent verilog is

20:05 <q3k> plenty of industry has difficulty being able to say both 'i use this tool because it's less bad than the alternatives' and 'we could still do better'

20:05 <q3k> whitequark: what about yaml? :P

20:06 <q3k> maybe not as beaten into in absolute terms

20:06 <whitequark> in the ops world it's similar, i think

20:06 <q3k> but got here fast and is here to stay

20:06 <q3k> even though it's hot fucking trash

20:06 <whitequark> yeah i can't argue

20:13 <awygle> C is probably as beaten into software people as verilog is into hardware people if you somehow weight the metric by the number of software people vs the number of hardware people

20:14 <whitequark> hrm

20:14 <whitequark> yeah fair

20:15 <q3k> my favourite projects contain all three: verilog, c and yaml

20:17 <sorear> somewhere, there must exist a synthesizable verilog yaml parser

20:18 <daveshah> yaml pcie accelerator

20:19 <tpw_rules> ......i know a guy who could have conceivably designed that

20:23 <whitequark> wtf

20:23 <gruetzkopf> i've seen json and xml accellerators

20:24 <tpw_rules> yeah i've seen them as network appliances

20:25 <kc8apf> XML accelerators were definitely a thing for a while

20:25 <emeb> anyone ever tried using the SB_I2C cores on ice40 UP5k?

20:25 <emeb> Giving it a shot now...

20:28 <kc8apf> archiving old programmable logic tools makes for frustrating categorization problem

20:29 <kc8apf> ModelSim Xilinx Edition II v5.6e for Xilinx ISE 5.1i

20:30 <pie_> gruetzkopf: wtf does that even do

20:31 <q3k> it makes your xml faster

20:33 <kc8apf> they parse in hardware. When you have a SOAP or similar interface, you can route the traffic to accelerator first