genii has quit [Quit: Time for beer and hockey.]
azonenberg_work has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
azonenberg_work has joined ##openfpga
<kc8apf> xc7a50t PCIe block supports up to 4 lanes. Is it possible to use them as 2 separate x2 ports?
promach3 has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
nrossi has joined ##openfpga
_whitelogger has joined ##openfpga
<ZombieChicken> Altera Cyclone IV EP4CE40F23 <- has that chip been reverse engineered?
<mwk> no
<ZombieChicken> ty
OmniMancer has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
m4ssi has joined ##openfpga
keesj has quit [Ping timeout: 252 seconds]
Bob_Dole has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 250 seconds]
OmniMancer has joined ##openfpga
keesj has joined ##openfpga
<OmniMancer> daveshah: so it seems the tools show a pip like this: x16y41_e6mid6.x16y42_n2mid6, but when I check what bits this produces it's the same as connecting it to n2beg6 so I am unsure what this is about :/
<daveshah> Very odd
<daveshah> Might just be a wire naming oddity?
<OmniMancer> makes me wonder if there is something weird about the 2 length wires or what
<OmniMancer> it might just have those names mapped to the beginning of the wire regardless?
<OmniMancer> most curious
<OmniMancer> daveshah: there are also some settings that seem to be resilient to fuzzing, but that might be because there are interdependencies :/
zng_ has quit [Quit: ZNC 1.7.2 - https://znc.in]
zng has joined ##openfpga
<OmniMancer> hmmm, perhaps python is not the best language to be parsing huge pnl files with, it takes a long time
<mwk> needs more pypy
<OmniMancer> that would probably work somewhat
emeb has joined ##openfpga
<OmniMancer> What does the extra logic look like for making adders faster?
<mwk> hm?
<mwk> you mean, carry chains?
<OmniMancer> yes
<mwk> well that depends on the FPGA family a lot
<OmniMancer> Ah
<mwk> but the main important part that you should expect is, well, the carry chain
<mwk> and dedicated multiplexers that allow you to propagate the carry quickly across it
<OmniMancer> Do those take the form of extra inputs/outputs on the LUT
<mwk> it's usually a separate circuit after the LUT
<daveshah> For ECP5, there is an extra LUT output used for the carry logic
<mwk> the LUT tells the special MUX whether it should propagate the carry value, or insert a new one
<OmniMancer> and the LUT implements one part of a half adder?
<daveshah> Using the first two LUT inputs and 4 init bits
<daveshah> ie the first LUT2 of the LUT4
<mwk> huh
<OmniMancer> The Anlogic Eagle LSlices seem to be able to implement a 2 bit adder with the two LUT4s that make up the "LUT5"s in the slice
<OmniMancer> from what I can see of how settings affect things it appears that the first two inputs are used for the first two bits
<OmniMancer> the third input is wired to ground
<OmniMancer> oh no I think I have it wrong
<OmniMancer> let me go look at the file again
<daveshah> mwk: they typically connect the LUT MSB input to 1, so effectively end up with a LUT3 and LUT2 but sharing two inputs
<daveshah> So not actually that different to Xilinx, barring the shared inputs and lack of routing of fractured LUT output to fabric
<mwk> right
<sorear> ice40 carry chain is logically before the LUT. details vary widely
<daveshah> Yeah iCE40 is also odd because it's actually the carry part of a full adder rather than something more like lookahead carry
<daveshah> SB actually patented the iCE40 approach - supposedly lower power
emeb has quit [Quit: Leaving.]
emeb has joined ##openfpga
genii has joined ##openfpga
<ZirconiumX> Cyclone V is a bit odd there. They seem to favour a carry-select design
<OmniMancer> The ripple mode bits might take more effort than others since they appear more annoying to cause a difference
emeb_mac has joined ##openfpga
emeb_mac has quit [Client Quit]
Asu has joined ##openfpga
<OmniMancer> The mslices are more amenable to things
<OmniMancer> daveshah: is there any info written down on how the timing info extraction in project trellis work?
<daveshah> No :/
<OmniMancer> So the ripple mode appears to set two bits per LUT4 involved
<daveshah> There are a few slides on timing (36/37) at https://ds0.me/duhde19.pdf for very high level overview
dh73 has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
<OmniMancer> does light dram have a plain SDRAM controller?
<daveshah> Yes, it does, and it is arch independant
_whitenotifier-e has joined ##openfpga
<_whitenotifier-e> [libfx2] jedrzejboczar opened pull request #3: Add support for modifying USB strings during runtime - https://git.io/Je14K
<OmniMancer> I shall have to see if I can get that to go on the Tang board with the embedded SDRAM
<_whitenotifier-e> [libfx2] jedrzejboczar synchronize pull request #3: Add support for modifying USB strings during runtime - https://git.io/Je14K
C_Elegans has joined ##openfpga
<_whitenotifier-e> [libfx2] jedrzejboczar synchronize pull request #3: Add support for modifying USB strings during runtime - https://git.io/Je14K
C_Elegans has quit [Ping timeout: 245 seconds]
dh73 has quit [Read error: Connection reset by peer]
ym has quit [Quit: Leaving]
m4ssi has quit [Remote host closed the connection]
OmniMancer has quit [Quit: Leaving.]
C_Elegans has joined ##openfpga
Asu` has left ##openfpga ["Konversation terminated!"]
<_whitenotifier-e> [libfx2] jedrzejboczar commented on pull request #3: Add support for modifying USB strings during runtime - https://git.io/Je1RK
C_Elegans has quit [Ping timeout: 245 seconds]
<_whitenotifier-e> [libfx2] whitequark commented on pull request #3: Add support for modifying USB strings during runtime - https://git.io/Je1RX
<hackerfoo> Now I just need to add necessary signals that are missing, if any.
Jybz has joined ##openfpga
m4ssi has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
m4ssi has quit [Remote host closed the connection]
m4ssi has joined ##openfpga
m4ssi has quit [Read error: Connection reset by peer]
massi_ has joined ##openfpga
Bob_Dole has joined ##openfpga
genii has quit [Quit: Time for beer and hockey.]
massi_ has quit [Remote host closed the connection]
emeb_mac has joined ##openfpga
<azonenberg> rqou: did you see that github issue re xc2par?
nrossi has quit [Quit: Connection closed for inactivity]
lexano has quit [Ping timeout: 240 seconds]
lexano has joined ##openfpga
<ZirconiumX> ZipCPU: Read your sdspi spec, even if not the actual RTL. It does seem like a very nice interface to use, and I might use it as a reference.
<ZipCPU> ZirconiumX: Let me invite you to do so
<ZipCPU> ... if I haven't already
<ZirconiumX> My signal names are probably going to be different to yours, but it'll be interesting to compare approaches
<ZipCPU> I will need to modify the interface subtly when I create the SDIO version, but I do want to keep the spec's nearly identical
<ZipCPU> If I make any changes, it would be to make the "hidden" register more visible
<ZirconiumX> Something which comes to mind is that your spec should probably have a base address parameter of some kind for wishbone
<ZipCPU> Not at all. That's handled by the interconnect. The core never needs to know its base address.
<ZipCPU> The core only gets two address lines--so the interconnect can place its base address anywhere with the upper bits
<ZirconiumX> Given I'm using a *bus* topology, I have no interconnect, unless nmigen-soc tries to handle it internally.
<whitequark> nmigen-soc has a Decoder, which according to Wishbone terminology is "interconnect"
<ZirconiumX> Right, okay
lexano has quit [Ping timeout: 240 seconds]
lexano has joined ##openfpga
<ZirconiumX> ZipCPU: What happens if you try to read from an empty FIFO in SDSPI?
<ZirconiumX> I can't find mention of it in the spec
emeb has quit [Quit: Leaving.]