FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
NF6X has joined #nmigen
NF6X has left #nmigen [#nmigen]
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter_ is now known as PyroPeter
PyroPeter has quit [Ping timeout: 272 seconds]
hookworms has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
jjeanthom has joined #nmigen
nelgau has quit []
jjeanthom has quit [Ping timeout: 240 seconds]
<d1b2>
<dub_dub_11> does convert() have a way to invert resets?
<d1b2>
<dub_dub_11> I know that when doing build, active low resets are defined in the platform file
<d1b2>
<dub_dub_11> but using ISE on windows means that I don't have much choice other than to write to verilog, and it would be a pain to have to manually add an inversion every time I compile
<d1b2>
<dub_dub_11> on a similar note, is there a build option that will create the project files and constraint files without trying to use the toolchain?
<d1b2>
<dub_dub_11> hmm it does say the required tool is not in Path, which I will fix, but it's odd that it would require it just to make the project file
<whitequark>
oh, hm
<whitequark>
which version of nmigen are you using?
<whitequark>
this should be fixed on master
<d1b2>
<dub_dub_11> that's a good question, It's possible that it's an older version because I just installed nmigen_boards and that may have installed older nmigen
<whitequark>
yeah... I actually came up with a plan to fix *that* problem the other day
<d1b2>
<dub_dub_11> I seem to have nmigen version 0.2
<whitequark>
yeah you should update to master. either using `pip install -e .` in a git checkout, or `pip install git+https://github.com/nmigen/nmigen` also works
<d1b2>
<dub_dub_11> ok
<d1b2>
<dub_dub_11> so 0.2 is the version on pip then?
<whitequark>
yes
<d1b2>
<dub_dub_11> I see
<whitequark>
i'm currently working on the last blocker for 0.3
<d1b2>
<dub_dub_11> ah nice
jjeanthom has joined #nmigen
<d1b2>
<dub_dub_11> with do_build=False it doesn't seem to have produced any outputs
<whitequark>
right, so what it does is returns a "build plan"
<d1b2>
<dub_dub_11> I set do_program=False too to make sure it wasn't getting confused there
<whitequark>
which is a python object with the virtual build tree
<d1b2>
<dub_dub_11> awesome, that's done exactly what I was looking for, tyvm
hookworms has left #nmigen [#nmigen]
jjeanthom has quit [Ping timeout: 264 seconds]
<d1b2>
<dub_dub_11> also: I'm about to do the configurable jumper for de4 and I'm wondering whether the same method would work to allow configuration of what device you have? (the same board is available with a 200k and 500k LE part
<whitequark>
we still haven't decided which way is better
<whitequark>
there's an open issue
<whitequark>
both have their pros and cons, and no argument is sufficiently convincing to make a decision easy
<whitequark>
heh
<d1b2>
<dub_dub_11> right 😄
<d1b2>
<dub_dub_11> in that case I'll leave it as-is for the moment
<d1b2>
<dub_dub_11> either way I think for this board the actual number of them going around is probably pretty low so I'm not super worried. on the other hand I would like to make the De1SoC pin assignments much more complete, since that's a much more widely used teaching board
<d1b2>
<dub_dub_11> and atm I've only done the really basic IO
<whitequark>
we can probably return to that question relatively early after 0.3 ships
<d1b2>
<dub_dub_11> 👍
<d1b2>
<dub_dub_11> this feels like a really stupid question but I'm trying to follow the same method as the Atlys board which has Attrs(IOSTANDARD=bank2_iostandard) but for some reason it doesn't like Clock( GCLKIN_speed ) where I have python def GCLKIN_speed(self): return self._GCLKIN and self._GCLKIN = 100e6 I tried Clock( GCLKIN_speed() ) which said missing required positional argument, and Clock( GCLKIN_speed(self ) which said name self is not defined
<d1b2>
(which is the part that's really confusing me)
<whitequark>
that pattern only works with Attrs() specifically
<whitequark>
clock constraints are different. (maybe they shouldn't be? but they certainly are today)
<d1b2>
<dub_dub_11> oh hmm. so I can't put a function call as a parameter for Clock() ?
<whitequark>
no. it's specifically some code that exists for Attrs() that handles that
<whitequark>
for the clocks, we usually have the end user set an attribute on the platform
<whitequark>
but it really depends on the arrangement you have
<whitequark>
if you describe it in the PR (without necessarily writing any code yet) i'll try to figure something out
<d1b2>
<dub_dub_11> ah ok. will do. I think I can handle easily enough configuring based on the switch setting, but the issue seems to be that some configurations allow an arbitrary clock input (as it's an SMA connector that could be any clock rate)
<whitequark>
in that case you do not need to place any Clock() items anywhere
<whitequark>
the developer who plugs in the clock should use `platform.add_clock_constraint()` instead
<whitequark>
Clock() is really just a shortcut for the simplest common case of a fixed clock on a fixedp in
<whitequark>
it's not mandatory
<d1b2>
<dub_dub_11> oh ok. so I would say something like python if(SW7=="00"): Resource("clk100"...Clock(100e6)) and just leave it at that
<whitequark>
i'm not sure what are you suggesting exactly
<_whitenotifier-f>
[YoWASP/yosys] whitequark pushed 7 commits to release [+0/-0/±7] https://git.io/JkpL8
<_whitenotifier-f>
[YoWASP/nextpnr] ... and 7 more commits.
<d1b2>
<dub_dub_11> well depending on the switch settings, you either get a fixed 100MHz or a variable input. in the first case it seems like it would preferable that the end user shouldn't have to add the clock constraint themselves
<whitequark>
hm, bit of a tricky issue
<d1b2>
<dub_dub_11> maybe you can't have an entry in the resources list that only exists if a certain condition is true
<whitequark>
there's currently no built-in support for this, no
<whitequark>
there are of course a few ways to achieve anyway
<d1b2>
<dub_dub_11> I suppose I should just remove it entirely, and the 0.5 people who are likely to both own this board and use nMigen will have to manually add the clock constraint
<whitequark>
is it the primary/only clock?
<d1b2>
<dub_dub_11> no, there are 6 fixed 50MHz clocks as well
<d1b2>
<dub_dub_11> so it should really be nbd
<whitequark>
oh ok zero problems then
<d1b2>
<dub_dub_11> and I am probably just overthinking this a lot. yeah