<Guest_60>
Is it fair to say that the list of supported boards by nmigen is currently the set of boards in nmigen-boards? Any one tried nmigen on Xilinx boards yet?
<Guest_60>
Not to say it can't be done quickly
<cr1901>
nmigen-boards is the boards repository. A very long time ago, migen took a similar approach with mibuild, but then merged mibuild directly into migen during a 2015 refactor
<cr1901>
I have one Xilinx board I'm interested in adding, but at present there's no Spartan 3 support
<Guest_60>
cr1901: you mean there is no vendor/xilinx_3series?
<cr1901>
not yet. Would be fairly similar to xilinx_6series, so there's prob code reuse to be refactored out
<Guest_60>
I now see a PR for the Arty board. Is the plan going forward adding these sort of files into nmigen?
<cr1901>
nmigen-boards is the proper repo
<cr1901>
for that PR
<cr1901>
Seems to be waiting for the PR opener to finish tidying up the PR
<whitequark>
Guest_60: yes, the PR for Arty will be merged soon
sb0 has joined #m-labs
proteusguy has quit [Ping timeout: 245 seconds]
early` has joined #m-labs
early has quit [Ping timeout: 246 seconds]
proteusguy has joined #m-labs
<Guest_60>
cr1901 whitequark Thanks.
mtrbot-ml_ has quit [Remote host closed the connection]
mtrbot-ml has joined #m-labs
<cr1901>
whitequark: WOuld you prefer I attempt to refactor out common code from xilinx_6series if I make a xilinx_3series backend (I still have use for it, the last version of ISE still supports it, and it's still produced by Xilinx. Thus I think it's harmless to add)?
<cr1901>
Or don't bother and eat the potential code dup
<whitequark>
cr1901: no, code duplication is deliberate
<whitequark>
tl;dr if you factor out stuff from 6series then each change needs to be tested on 2 platforms (6series and 3series)
<whitequark>
actually
<whitequark>
why do we have spartan6 and not 6series?
<whitequark>
is virtex6 different from spartan6 in terms of primitives?
<cr1901>
spartan6 is different
<whitequark>
cc sb0 jfng key2
<whitequark>
ok
<whitequark>
fine
<sb0>
iirc yes, it's only 7-series that has some consistency
<cr1901>
ask azonenberg for more info
<whitequark>
ahhh
<whitequark>
so it will be xilinx_spartan3 then, right?
<whitequark>
or is 3 and 3e also different?
<sb0>
yeah I don't think there's such a thing as "3 series"
<cr1901>
yes, spartan3 it is
<sb0>
why do we support spartan 3/3e/3a? who's using that?
<sb0>
they seem worse in every respect than lattice devices
<cr1901>
(10:02:19 PM) cr1901: I still have use for it, the last version of ISE still supports it, and it's still produced by Xilinx. Thus I think it's harmless to add
<cr1901>
And oMigen supports it
<whitequark>
sb0: given that all the code for 3/3e/3a is contained in a single file, the cost to support them is extremely low
<whitequark>
this is the whole point of duplicating code instead of factoring it
<whitequark>
hm, the largest 3e device is 28k LUTs
<cr1901>
Still larger than ice40 or mach :P
<whitequark>
yes but it's like 3x smaller than ecp5
<whitequark>
no SERDES, only DDR
<whitequark>
honestly it seems like all of the 3e devices are shit
<sb0>
also, as you hinted, they need ISE
<sb0>
well they aren't shit, they're just something like 15 years old?
<whitequark>
by today's standards, of course
<whitequark>
anyway, i have no objection to adding this support, and i do not anticipate issues
<cr1901>
I need s3 for the Mercury platform, which I have a decent amount of code for. And while it doesn't do it as well as Glasgow, it has 5v tolerance.
<cr1901>
on 40 of it's pins
<cr1901>
so I can use it for vintage crap (yes, I am going there ;)...)
<whitequark>
if it had any XDR over 2 i would be a little bit worried about adding support for that
<whitequark>
but, it has no SERDES, so if you port everything series6 can do now, it can be effectively frozen
<cr1901>
I know nothing about XDR, tbh lol
<cr1901>
I think the most advanced thing I've used on S3 is DCMs, which are a joke compared to even the S6 DCMs
<whitequark>
cr1901: i think S3 uses the same DDR primitives as S6
<cr1901>
Ahhh
<cr1901>
Well, I'll port the stuff when I have access to Mercury
<cr1901>
which will be sunday at the earliest
<cr1901>
oh and more importantly, access to ISE
<cr1901>
which is not compatible with the ARM netbook I'm using now :P
<whitequark>
sb0: btw, here's something I was thinking about
<sb0>
cr1901: right, so use lattice :)
<whitequark>
sb0: lattice doesn't have 5V tolerant devices
<sb0>
between ISE and a level shifter, I'd choose the latter...
<cr1901>
S3 isn't 5v tolerant either... mercury was just designed w/ a crapload of 5v tolerant pins from the onset.
<cr1901>
and chose to use an FPGA that was becoming obsolete in 2012
<whitequark>
ah
<whitequark>
sb0: anyway, what i was thinking about is a platform abstraction for PLLs
<cr1901>
I don't claim to understand their design decision
<whitequark>
a fairly small one, similar to what i want to provide for SERDES
<sb0>
whitequark: hmm those things (and SERDES) have a lot of platform-dependent quirks
<whitequark>
sb0: that is true, however consider this
<cr1901>
afaik DDR IO abstraction doesn't handle all possible cases as-is in nMigen either. And can't really. But it handles the usual case
<whitequark>
i looked at XDR>2 (so, XDR=4, XDR=7, XDR=8) on xilinx and lattice
<whitequark>
and i believe i can provide a good abstraction for that
<whitequark>
including delay blocks
<sb0>
whitequark: ultrascale doesn't support xdr=7 for example
<whitequark>
yes, and that's fine
<sb0>
whitequark: and have you looked at e.g. the details of clocking on the cameralink core on kasli?
<whitequark>
not that specific core, no
<cr1901>
Also I have no particular attachment to them but what if someone tries to add Altera support? I know it mostly bitrotted in oMigen and Altera has a tendency of deprecating devices much faster than Xilinx. But I can see someone wanting them.
<cr1901>
(since you mentioned only Lattice and Xilinx)
<whitequark>
what's the issue with Altera?
<cr1901>
I know nothing about their DDR primitives and whether XDR maps well to them
<cr1901>
oh, last I checked the Quartus backend needed a revamp b/c Altera changes crap around much faster than Xilinx
<cr1901>
but that was a while ago and I certainly don't remember the details of what broke
<cr1901>
I think rqou has more to say tho (if he's around on IRC still)
<whitequark>
sb0: looking through that phy i don't see anything that would break the abstraction i have in mind
<sb0>
whitequark: what about siphaser?
<sb0>
whitequark: that's an old version, the new one is in artiq
<sb0>
but same thing iirc
<whitequark>
sb0: that one's kind of weird
<whitequark>
does it use one BUFG solely for feedback and another for distributing the clock?
<whitequark>
oh, I see, UG472
<whitequark>
... that looks like a horrible hack, actually
<sb0>
what looks like a horrible hack?
<sb0>
using a BUFG for feedback only?
<whitequark>
ues
<whitequark>
*yes
<sb0>
siphaser doesn't do that, but yes, xilinx recommends that
<sb0>
why?
<whitequark>
oh, i was looking at rtio code, not siphaser
<whitequark>
yes, i don't see anything concerning in siphaser either
<whitequark>
apart from PLL abstraction there needs to be a clock mux abstraction, but that's not any worse
<sb0>
what about the platform-dependent programmable fine phase shift?
<whitequark>
my plan is to find the lowest common denominator of every FPGA and provide that
<whitequark>
this is very similar to IOB delay blocks
<whitequark>
as far as i can tell, all phase shift blocks in all FPGAs can be driven with reset, step, direction
<sb0>
there are all sort of subtleties with IOB delays, look at the various ultrascale modes and reset sequence for example
<sb0>
also IDELAYCTRL
<whitequark>
yes, I have in fact looked at them
<sb0>
iirc regarding the MMCM some features are also available on some outputs as well
<whitequark>
it is exactly because there are all sorts of subtleties that I want to make an abstraction for them; that's much better than duplicating this in each PHY core, with more bugs
<sb0>
it could be that the fine phase shift is one of them
<whitequark>
PLLs will need a kind of pattern matching mechanism
<whitequark>
you request a list of outputs with the bare minimum of features that you can use
<whitequark>
and the platform layer tries to satisfy it with the primitive it has
<sb0>
I also wonder how future-proof that abstraction will be. Xilinx might release a Ultrascale++ FPGA and make up another set of rules
<whitequark>
I will never be able to cover every conceivable MMCM feature nor am I trying to
<whitequark>
I want to cover 90% of use cases, which is "1-2 outputs, 90/180/fixed/variable phase shift on one of them, no feedback through fabric"
<cr1901>
wouldn't you need to request a list of inputs too, since AFAIK the SB_PLL has a few inputs (mostly used as a hint as to whether the clk comes from from global nets) versus, say S6 PLL which has extra inputs for feedback connections to deal w/ clock skew
<cr1901>
has a few inputs Xilinx PLLs don't have* and vice versa
<sb0>
if you look at siphaser, you can see that it inserts a BUFG to route between the MMCMs on Ultrascale
<sb0>
this BUFG is not necessary on 7-series, but routing fails on US when it's not present
<sb0>
your abstraction will still leak platform-dependent details like this...
<whitequark>
it will, and I think that's fine
<whitequark>
it doesn't need to be perfect to be an improvement on status quo
<whitequark>
or to be useful
<whitequark>
just like you can always ask the platform layer to not insert a buffer, you could always instantiate an MMCM or route signals manually if you need it
<sb0>
okay, so you can still explicitly request a BUFG?
<whitequark>
of course
<sb0>
and not a BUFR or any of the other xilinx inventions
<cr1901>
Should BUFG be abstracted in a manner similar to tristate and DDR?
<cr1901>
seems like low-hanging fruit at quick glance
<whitequark>
not necessarily
<whitequark>
it's obviously easy to do but it might be solving the wrong problem
<whitequark>
consider this. one rarely instantiates BUFG or SB_GB in isolation, right?
<whitequark>
on ice40 for example, you virtually always want SB_GB_IO, and this is already handled via Attrs(GLOBAL=1)
<whitequark>
if you need an explicit SB_GB, it means one of 2 things:
<whitequark>
- your board designer fucked up
<sb0>
whitequark: on ultrascale (again) you can't use PLL outputs to clock SERDES
<whitequark>
sb0: do they need to go through BUFG?
<sb0>
you need a high frequency PLL output driving a pair of BUFGCE_DIV with different ratios
<whitequark>
ah right, that thing
<sb0>
otherwise the skew isn't right and you get hold time violations most of the time
<sb0>
another option to generate those clocks, which has proven useful with ARTIQ DRTIO, is to generate the high frequency clock from the transceiver block
<sb0>
you program the transceiver PLL to generate an output that is higher by some factor than what it should be, then you do an external division with the new US BUFG_GT and feed that back into the transceiver
<sb0>
since the high frequency clock is now out of the transceiver, you can fan out to another BUFG_GT with a smaller division ratio
<cr1901>
whitequark: I used BUFG in HDMI2USB semi frequently to reroute PLL generated clocks to the global buffers. But admittedly, it's because "I've always done it this way."
<sb0>
and the outputs of those BUFG_GT have the right skew to drive SERDES
<cr1901>
Also, mostly S6. Idk is S7 is less dumb and won't try to route a PLL output to local fabric
<sb0>
this is of course very annoying but there aren't many options on US
<cr1901>
series* 7
<whitequark>
sb0: hmm I'm a bit confused
<whitequark>
by transceiver block do you mean ISERDESE3 or something else?
<sb0>
the GTH
<whitequark>
oh, GTH
<whitequark>
I don't think I can abstract high speed transceivers like ECP5 SERDES or GT*
<whitequark>
wasn't able to come up with a design so far
<whitequark>
not only there are too many features and arbitrary constraints, but each high speed interface needs a very specific configuration as well
<sb0>
yeah and things like those complicated clocking schemes won't make it easier...
<whitequark>
so that's not in scope
* cr1901
will read scrollback in the morning... night all
<whitequark>
there aren't that many PHYs anyway
<whitequark>
what I want is to eliminate most-to-all cases where some code is not portable solely because you want something trivial, like 100 MHz input 125 MHz output, or x4/x7/x8 IO gearing, specifically because the primitives to do so are so similar in the first place
<whitequark>
there are still some tricky questions, for example ISERDESE3 has a reset input and Pin() currently doesn't have a reset
<whitequark>
and for that matter SB_IO has neither a reset input nor a way to specify reset FF values
<_whitenotifier-3>
[nmigen] whitequark commented on issue #57: Should non-existent clock domains be silently created in Fragment.prepare? - https://git.io/fjol0
rohitksingh_work has joined #m-labs
<_whitenotifier-3>
[nmigen] whitequark commented on issue #92: Using Yosys with Xilinx Series 7 devices (and non-standard tool flows) - https://git.io/fjola
<_whitenotifier-3>
[nmigen] whitequark closed issue #92: Using Yosys with Xilinx Series 7 devices (and non-standard tool flows) - https://git.io/fjzZ0
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjolr
<_whitenotifier-3>
[m-labs/nmigen] whitequark f0a7f84 - README: tone down the instability warning to reflect current status.
<_whitenotifier-3>
[nmigen] whitequark opened issue #112: Update COMPAT_SUMMARY for non-lib items - https://git.io/fjoli
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #92: Using Yosys with Xilinx Series 7 devices (and non-standard tool flows) - https://git.io/fjolX
<_whitenotifier-3>
[nmigen] whitequark commented on issue #92: Using Yosys with Xilinx Series 7 devices (and non-standard tool flows) - https://git.io/fjol1
<cr1901>
whitequark: The only thing I remember needing to explicitly change for spartan3 support in oMigen is using the undocumented command to ISE use_new_parser=yes and making optimizing for area the default
<cr1901>
both of these were specifically to make misoc cores fit more easily on the 100k gate variant
<cr1901>
err 200k*
<cr1901>
whitequark: I do want to read the list of primitives S3 has compared to S6 before concluding it's a 5 line change tho.
<whitequark>
sure
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<_whitenotifier-3>
[nmigen] mithro commented on issue #92: Using Yosys with Xilinx Series 7 devices (and non-standard tool flows) - https://git.io/fjoaG