<whitequark>
04:25 < sorear> extremely happy that mithro has taken a position in favor of self-contained documentation for FPGA architectures
<whitequark>
as opposed to?
<sorear>
whitequark: there have been previous comments to the effect that the trellis docs are only intended to make sense to people who have (a) read every Lattice TN (b) written a fuzzer (possibly for a different arch)
<sorear>
i was unamused
pie_ has quit [Ping timeout: 244 seconds]
Maylay has quit [Ping timeout: 268 seconds]
<sorear>
which I interpreted as such, etc
<whitequark>
wtf
Maylay has joined ##openfpga
Atlantic778 has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
Atlantic778 has quit [Ping timeout: 246 seconds]
pie_ has quit [Ping timeout: 272 seconds]
dj_pi has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
<tpw_rules>
esden: how fast can the icebreaker's usb fifo go? i'm eying one for an experiment where i need to sustain 150Mbps out of the fpga over many minutes, with at least 15 inputs
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
Atlantic778 has joined ##openfpga
Atlantic778 has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Quit: Leaving]
Miyu has quit [Ping timeout: 240 seconds]
Maylay has quit [Ping timeout: 250 seconds]
Maylay has joined ##openfpga
dj_pi has quit [Ping timeout: 246 seconds]
<swetland>
tpw_rules: I'm trying to figure out how to enable it -- the docs talk about EEPROM settings
<swetland>
based on the icebreaker schematic and ft2232h docs I'm assuming it's the ASYNC FIFO mode
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark pushed 3 commits to master [+80/-4/±3] https://git.io/fhLsG
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark 99fe969 - Start designing the new pipeline.
<swetland>
suggestions for ECP5 dev/eval/etc boards?
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<daveshah>
swetland: if you want something commercially available now, I'd recommend either the Versa 5G or the LFE5UM5G-85F-EVN
<swetland>
the 5G is the PCIE formfactor one with GBE?
<daveshah>
Yes
<swetland>
I'm interested in poking at somewhat larger stuff with the open toolchains and ECP5 seems like the place to be for that (though the state/progress on 7-series is encouraging)
<daveshah>
Yes as it stands the ECP5 tools support a reasonable feature set but definitely need more testing
<swetland>
I've enjoyed putting the ICE40 stuff through its paces ^^
<swetland>
also I didn't realize how much more reasonably the ECP5 stuff is pricewise compared to -7 stuff
<daveshah>
That's definitely a nice benefit of the ECP5 (but be aware ECP5 is 40nm and LUT4 compared to xc7 being 28nm and LUT6)
* swetland
nods. it's not exactly apples to apples, but still, ECP5 looks pretty reasonable
* swetland
wonders if there's somewhere in the bay area to conveniently obtain random small quantity 0402/0603 Rs and Cs
<daveshah>
At the low end the 12k ECP5 is in a similar price bracket to the 5k/8k iCE40s
<daveshah>
If you don't need tiny or low power
<swetland>
yeah the single digit pricing on the small parts caught my eye
<whitequark>
tpw_rules: you kinda sound like you want a glasgow lol
<tpw_rules>
yes but they aren't available yet :(
<tpw_rules>
what makes it 50MHz? can i do 75MHz with some fpga logic?
<whitequark>
tpw_rules: glasgow?
<whitequark>
so, hm
<whitequark>
the USB FIFO is either 30 or 48 MHz, but you can saturate the USB bus with either
<whitequark>
so that's not a problem
<whitequark>
75 MHz clock on UP5K is out of question, but you could do DDR to capture at 75 MHz
<tpw_rules>
i have a 75MHz input clock and a 3 bit data bus that i plan to deserialize into 16 bit words
<tpw_rules>
oh
<whitequark>
not on UP5K, unfortunately
<whitequark>
revC will cope with that easily
<whitequark>
but for that we just need to wait until esden returns
<tpw_rules>
well as far as i know revC is the only glasgow i can get
<tpw_rules>
what fpga does revC have?
<whitequark>
HX8K
<whitequark>
there are some people selling revBs
pie_ has joined ##openfpga
<whitequark>
however it really sounds like you want revC
pie_ has quit [Remote host closed the connection]
<tpw_rules>
is following marcan enough to get me notified when it's ready
<marcan>
whitequark: I got a glasgow!
<marcan>
thanks TD-Linux
pie_ has joined ##openfpga
<whitequark>
tpw_rules: yeah
<marcan>
also I just now realized how tiny it is
<whitequark>
marcan: nice
<whitequark>
and yeah
<marcan>
no wonder fitting all that stuff in there was hard
<esden>
Sorry I wanted to have the prototypes for the Congress but failed
<tpw_rules>
cool. well i will wait excitedly
<whitequark>
esden: its okay!
<whitequark>
there's no real rush
<marcan>
esden: failing is part of my brand, you know ;)
<esden>
You can follow me on twitter too I will announce it there too
<esden>
whitequark: I know I hope you have a good time with Robert ;)
<esden>
marcan: ;)
<tpw_rules>
are the plugs and dimensions stable? i need to do an interface board for my project
<whitequark>
tpw_rules: yes, you can use the dimensions from revC kicad files
<tpw_rules>
cool
<whitequark>
they will not change for revC and revD will be compatible
<whitequark>
just wider
<esden>
I have the feeling that I should consider making revb too it has some applications where the bigger memory might be useful. What do you think about that whitequark?
pie_ has quit [Ping timeout: 245 seconds]
<tpw_rules>
also remember how many times i threatened to change up migen? it might be closer to the time...
<esden>
i now got two boards of revb from tnt so I can make one for me and one for uwe_
<esden>
But I I might get more if there is potential interest
<tpw_rules>
ie now that migen is getting a refresh i can actually define what i want and work on implementing it
<whitequark>
esden: hmmm the problem is FXMA
<whitequark>
with any given design theres about a 80% chance that FXMA will cause a footgun
<whitequark>
i feel uneasy about releasing such hardware
<whitequark>
i am ok with it because i intimately know the tool having designed it, but other people are likely to struggle
<whitequark>
not knowing whether this is the DUT or FXMA
<marcan>
the shifters?
<whitequark>
yes
<marcan>
yeah
<whitequark>
tpw_rules: change up migen?
<marcan>
single port glasgow-lite?
<marcan>
revC I/O buffer, revB FPGA
<whitequark>
marcan: maaaaybe
<whitequark>
that's still kind of expensive
<whitequark>
since the cost of FX2 is not amortized
<marcan>
true
<whitequark>
but yes, this is an option
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<tpw_rules>
whitequark: basically implementing context managers. https://github.com/tpwrules/migen/blob/context-manager/doc/fhdl.rst#context-managers you could also do with If(cond): blah.next = 3 to replace self.sync += If(cond, blah.eq(3)) or so. there's a bit in there about hdl functions which would do AST magic to convert python to a migen object, but i think it was decided that that was gross
<whitequark>
i... still don't really think it's necessary or a good idea
kloppstock_ has quit [Ping timeout: 256 seconds]
<tpw_rules>
oh ok
<whitequark>
it's splitting the language in half (or in three parts) for marginal benefit
<whitequark>
so now you have to learn it three times
<whitequark>
and potentially switch between three syntaxes
<tpw_rules>
oh, so yes my proposal was basically already implemented lol
<tpw_rules>
but should it really be m.next? i would expect fsm.next
<whitequark>
hrm
<whitequark>
good point
<whitequark>
that would solve nested FSMs nicely
<tpw_rules>
also how would i change the next state synchronously? for example in verilog: always @(posedge clk) if (reset) fsm_next <= IDLE else fsm_next <= fsm_Curr
<esden>
whitequark: thanks for explaining. No revb then ;) our of morbid curiosity what is the footgun with the FXMA?
Atlantic778 has joined ##openfpga
<whitequark>
esden: first, it doesn't tolerate pullups
<whitequark>
and pulldowns
<whitequark>
and these are very very common even in interfaces that dont explicitly have pullups
<whitequark>
second, it has an extremely high slew rate
<whitequark>
although this should be fixed with revB, it's been causing lots of glitches with revA
<esden>
Ugh ok that is indeed annoying :/ good to know
Atlantic778 has quit [Ping timeout: 246 seconds]
Atlantic778 has joined ##openfpga
<felix_>
whitequark: for nmigen it might be worth a thought to redesign how the c code for the csr stuff is generated, so that one driver can be written to handle multiple instances of one block without having a huge mess of duplicated code or really ugly hacks around that (i was looking at the HDMI2USB-litex-firmware
jcreus has joined ##openfpga
<felix_>
when i thought about solving that problem; also talked with _florent_, but don;t really remember what the solution we talked about was thb)
<whitequark>
felix_: that's not in scope for nmigen
<whitequark>
i don't really work on misoc at all
<whitequark>
but yes, i agree in general
<whitequark>
the rust codegen already fixes that, actually
<whitequark>
iirc
<felix_>
ah, ok, so the csr stuff was from misoc; i mostly looked at the litex side
<felix_>
i wanted to have a closer look at rust for some time now, but haven't really had the time to do so... maybe that can become a reason for me to try to write some stuff in rust ;)
<whitequark>
yeah
mumptai has joined ##openfpga
dj_pi has quit [Ping timeout: 244 seconds]
Atlantic778 has quit [Ping timeout: 268 seconds]
Atlantic778 has joined ##openfpga
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/fhLwS
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark dd047d5 - Minor typographical improvements.
rohitksingh has quit [Remote host closed the connection]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
cr1901_modern has quit [Ping timeout: 268 seconds]
m_w has joined ##openfpga
jcreus has quit [Ping timeout: 250 seconds]
Atlantic778 has quit [Ping timeout: 250 seconds]
<swetland>
so clifford's talk yesterday? mentioned using the python stuff in nextpnr to specify constraints using attributes attached to entities -- is there any documentation for this or examples? looks quite useful