<_whitenotifier>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjvb1
indefini[m] has quit [Remote host closed the connection]
thehurley3[m] has quit [Remote host closed the connection]
galv[m] has quit [Remote host closed the connection]
jfng has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
nrossi has quit [Remote host closed the connection]
swedishhat[m] has quit [Remote host closed the connection]
GenTooMan has joined ##openfpga
nrossi has joined ##openfpga
<_whitenotifier>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjvbd
<whitequark>
daveshah (and everyone else who's around): any thoughts on the most reasonable way to satisfy timings when interfacing to an FX2 from iCE40?
<whitequark>
i'm already using SB_GB_IO and registered I/O pins but there are clearly some timing violations, visible as a kind of visual snow
<whitequark>
in my RGB capture applet
gsi_ has joined ##openfpga
gsi__ has quit [Ping timeout: 272 seconds]
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjvNI
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark 43e6ffa - target.hardware: fix system clock constraint.
<daveshah>
Mainline VexRiscv has a simple software refilled TLB type MMU
<daveshah>
Antmicro added a fixed kernel mapping as well
<guan>
awesome
<daveshah>
Subsequently there has been work on a hardware-refilled MMU
<daveshah>
but I haven't tried that with Linux yet
<sorear>
very exciting btw
<Flea86>
daveshah: What?!! you got your HDL tools running on an FPGA? :D
<daveshah>
yes
<Flea86>
Very cool!
<daveshah>
Yosys & nextpnr running on an ECP5 building and programming a bitstream for an iCE40
<daveshah>
The ECP5 tools can run on an ECP5 too, but it starts to get very slow
<Flea86>
I suppose there is no advantage of a c -> verilog translator to get the speed up?
<sorear>
unfortunately no ice40 boards with 128+ MB
<daveshah>
Synthesis is much too complex for any real advantage from HLS compared to general-purpose compute
<daveshah>
There are parts of pnr that could probably be sped up in gateware
<Flea86>
I see
rohitksingh has quit [Ping timeout: 255 seconds]
<felix_>
wow, this is awesome. great work!
<sorear>
would or1k have worked for this?
<daveshah>
Yes, it would have too
<daveshah>
although the earlier or1k demo didn't have enough RAM or any mass storage options
<daveshah>
swapping out the vexriscv for or1k now should actually be fairly easy, as litex has an or1k
<daveshah>
would be the first time nextpnr has been tested with BE, afaik
rohitksingh has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
emeb has joined ##openfpga
X-Scale has joined ##openfpga
<Bob_Dole>
sorear, did you end up looking at that gddr5, to see if my assumption it needed a bit extra for a memory controller but would otherwise lend itself to working on quite a lot of things?
shapr has left ##openfpga ["ERC (IRC client for Emacs 25.3.1)"]
m4ssi has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 250 seconds]
X-Scale` has joined ##openfpga
scrts has joined ##openfpga
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
inoor has joined ##openfpga
gsi__ is now known as gsi_
Asu has joined ##openfpga
Bob_Dole has quit [Ping timeout: 264 seconds]
rohitksingh has quit [Read error: Connection reset by peer]