<_whitenotifier-f>
[nmigen] shawnanastasio synchronize pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IM
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] shawnanastasio commented on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/JfPnU
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] shawnanastasio synchronize pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IM
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IF
nengel has quit [Ping timeout: 260 seconds]
nengel has joined #nmigen
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #nmigen
Guest30583 has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
chipmuenk has joined #nmigen
<zignig>
whitequark: the cert has expired on freenode.irclog.whitequark.org , it may be that I am on the other side of the dateline , but I can't see history anywway.
Asu has joined #nmigen
peepsalot has quit [Ping timeout: 265 seconds]
peepsalot has joined #nmigen
futarisIRCcloud has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #nmigen
jeanthom has quit [Quit: Leaving]
jeanthom has joined #nmigen
<jeanthom>
hi, is it possible to generate anonymous states in an FSM?
<Lofty>
jeanthom: if they're anonymous how do you refer to them?
<Lofty>
By definition they can't be referred to if they're anonymous, so you can't actually access them
<whitequark>
here's the problem: with m.FSM(domain="tx", reset=~lane.det_enable):
<whitequark>
a `reset` value can only be an integer
<whitequark>
well, or an integral enum value or something like that
<Degi>
Ah yes, that is the reset signal which should go to a ResetSignal I think. If I want it to reset to the first declared state, should that simply be 0?
<whitequark>
er, sorry, what I just said isn't entirely right
<whitequark>
a reset value has to be concrete
<whitequark>
so for signals that would be an integer or an integral enum
<whitequark>
and for FSMs that would be a state
<whitequark>
if you want that to be the first declared state you simply omit it
<Degi>
Thank you! I think it should work now.
<ktemkin>
or, in other words, the `reset` argument is the reset value, not the reset condition (which is implicitly pulled in with the clock domain)
<ktemkin>
IIRC, if you _do_ want to add a reset condition for a particular unit, you can use a ResetInserter to transform the Fragment/Elaborable; though in many cases you're better off making it explicit in your logic
<whitequark>
thanks, that's a good way to describe it
<ktemkin>
whitequark: by the way, is QuickLogic sending you any of their pre-release open-toolchain FPGAs?
<daveshah>
not wq, but as a data point I have one in the post
<ktemkin>
they've mailed me one, but I don't have docs, yet -- if what they have winds up looking reasonable, I might add support to nMigen
<ktemkin>
daveshah: per tracking, mine's downstairs
<ktemkin>
not much to do with it without docs, though :)
<whitequark>
ktemkin: I don't think they did
<ktemkin>
if you're interested in playing with one (Cortex M4 + FPGA fabric w/ vendor supported open tools), I can poke someone over there and recommend they send you one
<whitequark>
yep, in fact it is a requirement for having it upstream in nmigen (soft requirement, not a hard one, but I would be concerned if there were any devices I could not verify still work)
<whitequark>
(eventually I'd like to have a machine with every FPGA family and toolchain available for anyone contributing to nMigen vendor code)
<whitequark>
(ultrascale makes this... somewhat hard, though I do have a dead ultrascale board I might be able to fix)
<Degi>
azonenberg has some bigger FPGA dev boards too
<ktemkin>
whitequark: okay, I messaged the QuickLogic guy who reached out to me; we'll see if he follows up with you
<whitequark>
all I wanted to do is to add hdlname support to flatten...
<Degi>
nmigen throws an AssertionError of "assert defs[sig] is self" when I assign to a primitive instances output a pin whose direction is not specified (if I add dir="o" it works again). Thats similar to #191 and #320, should I still file a bug report or would that be redundant?
<whitequark>
sure, more test cases is helpful
<whitequark>
ktemkin: he did!
<ktemkin>
that was fast
<_whitenotifier-f>
[nmigen] x44203 opened issue #398: Obscure AssertionError when assigning an io pin to the output of an instance - https://git.io/JfPN9
<agg>
Huh, cortex-m4 plus open tool supported FPGA fabric sounds amazing
<agg>
Cm4 is exactly what I want rather than the infinite complexity of zync etc
<whitequark>
yeah it's quite reasonable
<agg>
My current work thing is an stm32f4 with a 16 bit memory bus to an ice40 which is pretty good, I can basically memory map whatever peripherals I want and DMA to/from, but an actual axi or ahb or something bus would be a lot nicer
<agg>
Wonder what the eos S3 peripherals are like though
<_whitenotifier-f>
[nmigen] rroohhh edited issue #320: Unclear error message on direction mismatch between Instance in submodule and toplevel usage - https://git.io/Jv8fh
<ktemkin>
we'll see some of what it's like today, hopefully -- Brian over there suggests docs / repos will be sent out sometime today :)
<sorear>
is there more public information on the quicklogic thing?
<ktemkin>
just got mine (excuse the potatocam photo)
<MadHacker>
Cute little board. What's in the guts of the chip? Anything interesting? SERDES?
* MadHacker
clicks the links rather than demanding knowledge. ARM+FPGA, shiny.
<whitequark>
huh, 8-wide resistor arrays
<MadHacker>
Saw those. Density, I guess.
<ktemkin>
MadHacker: I'll only know more than what's posted online when they send me docs later :)
<ktemkin>
now I just have to avoid cleaning off that factory flux before testing the thing :)
<MadHacker>
Hm, from the datasheet, the FPGA's not "between" any bits, it's sort of more adjacent to.
<Sarayan>
You people who know that stuff, is there a reasonable way currently to do bisimulation and possibly even adc with 5V chips is the 40 pins range?
<MadHacker>
Good for acceleration, not so good for smart I/O.
<Sarayan>
glasgow is extremely nice but kinda limited in the pin count area
<Sarayan>
I'm thinking old cpus, yamaha sound chips, that kind of things
<ktemkin>
there's a theoretical Big Glasgow (revD) one of us will have to spend the time routing
<MadHacker>
Analogue switch chip + fast ADC instead?
<whitequark>
Sarayan: i'm also working (intermittently) on a pin extender
<Sarayan>
Nice, let me know if it materializes at some point
<whitequark>
based on ATF15xx CPLDs
<whitequark>
well, I'm going to need to RE the CPLD first
<Sarayan>
microchip... nah, one brand at a time
<Sarayan>
need to finish the quartus v first :-)
<Sarayan>
atmel, not microchip, duh
<miek>
ktemkin: does this imply there is a smol glasgow?
<Sarayan>
mister has ~ 80 gpios, but 5V no way
<ktemkin>
miek: revC's decently smol
<whitequark>
Sarayan: i'm almost done with the logic block
<whitequark>
what remains is summarizing my existing findings in a nice equation form, + fuzzing routing
<ktemkin>
miek: if you want I can make you one and then take tinsnips to a corner
<ktemkin>
=P
<whitequark>
s/logic block/macrocell/
<Sarayan>
wq: Yeah, I had made the substitution myself :-)
<awygle>
lol @ Big Glasgow
<awygle>
so E is the ECP5 one w/ USB 3 and D is "C but bigger" somehow?
<awygle>
(i've lost track....)
<ktemkin>
just think of it like
<ktemkin>
revD = Double
<ktemkin>
revE = Extremely Complicated
<whitequark>
:D
<whitequark>
yeah, revD = revC+revC
<whitequark>
revE = ECP5+USB3+GigE
<whitequark>
(where USB3 would act simply as a fast USB Ethernet bridge)
<whitequark>
and somewhere between that we'll provide a network based abstraction layer for revABCD that would have the same interface as revE eventually will
<Lofty>
After revF it wraps around to rev0 /s
<whitequark>
hm.
<whitequark>
we *could* do that
<whitequark>
but revF is probably just starshipraider
<Sarayan>
wq: did you open the package, eventually, or is it just lost to the mist of time now? ;-)
<whitequark>
not lost
<whitequark>
let me open it now
<Sarayan>
huhuhu
<ktemkin>
hot take: we should be using the UK progression
<ktemkin>
so revD, revDD, revE, revF, revFF
<Sarayan>
rev95C for foone?
<Sarayan>
(only works for europeans)
<awygle>
i thought you didn't want to use Ethernet
<awygle>
because it's not plug and play
<Sarayan>
with modern dhcp it kinda is
<whitequark>
Sarayan: found it. YM3438, SC-01, CAT702, C8008
<whitequark>
awygle: it is these days, ipv6 autoconfiguration finally works
<Sarayan>
yay, nothing lost :-)
<whitequark>
i talked to android people
<awygle>
but power tho
<whitequark>
Sarayan: going to keep it safe for the time being, i'm still not well enough for serious projects like that
<Sarayan>
no problem
<whitequark>
but better than before
<whitequark>
awygle: re android people, they told me that today they wouldn't go for adb usb protocol and would use ipv6 over usbnet
<Sarayan>
cat702 is for die shot for pure curiosity, 8008 is whatever we want/can
<whitequark>
there *is* still a problem that usbnet is hell
<Sarayan>
sc-01 is for putting on the internet somehow, and ym3438 is as you wish
<whitequark>
Sarayan: gotcha
<whitequark>
awygle: for power we have usb3!
<whitequark>
like, that's the whole point of having usb at all
<whitequark>
so you can plug it into a laptop and have it work
<Sarayan>
the 3438 comes for an arcade pcb I had ~20 years ago, so it's very probably a real, working one fwiw
<whitequark>
i have no OPN2 yet
<whitequark>
so i can put it on the internet too
<whitequark>
ahhh it's one of those annoying ones with internal DAC
<Sarayan>
a modern dac probably has the resoljtion to fully distinguish the levels
<Sarayan>
depends on the analog coupling I guess
<whitequark>
yes
<whitequark>
it's not that
<whitequark>
it's the fact that... you know why i built glasgow right/
<Sarayan>
digital swiss knife?
<whitequark>
too adhd to prototype digital (or analog) circuits on protoboard or whatever
<whitequark>
and now i have to go back to that
<Sarayan>
emphasis on digital?
<whitequark>
so it takes approximately forever
<whitequark>
i even have some ADCs... which are in a case i dont have protoboards in
<Sarayan>
Tale all the time you need and then more, the sc01 is are and not lost so I'm happy
<Sarayan>
rare
<whitequark>
yep, I was very careful to not lose it
<whitequark>
in fact that was a part of why I didn't open it for so long... my place was a horrible mess
<whitequark>
and I'd rather wait than risk losing it
<Sarayan>
heh :-)
<whitequark>
well, it's still a horrible mess but you get the idea
<Sarayan>
indeed
<Sarayan>
you personally are less of an horrible mess, which is rather good
<whitequark>
heh
<Sarayan>
hmm, looks like I'm getting close to understanding the cyclonev routing
<whitequark>
nice
<Sarayan>
2.2M route nodes, encoded over 16M bits, I hope nextpnr scales
<Sarayan>
essentially, the nodes are wires with connection points to other wires, and well of course a number of nodes are logic block ports
<Sarayan>
choosing which wires to go through must be an interesting algorithmic problem
<Lofty>
Sarayan: My understanding is that routing is some flavour of A*
<Lofty>
In nextpnr, anyway
<Lofty>
mwk and daveshah will probably correct me though
<daveshah>
A* with ripup
<daveshah>
Virtually all FPGA routing is soemwhat A*
<daveshah>
It's actually the placer that doesn't scale so well routeability wise though
<Lofty>
I think LAB placement is going to be the most painful part of a Cyclone V port for nextpnr
jeanthom has quit [Ping timeout: 246 seconds]
<Lofty>
Perhaps packing is the term I'm actually looking for here
<daveshah>
Hopefully some of the RippleFPGA stuff I am working on for improved Xilinx pack and place should help
<Lofty>
Placement within a LAB
<daveshah>
In practice nextpnr generally combines the two
<Sarayan>
well, you'll have real tests for scaling anyway :-)
<daveshah>
Chances are what you need is a very fast incremental legality check and a heuristic to combine strongly associated LUTs into a ALM
<Sarayan>
then you have to combine the LABs (cv's ALM) input column blocks
<Sarayan>
s/input/into/
<Lofty>
I actually wrote a mini-packer for Yosys to give myself a bit of practice
<daveshah>
The column blocks would definitely be combined during placement rather than pre packed
<Lofty>
Which is why the intel_alm sources contain a commented-out implementation of some of the ALM logic
<daveshah>
But you would need validity check rules to deal with control set legality if that is shared
<Sarayan>
control set?
<daveshah>
Clk/set-reset/ce
<Lofty>
Checking set legality is easy
<Lofty>
return false;
<Lofty>
/s
<Lofty>
(yeah, the Cyclone V does not have sets)
<Sarayan>
there are iirc 4, maybe six vertical lines grouping iirc 10 LABs (which each have two lut groups or 3 luts each) and you can get the clock from any of the 4/6 lines
<Lofty>
3
<Lofty>
3 clock lines.
<Sarayan>
ok, there are data lines in the mix too
<daveshah>
Ah that is a tiny bit tricker, but still the kind of thing that fits the validity check rules
<Sarayan>
it's not a mess, quite, but it's complicated