<lkcl>
ktemkin, i really appreciate your insights. i hear you. please allow me some time to give a proper response the thought it deerve.
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<cr1901>
>e.g. SPIFlashResources looks like a constructor function, but it's really a type
<cr1901>
What do you mean by this? SPIFlashResources _is_ a function.
emeb_mac has quit [Quit: Leaving.]
kaucasus has joined #nmigen
<whitequark>
it's implemented as a function, but the design intent is for it to be a type
<whitequark>
(in the approach I use, code is secondary to intent, since code is the expression of intent)
<_whitenotifier-1>
[yosys] BharathS11 commented on issue #24: Error when used with VSCode and Teroshdl - https://git.io/JwHur
<_whitenotifier-1>
[yosys] whitequark commented on issue #24: Error when used with VSCode and Teroshdl - https://git.io/JwQyC
<Sarayan>
Design question: For the sx120f support I want to create methods/classes/not sure what to create Instances of useful stuff. Some should create a new one on each call (dsp blocks for instance), some should create one and share it (block of 64 irq lines going to the hps for instance). What should they look like and where should I put them?
<Sarayan>
it's internal stuff, no associated pins
<whitequark>
what is sx120f?
<whitequark>
stuff?
<whitequark>
can you link some documentation explaining what it is?
<Sarayan>
de10 nano\s cyclone v, one with an integrated ARM
<mwk>
altera part name, I think
<whitequark>
what are you working on related to that part?
<Sarayan>
full reverse engineering then nmigen/yosys/nextpnr support
<whitequark>
do I understand it correctly that you'd like to have an nMigen `Platform` supporting that part with the FOSS toolchain?
<Sarayan>
yes
<whitequark>
take a look at how support for dual FOSS/proprietary toolchains is done for Xilinx and Lattice parts
<whitequark>
ideally for Intel it would look much the same
<whitequark>
I'd expect that Yosys would have the same black boxes as the Intel toolchain provides, and they would be hooked up in the same way, which is by the user instantiating them directly when needed
<Sarayan>
Ok, so it should be in IntelPlatform
<Sarayan>
how are singletons supposed to be handled?
<whitequark>
there's nothing special about them
<whitequark>
nMigen currently doesn't have any special handling for singletons for the proprietary toolchain, so the FOSS one shouldn't add any such handling
<Sarayan>
you can have a submodule common to multiple modules and nothing is going to go wrong?
<whitequark>
you cannot
<whitequark>
if it's a singleton you manually instantiate it once somewhere in the module tree
<Sarayan>
that's a little bad for modularity
<whitequark>
perhaps, but it's currently true for every device and every toolchain
<Sarayan>
as programming languages, HDLs are... sad
<whitequark>
to rephrase: I agree that it's not ideal for SoC devices and I have plans to address that, but addressing it is separate from any work that goes into the Intel FOSS toolchain support
<Sarayan>
so it's not handled at this point, essentially, and hopefully someday it will be possible?
<whitequark>
yeah
<Sarayan>
ok, I can work with that
<whitequark>
without any extra effort from platform maintainers
<Sarayan>
well, you can't fix every issue with HDLs in five minutes
<whitequark>
most likely, you'd get something like `platform.request("hps_irqs")` that looks up `InstancePins("HPS", "irqs[24]", dir="o")` in the platform definition
<whitequark>
very vague outline
<whitequark>
then the singleton would be instantiated automatically in the toplevel, once, and routed as appropriate
<whitequark>
actually designing this is a significant amount of work
<Sarayan>
ok, and I get that there are more pressing priorities
<Sarayan>
as far as I can tell there's no dual-support in the current platforms, lattice is OSS only, xilinx is Proprietary only
<Sarayan>
Would a new IntelMistralPlatform for whatever mistral supports now and in the future be acceptable?
<mwk>
Sarayan: Xilinx has three different toolchains available
<whitequark>
Lattice ECP5 supports two toolchains (Trellis and Diamond), Lattice iCE40 supports three (IceStorm, LSE-iCECube2, Synplify-iCECube2)
<Sarayan>
ohhhh
<Sarayan>
ok, I see how it goes
<_whitenotifier-1>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JwFqr
<_whitenotifier-1>
[YoWASP/yosys] whitequark 3d4b0fb - Allow using any absolute or relative paths on Linux and Windows.
<_whitenotifier-1>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JwFGL
<_whitenotifier-1>
[YoWASP/yosys] whitequark 0923e16 - Handle uppercase drive letters in preopens on Windows.
<_whitenotifier-1>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JwFZJ
<_whitenotifier-1>
[YoWASP/yosys] whitequark 4ae03d9 - Allow using any absolute or relative paths on Linux and Windows.
<_whitenotifier-1>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JwFPv
<_whitenotifier-1>
[YoWASP/yosys] whitequark 33f7191 - Use upstream YOSYS_VER variable verbatim when computing version.
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 245 seconds]
bvernoux has joined #nmigen
<kaucasus>
Hey folks, I've got a question. I need to have a very basic buffer. Basically signals in, clock later those signals out. However the size of this buffer changes depending on where it is. Currently I thought to solve it by requiring a record to be passed through. That kind of works, but when simulating and viewing the vcd file with gtkwave it
<kaucasus>
Basically I'm asking 1) Is this even a good/recommended way to implement such a buffer? 2) why doesn't it simulate correctly?
<whitequark>
in your example, the input and the output are the exact same object
<d1b2>
<zyp> you're making multiple references to a single record instance, rather than making multiple instances of it
<kaucasus>
ohhhh right, so how do I go about making multiple instances of it, passing through the layout instead and just making the record in the class itself?
<whitequark>
that's one option
<kaucasus>
Right got it, Thanks both of you!
<_whitenotifier-1>
[yosys] whitequark commented on issue #24: Error when used with VSCode and Teroshdl - https://git.io/Jwbzh
peepsalot has joined #nmigen
peeps[zen] has quit [Ping timeout: 245 seconds]
balrog has quit [Ping timeout: 264 seconds]
balrog has joined #nmigen
lf_ has joined #nmigen
lf has quit [Ping timeout: 265 seconds]
emilazy has quit [Ping timeout: 260 seconds]
Niklas[m] has quit [Ping timeout: 260 seconds]
Chips4Makers[m] has quit [Ping timeout: 260 seconds]
tiltmesenpai[m] has quit [Ping timeout: 260 seconds]
cesar has quit [Ping timeout: 260 seconds]
tpw_rules has quit [Ping timeout: 264 seconds]
tpw_rules has joined #nmigen
Niklas[m] has joined #nmigen
<_whitenotifier-1>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JwAz1
<_whitenotifier-1>
[YoWASP/yosys] whitequark 5b8037b - Prepend YoWASP Python module path to `sys.path`, not append.
emilazy has joined #nmigen
tiltmesenpai[m] has joined #nmigen
cesar has joined #nmigen
Chips4Makers[m] has joined #nmigen
kaucasus has quit [Ping timeout: 256 seconds]
emeb has joined #nmigen
kaucasus has joined #nmigen
kaucasus has quit [Client Quit]
<lofty>
whitequark: how perfectly are you expecting Mistral to line up with Quartus, because at the moment the answer is "it doesn't"
<lofty>
I got kind of fed up with dealing with the megafunction IP blocks that Intel uses for abstraction over things
<whitequark>
ultimately this isn't about me but the people who use nMigen targeting Intel
<whitequark>
not being able to switch `toolchain` from "Mistral" to "Quartus" to see if your design works then is a significant downside; I did that a lot while working on e.g. ECP5 PCIe
<lofty>
It is a downside, I won't lie, but the Intel megafunction library is huge and to reimplement that inside Yosys is probably not likely to get merged
<lofty>
e.g. the Intel altsyncram cell for instantiating block RAM is effectively equivalent to $mem (or whatever the V2 cell is called)
<lofty>
If someone needs something that it provides that nMigen's Memory doesn't, I have strong doubts Yosys itself could express the block in question
<whitequark>
mwk: what do you think?
<whitequark>
mm, sure, but the Yosys Intel support isn't just for nMigen
<lofty>
The current Mistral cell list was designed to work well with Yosys and nextpnr because the Quartus cells do not
<whitequark>
bottom line is: nMigen itself avoids placing requirements on toolchains (for the obvious reason that most toolchains don't care about nMigen at all), so whichever you end up doing, nMigen will necessarily support
<whitequark>
what I wrote above is just my personal thoughts on FPGA cell libraries
<lofty>
I mean, I do agree that interoperability is a useful tool for comparison between toolchains
<lofty>
So I guess my thoughts are "we'll aim for feature parity, but not cell equivalence"
<whitequark>
let me answer your question a bit more explicitly
<whitequark>
as the nMigen maintainer, I do not expect anything from Mistral because Mistral is an upstream project, though I may make suggestions
<whitequark>
as an individual HDL developer, I do expect cell library equivalence
<electronic_eel>
the stuff in the intel megafunctions lib is not in a form that nicely maps to the actual hardware, but it is a thick abstraction layer with lot's of glue, right?
<lofty>
electronic_eel: more glue than abstraction layer
<mwk>
hm
<lofty>
For example, if you want a flop, Intel want you to use the dffeas primitive
<mwk>
imo the discussion about whether the cell library should be equivalent is orthogonal to discussion on whether the platform code can be shared
<whitequark>
I'd say not entirely
<mwk>
nMigen's job is not to understand the cell library (other than the small subset used in platform code itself for DDR / startup hacks), nMigen's job is to pass Instance calls down to yosys
<lofty>
An equivalent cell library does make sharing platform code easier
<whitequark>
if there's no cell equivalence, then you can't share even things like get_ff_sync/get_async_ff_sync implementations
<whitequark>
and it doesn't make sense to have a `toolchain` argument in the constructor of a platform that provides a different interface (in the sense of having different Instances available) to user code
<mwk>
oh right, the FFs
<lofty>
[21:14:00] lofty: For example, if you want a flop, Intel want you to use the dffeas primitive <-- however, the dffeas primitive has features that cannot be implemented in the underlying hardware (or perhaps were at one point)
<mwk>
yeah, I do agree intel is... special
<whitequark>
so it may be possible that, unlike with all other platforms, it makes sense here to have `IntelPlatform` and `MistralPlatform` separate
<mwk>
in that the hardware "primitives" it exposes... aren't
<whitequark>
because prjmistral is effectively a vendor here
<whitequark>
not just a toolchain
<mwk>
~now that's just unwarranted namecalling~
<lofty>
Oh great, I'm a Vendor now
<whitequark>
hahahah
<electronic_eel>
lofty: how does it feel being a vendor?
<lofty>
electronic_eel: You need to sign at least three NDAs for that
<electronic_eel>
oh great.
<mwk>
that said... I would say that aiming for cell compatibility is a good plan in general, *if possible*
<lofty>
So, if Intel are lying about what their hardware can perform and we're exposing what it actually can do, and there is inherent breakage in this, then what?
<whitequark>
mwk: re nMigen's understanding of the cell library: that's something that I think may become nMigen's job in the future
<whitequark>
mwk: once we have clock domains in the type system, we have to do something about Instances that's not just "ask the user to enter annotations at every use site"
<mwk>
as for altsyncram: it may not be expressible by yosys cells, but what we'd actually need it is to express it in terms of whatever mistral primitives are, and make a techmap rule for that; that may be a significantly easier proposition
<lofty>
Intel aren't even consistent themselves: the current nMigen IntelPlatform does not work with Cyclone 10
<whitequark>
that's an nMigen bug
<lofty>
This is because with Cyclone 10 they changed the GPIO cells into a new altera_gpio
<lofty>
And also replaced quartus_map with quartus_syn
<whitequark>
no, really, that's an nMigen bug, look at the crimes XilinxPlatform has to do
<lofty>
I know, but I think it's maybe a little weird
<whitequark>
vendors!
<whitequark>
they're more than a little weird
<lofty>
Anyway, Mistral tries to sidestep another of Intel's idiosyncrasies
<mwk>
whitequark: hah, we'll need to talk about that sometime; I had thoughts about blackbox annotations for vfront / hypothetical future ummm you know what
<whitequark>
yep yep
<lofty>
For example, you can skip a megafunction call, if you know the name of the family primitive
<whitequark>
mwk: and CXXRTL has related functionality too
<mwk>
I know
<whitequark>
for similar reasons
<lofty>
So, an altsyncram might be a cyclonev_ram_block
<mwk>
yep
<lofty>
But if you want a Cyclone IV ram block?
<lofty>
Well that's a fiftyfivenm_ram_block
<electronic_eel>
lofty: sounds a bit like magic, where you control something if you know the name of it...
<lofty>
electronic_eel: I know too many True Names
<lofty>
Tell me, Muse, of why the Intel RAM block primitives appear to be the only ones supported by Yosys that do *not* support initialisation in a parameter
<lofty>
Of why Intel ship a function to convert from HEX format to MIF
<lofty>
In Verilog
<whitequark>
nice
emeb_mac has joined #nmigen
<lofty>
They also have some functions to helpfully assist with whether a chip name is of a particular family
<lkcl>
ktemkin, i promised i'd get back to you: i have however been in chronic pain the entire day which is somewhat of a distraction for holding irc conversations.
<lkcl>
your patience appreciated: usually these go away in around 36 hours.
<mwk>
whitequark: but, as for an argument for sharing platform code
<mwk>
consider nmigen-boards
<mwk>
you have `class ShinyBoard9000Platform(IntelPlatform): ...`
<whitequark>
I am!
<whitequark>
hm
<mwk>
if there is only one IntelPlatform, changing toolchain is a matter of changing the right setting
<whitequark>
I was thinking of exposing SoC stuff via nmigen-boards
<whitequark>
in which case IntelPlatform boards and MistralPlatform boards will be incompatible
<mwk>
if there's an IntelMistralPlatform, you need to make another boar platform class that inherits from something else
<whitequark>
but something like HPS is actually not something you want to have stuff for in boards
<whitequark>
JTAG primitives, yes
<whitequark>
I agree
<whitequark>
having two IntelPlatform classes, per toolchain, is probably just not viable
<whitequark>
the code that chooses between toolchains has got to live -somewhere- and it might as well live in `IntelPlatform`
<mwk>
Xilinx could get away with it (before the unification), because it was split by device generation, not by toolchain
<mwk>
also: memory primitives are kind of the least of our problems, given that memories can in principle be infered
<mwk>
what about the stuff that needs to be instantiated, like hard IP? will there be a MISTRAL_HPS primitive?
<mwk>
or will the new toolchain use the same cells for at least the less insane hardware primitives?
esden has quit [Ping timeout: 268 seconds]
benreynwar has quit [Ping timeout: 260 seconds]
Qyriad has quit [Ping timeout: 250 seconds]
alanvgreen has quit [Ping timeout: 252 seconds]
yuriks has quit [Ping timeout: 246 seconds]
guan has quit [Ping timeout: 250 seconds]
tcal has quit [Ping timeout: 250 seconds]
gatecat has quit [Ping timeout: 250 seconds]
tcal has joined #nmigen
mithro has quit [Ping timeout: 260 seconds]
tannewt_ has quit [Ping timeout: 268 seconds]
sorear has quit [Ping timeout: 268 seconds]
ktemkin has quit [Ping timeout: 260 seconds]
key2_ has quit [Ping timeout: 260 seconds]
tucanae47_ has quit [Ping timeout: 264 seconds]
gatecat has joined #nmigen
mithro has joined #nmigen
ktemkin has joined #nmigen
alanvgreen has joined #nmigen
tannewt_ has joined #nmigen
tucanae47_ has joined #nmigen
yuriks has joined #nmigen
key2_ has joined #nmigen
sorear has joined #nmigen
guan has joined #nmigen
Qyriad has joined #nmigen
benreynwar has joined #nmigen
esden has joined #nmigen
bvernoux has quit [Read error: Connection reset by peer]