dh73 has quit [Ping timeout: 260 seconds]
genii has quit [Remote host closed the connection]
lutsabound has quit [Quit: Connection closed for inactivity]
Bike has quit [Quit: Lost terminal]
emeb_mac has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
Thorn has joined ##openfpga
Zorix has quit [Ping timeout: 264 seconds]
pie_ has quit [Ping timeout: 252 seconds]
Zorix has joined ##openfpga
bluezinc has quit [Quit: Do not go gentle into that good night.]
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
Asu has joined ##openfpga
Jybz has joined ##openfpga
pie_ has joined ##openfpga
freemint has quit [Remote host closed the connection]
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
Mimoja has joined ##openfpga
Asu has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined ##openfpga
genii has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
emeb has joined ##openfpga
Asu has joined ##openfpga
freemint has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
freemint has quit [Ping timeout: 250 seconds]
mumptai has joined ##openfpga
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
Asu` has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 244 seconds]
pie_ has quit [Ping timeout: 252 seconds]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
<freemint> The https://github.com/j-core/j-core-ice40 Ice40 release is out there !! (If you have not noticed yet)
<freemint> Wrong channel - sorry still interesting for you i guess
emeb_mac has joined ##openfpga
<tnt> size / fmax ?
<freemint> I am not involved with this port. I di not know. Should i ping you when i learn more?
<freemint> (I am just an "user" as in that i port some software to the J2 a larger version of this core on a LX9)
<tnt> sure
<sorear> freemint: on topic imo. awesome
<sorear> Now we just need to get it working with free tools ;)
<TD-Linux> yeah it's all vhdl so...
<ZirconiumX> So GHDL should work as a Yosys front-end
<sorear> landley wants to use nvc
<sorear> I don’t really care except that I really want vhdl and mixed language projects to work seamlessly
<freemint> https://github.com/j-core/j-core-ice40/blob/master/ghdl.sh there seems to be some ghdl support but i have no idea what that means for Yosys
<ZirconiumX> There's a GHDL-based frontend for Yosys
<ZirconiumX> pepijndevos wrote an article about it
<freemint> Are there some other questions the community is curious about, other than size/fmax?
<sorear> well I asked if they’ve finally released the MMU, doesn’t seem like it
<ZirconiumX> The SH2 was MMUless
<ZirconiumX> You'd need to go up to SH3 for that
<ZirconiumX> It's a shame; J4 would be a good core for Dreamcast emulation
<sorear> j2 is no longer a sh2 clone
<freemint> J4 probably not perfect for dreamcast emu because timing differences?
<ZirconiumX> Software dreamcast emulators play fast and loose with the timings
<ZirconiumX> Even known-wrong but consistent timings are probably good compared to software
<freemint> Did the dreamcast have one or two SH4s?
<ZirconiumX> One
<TD-Linux> I don't think sh3/4 are old enough for all patents to have expired yet
<ZirconiumX> The Naomi 2 had two
<ZirconiumX> I lie: it had one SH4 and two PVR2s
<freemint> The J-core site things they are expired: The sh4 processor (dreamcast) has an mmu, but the last sh4 patents don't exire until 2016.
<TD-Linux> oh nice
<freemint> god this site is so old but things seem to be moving in a good direction slowly.
<sorear> There is no plan to implement a sh4-compatible MMU design because it interacts inefficiently with Linux
<sorear> the current j-core MMU, as described, is rather different with hardware page tables
<sorear> also the successor is “j32” last I heard due to a trademark scare
<freemint> tnt i have not have an answer yet but i found a commit to make it work with some ICE40 UP5k
<ZirconiumX> WinCE made the SH4 MMU work, I think
<tnt> I saw it has a script to build it for the upduino, but I don't really want to install ghdl just to check hat.
<ZirconiumX> But I think it's a soft MMU?
<ZirconiumX> As in, refill in software, like early MIPS
<sorear> yes, that’s the issue
<sorear> they don’t like the i-cache pollution on every page fault
<freemint> from what i heard it targets the upduino v2.0
<freemint> so yeah the ghdl_up5k.sh does not work currently. I see if i can get them to fix it?
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
<freemint> How many gates/what clock is the most that people got out of an ICE40 for a 32bit processor?
<tnt> I got picrorv32 in ~ 1500 LCs running at 30 MHz on a UP5k
Jybz has quit [Quit: Konversation terminated!]
<freemint> I found 40 MHz for a "ZipCPU" but nothing for hardware resources.
<ZipCPU> That's because "it depends"
<ZipCPU> It depends upon how much of the CPU you enable.
<ZipCPU> If you turn the cache on, as an example, you'll overload the iCE40
<sorear> with a skewed pipeline you can, in principle, have a cycle time that does not depend on width
<ZipCPU> freemint: For an ice40, I typically get about 50MHz for an 8kHX, and about half that for the LX
<ZipCPU> Those numbers were also measured before NextPNR, so you might be able to do faster
<freemint> Oh Hi
<ZipCPU> I love the way IRC works on the "Speak of the devil" principle :D
Bike has joined ##openfpga
<freemint> Anyway. That release is not the "state of the art" of J-Core and there might be an burst of activity in the next week.
<freemint> tnt i could not get your numbers yet and have to fetch some sleep when i hear something i tell you.
<sorear> freemint: yay, a timeline
<ZirconiumX> So, since I'm a little out of the loop regarding Lattice chips: the LP is low-power, the HX is high-performance. Where does the UP come into this?
<ZipCPU> The UP has fewer LUTs, but supports DSPs
<tnt> it's Ultra Low Power.
<ZipCPU> So where you can get an 8k LUTs in HX, the UP only has about 5k LUTs
<sorear> UP is even lower power and slower than LP, but also has special features
<tnt> I'm not sure if it's actually slower than LP or just better process.
<ZirconiumX> I'm guessing the DSPs help with Fmax despite being slower, due to needing less logic for things like adders
<ZirconiumX> ?
<tnt> sorear: yeah, it has DSPs, it also has HW blocks for I2C / SPI and also a pretty nice 1 Mbits of SPRAM.
<sorear> tnt: I’ve read all of the Lattice documents and am not the person asking questions today
<sorear> You wanted ZirconiumX
<ZirconiumX> :P
<freemint> tnt There will be more elaborate testing soonish but here is what he thought: But quickly and IIRC, lattice timing closure says it will do about 20MHz in ICE40 UP5k, but the UP5k internal clock is 48MHz. You therefore basically have to run /4 = 12MHz unless an external clock is provided, or some dodgy tricks with the PLL are tried.
<tnt> "dodgy tricks" ... it's a PLL, it's _designed_ to generate a frequency from another :)
Asu has quit [Quit: Konversation terminated!]
<freemint> So there core is not optimal yet but it is really just a J2 core with somethings teared out to make room. A new design which targets these smaller processor already has a name. It is going to be called "J0" but i am blissfully unaware how far the progress is on that.
<GenTooMan> <opinion>Side note I am not a fan of the ice40 PLL so dodgy is somewhat accurate too me</opinion>
<freemint> ( I think the name should be J-0.5 so that there is room in the name space for getting bigger or smaller but hey not my beer)
<sorear> ugh, more secret things
<sorear> well clearly j-1 is smaller than j0 and j1
<freemint> oh true ... so J0.5 it is then
emeb has quit [Quit: Leaving.]
<emeb_mac> GenTooMan: What's wrong with ice40 pll? I've found it to be reasonably stable when used carefully - ie make sure the PCB design provides proper bypass and that the reference is also stable.
<emeb_mac> note that the on-chip 48MHz osc is *not* particularly stable, so if you try to drive the PLL from that you'll get equally bad results.