<q3k>
although i still wanna know a better way than hacking on nextpnr to make it spit out all BELs :P
<q3k>
anyway, PLL on 85k works now ^^
Miyu has quit [Ping timeout: 244 seconds]
<SolraBizna>
my core now hangs the simulator, but works on real hardware
<SolraBizna>
#firstworldproblems
<sorear>
which sim
<TD-Linux>
if I make a basic ecp5 breakout, what would people want on it? ping zkms
azonenberg_work has joined ##openfpga
<sorear>
what are you targeting with "basic"
<TD-Linux>
no pcie or ethernet, mostly my first bga project
<sorear>
i suppose DDR3 is also right out
<TD-Linux>
yeah. I mean you can just get the ecp5 devkit for that
<SolraBizna>
iverilog
<zkms>
TD-Linux: i'm likely getting the ecp5 board that has an 85k-5g and doesnt have ddr3 ram but for a breakout i'd also want the biggest part (iirc 85k 5g) and also enough I/O to connect stuff like USB and also to interface with parts like AD9361, idk what else
<zkms>
(have to go afk to eat ttyl)
<TD-Linux>
hmm yeah the 85k 5g itself is over 50% of the devkit price
unixb0y has quit [Ping timeout: 240 seconds]
<zkms>
idk actually i might not need all the stuff on the 85k 5g but i do want to get at least one board with it
<zkms>
mayb i'll end up fitting my design just fine on a smaller part
<zkms>
idk it's complicated
<TD-Linux>
I might just yolo straight into an actual design
unixb0y has joined ##openfpga
* zkms
afk
lovepon has quit [Ping timeout: 250 seconds]
<SolraBizna>
so, nextpnr and its magical timing-based algorithms
<SolraBizna>
how much of an improvement to max clock speed over arachne-pnr is it reasonable for me to expect?
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tnt>
awygle: I'm looking at the glasgow schematic and ... I can't figure out where the DIRection signal for the sn74lvc1t45 comes from ... am I missing a schematic sheet or something ?
<sorear>
possibly this is one of the not-quite-done parts of revC
<tnt>
Ah yeah might be ... I'm kind of new to kicad so I was wondering if I had missed something somewhere :p
jevinskie has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
jevinskie has quit [Ping timeout: 260 seconds]
jevinskie has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
_whitelogger has joined ##openfpga
lovepon has joined ##openfpga
azonenberg_work has joined ##openfpga
Bike has quit [Quit: Lost terminal]
s_frit has joined ##openfpga
<whitequark>
tnt: yeah, revC is not done at all
<whitequark>
take a look at revB/ schematics
<whitequark>
which is for hardware that actually works
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 245 seconds]
Xark has quit [Ping timeout: 250 seconds]
Xark has joined ##openfpga
lovepon has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
<whitequark>
daveshah: OH GOD I JUST REALIZED
<whitequark>
LATTICE DIAMOND IS CALLED THAT BECAUSE
<whitequark>
DIAMOND LATTICE
m_t has joined ##openfpga
<whitequark>
daveshah: also, I'm messing with timing in Diamond now
<whitequark>
it makes a whole lot of difference to how the design works
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daveshah>
Chances are I'm afraid if messing with timing in Diamond is needed for it to work then it's beyond nextpnr right now
<whitequark>
i'm not sure if it's *needed* per se
<whitequark>
it *affects* things
<daveshah>
Maybe the multiclock stuff coming soon will help
<whitequark>
like, i've never touched timing before in any FPGA toolchain
<whitequark>
this is all new to me
<whitequark>
i mean, --frequency doesn't count
<whitequark>
this is just a single critical path
<daveshah>
Next week nextpnr will support multiple frequency constraints
<daveshah>
Specified by a Python file
<whitequark>
niiiice
<whitequark>
daveshah: so i've been observing interesting behavior where bringing out FSM outputs from the 250 MHz domain to LEDs would sometimes break the FSM
<whitequark>
not sure why
<daveshah>
My guess is that this might pull FSM logic away from the SERDES and closer to the LEDs
<daveshah>
Because the placer aims to minimise wirelength
<whitequark>
with diamond, too
<whitequark>
mhm
<whitequark>
how do I tell the placer to stop doing stupid shit?
<daveshah>
A false path constraint to the LEDs might help a bit
<whitequark>
thanks
<daveshah>
Never done one in Diamond though
<daveshah>
Is this meeting timing even with the LEDs though?
<whitequark>
yes
<whitequark>
but it's broken
<whitequark>
interestingly, the Lattice PCIe example uses 300 MHz constraint for 250 MHz domain
<whitequark>
so I'm wondering if the timing analyzer just ... sucks
<daveshah>
Not beyond the bounds of possibility
<whitequark>
lmao
<daveshah>
I guess there is no domain crossing in this case? Just serdes and state machine
<whitequark>
no domain crossing
<whitequark>
I tried using microscope and all shit broke loose
<whitequark>
probably a bad idea to insert probes into SERDES domain
<whitequark>
pity
<whitequark>
I'll have to make some kinda customized chipscope for this
<daveshah>
I think 250MHz is on the high side for the ECP5
<whitequark>
well I aim for 250 MHz in case I want to do Gen2 someday
<daveshah>
Well, you could in theory have little more than a fabric gearbox in the 250MHz design
<daveshah>
Then 32 bit logic at 125MHz
<whitequark>
mhmmmm
<whitequark>
possible, i guess
<daveshah>
I think this is what pcsclkdiv is for
<whitequark>
oh, a synchronous gearbox?
<whitequark>
that's interesting
<whitequark>
that would definitely be very compact
<daveshah>
It might be something to think about
<whitequark>
problem is, i kind of detest writing state machines for multiword input data
<whitequark>
writing them to work symbol by symbol is bad enough
<whitequark>
... that said.
<daveshah>
I've had fun like this with MIPI in the past, I can agree
<whitequark>
32-bit logic would make it *very* convenient to process TLPs
<whitequark>
since everything is dword-aligned
<whitequark>
so I might want to do it anyway?..
grummel_ has joined ##openfpga
<whitequark>
then on Gen1 I'd be at 62.5 MHz which is just phew
<whitequark>
could probably meet it at HX8K :D
<daveshah>
Yeap
<whitequark>
hm, let me fuck around with timing here a bit more and i'll think
<whitequark>
ah, i think the gearbox would have to implement symbol slip
<daveshah>
The other thing to try is floorplanning
<whitequark>
which could make timing worse
<daveshah>
Yes
<daveshah>
Hmm
<whitequark>
symbol slip is just a mux but it's kinda wide here
<whitequark>
however
<daveshah>
You could do it in your slow domain though?
<whitequark>
i *could* hack bitslip to do symbol slip inside the SERDES
<whitequark>
mhm
<daveshah>
That's what I would do
<whitequark>
that's kind of annoying too
<whitequark>
like I need to ummm
<whitequark>
have two 32-bit words and mux into one of 4 positions, right?
<whitequark>
and shift by 32 bits each time
<daveshah>
Yes
<daveshah>
But at the slow speed that's much easier
<whitequark>
I guess that's more predictable than hacking SERDES bitslip code
<daveshah>
And you can register before and after it presumably
<whitequark>
sure
<daveshah>
I guess latency isn't super critical
<whitequark>
it isn't
<daveshah>
You're not doing high frequency trading, I guess, lol
<whitequark>
no, fuck that
<whitequark>
if my core is unsuitable for HFT that is a *feature*
<daveshah>
+1
grummel_ has quit [Remote host closed the connection]
grummel_ has joined ##openfpga
grummel has quit [Quit: WeeChat 2.0.1]
grummel_ is now known as grummel
* whitequark
sighs
<whitequark>
ok, let's do a gearbox.
<whitequark>
i figure better do this now until i invest too much into a nonviable design
<q3k>
heh, i was wondering why my PLL output on the UL3S was absolute trash
<q3k>
then it turns out I was measuring the pin next to the one i should've
<q3k>
at 100MHz they just happen to couple quite well :P
rohitksingh has joined ##openfpga
<whitequark>
been there
edmund_ has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined ##openfpga
<daveshah>
q3k: lol
<daveshah>
just managed to plug my 19V TX2 supply into my Versa board
<daveshah>
luckily, it seems to have survived
<daveshah>
whitequark: serdes clocking fixes are pushed
<daveshah>
I am seeing the state machine on the TX2 work sometimes, but more intermittently than Diamond
<daveshah>
so timing is still not good
<whitequark>
daveshah: versa has fairly wide input voltage range
<whitequark>
what i dont like aobut it
<whitequark>
is how it shorts external supply to pcie 12V
<daveshah>
yes, I noticed that
<daveshah>
have been quite careful about that
<whitequark>
its not even documented
<daveshah>
whitequark: added better timing data for the DCU to nextpnr now, so the placer will at least try and optimise logic around it (paths to and from the DCU weren't being treated properly before)
<daveshah>
it does seem to be working a bit better
<daveshah>
that might just be random luck of course
<whitequark>
nice
<whitequark>
lemme enable the gearbox
<whitequark>
then switch back to nextpnr
<whitequark>
daveshah: hm
<whitequark>
do you understand how full/half clocks work?
<daveshah>
no, haven't looked at fast clocks
<daveshah>
*half clocks
<whitequark>
...
<whitequark>
their docs have full_clk and half_clk swapped in one place
<whitequark>
god fucking damn it
<whitequark>
the SERDES technote is *really* bad on typos
<daveshah>
They are all too common in Lattice docs
<daveshah>
They managed to put the totally wrong I2C register set for the UltraPlus in their hard ip docs
<whitequark>
aaaaaa
<azonenberg_work>
daveshah, whitequark: my rule is, you dont truly understand a system until you've found errors in the documentation
<whitequark>
i understand everything
<whitequark>
i found multiple errors in the pcie spec already
<azonenberg_work>
i'm personally responsible for at least half a dozen minor revs of the slg46620 datasheet :p
<whitequark>
lol
<azonenberg_work>
and one of UG380
<azonenberg_work>
(although they did fit some other edits into that release, unlike the silego ones which were all issues i had reported)
<whitequark>
daveshah: added 1:2 gearing on SERDES side
<whitequark>
cany'all suggest me a way to do further 2:4 gearing?
<whitequark>
i need a half rate clock made from pcie clock
<whitequark>
ideally, this clock would be phase aligned with the pcie recovered data clock
<whitequark>
i need a pll for that right?
<whitequark>
daveshah: or does lattice have some kinda feature for it?
<azonenberg_work>
you can clock divide with a TFF if you dont need phase alignment
<whitequark>
sure
<whitequark>
but i want the gearbox to be synchronous
<azonenberg_work>
but if you do, a pll is probably the way to go
<whitequark>
so, no additional FIFO
<whitequark>
this seems more elegant
<whitequark>
that said, doing it with a FIFO is more portable
<whitequark>
azonenberg_work: idea
<whitequark>
I could write the gearbox as synchronous and then just stick a FIFO in front of it if I don't have a PLL
<whitequark>
same codebase though
<whitequark>
so, all the action happens on the high side, it just commits a packet once per cycle
rohitksingh has quit [Ping timeout: 252 seconds]
<cr1901_modern>
azonenberg_work: Heh, it's been a while since I've heard someone actually qualify FF with a type ("TFF")
<cr1901_modern>
I don't remember what they do offhand, other than JK is "universal"
<sorear>
whitequark: does supporting x2/x4 later (and needing to bring all RX data into a single clock domain) put any constraints here?
<whitequark>
sorear: not really
<whitequark>
not afaik
<daveshah>
whitequark: I think PCSCLKDIV is intended for this
<sorear>
mostly I'm just not sure why anyone ever used types other than D
<daveshah>
whitequark: TN1263
<daveshah>
page 8
<whitequark>
thanks!
<qu1j0t3>
sorear: perhaps to save an IC or two in glue logic, which used to matter a great deal
<qu1j0t3>
(both in cost and board space)
<daveshah>
imo JK and T flipflops are mostly found in outdated university courses
<sorear>
the last time I saw them was in a radio shack catalog
<cr1901_modern>
Maybe I'm just starting to get old then...
<daveshah>
I've seen some horrible things at uni because we went from JK and T flipflops and SR latches to FPGA design in the Quartus schematic editor
<daveshah>
I saw someone make D flipflop
<daveshah>
from a SR latch out of NAND gates
<daveshah>
and an edge detector with an AND and invertor
<daveshah>
I think it just broke Quartus's synthesis
<cr1901_modern>
do you mean a D-La- oh god...
<qu1j0t3>
daveshah: :D
<qu1j0t3>
daveshah: Yeah it's important to learn the standard library...
<daveshah>
I'd personally say uni courses should start with only DFFs and one clock
<daveshah>
it's much more useful for digital stuff today
<daveshah>
later on multi-clock and async stuff an be brought in
<daveshah>
otherwise everyone is confused once they start on FPGAs
Bike has joined ##openfpga
<sorear>
i kind of want there to be a characterization of the glitch behavior of at least one common fpga and decent async tooling
<daveshah>
Async stuff on the ice40 would be fun for crazy low power
<daveshah>
But the lack of latches make it a bit harder
ZipCPU has quit [Ping timeout: 246 seconds]
ZipCPU has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: No Ping reply in 180 seconds.]
rohitksingh has joined ##openfpga
Bike has quit [Quit: Lost terminal]
m_t has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 244 seconds]
<tnt>
whitequark: The revB gerbers for the gnd plane look a bit funny under the fx2, looks like the vias have thermals and the isolation on them made most of them unconnected to anything.
<SolraBizna>
now that I put all that back, it crashes
<whitequark>
crashes in nextpnr are usually fixed in <1 day
<whitequark>
sometimes <1 hour
<daveshah>
yes, please file a gh issue or post your code SolraBizna
<SolraBizna>
k
<whitequark>
daveshah: what do you think i should do...
<SolraBizna>
if I'm serious about open source development I need to get used to posting my own code, even when it's awful code :P
<whitequark>
a) should i make a generalized FSM unroller that takes an FSM working on single symbols and unrolls it into a pipelined FSM that works on a stream of data
<whitequark>
b) should i just gearbox to 32-bit and hardcode everything like that
<whitequark>
(b) is definitely easier to start with, but
<whitequark>
i feel like (a) would be immensely useful in general and moreover once you go *anywhere* beyond gen1 x1 you need (a) anyway
<whitequark>
well either that or you get some nightmarish spaghetti
<whitequark>
ok, there's an option (c)
<daveshah>
(a) sounds like a lot of fun too
<daveshah>
imo
<whitequark>
(c) is to add a thicc FIFO in front of the DLLP parser
<whitequark>
and use the pcie credit mechanism
<whitequark>
i started thinking about (a) because in pcie, you can get a DLLP immediately followed by TLP
<whitequark>
and they do not have to be lane aligned
<daveshah>
Yeah, I'm liking (a), it seems like a good way of dealing with something like this
lovepon has joined ##openfpga
<daveshah>
Could be quite useful for other protocols too if done in a generic way
<whitequark>
the idea is to make it totally generic but i'm not yet sure how to actually do that
<whitequark>
i'm thinking, you need some way to store internal state, and...
<whitequark>
hm
<whitequark>
this is actually really similar to what the migen FSM *already* does
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SolraBizna>
okay, I filed an issue
<SolraBizna>
now the whole world can see the answer to the question "what if you tried to make an RV32I whose bus characteristics were as much like a 6502 as possible?"
<SolraBizna>
well, except that it's a 32-bit data bus and not an 8-bit one
mumptai has joined ##openfpga
edmund_ has quit [Quit: Ex-Chat]
jevinskie has joined ##openfpga
<SolraBizna>
is there a good way to untangle which part(s) of my Verilog source correspond to yosys's autogenerated net names?
<SolraBizna>
nextpnr gives me some tantalizing info that I should be able to use to *massively* improve my Fmax, but I only recognize one or two of the nets in this critical path report
<azonenberg_work>
whitequark: i've done fun stuff like that too
Bike has joined ##openfpga
Patater_ has joined ##openfpga
Patater_ has quit [Quit: Explodes into a thousand pieces]
Patater_ has joined ##openfpga
<SolraBizna>
whitequark: ≈20 minutes to a clear response telling me what to do to fix my code, and ≈1 hour to eddiehung making a PR that turns the crash into a friendly error message
<SolraBizna>
I am convinced :P
azonenberg_work has quit [Ping timeout: 246 seconds]
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 240 seconds]
<fseidel>
any of you guys ever experienced "Two or more logical RAMs use the same name" in Quartus?
<fseidel>
there's 0 useful info on this error online, and it only seems to happen when I have signaltap enabled
<fseidel>
seems to go away when I do a full compile instead of a quick compile o.O
_whitelogger has joined ##openfpga
<azonenberg_work>
SolraBizna: re yosys net name preservation
<azonenberg_work>
this is a bi priority for me to make tools more usable
<azonenberg_work>
but i havent had time to work on it
<azonenberg_work>
big*
mumptai has quit [Quit: Verlassend]
<SolraBizna>
ah
<azonenberg_work>
i think abc is the big offender here
<daveshah>
azonenberg_work: Clifford's comments in the past haven't been optimistic
<daveshah>
It seems the way abc is structured makes this hard
<azonenberg_work>
daveshah: i was going to sidestep abc entirely
<daveshah>
Because it tends to rip out everything and effectively replace it with new but equivalent logic
<daveshah>
That would be the only option
<azonenberg_work>
no i meant
<azonenberg_work>
you know the inputs and outputs to the subgraph
<azonenberg_work>
preserve those names
<azonenberg_work>
then work your way through ff by ff, since abc doesn't (i think) do retiming
<azonenberg_work>
so every ff should be a 1:1 correspondence
<azonenberg_work>
the alternative would be to remove abc and write a new tool that preserves names from the start, but thats a lot more work
<azonenberg_work>
might be the better long term option though
<azonenberg_work>
In terms of not producing optimized but undebuggable spaghetti netlists
<daveshah>
abc can do retiming
<daveshah>
I don't think it's the default at the moment
<azonenberg_work>
yeah exactly
<daveshah>
But I believe this may change eventually
<azonenberg_work>
personally i dont like retiming to be automatic
<azonenberg_work>
i want to request retiming on specific blocks of logic
<azonenberg_work>
but normally if there are bottlenecks in my pipeline i *want* to fail timing
<azonenberg_work>
so i know what to fix
<azonenberg_work>
finding the true source of timing problems in retimed netlists is almost impossible
<daveshah>
Yeah, I'm not exactly sure where we will go with this
gruetzkopf has joined ##openfpga
<SolraBizna>
meanwhile, I can guess a lot based on the few names that are intact in this report
gruetzkopf has quit [Read error: Connection reset by peer]
<SolraBizna>
and I knew the real problem going in: trying to do a whole RV32I with single-cycle latency and no waits
<azonenberg_work>
lol
<azonenberg_work>
and no pipelining? :p
<SolraBizna>
yup
<SolraBizna>
I'm honestly pleasantly surprised that it's stable at 8MHz
<SolraBizna>
It's replacing a ~6-8MHz 65816, so technically that makes it strictly faster already
Bob_Dole has quit [Read error: Connection reset by peer]