<pepijndevos>
would maybe be useful to add an option to icepll
<daveshah>
yeah
<pepijndevos>
what is even an icestorm_lc and why do I have one *facepalm*
<pepijndevos>
ERROR: failed to place cell 'm_vc.data[1]_SB_DFFE_Q_11_D_SB_LUT4_O_I2_SB_LUT4_O_I2_SB_LUT4_O_I2_SB_LUT4_O_I3_SB_LUT4_O_I2_SB_LUT4_O_I2_SB_LUT4_O_LC' of type 'ICESTORM_LC'
<OmniMancer>
24 bit signals are not exactly small?
<OmniMancer>
daveshah: and how do you model only having them separate?
<daveshah>
It now has separate outputs as pepijndevos said
<daveshah>
He fixed that for gowin
<daveshah>
But still only allows one at to be used at a time
<pepijndevos>
Wait? what stops you frm using both?
<OmniMancer>
pepijndevos: is your gowin generic backend available anywhere to look at?
<daveshah>
The packer doesn't allow that because some FPGAs don't support that
<daveshah>
I don't think the packer will ever use both at present?
<OmniMancer>
is there any way to allow that being a setting?
<pepijndevos>
daveshah, thought I had this morning: could you "infer" a packer from something like techmap files to once and for all solve "but my fpga has ..." for the generic slice
<daveshah>
Nice idea but in practice becomes a massive PITA with non trivial constraints
<daveshah>
The real arches tend to do minimal packing anyway
<daveshah>
And be much more reliant on validity checks
<pepijndevos>
right...
<daveshah>
But if you want to try that approach, feel free to have a look at VPR
<pepijndevos>
OmniMancer, uh, public release will be Soon(tm), but I could add you to the private repo maybe, if you give me a gitlab account name
<OmniMancer>
pepijndevos I do not think I have a gitlab account yet
<sorear>
which arch is OmniMancer working on?
<OmniMancer>
Anlogic Eagle
<OmniMancer>
sorear: ^^
<OmniMancer>
is it common to have no clock inputs from the general interconnect?
<daveshah>
No
<daveshah>
But there might be some special general to clock routing, I suppose
freemint has quit [Ping timeout: 245 seconds]
<OmniMancer>
Ah, yes that may be the case
<OmniMancer>
but I will have to figure out how to convince the tools to produce such a thing to see how to provoke it
<sorear>
is there a documentation deliverable for these projects?
<sorear>
which has pretty pictures AND a lot of text
<sorear>
symbiflow has the pretty tables but nobody's written the necessary explainers yet so it's still quite opaque
<OmniMancer>
presumably there is eventually
<sorear>
that was a question for you. do you plan to write human-readable, self-contained documentation for Anlogic FPGAs which I can read and, in principle, produce tools from
<OmniMancer>
I will see how far I get
<OmniMancer>
would adding the explainers for the symbiflow style tables to the symbiflow documentation be helpful?
<sorear>
I don’t think I’ve seen them so I can’t say
Jybz has quit [Quit: Konversation terminated!]
<OmniMancer>
I suppose my question is do you want documentation that consists of an explanation of how every piece works?
<sorear>
If a piece exists and we know facts about it, those facts should be documented
<OmniMancer>
many "facts" are currently conjecture inferred from naming of inputs in the vendor tools and the way the vendor tools behave
<sorear>
I want there to be as much information on Ultrascale at 70 as there is about random early mainframes at 70. People will care about this, don’t let the knowledge die with you
<OmniMancer>
daveshah: how do you determine which signals are used for the extra ones needed for distributed RAM?
<sorear>
that was maybe a little harsh, sorry, I’m in a mood
<OmniMancer>
Its okay, it just feels like a rather large burden...
ym has quit [Remote host closed the connection]
<OmniMancer>
daveshah: in ECP5 what can the ends of the 6 span wires be connected to?
Bike has joined ##openfpga
jemk has quit [Remote host closed the connection]
jemk has joined ##openfpga
jemk is now known as Guest310
Guest310 has quit [Quit: leaving]
jemk_ has joined ##openfpga
jemk_ is now known as jemk
Guest74185 has joined ##openfpga
Guest74185 has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
davidthings has quit [Remote host closed the connection]
davidthings has joined ##openfpga
<pepijndevos[m]>
Is there anywhere I can read about different bus standards? I hear ZipCPU talking about axi all the time, but also axi lite, this other thing I forgot. Just ran into axi stream?? I've not really used any bus at all
davidw has joined ##openfpga
davidw is now known as Guest30695
davidthings has quit [Read error: Connection reset by peer]
david__ has joined ##openfpga
Guest30695 has quit [Read error: Connection reset by peer]
<ZirconiumX>
pepijndevos[m]: There are two main bus standards for you to google. AXI - used by mostly commercial silicon, and Wishbone - used mostly by opencores stuff
david__ has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
davidthings has quit [Remote host closed the connection]
davidthings has joined ##openfpga
zino has quit [Quit: Leaving]
david__ has joined ##openfpga
davidthings has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
Maya-sama has joined ##openfpga
hackkitten has quit [Ping timeout: 246 seconds]
<mwk>
pepijndevos[m]: axi stream is what the axi bus (lite or otherwise) is made of
<whitequark>
I thought that was such a weird design...
<mwk>
whitequark: ?
<mwk>
axi?
<whitequark>
axi yeah
<hackerfoo>
AXI Stream is just a ready/valid stream. AXI is built pretty straightforward from streams, but full AXI supprts tagging with an ID to support multiple transactions.
<hackerfoo>
So I
<hackerfoo>
So I'm working on natively implementing AXI-lite in my language, which has natural support for ready/valid streams.
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` has joined ##openfpga
<hackerfoo>
Rather than writing a bridge in Verilog.
X-Scale` is now known as X-Scale
<pepijndevos>
wooow okay
<pepijndevos>
So AXI is 6 times these data/ready/busy/done/whatever "stream" lines
<mwk>
ready and valid
<mwk>
6 times, yes
<mwk>
axi lite has fewer IIRC
<mwk>
ready/valid is a pretty elegant thing btw
* mwk
likes
<whitequark>
ready/valid will be a core part of nmigen, yeah
<mwk>
whitequark: oh, nice
<mwk>
hm
<mwk>
I need to finally have a look at that
* mwk
adds "learn nmigen" to her todo
<pepijndevos>
And what about Wishbone?
<mwk>
oh, wishbone is much simpler
<pepijndevos>
But actually I think my real question is more... in which scenarios should I be using a bus?
<mwk>
axi is really stream-oriented and made for heavy pipelining
<mwk>
while wishbone is dead simple and has one outstanding transaction
<TD-Linux>
axi stream by itself is also how at least xilinx likes to expose accelerators etc on zynq. they have an axi dma peripheral that can read/write to axi streams
<whitequark>
wishbone is also kind of pretty awful
<whitequark>
it's usable just fine for really simple peripherals but even if you want just pipelining it gets really gnarly
<mwk>
pepijndevos: any scenario when you want something to be doing random access to something else's memory or registers
<mwk>
esp. when you have multiple clients
<ZipCPU>
whitequark: That might depend upon which wishbone standard you are using
<mwk>
and depending on your use case, the bus may range in complexity all the way from some dead simple arbiter to fullblown AXI
<ZipCPU>
The B4 standard includes a "pipelined" option that pipelines much like AXI does
<whitequark>
ZipCPU: yes, I know
<pepijndevos>
And is this in any way related to LiteX and/or FuseSoC, or completely orthogonal? Just some other names I've seen being thrown around that I should maybe look into more...
<mwk>
AXI/wishbone are bus *interfaces*
<whitequark>
ZipCPU: I remember that I looked at it really closely a few weeks ago and found it not especially well designed
<mwk>
liteX / fusesoc are actual *circuits* that use them inside
<whitequark>
while writing integration code for nMigen
<mwk>
(not sure which bus they use, but they definitely use something, everyone does)
<whitequark>
I don't remember the exact details and I'm busy with something else so I'd rather not spend a hour with the spec again
<ZipCPU>
Really? I'd be curious to hear what problems you found
<ZipCPU>
Ah, oh, sorry
<ZipCPU>
I'd still love to hear it sometime
<whitequark>
I'll make sure to discuss this with you next time I find myself looking at it
<ZipCPU>
Thanks!
<ZipCPU>
pepijndevos: When do you need a bus? When communicating with anything that looks or acts like a memory
<whitequark>
ZipCPU: oh, I remember at least one issue
<ZipCPU>
Cool! What?
<whitequark>
ZipCPU: look at section 5.1
<ZipCPU>
B3 or B4?
* ZipCPU
opens B4
<whitequark>
B4.
<pepijndevos>
Ah, that's a useful criteria, and explains why I have not used it much so far... not many things in my world look like memory. *Shared* memory I assume though, because just one module having its own BRAM seems waste of time to give it a bus.
<whitequark>
so, it essentially says that ACK_O terminates a bus cycle. so far so good.
<whitequark>
but it does not say whether ERR_O and RTY_O terminate a cycle.
<pie_>
you sunk my battleship
<ZipCPU>
whitequark: Ok, you are confusing the classic mode with the pipeline mode
<ZipCPU>
Section 5.1 is about bridging between the two
<whitequark>
am I?
<ZipCPU>
Yes
<whitequark>
does the pipelined mode not have ERR_O and RTY_O?
<ZipCPU>
In classic mode, the ACK|ERR|RTY ends the bus cycle
<ZipCPU>
In pipelined mode, the transaction completes with ACK|ERR|RTY, but you might have other transactions in the pipeline that will remain ongoing
<ZipCPU>
You can also terminate a transaction before ACK|ERR|RTY by dropping CYC
<whitequark>
where does the spec say that in pipelined mode the transaction completes with ERR|RTY?
<ZipCPU>
You know I mean one beat of the transaction, right?
<whitequark>
yes
<ZipCPU>
Every beat gets a response of either ERR|RTY|ACK
<whitequark>
I understand what you're saying
<whitequark>
my problem is that the spec doesn't actually say this anywhere
<whitequark>
it only mentions ACK
<whitequark>
and their sample HDL code for converting classic<>pipelined is incorrect, if a transaction terminates with ERR|RTY|ACK
<ZipCPU>
Let's try this: imagine ERR|RTY|ACK is equivalent to the AXI-lite (BVALID & BREADY)|(RVALID&RREADY)
<whitequark>
I think you misunderstand my complaint
<whitequark>
I also have common sense, and I can interpret whatever the spec omits according to that
<ZipCPU>
Perhaps
<whitequark>
I *shouldn't have to*.
<ZipCPU>
As in, I might be misunderstanding your complaint
<whitequark>
it should clearly explain the semantics of ERR|RTY|ACK.
<whitequark>
as it is, it actually never says *anywhere* that RTY terminates a cycle.
<tpw_rules>
ZipCPU: re wishbone pipelined, is it correct to say that for as long as CYC is asserted, one of (ERR, RTY, ACK) must be asserted exactly once for every clock cycle that STB is asserted?
<whitequark>
I just searched it again to be sure.
<ZipCPU>
... for every clock cycle that STB && !STALL
<tpw_rules>
i mean well e.g. if you error then all the future transactions are cancelled
<whitequark>
yes, that's another aspect the spec doesn't actually explain
<ZipCPU>
tpw_rules: That's certainly how I do it: ERR cancels everything on going
<ZipCPU>
That's not necessarily in the spec, that's how I implement the spec
<ZipCPU>
The spec does state that there should be one ERR|RTY|ACK for every (STB&!STALL)
<ZipCPU>
It also says that the bus cycle can be terminated early (IIRC) by lowering CYC
<ZipCPU>
whitequark: This confusion was one of those reasons why I wrote a set of formal properties for WB
<whitequark>
ZipCPU: yes. IMO every bus should come with a formal specification, which takes precedence over the text.
<ZipCPU>
:D
<whitequark>
but if it does not, then the informal specification should at least be clear and unambiguous
<whitequark>
the Wishbone B4 specification is not, which is why I have said that it is poorly designed / written.
<whitequark>
(well, one of the reasons)
<ZipCPU>
So it sounds like your issue is with the specificity of the text
<whitequark>
this specific issue, yes.
<ZipCPU>
I'll admit that, on my first ORCONF trip, that was one of the issues I wanted to discuss
<ZipCPU>
My solution was to add definition where the text wasn't clear
<whitequark>
in fact, I have initially implemented ERR|RTY behavior incorrectly (according to your explanation) in nMigen-SoC
<ZipCPU>
For example, the text doesn't plainly state that if (STB) assert(CYC); You have to dig for that one.
<whitequark>
but I thought that it is too ambiguous and just removed the implementation completely
<whitequark>
as it turns out, that was the right thing to do
<ZipCPU>
Feel free to use my formal properties to know if something works or doesn't
* ZipCPU
doesn't use the RTY signal
<whitequark>
I think I'll make ergonomics of formal properties a focus for nMigen 0.3, and integrate properties for some busses
<ZipCPU>
WB and AXI-lite are easy. Avalon isn't that hard either.
<ZipCPU>
AXI is a @#$@*& to get right
<whitequark>
I can see that.
<ZipCPU>
I have formal property sets for all of the above. Let me encourage you to use them.
<whitequark>
do you think they can be distributed as a part of nMigen, eventually?
<ZipCPU>
All but AXI, yes
<whitequark>
nMigen uses a 2-clause BSD license.
<tpw_rules>
ZipCPU: where in the world are you? dicussions came up with a friend about bringing you over
<pie_>
ZipCPU: try to think back to when you werent an expert? :P
<ZipCPU>
USA--not all that far out of DC, but far enough to be in horse country
<ZipCPU>
After slaughtering our geese, we still have turkey's in the backyard
<pie_>
something is probably wrong if whitequark makes a mistake in implementation from spec >.>
<tpw_rules>
oh ok that's not horrendously far
<whitequark>
I write bugs all the time.
<whitequark>
I'm not particularly better at programming than most people.
<tpw_rules>
*grimace/grin emoji*
<pie_>
hm :p i dont wish to contest that
<pie_>
but you do have a lot of experience
<ZipCPU>
Heheh ... that's one of the reasons why I like formal in the first place. It makes it easier to double check your work
<whitequark>
more persistent and focused, yes. though that comes with a cost.
<ZipCPU>
pie_: You might be surprised at how little experience I actually have ... ;)
<pie_>
ok fine ill just be quiet :p
<pie_>
im just trying to say if a domain specialist cant get it right easily something is fucky
<whitequark>
in fact it's exactly *because* I make mistakes all the time, I have so much interest in better language design and formal methods
<pie_>
unless the inherent complexity is high, in which case ok sure
<pie_>
whitequark: hard agree
<whitequark>
also, my domain is compilers, not digital logic
<pie_>
i cant tell
<pie_>
:p
<ZipCPU>
I am certainly not a domain specialist on AXI.... I only recently started working with it
<ZipCPU>
(December, 2018 was my first formally verified AXI-lite design)
<pie_>
(compilers are cool though, *wistful sigh*)
<whitequark>
ironically, that could be why you're finding bugs in AXI designs from major companies
<whitequark>
well, a part of the reason
<pie_>
also yeah i wish specs came with formal models you could test stuff against and whatever
<whitequark>
experienced people can end up brushing aside the brokenness they grew up (professionally) with
<pie_>
im in the space of being interested in formal stuff but having not much of an idea how to practically use it in software dev
<whitequark>
"oh, that's just how things always were"
<pie_>
other than fighting with haskell and scratching my head about theorem provers
<pie_>
whitequark: im young and it seems really easy to get stuck in something akin to that mindset
<whitequark>
well, SVA is like easy mode for formal, compared to most other tools
<pie_>
SVA?
<whitequark>
(SVA is much much easier to use than, say, Kami)
<whitequark>
SystemVerilog Assertions
* ZipCPU
isn't young, but only has about 4yrs of intense experience with FPGAs
<whitequark>
a sub-language of SV that lets you state formal properties
<whitequark>
ZipCPU: that's probably similar to the entirety of my FPGA experience. maybe a bit more than that
<whitequark>
and for the longest time I wasn't very serious about it
<pie_>
oh @ systemverilog assertions
Zorix has quit [Ping timeout: 245 seconds]
Zorix has joined ##openfpga
rombik_su has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
Maya-sama is now known as Miyu
Miyu is now known as hackkitten
dh73 has joined ##openfpga
awordnot has quit [Ping timeout: 245 seconds]
awordnot has joined ##openfpga
kbob has joined ##openfpga
kbob is now known as Guest13541
Guest13541 is now known as kernlbob
<kernlbob>
Can anyone explain the relation between nMigen Resources and Records?
nrossi has quit [Quit: Connection closed for inactivity]
david__ has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
<whitequark>
a Resource is a way to describe board pins in a structured way
<whitequark>
if you request a Resource (by its name), the platform returns a Record that is connected to those pins in the way you request
davidw has joined ##openfpga
davidw is now known as Guest15525
davidthings has quit [Read error: Connection reset by peer]
Guest15525 has quit [Read error: Connection reset by peer]
rombik_su has quit [Ping timeout: 265 seconds]
Guest15525 has joined ##openfpga
egg has quit [Disconnected by services]
oeuf has joined ##openfpga
dh73 has quit [Quit: Leaving.]
freemint has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 276 seconds]
dh73 has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
<kernlbob>
Is a Record unidirectional? Would it be wrong to put the three lines of a SPI interface into a Record?