clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
FL4SHK has quit [Quit: WeeChat 2.4]
FL4SHK has joined #yosys
pie__ has quit [Ping timeout: 244 seconds]
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 246 seconds]
emeb_mac has joined #yosys
<corecode> wow, on the ecp5 my cpu also only does 44MHz
<corecode> i guess i have a shit design
<sorear> what are you comparing to? what's your goal?
<corecode> comparing to u4k
<corecode> where i get 29MHz
<corecode> sorear: my goal is to improve my design :)
<sorear> rough specs ? critical path ?
<corecode> seems to be related to instruction fetch going through some MUXes
emeb has quit [Quit: Leaving.]
_whitelogger has joined #yosys
<emeb_mac> corecode: have you tried checking the max freq of your CPU design using icecube?
<emeb_mac> (just for comparison to FOSS tools)
rohitksingh_work has joined #yosys
mirage335 has quit [Ping timeout: 245 seconds]
mirage335 has joined #yosys
leviathanch has joined #yosys
emeb_mac has quit [Ping timeout: 272 seconds]
leviathanch has quit [Remote host closed the connection]
pie__ has joined #yosys
m4ssi has joined #yosys
<daveshah> corecode: switching to the faster ECP5 (normal -8 speed grade or 5G variant) should make a big difference
<daveshah> The tools for the ECP5 aren't as optimised yet either
leviathanch has joined #yosys
citypw has joined #yosys
<sxpert> daveshah: ok. manage to get the placer to compile. had to redo the CMake
<sxpert> daveshah: ok, it seems to work as advertised. design is even faster than before
<daveshah> Yeah, the new placer does tend to improve ECP5 quality of results
<sxpert> hmm
<sxpert> looks like the generated bitfile doesn't work though
* sxpert tries again
<daveshah> Sounds like something marginal might be going on
<sxpert> ah, getting "2 warnings, 1 error"
<sxpert> ERROR: unsupported frequency unit 'MHZ'
<sxpert> and
<sxpert> Warning: ignoring unsupported LPF command 'BLOCK RESETPATHS'
<sxpert> Warning: ignoring unsupported LPF command 'BLOCK ASYNCPATHS'
<daveshah> The warnings don't matter
<sxpert> the error however ?
<daveshah> The frequency bug was fixed on master but not merged into that branch
<daveshah> Just change MHZ to MHz
* sxpert tries again
<sxpert> tons of "Unmatched LPF" warnings, but I suppose that's because I don't use them
<sxpert> no more errors
<sxpert> lets program the thing in the chip
<sxpert> ok, it now works
<sxpert> does what it should
<sxpert> good
<daveshah> The unmatched warnings are also solved in master
<daveshah> Out of curiosity, what freq are you getting now?
leviathanch has quit [Remote host closed the connection]
<sxpert> hah, looks like we will get rectangles, no more fpga art
<sxpert> Info: Max frequency for clock '$glbnet$clk_25mhz': 70.67 MHz (PASS at 25.00 MHz)
<sxpert> before routing :
<sxpert> Info: Max frequency for clock '$glbnet$clk_25mhz': 40.46 MHz (PASS at 25.00 MHz)
<daveshah> Yeah, the pre routing delay estimates need tuning
<daveshah> 70MHz is pretty good, what was it before
<sxpert> 65 or so
<sxpert> the design seems pretty fast for such a complicated beast
<sxpert> still complains about the rom_data
<sxpert> though
<daveshah> Yeah, part of the problem is just ECP5 BRAMs being fairly slow - combined with such a big RAM being spread all around the chip
<daveshah> The BRAMs on the ECP5-5G parts are about 3x faster than the -6 grade normal past
<daveshah> *parts
<sxpert> am about to add some more, hah !
<sxpert> I have to add 64 BRAMs for the system ram
<daveshah> Unlikely to make the design any slower - each clocked RAM starts a new timing path, so to say
<sxpert> right
<daveshah> It would be interesting to see how making the main ROM smaller changed Fmax
<sxpert> well, the main issue is that the rom jumps to 7xxxx on the 11th instruction ;-)
<daveshah> It doesn't need to work
<daveshah> would just be interesting to see how it changes things...
<sxpert> ah I see
<sxpert> just a compile
<sxpert> I can probably do that
<sxpert> say, 1 bram worth ?
<daveshah> yeah
<sxpert> ok so 1 bram is 16Kb, that's 2**12 nibbles
<sxpert> I have the system ram in, all 64 brams of it
<sxpert> and 1 bram for rom
<sxpert> daveshah: the next thing I want to tackle is the debugger string generation, seems suboptimal, generate ffs instead of brams
<daveshah> sxpert: sure, where is the code for that
<tpb> Title: hp-saturn/saturn_debugger.v at fix_rom_read · sxpert/hp-saturn · GitHub (at github.com)
<sxpert> here
cr1901_modern has quit [Ping timeout: 252 seconds]
<daveshah> sxpert: I'm afraid that's a bit ambitious
cr1901_modern has joined #yosys
<sxpert> ah
<daveshah> an intermediate write data and write enable register would be more likely to work
<sxpert> hah !
<sxpert> so have an 8 bit byte reg, and write to the memory in another domain ?
<daveshah> yeah
<sxpert> with only one rom bram, I get Info: Max frequency for clock '$glbnet$clk_25mhz': 75.16 MHz (PASS at 25.00 MHz)
<daveshah> Is the critical path still the ROM?
* sxpert added the sysram
<sxpert> lessee
<sxpert> daveshah: I get this : https://pastebin.com/sqRb589G
<tpb> Title: Info: Critical path report for clock '$glbnet$clk_25mhz' (posedge -> posedge): - Pastebin.com (at pastebin.com)
<daveshah> Looks like system RAM has taken over now
<sxpert> yeah
<daveshah> (26,82) -> (27,27) is a long wire
<sxpert> I see
<sxpert> guess I could use some registers or something
<daveshah> yeah
<sxpert> on reading and writing
<sxpert> for the rom, I pre-read on phase 0, then dump that on phase 1 to the bus
<sxpert> guess I could do the same for the ram
<corecode> ah, it was 44 pre route, 61 post route
<corecode> and with -8 68 pre route, 85 post route
<daveshah> that makes much more sense
<daveshah> what if you try a 5g part (--um5g-45k)
<daveshah> they have much faster block RAMs
<corecode> i thought they're all the same die
<corecode> oh yea
<corecode> 120 pre, 120 post
<daveshah> the 5g parts run at 1.2V rather than 1.1V
* sxpert would love an ULX3S++ with an 85FUM5G ;-)
<daveshah> this makes a big difference
<corecode> aha!
<sxpert> 47€ a piece on mouser !
<sxpert> not too bad
<sxpert> the evn board is 86 eur
<daveshah> yeah, the evn board is very good value for money
<daveshah> only problem is it has no external RAM :(
<sxpert> hah
<sxpert> that's a problem
<sxpert> all depends on the system flash though. I could do with the system rom in the flash
m4ssi has quit [Ping timeout: 246 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
<sxpert> daveshah: ok, ram accesses are now pipelined
<sxpert> Info: Max frequency for clock '$glbnet$clk_25mhz': 72.06 MHz (PASS at 25.00 MHz)
<sxpert> rom still shows up as the biggest delay
<sxpert> not a big issue though
<daveshah> what does --um5g-85k give?
<daveshah> I guess this is much faster than a real Saturn?
<sxpert> the real saturn ran at 4MHz
<sxpert> also, I seem to be able to implement things in less cycles than the original
<daveshah> Could you make an upgrade board for calculators with an ECP5 on?
<sxpert> possibly
<daveshah> Might need a bigger battery too
<daveshah> that would be really awesome
<sxpert> yeah
<sxpert> replace those 3x AA with lipo
<sxpert> or was it AAA
<sxpert> yeah, 3x AAA
<sxpert> blast the TIs out the water ;)
<sxpert> the original idea was to build one with a giant led screen
<sxpert> so, with all basic modules setup, am going at 70Mhz or so
<sxpert> (rom, mmio, ram)
AlexDaniel has quit [Ping timeout: 255 seconds]
<sxpert> now, just need to fill in alu based instructions
m4ssi has joined #yosys
rohitksingh has joined #yosys
AlexDaniel has joined #yosys
<sxpert> daveshah: on the um5g-85k part: Info: Max frequency for clock '$glbnet$clk_25mhz': 108.05 MHz (PASS at 25.00 MHz)
<daveshah> Nice
m4ssi has quit [Ping timeout: 245 seconds]
<MoeIcenowy> daveshah: I think a Saturn emulator on ARM920T is faster than real Saturn
<MoeIcenowy> (I have such an emulator
citypw has quit [Ping timeout: 272 seconds]
citypw has joined #yosys
<sxpert> MoeIcenowy: indeed, an emulator on an arm is faster, but it's not the same thing
<sxpert> for instance, you can't do grayscale display
<sxpert> also, that's no fun ;)
<sxpert> the fun part is, I may also implement the instruction added in that emulator ;-)
emeb has joined #yosys
<sxpert> (all those 80Cblah instructions)
m4ssi has joined #yosys
<MoeIcenowy> sxpert: I only bought a 39gs because it's dirty cheap
<MoeIcenowy> sxpert: in fact I wonder why don't they add some "execute raw ARM code" instruction ;-)
<somlo> daveshah: is there a branch on github for the "stable" trellis? (https://twitter.com/fpga_dave/status/1101216373454393349) Do you have version numbers anywhere that I should "bump" (from "0.0") before I open a bugzilla ticket for submitting to Fedora ?
<daveshah> somlo: It's a git tag, 1.0
<somlo> oh, so I'll actually have to clone the repo before I can see it :) Thanks!
<daveshah> You can get it on github too
<tpb> Title: GitHub - SymbiFlow/prjtrellis at 1.0 (at github.com)
m4ssi has quit [Remote host closed the connection]
<sxpert> MoeIcenowy: there is
<sxpert> MoeIcenowy: the main issue with those is that the keyboard is chicklet and pretty bad
rohitksingh has quit [Remote host closed the connection]
mms has joined #yosys
maikmerten has joined #yosys
GuzTech has quit [Remote host closed the connection]
mms is now known as shabgard
<MoeIcenowy> daveshah: BTW why does icestorm have no version number?
<daveshah> idk
<daveshah> getting clifford to do proper releases is always hard
<ZipCPU> ;)
<sxpert> heh
rohitksingh has joined #yosys
danieljabailey has joined #yosys
danieljabailey has quit [K-Lined]
<somlo> fedora review request for trellis: https://bugzilla.redhat.com/show_bug.cgi?id=1689397
<tpb> Title: 1689397 Review Request: trellis - Lattice ECP5 FPGA bitstream creation/analysis/programming tools (at bugzilla.redhat.com)
maikmerten has quit [Remote host closed the connection]
<sorear> gonna try to get that in #fedora-riscv? :D
<somlo> yeah, that's the plan -- find/buy (or, worst case, design/build) a dev board with 2GB RAM and an 85k 5g ECP5 chip, build a rv64gc based SoC that can boot Fedora (similar to lowRISC), then we'd have a self-hosting computer (that can not only rebuild its own kernel, but also its own *hardware*) :)
rohitksingh has quit [Ping timeout: 245 seconds]
AlexDaniel has quit [Remote host closed the connection]
AlexDaniel has joined #yosys
AlexDaniel has quit [Ping timeout: 245 seconds]
<sxpert> somlo: can you self-update the flash and reboot the fpga ?
dys has joined #yosys
dys has quit [Ping timeout: 255 seconds]
dys has joined #yosys
dys has quit [Ping timeout: 245 seconds]
<somlo> sxpert: I think that depends on the particulars of the (at this point, theoretical) development board
shabgard is now known as mms
mms has quit [Quit: Leaving]
tpb has quit [Remote host closed the connection]
tpb has joined #yosys