futarisIRCcloud has quit [Quit: Connection closed for inactivity]
eightdot has quit [Ping timeout: 250 seconds]
Asu has joined ##openfpga
<_whitenotifier-1>
[Glasgow] whitequark reopened issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjvFD
unixb0y has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 258 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjIsr
wpwrak has quit [Ping timeout: 246 seconds]
wpwrak has joined ##openfpga
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjIGL
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjIGZ
Sprite_tm has joined ##openfpga
<Sprite_tm>
Hi all... Quick (I hope) question: I'm developing using a Yosys/nextpnr/prjtrellis tool suite for the Lattice ECP5 series.
<daveshah>
Hi!
<Sprite_tm>
Now, I've coded up a nice cache for my CPU. Unfortunately, the tools insist on stashing the bits for the cache in standard Trellis flipflops, not in BRAM.
<Sprite_tm>
If I understand corrctly, the tools should be able to infer that stuff can be placed in BRAM and I'm just doing something terribly wrong, right?
<daveshah>
Yes
<whitequark>
what's your verilog?
<Sprite_tm>
Erm, lemme upload it somewhere... sec.
<Sprite_tm>
I can imagine the tag memory and the flags memory don't make it into BRAM, as they're abused a fair bit, but I'd expect at least the main cachedata to end up there... It's a simple 32-bit wide memory, and I only read and write it in clocked blocks...
<Sprite_tm>
Also, I would not be surprised if it's something silly I did... I don't have that much experience with Verilog yet.
Asu has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
<whitequark>
Sprite_tm: that memory has two read and two write ports
<whitequark>
line 150-153 and line 214 are the two write ports
<whitequark>
that's not synthesizable
<Sprite_tm>
Ah, huh, both are clocked by clk and they're not exclusive.
<Sprite_tm>
I thought yosys could figure that out :P
<whitequark>
oh wait
<whitequark>
that IS synthesizable for ECP5
Asu` has joined ##openfpga
<whitequark>
since it has true dual port RAM
<daveshah>
Yosys can't do mixed ports
Asu has quit [Read error: Connection reset by peer]
<Sprite_tm>
mixed ports?
<daveshah>
Ports that both read and write
<Sprite_tm>
Thanks for taking the time to look at this, btw, I do appreciate it.
<Sprite_tm>
FYI: data point: if I comment out the always block around 214, it still doesn't use bram.
<daveshah>
There is also a known bug where memory accesses are deeply embedded in nested `if`s
<Sprite_tm>
Hm, guess I'm better off making the main cache mem its own module... that way I can at least control how it gets synthesized better.
<Sprite_tm>
Thanks you all, this should allow me to continue for now.
Asu` has quit [Quit: Konversation terminated!]
<tnt>
Sprite_tm: tbh in general I always find it better to isolate memories in separate modules. Write it in verilog and see if that works out but at least that make it easy to replace with instanciation for the numerous cases where inferring fails to produce what's needed.
rohitksingh_work has quit [Read error: Connection reset by peer]
<Sprite_tm>
tnt: Yeah, I also came to that realization just now... I have absolutely no way of figuring out (aside from asking the wise people here) of figuring out why it doesn't want to put it in bram... it's easier when it's just in a submodule I'd think.
<whitequark>
Sprite_tm: yosys writes a detailed log file
<whitequark>
that says why noto
<tnt>
Sprite_tm: sometime you can figure it out in the log file.
<Sprite_tm>
Hehe, if you can *find* it :P
<Sprite_tm>
I think I went through the log files, but probably missed the line.
<tnt>
but tbh ... when it fails to do it most of the time I can't finish the synthesis because it crashes with lack of memory trying to create hundreds of thousands of FFs ...
<Sprite_tm>
Yeah, I think having only a small cache saved me there... although I now probably know why synth time went up from one to ten minutes :P
<whitequark>
there should be an option that forbids creation of FF RAM
<Sprite_tm>
Btw, is it possible to pass the file for readmemh to a module in a parameter or something?
<tnt>
yes as a param.
<Sprite_tm>
And you guys said Yosys can't infer ram with two read-write ports yet, right? Should I fall back on instantiating primitives for that?
<cn04_>
daveshah: I heard ecp5-12k has the same die as 25k. Can the extra LUTs past 12k be used by nextpnr/trellis? I saw that there isn’t a separate chipdb for the 12k, so is it basically treated just like it’s a 25k?
<daveshah>
Yes
<daveshah>
You need to add ` --idcode 0x21111043` to ecppack to change the idcode though
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjI0l
<tnt>
mmm, I'm wondering if tinyusb could be made to support my ice40 usb core ....
<cr1901_modern>
mithro and tinyfpga are already porting valentyusb to tinyusb
<tnt>
oki. but not the same core :)
<cr1901_modern>
But since tinyusb's organization is "per-microcontroller-vendor", I'm not sure how they're handling that the core can be used with an arbitrary CPU
<cr1901_modern>
tnt: Anyways, my guess is "probably, but I don't know how to extend tinyusb to be SoC-agnostic for a given USB core"
<cr1901_modern>
I would've rather finished this port by using only hobbyist-accessible hardware, so had I know about iua, I would've likely used that next.
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjI0E
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjI0u
<cr1901_modern>
tnt: >The FIFO turns out to be the hardest part :p
<cr1901_modern>
Referring to a certain bug that was fixed today :P?
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjI0a
mossmann has quit [Read error: Connection reset by peer]
mossmann has joined ##openfpga
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjI0y
<tnt>
(granted written so I could debug my usb core, but it's not the core itself)
<mithro>
tnt: Ahh
<_whitenotifier-1>
[Glasgow] electroniceel opened issue #119: Print IO bank pin mappings on silkscreen - https://git.io/fjI0h
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #119: Print IO bank pin mappings on silkscreen - https://git.io/fjIEJ
<cr1901_modern>
tnt: So it's fast enough to do real time capture?
<cr1901_modern>
iua, that is
<tnt>
cr1901_modern: Well, it doesn't have the bandwidth to stream everything for a 100% occupied bus, but for small transactions / enumerations / ... it works just fine.
<cr1901_modern>
I assume it relies on the idea that USB has a well defined transition rate, so RLL compression gets good results to send 12 megabits of data down a 115200*(8/9) bit pipe
<cr1901_modern>
err (8/10)
<tnt>
I think I set the uart to 1Mbits.
<tnt>
but mostly it relies on massive idle periods :p
<tnt>
and the large buffer of the UP5k.
Asu has quit [Quit: Konversation terminated!]
emeb has joined ##openfpga
Miyu has quit [Read error: Connection reset by peer]
Miyu has joined ##openfpga
Bike has joined ##openfpga
genii has quit [Remote host closed the connection]