<tpw_rules>
esden: are all the icebreakers i'm hearing of prereleases? is the jul 1 2019 ship date on crowdsupply still accurate?
<esden>
tpw_rules: all the iCEBreakers that people have in their hands now, are either prototypes, or prep production units from 35C3. The crowd supply rewards will start shipping as soon as we start proucing. All will be documented on twitter and through CS campaign updates.
<tpw_rules>
cool, thanks for the information
<esden>
np ;)
<tpw_rules>
oh blah, i missed out by like 24 hours
soylentyellow_ has quit [Ping timeout: 272 seconds]
lineprinter_ is now known as parport0
rohitksingh has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
rofl_ is now known as jcarpenter2
_whitelogger has joined ##openfpga
<whitequark>
daveshah: so, i made the mffc partitioner
<whitequark>
can yo utake a look
rohitksingh has quit [Ping timeout: 250 seconds]
<daveshah>
whitequark: sure
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has joined ##openfpga
<daveshah>
All looks reasonable to me
<whitequark>
thanks
<whitequark>
it's really impressive how i spent like 6 days completely stuck on it and all it took was 50mg of L-DOPA to finish all t he MFFC stuff in maybe a hour
<Flea86>
whitequark: Neat, 1980's stimulus of choice for devs used to be diet coke :D
<_whitenotifier-e>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fhnoG
C_Elegans has joined ##openfpga
C_Elegans has quit [Ping timeout: 268 seconds]
octycs has quit [Ping timeout: 250 seconds]
octycs has joined ##openfpga
C_Elegans has joined ##openfpga
C_Elegans has quit [Ping timeout: 250 seconds]
rohitksingh 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
rohitksingh has quit [Ping timeout: 245 seconds]
octycs has quit [Ping timeout: 250 seconds]
Miyu has joined ##openfpga
C_Elegans has joined ##openfpga
Bike has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
octycs has joined ##openfpga
<kbeckmann>
migen question: I'm using tristate signals using TSTriple which works great on hardware. But when I'm building my testbench i get "Could not lower all specials"... Not sure what that means and how to solve it. Any hint on what it means?
<whitequark>
it means that the simulator does not have high-Z support
<whitequark>
so, you avoid having any "triple.get_tristate" statements for simulation
<adamgreig>
marcan: i was wondering on glasgow rev c how the lvds signals are meant to work given the ice40's need(?) for external resistors as i understand it (i.e. lattice TN1253)
<whitequark>
adamgreig: you are supposed to construct this network externally
<adamgreig>
i.e. after the connector on glasgow?
<adamgreig>
fair enough
<whitequark>
since there is no single standard we can choose, nor there is an easy way to make it reconfigurable
<whitequark>
and by easy i mean viable at all
<adamgreig>
yes it's a pain huh
<adamgreig>
thanks for fixing the read-only memory bug in nmigen btw, my 10/100 MAC is now fully functioning in nmigen
<whitequark>
niiiice
<C_Elegans>
adamgreig: what did you use as a testbench for your MAC?
<adamgreig>
C_Elegans: i have just written a bunch of tests for it in nmigen
<adamgreig>
generating rmii isn't too bad
<adamgreig>
(also then plugged it into my lan :p)
<C_Elegans>
Ah ok. Trying to get the PHY on the ECP5 versa to do *something*. The rmii I'm sending it looks right, it just doesn't do anything
<adamgreig>
does the phy establish link?
<C_Elegans>
yeah it looks like it goes through autonegotiation
<adamgreig>
do you have an mdio interface to talk to the phy?
<C_Elegans>
Not yet, it looked on the datasheet like it should work without it, I guess not though.
<adamgreig>
most phys should -- my one i'm only reading to get link status, i don't actually need to set any control registers
<adamgreig>
but at least it means i can read the status register to check it's got a link, what the link speed is, that sort of faff
<adamgreig>
what phy is it?
<C_Elegans>
Marvell 88e1512
<adamgreig>
ah, gigabit
<adamgreig>
idk how you tell it to use rmii 100mbps only, if that's what you're trying to do
<C_Elegans>
From the datasheet, it seemed like all you needed to do was give it a lower clock speed.
<C_Elegans>
Maybe I do need to configure the phy
<adamgreig>
can it even do rmii?
<C_Elegans>
rmii is 2 bits per direction right? On the low speeds it says it takes 4 bits per clock, but it doesnt transfer data on both edges. I think it also does the rgmii multiplexing of en and err on the control lines at low speeds
<adamgreig>
as far as I can tell you still have to do RGMII yourself, just the RGMII clock is lower in 100Mbps mode
<adamgreig>
but slow RGMII isn't the same as RMII
<C_Elegans>
Ok, I see
<C_Elegans>
thanks!
<C_Elegans>
It works! Evidently you can't just slow the clock on this IC
<tnt>
whitequark: Oh, I think I understand why you're seeing increased latency. It's not only the change of rising edge to falling edge + internal re-register. This should have kept the latency the same. But there is also the change to using sb_gb_io. Previously the longer path from the clock pad to the actual IO register means you probably were capturing the data that the FX2 had outputted on that very same edge that triggered the capture ...
<SolraBizna>
if I've got some black box logic, is there a best way to go from "here is an exhaustive list of which outputs happen for which valid inputs" and "here is the simplest logic for the black box"
<azonenberg>
SolraBizna: exhaustive list of outputs basically just means bruteforcing the inputs
<azonenberg>
a sat solver can use some tricks to find ONE set of inputs for an output, if possible
<tnt>
SolraBizna: I use espresso for that
<whitequark>
tnt: hm, I might be just wrong, period
<whitequark>
let me check
<azonenberg>
for simplest logic, that's logic minimization
<whitequark>
again that is
<tnt>
SolraBizna: https://pyeda.readthedocs.io/en/latest/2llm.html I feed a truth table in input (including possible 'don't care' as possible output). And it provides me expression to generate that. Then I give those expressions to yosys and it finds lut4 that do that.
<SolraBizna>
where can I find espresso?
<whitequark>
tnt: yeah, so
<whitequark>
whatever the reason, if I do not add the register, selftest passes
<whitequark>
if I add the register, selftest fails
<SolraBizna>
I'm specifically trying to recreate the W65C02S's decimal subtract-with-carry logic
<tnt>
whitequark: yeah I think it makes sense now that I think about it. And if you add the register but go back to sb_io + sb_gb, then self-test should pass too.
<whitequark>
should fail?
<SolraBizna>
is PyEDA going to freak out and produce something overly complicated because there's at least one adder in the mix?
<tnt>
whitequark: wait no, sorry forget what I said.
<tnt>
(just the sentence above, my earlier statement is correct :p)
<tnt>
SolraBizna: huh ... yeah probably :/
<tnt>
SolraBizna: technically the result will be correct but yosys won't re-extract carry chain logic from the result I think.
<SolraBizna>
the target is C++, fortunately(?), not an HDL
<tnt>
Ah ... well, it will work and find correct logic. Just maybe there would be an easier way using '+' instead of only & and | operators.
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` has joined ##openfpga
<tnt>
whitequark: I'm reading the FX2 docs now ... but given that if you want proper rising edge io register for both input and output you would always have minimum 2 cycles of latency, then the current state with your latest commit might be the only way.
<SolraBizna>
maybe I'll be able to extract the adder part by eye
<sorear>
did anyone ever bother to document the decimal arithmetic, or are you testing a real 6502?
<SolraBizna>
I've exhaustively tested a real W65C02S
<SolraBizna>
Lots of people have documented the decimal arithmetic of various '02s, and none of them matches what I'm actually getting from this chip
<tnt>
Wasn't the 6502 complete reversed at a transistor level ?
<SolraBizna>
yes, but unfortunately, the W65C02 contains lots of fixes to BCD arithmetic
<SolraBizna>
(by "exhaustively tested" I mean "I literally have a giant table of the output of every possible combination of input operands and carry flag")
<whitequark>
tnt: hmmm
<sorear>
SolraBizna: if you post the table somewhere someone might be bored enough to look
<sorear>
there are only a couple ways that make sense, and the logic almost surely works on nibbles separately
C_Elegans has joined ##openfpga
<SolraBizna>
turning it into something readable now
<C_Elegans>
adamgreig: sorry, I disconnected without realizing. I put it into gigabit mode and it worked on the first try
<adamgreig>
ah, nice :P
X-Scale` is now known as X-Scale
<C_Elegans>
Nice to finally exit FPGA hell
<SolraBizna>
making this an HTML table was a bad idea :D
<sorear>
this person claims to have fully determined the logic used on the 6502, 65C02, and 65816 (all different)
<SolraBizna>
ah... I used that to implement ADC, but stopped reading before I got to the SBC part (and assumed, back then, that `SBC x` was always the same as `ADC x` with all bits in x flipped)
<sorear>
that wouldn't even be correct for the documented cases
<sorear>
you'd have to generate a nines complement somehow
<SolraBizna>
it was, indeed, incorrect nearly all the time in decimal mode
<sorear>
say what you will about Intel but their current programming manual has pseudocode for AA* and DA* covering all possible cases
<_whitenotifier-e>
[Glasgow] whitequark commented on issue #81: Verify jtag-mips functionality after 1f6a5041 - https://git.io/fhnyB