<cr1901_modern>
cmd /c "call C:\Xilinx\14.7\ISE_DS\settings32.bat && xst" <-- this also works (duh)
<cr1901_modern>
Anyways, looks like "/k" isn't required at all. The way omigen did it was to do the call to the source script inside the batch file. And this appears to be equivalent to invok
<cr1901_modern>
ing each command in order using cmd /c (also duh I guess, but I never got it to work before now)
<cr1901_modern>
I'll write the issue now.
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjitq
<cr1901_modern>
whitequark: It probably should be TOOLCHAIN_SOURCE and TOOLCHAIN_CALL, b/c we generate both .sh and .bat files unconditionally in nmigen, and they should be different
<cr1901_modern>
these _incidentally_ can also serve as the variable that sets up paramiko builds whenever that functionality is added
<cr1901_modern>
s/paramiko/remote/
<whitequark>
huh?
<whitequark>
how is that related to remote builds?
<cr1901_modern>
You'll most likely need some initial setup script when doing remote builds
<whitequark>
to do what?
<cr1901_modern>
to get the paths ready, unless you already source ise/vivado settings in your .bashrc
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjitG
<_whitenotifier-3>
[m-labs/nmigen] whitequark 744154e - build.run: only use os.path on the target OS.
<whitequark>
yeah, but there's no difference between local and remote builds here
<cr1901_modern>
I'm saying reuse the var. Just my two cents
<cr1901_modern>
s/Just my two cents//
<whitequark>
what do you mean by reuse? remote builds work by extracting the build plan on the remote system and then running the same script
<cr1901_modern>
I'm just discouraged that I ran into a bunch of snags getting things to work today on my end.
<whitequark>
yeah, that happens...
<_whitenotifier-3>
[nmigen] whitequark commented on issue #131: `TOOLCHAIN_ENV` user variable - https://git.io/fjit8
<cr1901_modern>
mercury is only ready to the extent I implemented the bare minimum to hook it into xilinx_spartan6.py. Once you implement TOOLCHAIN_ENV, I could probably make a PR for S3 support in nmigen tonight and things would be okay.
<cr1901_modern>
But I think I want to hold off until mercury is fully implemented and tested.
<whitequark>
mercury?
<cr1901_modern>
the Spartan3A platform I want to add
<cr1901_modern>
yes, will do now. Gimme a sec to patch
<whitequark>
also, good catch on it being per-platform... should be NMIGEN_ise_env, NMIGEN_vivado_env, etc
<cr1901_modern>
I'm testing the patch as-is right now
<cr1901_modern>
it'll be fine I think
<whitequark>
it's more useful if you have both ISE and Vivado
<whitequark>
and want to put it all in your bashrc
<cr1901_modern>
My case would be diamond and ise on one machine and diamond and vivado on another
<cr1901_modern>
and well it'll equally apply to quartus if someone is an altera/intel fan
<cr1901_modern>
and eventually adds that
<whitequark>
exactly, so you need both NMIGEN_Diamond_env and NMIGEN_Vivado_env
<whitequark>
and NMIGEN_Trellis_env and so on
<cr1901_modern>
trellis and icestorm indeed live on my system path :P
<_whitenotifier-3>
[nmigen] cr1901 commented on issue #131: `TOOLCHAIN_ENV` user variable - https://git.io/fjit2
<cr1901_modern>
whitequark: toolchain was found with your patch
<mtrbot-ml>
[mattermost] <sb10q> @hartytp one thing that worries me a little about the si549 and similar chips is possible timing jitter or non-determinism between the i2c adpll write and the actual frequency change. It is a complex chip with probably a MCU inside to process the i2c commands. This isn't present with the original WR that uses a simple DAC to tune a VCXO. But maybe this jitter is very small and/or <message clipped>
<whitequark>
excellent
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±5] https://git.io/fjitV
<_whitenotifier-3>
[m-labs/nmigen] whitequark 1fcd495 - build.plat: source a script with toolchain environment.
<mtrbot-ml>
[mattermost] <sb10q> And there is jitter anyway in the ddmtd measurement completion times, so the pll has to be tolerant of that
<cr1901_modern>
whitequark: Okay stumbled across a fun bug... I copied mercury.py platform from icebreaker.py just to get started, right? >>
<_whitenotifier-3>
[nmigen] mithro opened issue #133: Possible wording fix for error message when an "If" is accidently directly under an FSM. - https://git.io/fjitX
<cr1901_modern>
s/bug/oversight/
<cr1901_modern>
actually wait, that might not be relevant
<_whitenotifier-3>
[nmigen] mithro opened issue #134: Add FSM state name annotations to generated Verilog output - https://git.io/fjitH
<_whitenotifier-3>
[nmigen] whitequark commented on issue #134: Add FSM state name annotations to generated Verilog output - https://git.io/fjitd
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 3 commits to master [+0/-0/±6] https://git.io/fjitF
<_whitenotifier-3>
[m-labs/nmigen] whitequark 3388b5b - hdl.dsl: gracefully handle FSM with no states.
<_whitenotifier-3>
[m-labs/nmigen] whitequark da1f58b - hdl.dsl: further clarify error message for incorrect nesting.
<_whitenotifier-3>
[nmigen] whitequark closed issue #133: Possible wording fix for error message when an "If" is accidently directly under an FSM. - https://git.io/fjitX
<_whitenotifier-3>
[nmigen] mithro opened issue #135: Support setting FSM encoding attribute - https://git.io/fjitx
<cr1901_modern>
whitequark: Anyways I ended up in a weird scenario where half my files were from icestorm and the other half were from ISE. I can no longer duplicate this fiasco, though I saved the build dir for later
<cr1901_modern>
_Now_ I can retire satisfied for the night lol. Thanks for the help fixing the snags.
<whitequark>
o/
<_whitenotifier-3>
[nmigen] mithro commented on issue #133: Possible wording fix for error message when an "If" is accidently directly under an FSM. - https://git.io/fjiqs
<mithro>
whitequark: Trying my first nmigen code right now...
<whitequark>
mithro: excellent. always a good way to determine usability issues before everyone learns to work around them
<whitequark>
I'm wondering if maybe nmigen should encode FSMs itself
<mithro>
whitequark: Maybe...
<mithro>
whitequark: Vivado seems to use One-Hot State Encoding, Gray State Encoding, Johnson State Encoding and Sequential State Encoding....
<_whitenotifier-3>
[nmigen] mithro commented on issue #135: Support setting FSM encoding attribute - https://git.io/fjiqE
<whitequark>
there is also the problem that e.g. Yosys doesn't want to recognize FSMs if it can detect a reset
<mithro>
whitequark: What parts of Yosys are you actually using? Just the RTIL and write_verilog ?
<whitequark>
mithro: also a few proc and memory passes
<whitequark>
mithro: again: I am not emitting Verilog, so *parsing* Verilog is irrelevant here
<mithro>
whitequark: We /were/ working on attribute support but that make clifford unhappy
<whitequark>
Yosys can only emit attributes on switch cases if there is an attribute dictionary attached to each switch case
<whitequark>
and there isn't
<mithro>
whitequark: IE round tripping Verilog too
<whitequark>
similarly, there is no attribute dictionary on assignments inside cases (which are just a pair of SigSpec internally)
<whitequark>
so there would need to be an attribute dictionary on each case. I'll talk to Clifford about this.
<whitequark>
and then there would need to be another Yosys patch that allows emitting comments from the comment attribute
<mithro>
whitequark: All seems reasonable to me - but I haven't had a good track record of understanding what Clifford thinks is reasonable
<_whitenotifier-3>
[nmigen] sbourdeauducq opened issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqr
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqK
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiq6
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiq1
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqD
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqy
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiq9
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqH
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqQ
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiq5
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjiqb
<_whitenotifier-3>
[nmigen] whitequark closed issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqr
<cr1901_modern>
I still plan to add it b/c I don't plan on getting the new board right now. And well, it was a productive day for nmigen I think lol
<whitequark>
there is Artix with natively 5V tolerant pins?
<whitequark>
ohhhhh
<whitequark>
that's
<whitequark>
wow that's clever
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjiqp
<_whitenotifier-3>
[nmigen] whitequark commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjime
<whitequark>
I've seen the same approach used for I2C, but never one that is 20 bit wide
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #136: nextpnr crash: "terminate called after throwing an instance of 'std::out_of_range'" - https://git.io/fjimf
<_whitenotifier-3>
[nmigen] whitequark opened issue #137: Versioneer breaks on git-archive (e.g. GitHub zip) downloads - https://git.io/fjimJ
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
tweakoz has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger_ has joined #m-labs
ChanServ has quit [*.net *.split]
_whitelogger has quit [*.net *.split]
forrestv has quit [*.net *.split]
marble[m] has quit [*.net *.split]
kmehall has quit [*.net *.split]
tweakoz has quit [*.net *.split]
cr1901_modern has quit [*.net *.split]
lkcl has quit [*.net *.split]
early has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
anuejn has quit [*.net *.split]
gric_ has quit [*.net *.split]
ZirconiumX has quit [*.net *.split]
proteusdude has quit [*.net *.split]
cedric has quit [*.net *.split]
vup has quit [*.net *.split]
rjo has quit [*.net *.split]
zignig has quit [*.net *.split]
siruf has quit [*.net *.split]
ohama has quit [*.net *.split]
mtrbot-ml has quit [*.net *.split]
nurelin_ has quit [*.net *.split]
felix_ has quit [*.net *.split]
qinfengling has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
elmarco has quit [*.net *.split]
jfng has quit [*.net *.split]
Ultrasauce has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
_whitenotifier-3 has quit [*.net *.split]
awygle has quit [*.net *.split]
linzhi-sonia has quit [*.net *.split]
acathla has quit [*.net *.split]
zng has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
balrog has quit [*.net *.split]
ohsix has quit [*.net *.split]
edef has quit [*.net *.split]
Astro- has quit [*.net *.split]
cyrozap has quit [*.net *.split]
flammit has quit [*.net *.split]
adamgreig has quit [*.net *.split]
daveshah has quit [*.net *.split]
mithro has quit [*.net *.split]
whitequark has quit [*.net *.split]
uberardy has quit [*.net *.split]
plonk has quit [*.net *.split]
stekern has quit [*.net *.split]
jaeckel has quit [*.net *.split]
remote_user__ has quit [*.net *.split]
_whitelogger has joined #m-labs
forrestv has joined #m-labs
marble[m] has joined #m-labs
kmehall has joined #m-labs
futarisIRCcloud has joined #m-labs
guan has joined #m-labs
tpw_rules has joined #m-labs
Gurty has joined #m-labs
kuldeep has joined #m-labs
miek has joined #m-labs
lynxis has joined #m-labs
attie has joined #m-labs
reportingsjr has joined #m-labs
<_whitenotifier-3>
[nmigen] whitequark reopened issue #108: Simulations for code that uses Platform - https://git.io/fjrOG
<_whitenotifier-3>
[nmigen] whitequark commented on issue #108: Simulations for code that uses Platform - https://git.io/fjiYk
jfng has quit [Remote host closed the connection]
xobs has quit [Remote host closed the connection]
jryans has quit [Write error: Connection reset by peer]
rjo[m] has quit [Remote host closed the connection]
marble[m] has quit [Read error: Connection reset by peer]
marble[m] has joined #m-labs
jfng has joined #m-labs
xobs has joined #m-labs
jryans has joined #m-labs
rjo[m] has joined #m-labs
plaes has quit [Ping timeout: 250 seconds]
plaes has joined #m-labs
tweakoz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Getorix has joined #m-labs
<mtrbot-ml>
[mattermost] <hartytp> You think an MCU rather than just a bit of logic to handle the I2C interface etc?
<mtrbot-ml>
[mattermost] <hartytp> Anyway, my guess is that any timing indeterminism there will be small and so have a negligible impact on the overall phase jitter (the frequency steps are typically tiny once the loop is locked)
Getorix has quit [Ping timeout: 258 seconds]
<mtrbot-ml>
[mattermost] <hartytp> That intuition is backed up by Weida's measurements of the closed-loop phase noise, which show very good results and don't hint at any noise above the DDMTD noise floor.
<mtrbot-ml>
[mattermost] <hartytp>
<mtrbot-ml>
[mattermost] <hartytp> If you want a better answer than that, ask Weida, as he's thought about this more and done a lot of modelling
<_whitenotifier-3>
[nmigen] cr1901 commented on issue #108: Simulations for code that uses Platform - https://git.io/fji3r
<_whitenotifier-3>
[nmigen] whitequark commented on issue #108: Simulations for code that uses Platform - https://git.io/fji3P
<_whitenotifier-3>
[nmigen] cr1901 commented on issue #108: Simulations for code that uses Platform - https://git.io/fji3D
Getorix has joined #m-labs
<cr1901_modern>
whitequark: TLDR to my follow-up; the way I started coding it, I don't see why "that's kinda different".
<cr1901_modern>
Getorix: Looked through the public logs, and I couldn't find the relevant messages in the time frame I know I brought it up. I'll check my personal logs later.
<cr1901_modern>
But again, all solutions _I_ have for decoupling platform basically use Elaboratable.__init__ creatively (Mixin? Subclass? The general consensus seems to be to use Mixins) to set up some boilerplate methods that is either is invoked initially in elaborate()
<Getorix>
Basically when you agree on general design and syntax of decoupling platform and sym, I just would like to see simple blink example modified accordingly :)
<cr1901_modern>
sure
<cr1901_modern>
Makes my life easier if I don't have to do it ;).
<Getorix>
I have done this decoupling in a silly way by detecting simplatform in elaborate, cause it is not available in __init_
<mtrbot-ml>
[mattermost] <sb10q> @hartytp the gateware is only capable of programming ADPLL. for all other Si549 programming and for diagnostics, the idea is to use bitbanging I2C from the main/comms ARTIQ CPU
<mtrbot-ml>
[mattermost] <sb10q> so this needs a mux between gateware control and GPIO
<mtrbot-ml>
[mattermost] <sb10q> @hartytp also it seems to me that the throughput of the whole thing is rather low (limited by ~50 bits at 1MHz on the I2C bus for each sample) so we probably can use only one multiplier for the DSP part
<mtrbot-ml>
[mattermost] <sb10q> e.g. make some kind of VLIW processor and compute a semi-optimal instruction sequence
_whitelogger has joined #m-labs
<_whitenotifier-3>
[nmigen-boards] cr1901 opened issue #17: Factor out Seven Segment Display Resources - https://git.io/fjiGs
<_whitenotifier-3>
[nmigen-boards] cr1901 opened issue #18: Handle edge case where the same `Subsignal` uses multiple `Connectors` - https://git.io/fjiGK
ohama has joined #m-labs
<_whitenotifier-3>
[nmigen-boards] mithro commented on issue #17: Factor out resource "sevenseg". - https://git.io/fjiZd
<_whitenotifier-3>
[nmigen-boards] cr1901 commented on issue #17: Factor out resource "sevenseg". - https://git.io/fjiZA
<_whitenotifier-3>
[nmigen] mithro commented on issue #108: Simulations for code that uses Platform - https://git.io/fjiZh
<mtrbot-ml>
[mattermost] <dpn> dpn joined the team.
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #18: Handle edge case where the same `Subsignal` uses multiple `Connectors` - https://git.io/fjic6
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #17: Factor out resource "sevenseg". - https://git.io/fjicP
<cr1901_modern>
whitequark: The baseboard_{sram, no_sram} resources should be fixed now. Right now I'm waiting on what to do about gpio_ctl and the SPIResources.
<cr1901_modern>
After that, I think all should be acceptable.