<mtrbot-ml>
[mattermost] <hartytp> Kasli 2.0 is currently only waiting for him to finish changes and produce an rc
electronic_eel has quit [Ping timeout: 240 seconds]
<mtrbot-ml>
[mattermost] <hartytp> Re artiq support: we agreed you’d send me a quote once the design was finished
electronic_eel has joined #m-labs
<mtrbot-ml>
[mattermost] <hartytp> @astro great! Will review later
<marble[m]>
Hello
<marble[m]>
in Solvespace
<marble[m]>
is there a way to substract one object from another and then rotate the resulting object?
vup2 has quit [Quit: No Ping reply in 210 seconds.]
TD-Linux has quit [Ping timeout: 245 seconds]
<marble[m]>
when I rotate, it just applies it to the subtrahend, not to the entire difference
linzhi-sonia has quit [Ping timeout: 245 seconds]
larsc has quit [Ping timeout: 245 seconds]
vup has joined #m-labs
TD-Linux has joined #m-labs
linzhi-sonia has joined #m-labs
larsc has joined #m-labs
Dar1us has quit [Quit: Bye]
Dar1us has joined #m-labs
sb0cn has joined #m-labs
<sb0cn>
marble[m], have you tried playing with the operations tree shown in the small window?
harryho has quit [Remote host closed the connection]
<sb0cn>
@hartytp so how to test wrpll? sayma?
Getorix has joined #m-labs
<mtrbot-ml>
[mattermost] <hartytp> depends how soon @pkulik can finish Kasli 2.0
<mtrbot-ml>
[mattermost] <hartytp> I'd prefer to demo on Kasli as that seems like less risk of Sayma-related stress
<sb0cn>
we only need the Ultrascale FPGA and its transceivers to work, then the new PLL circuit is just as risky on Sayma as it is on Kasli
<mtrbot-ml>
[mattermost] <hartytp> ok, well, I'm happy either way
<sb0cn>
the HMC chips and other troublesome stuff on the RTM do not need to be involved
<mtrbot-ml>
[mattermost] <hartytp> so long as we don't get stuck in some huge timesink fiddling with flaky hw
<sb0cn>
besides, most of the hw quirks are understood now I think
<sb0cn>
and this won't put much load on the FPGA so it can simply be tested outside of the crate without much cooling, with the AMC powered via ATX so we don't get involved with uTCA and its eternal IPMI bugs
<sb0cn>
at some point we should replace all the buggy MCH cruft with one little STM32...
<mtrbot-ml>
[mattermost] <hartytp> "most of the hw quirks are understood now I think" famous last words
<mtrbot-ml>
[mattermost] <hartytp> but, yes, that sounds like a good plan. we can abandon ship if things go wrong
<mtrbot-ml>
[mattermost] <hartytp> "some point we should replace all the buggy MCH cruft with one little STM32..." I'm slowly coming around to the idea of a 2ch version of Sayma on a Eurocard as the correct long-term solution
<mtrbot-ml>
[mattermost] <hartytp> scrap the AFE mezzanines, smaller FPGA, keep the power consumption really low etc etc
<sb0cn>
well the SAWG and JESD204 do use a lot of power
<mtrbot-ml>
[mattermost] <hartytp> true. would be interesting to look at a power budget for a 2ch card with a somewhat stripped-down SAWG implementation and see what it looks like
<sb0cn>
for those, at high channel densities, the uTCA power supply and cooling don't seem completely inappropriate. but IPMI is a lie.
<marble[m]>
sb0cn: how can I play with it?
<mtrbot-ml>
[mattermost] <hartytp> yes, it really depends on the power usage IMO. If that's <~10W per 2 channels then I think EEM is the way to go, otherwise probably uTCA
<marble[m]>
my tree is a line :/
<marble[m]>
still better than a circle :D
<sb0cn>
marble[m], how can it be a line if you stacked several extrude etc. operations?
<marble[m]>
they are just one after the other
<sb0cn>
hmm
<marble[m]>
which make the tree a line
<sb0cn>
and you can't select one?
<sb0cn>
that would apply the rotation to the whole set of objects
<marble[m]>
I can select them
<sb0cn>
okay, then select the top one and apply the rotation
<marble[m]>
with select you mean that I shoul make it active?
<sb0cn>
yes
<sb0cn>
I think (not a solvespace expert...)
<marble[m]>
Now I have three times the sketch that was in the root
<marble[m]>
that's now what I want
<marble[m]>
*not
<sb0cn>
uh? it copied it?
<marble[m]>
It copied the sketch yes
<marble[m]>
I want copies of a compound solid
<sb0cn>
ah. is there an element in the tree that would correspond to that compound solid?
<marble[m]>
e.g. I make a cube, then substract a cylinder and then I want the cube with a hole in it three times
<marble[m]>
not
<marble[m]>
no
<marble[m]>
there is an element for the cube and an element for the cylinder
<sb0cn>
okay let me try...
<_whitenotifier>
[nmigen] whitequark commented on pull request #234: make the set_max_delay value a string - https://git.io/Jesx7
<_whitenotifier>
[nmigen] whitequark closed pull request #235: vendor.lattice_ecp5: correct a typo in tristate buffer generation - https://git.io/JesFW
<_whitenotifier>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jesx5
<_whitenotifier>
[m-labs/nmigen] ktemkin d143664 - vendor.lattice_ecp5: correct a typo in tristate buffer generation
<_whitenotifier>
[m-labs/nmigen] whitequark 0858b8b - lib.cdc: specify maximum input delay in seconds.
<_whitenotifier>
[nmigen] whitequark closed pull request #234: make the set_max_delay value a string - https://git.io/Jes5N
<whitequark>
hm
<sb0cn>
if I rotate the view after that then it copies points
<sb0cn>
what the hell?
<whitequark>
that makes no sense
<sb0cn>
okay it's not just the view... after rotating I had selected a different reference axis for the rotation, too
<sb0cn>
I mean after rotating the view
<whitequark>
can you save the broken file and show it to me?
<sb0cn>
sent
<sb0cn>
select the center of the circle and an edge of the cube, depending on which edge you select it copies just the center point or the whole circle
<whitequark>
if you rotate the circle around its center you get back a circle.
<whitequark>
what do you expect?
<sb0cn>
hm
<sb0cn>
what are the additional points it creates then?
<whitequark>
that's the workplane origin point
<whitequark>
hide all and then show just the last group
<whitequark>
with the circle
<sb0cn>
okay I see
<whitequark>
sb0cn: do I understand it correctly that false path constraints in ISE are only needed when it traces a clock through a PLL but you don't want to consider this clock as related to the source clock?
<whitequark>
and not for 2FF synchronizers etc in general
<sb0cn>
marble[m], okay other than that I don't see particular issues with this rotation+extrusion thing
<sb0cn>
you also need to extrude first and then rotate
<sb0cn>
whitequark, yeah
<sb0cn>
PLL or other elements where clocks are related, like BUFGCE_DIV on US
<whitequark>
ok, then it seems like just ASYNC_REG is sufficient for now
<sb0cn>
marble[m], and 32 holes don't crash it here
<sb0cn>
marble[m], do you want the .slvs?
<_whitenotifier>
[nmigen] whitequark commented on issue #87: Automatic definition of false path constraints - https://git.io/Jespd
<sb0cn>
whitequark, iirc the vivado docs has some content on 2FF synchronizers
<whitequark>
yes. we made it work very nicely for vivado.
<whitequark>
you can set max_input_delay on synchronizers, and it automatically finds the clock of the data it is sampling, and adds a datapath-only max delay constraint
<whitequark>
(or a false path if that's not specified)
<whitequark>
but ISE is more primitive
<_whitenotifier>
[nmigen] whitequark commented on issue #220: Prune Yosys-internal attributes in emitted Verilog - https://git.io/Jeshv
<_whitenotifier>
[nmigen] whitequark commented on issue #220: Prune Yosys-internal attributes in emitted Verilog - https://git.io/Jeshn
<_whitenotifier>
[nmigen] ZirconiumX commented on issue #220: Prune Yosys-internal attributes in emitted Verilog - https://git.io/Jeshc
<_whitenotifier>
[nmigen] whitequark commented on issue #220: Prune Yosys-internal attributes in emitted Verilog - https://git.io/JeshW
<_whitenotifier>
[nmigen] whitequark commented on issue #220: Prune Yosys-internal attributes in emitted Verilog - https://git.io/JeshR
<marble[m]>
<sb0cn "marble, do you want the .slvs?"> sure
<sb0cn>
email?
cr1901_modern has quit [Ping timeout: 240 seconds]
sb0cn has quit [Ping timeout: 250 seconds]
<mtrbot-ml>
[mattermost] <hartytp> +
daveshah has quit [Excess Flood]
daveshah has joined #m-labs
<_whitenotifier>
[m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±9] https://git.io/JeGeB
alexhw has quit [Remote host closed the connection]
alexhw has joined #m-labs
lkcl has joined #m-labs
<ZirconiumX>
whitequark: So, there's a small problem with your suggestion of qsys-script/qsys-generate for instantiating altddio cells
<ZirconiumX>
I can't actually find it in the Lite version
<whitequark>
oh.
mumptai has joined #m-labs
<ZirconiumX>
Oh, they put it in a different folder to the rest of quartus
<ZirconiumX>
For no fucking reason
<ZirconiumX>
Well done
<ZirconiumX>
Stuff like quartus_map is in quartus/bin64
<ZirconiumX>
And qsys-edit is in quartus/sopc_builder/bin
<ZirconiumX>
Oh, and it's Java bloatware.
<ZirconiumX>
This depresses me.
<ZirconiumX>
whitequark: So there's a *different* small problem with your qsys idea. There seems to be no way to automatically generate an altddio without going through the MegaWizard
<whitequark>
wonderful
<whitequark>
ok
<whitequark>
i think you have to reimplement the core in fabric
<whitequark>
can you emit altddio for cyclonev and show it to me?
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #m-labs
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined #m-labs
gnufan_home has joined #m-labs
rohitksingh has quit [Ping timeout: 265 seconds]
<cr1901_modern>
rjo: What would the semantics of your proposed reshape() function be in dimensions higher than 2? Matlab has a reshape function for matrices, though it's not obvious to me that the same semantics should apply.
<cr1901_modern>
(Not to mention I have trouble memorizing them)
mumptai has quit [Quit: Verlassend]
attie has quit [Ping timeout: 245 seconds]
attie has joined #m-labs
gnufan_home has quit [Quit: Leaving.]
attie has quit [Read error: Connection reset by peer]