00:17
zng has joined #m-labs
03:13
<
mtrbot-ml >
[mattermost] <dgy> I don,t know how to solve the problem because I am not good at computer,who can help me?UnsatisfiableError: The following specifications were found to be incompatible with each other:
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package sphinxcontrib-wavedrom conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> sphinxcontrib-wavedrom
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package h5py conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> h5py=2.8
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package openocd conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> openocd[version='0.10.0|>=0.10',build='6|1']
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package pyqt5 conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> pyqt5
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package levenshtein conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> levenshtein
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package lit conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> lit
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package numpy conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> numpy
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package pyqt conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> pyqt[version='>=5.5']
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package scipy conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> scipy
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package binutils-or1k-linux conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> binutils-or1k-linux[version='>=2.27']
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package sphinx conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> sphinx==1.4.8
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package outputcheck conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> outputcheck
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package python-dateutil conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> python-dateutil
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package sphinx_rtd_theme conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> sphinx_rtd_theme
03:13
<
mtrbot-ml >
[mattermost] <dgy> Package dateutil conflicts for:
03:13
<
mtrbot-ml >
[mattermost] <dgy> artiq -> dateutil <message clipped>
04:46
<
lkcl >
very weird behaviour, occurred twice now, so i sort-of have a handle on it.
04:47
<
whitequark >
lkcl: pysim has a number of bugs that need to be fixed, yes.
04:47
<
whitequark >
probably via some medium scale rework.
04:47
<
lkcl >
ok so it's a known issue.
04:47
<
lkcl >
that's fine :)
04:47
<
whitequark >
not this specific one
04:47
<
whitequark >
but yes, it's an area i expect bugs in
08:09
_whitelogger has joined #m-labs
08:30
rohitksingh has quit [Ping timeout: 264 seconds]
08:33
sb0 has joined #m-labs
08:34
<
whitequark >
sb0: see irc above
08:34
<
whitequark >
and this should be a bug on github anyway.
10:37
ohsix has quit [Ping timeout: 245 seconds]
11:03
ohsix has joined #m-labs
12:05
mauz555 has joined #m-labs
12:08
rohitksingh has joined #m-labs
12:50
rohitksingh has quit [Ping timeout: 250 seconds]
13:42
rohitksingh has joined #m-labs
13:54
<
_whitenotifier-3 >
[nmigen] whitequark opened issue #172: AsyncFIFO/AsyncFIFOBuffered do not infer BRAMs on iCE40 -
https://git.io/fjFcp
14:00
<
_whitenotifier-3 >
[nmigen] whitequark commented on issue #172: AsyncFIFO/AsyncFIFOBuffered do not infer BRAMs on iCE40 -
https://git.io/fjFCf
14:00
<
whitequark >
huh, AsyncFIFO* are broken
14:04
<
cr1901_modern >
I was under the impression AsyncFIFO was never going to infer BRAMs on ice40 b/c no dist RAM
14:06
<
cr1901_modern >
FWIW, I also had a working AsyncFIFOBuffered design on ice40up5k for a soft core when I got icebreaker micropython to work in LiteX (sic!).
14:07
<
whitequark >
how is LUTRAM related to this
14:08
<
cr1901_modern >
(10:04:47 AM) cr1901_modern: I was under the impression AsyncFIFO was never going to infer BRAMs on ice40 b/c no dist RAM <-- misspoke
14:09
<
cr1901_modern >
nevermind.
14:14
<
cr1901_modern >
Actually, no I don't think I misspoke. I've had ice40 designs where yosys decided to but the entire AsyncFIFO into LUTs (eating about 20% of my LUTs)! Using an AsyncFIFOBuffered fixed this. But I don't remember why b/c this was like December 2018.
14:14
<
whitequark >
it's explained in the issue
14:15
<
whitequark >
AsyncFIFOBuffered doesn't help anymore
14:15
<
cr1901_modern >
>It was probably a bug in Yosys that allowed it before. <-- But my design
_worked_ when BRAM was used. Maybe a lucky accident?
14:18
<
cr1901_modern >
And this was a SoC/soft core, utilizing 90% of the up5k, not some 50 line minimal design.
14:18
<
whitequark >
interesting
14:19
* cr1901_modern
takes a quick look for his PR/and logs
14:27
<
cr1901_modern >
Can't find it in Github PRs... it's somewhere in mithro's/timvideos logs. I will look in a bit.
14:27
<
whitequark >
ok, so if it infers LUTs, that's ok
14:28
<
whitequark >
but it still infers LUTs with AsyncFIFOBuffered when i tested it just now
14:28
<
whitequark >
for reasons i haven't closely looked at
14:29
<
cr1901_modern >
I
_know_ you already considered this, but... how big was your FIFO? Would yosys have thought it too small to bother putting into BRAM?
14:29
<
cr1901_modern >
Anyways, it could've been an accident that my design worked at all. Just wanted to add it as a data point (perhaps as a "bisect good")
14:32
<
whitequark >
512 bytes
14:32
<
whitequark >
and it fails PNR
14:40
<
_whitenotifier-3 >
[nmigen] whitequark opened issue #173: Platform function to calculate optimal BRAM depth for width -
https://git.io/fjFCb
15:15
adamgreig has quit [Quit: WeeChat 1.8]
15:16
adamgreig has joined #m-labs
15:51
mauz555 has quit []
16:05
rohitksingh has quit [Ping timeout: 250 seconds]
16:18
mumptai has joined #m-labs
16:27
<
_whitenotifier-3 >
[m-labs/nmigen] whitequark d44ea4e - hdl.xfrm: make deprecated CEInserter more well-behaved.
16:27
<
_whitenotifier-3 >
[m-labs/nmigen] whitequark 84f2c3d - compat.fhdl.decorators: avoid using deprecated NativeCEInserter.
16:48
X-Scale has joined #m-labs
16:51
<
_whitenotifier-3 >
[smoltcp] crawford commented on issue #223: Unable to create UDP and TCP sockets -
https://git.io/fjF4m
17:09
rohitksingh has joined #m-labs
17:58
cr1901_modern has quit [Quit: Leaving.]
18:40
<
vup >
whitequark: is it possible to nest connectors in nmigen?
18:41
<
whitequark >
you can specify a connector pin that's from another connector yes
18:42
<
whitequark >
if you have Connector("X", 1, "A1") then use "X_1:1" in a new one
18:42
<
whitequark >
that will then map to ball A1.
18:44
<
vup >
great, thanks
18:51
cr1901_modern has joined #m-labs
18:51
<
vup >
whitequark: what do you think about adding a 'conn=' argument to Connector?
18:52
<
whitequark >
sure. feel free.
18:54
rohitksingh has quit [Ping timeout: 264 seconds]
19:06
mauz555 has joined #m-labs
19:24
<
_whitenotifier-3 >
[nmigen] codecov[bot] commented on pull request #174: add conn argument to Connector -
https://git.io/fjFRY
19:25
<
_whitenotifier-3 >
[nmigen] whitequark synchronize pull request #174: add conn argument to Connector -
https://git.io/fjFRL
19:29
<
cr1901_modern >
this is the nested connectors feature?
19:34
<
vup >
it just makes it easier to write nested connectors
19:36
<
cr1901_modern >
How was it done before this commit?
19:36
<
cr1901_modern >
And are both ways to write nested connectors still present?
19:38
<
vup >
if you had a Connector("con", 0, "A1") you could chain a second connectors using Connector("con_nested", 0, "con_0:1")
19:38
<
vup >
now you can wirte Connector("con_nested", 0, "1", conn=("con", 0))
19:39
<
cr1901_modern >
oh cool
19:40
<
cr1901_modern >
There's a few things in nmigen where "there's more than one way to accomplish the same goal". I try to keep track of them.
19:40
<
cr1901_modern >
But I missed this one lol
19:47
rohitksingh has joined #m-labs
19:56
<
_whitenotifier-3 >
[m-labs/nmigen] rroohhh 8e048c5 - build.dsl: add conn argument to Connector.
20:05
mauz555 has quit [Remote host closed the connection]
20:06
mauz555 has joined #m-labs
20:29
<
anuejn >
whitequark: how do you feel about having a function, that adds both connectors and resources from a mixed list?
20:29
<
anuejn >
or is there already one?
20:30
<
whitequark >
doesn't seem very appropriate to me
20:30
<
anuejn >
e.g. when you have an extention board that you want to connect to an SOM
20:30
<
whitequark >
i mean calling 2 functions instead of 1 doesn't seem like a huge effort
20:31
<
anuejn >
yup but then you wouldnt be able to represent the whole extention board as one thing
20:31
mauz555 has quit [Remote host closed the connection]
20:31
<
anuejn >
(or would have to employ some filter hack)
20:31
<
whitequark >
wouldn't it be like a function anyway?
20:31
mauz555 has joined #m-labs
20:32
<
whitequark >
def extend_with_your_board(platform): etc
20:32
<
whitequark >
it's usually a function anyway because it's parameterizable
20:32
<
anuejn >
yes that makes sense
20:37
mauz555 has quit [Remote host closed the connection]
20:38
mauz555 has joined #m-labs
20:47
<
Astro- >
@sb10q I receive ethernet packets from the cora
20:47
mauz555 has quit [Remote host closed the connection]
20:48
mauz555 has joined #m-labs
20:48
<
Astro- >
I passed my mhz as hz in the clock setup -_-
21:19
<
_whitenotifier-3 >
[nmigen-boards] whitequark commented on pull request #27: add zturn lite board -
https://git.io/fjF0y
21:46
mauz555 has quit [Remote host closed the connection]
21:46
mauz555 has joined #m-labs
21:46
mauz555 has quit [Remote host closed the connection]
21:46
mauz555 has joined #m-labs
21:50
mumptai has quit [Remote host closed the connection]
21:52
mauz555 has quit [Remote host closed the connection]
21:53
mauz555 has joined #m-labs
22:00
mauz555 has quit [Ping timeout: 252 seconds]
23:24
mauz555 has joined #m-labs
23:46
mauz555 has quit [Remote host closed the connection]
23:47
mauz555 has joined #m-labs
23:49
mauz555 has quit [Remote host closed the connection]
23:50
mauz555 has joined #m-labs
23:55
mauz555 has quit [Ping timeout: 250 seconds]