<Sprite_tm>
emeb_mac: You could do hardware-acceleration for the sample readout. Make a fixed point DDC for the address, set the start, looppoint and end of the samples, let the DDC read out the memory.
<Sprite_tm>
You should be able to play oldschool modfiles that way. That's what I'm planning for a project.
<Sprite_tm>
By the way: does trellis support multiboot already? I read some things on the Internet stating it was unsupported...
<emeb_mac>
Sprite_tm: that's correct
<emeb_mac>
I already do that on a small scale for the sine waveform in my current oscillator.
<emeb_mac>
My concern about processor loading for larger sample tables is more about table management and looping.
<Sprite_tm>
Welll... if you have lots of main memory, you could also use the sample memory as a multistage FIFO in order to DMA stuff in from main memory. That way, all your samples can stay in main memory, no real management needed.
<Sprite_tm>
Doing something similar for my current video driver; the framebuffer is in main memory which is an external serial PSRAM chip.
<Sprite_tm>
By multistage, I mean divide it into n fifos for n channels :)
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 246 seconds]
<emeb_mac>
Interesting idea
dj_pi has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Ping timeout: 245 seconds]
<Sprite_tm>
I've actually become quite a fan of doing dma tricks like that... especially if you're zealous with caches, you can even use a fairly small memory bandwith (mine atm is 24mbyte/second) to great results.
ym has joined ##openfpga
ZombieChicken has joined ##openfpga
mumptai_ has joined ##openfpga
calle__ has quit [Ping timeout: 244 seconds]
<Xark>
emeb_mac: Thanks! :)
<Xark>
emeb_mac: I was just reading about an easter egg in this BASIC. At D/C/W/M when prompted for memory size, enter "A". :)
<Xark>
Neat. I think I stubled across that in ROM as a kid (dumping it with BASIC or similar), but I didn't know about the "A" trick.
<Xark>
I notice you "patch" BASIC, I hope that includes the "garbage collection bug". When I was a kid, that frustrated me into learning machine/assembly language (so BASIC bug was likely good for my career).
<emeb_mac>
Xark: No - I don't address anything except for the backspace handling in the line input routine. I don't even know about the "garbage collection bug"
<emeb_mac>
Xark: A full-featured monitor would be fun - something with asm/disasm, etc but I've got something in there right now that's better than the original 6-digit Kim-1 thing.
<Xark>
Cool. I have not personally tried CEGMON but has some screen editing for BASIC (and fixed backspace) as well as very minimal monitor and assembler (I believe).
<Xark>
Yeah, the original was pretty damn minimal (as someone "forced" to use it). I would typically "poke" in my code from BASIC (easier to save and edit). :)
ym has quit [Remote host closed the connection]
ZombieChicken has quit [Quit: WeeChat 2.5]
<tnt>
emeb_mac: the 4 bit dvi pmod would probably work. It's only 16 color though. Alternatively the 12 bit one but it takes 2 pmod slots which is a bit annoying.
<emeb_mac>
tnt: ah cool - I need to study those to see what's on the interface. Been wondering about dvi / hdmi for compatibility w/ more modern monitors.
<Sprite_tm>
Can't you do dvi entirely on your fpga? There are encoders for it; I'm happily doing 640x480 on my ecp5, and people have done full-hd on it.
<Sprite_tm>
Should only require 8 ios or so, iirc.
<emeb_mac>
Sprite_tm: I don't think that the Ultra Plus I'm using can handle the required serdes rates.
ZombieChicken has joined ##openfpga
<tnt>
it can manage 640x480 directly ... but that pmod uses an encoder.
<tnt>
The ecp5 driving dvi directly I've seen were electrically a bit weird (as in: I don't doubt it worked, but I doubt the resulting signal was within the TMDS specs levels which might be an issue for some monitors/tv).
<emeb_mac>
looks like the BML single-PMOD just does 1 bit per R/G/B, plus clk, enable and v/h sync.
<Xark>
IIRC, you would typically use 125Mhz and DDR primitive to get ~25.175 x 10 pixel clock TMDS for DVI (like on MachXO2 e.g. or Spartan6).
dj_pi has quit [Ping timeout: 244 seconds]
<emeb_mac>
might be possible to do 2-bits per R/G/B with DDR tho
<tnt>
That's the modified version I came up with to get 16 colors.
<tnt>
It's basically RGBI (I being 'Intensity' like in old CGA :p)
<emeb_mac>
tnt: nice trick
<tnt>
Unfortunately the encoders DDR modes were not really suitable to get 6 bit colors, data channels never mapped at the right place.
<emeb_mac>
tnt: of course :P
<emeb_mac>
tnt: when driving the tfp410 do you have to use a 25.175MHz clock, or can you use a pixclk related to the VGA resolution?
<emeb_mac>
(ie - the 800x600 mode I use has a 40MHz pixclk because it's easy to generate from the 16MHz xtal osc my board provides)
<tnt>
you need to use the pixelclock matching your resolution.
<tnt>
I mean, it's basically the same signal as VGA except you need a 'Data Enable' which is when you are in the active zone.
<emeb_mac>
good - my pixclk & resolution are "standard"
<tnt>
(which you should probably have internally already)
<emeb_mac>
and yeah - I've got an "active video" signal internally
<Richard_Simmons>
you also could ask in here about the current state of affairs for ECP5 here SolraBiz1a
<Richard_Simmons>
namely, he was asking for state of PCIe, and what kind of fmax people were pulling off on risc-v cores with the ecp5's instead of ice40's.
<Richard_Simmons>
asking here in part because it's 2 am. I am not in a state to go searching now with diverse spread of where it'd be, but that there's enough activity in the space here.. someone might know off the top of their head.
<Sprite_tm>
I get 60MHz on my picorv32, fwiw :) but that core never was intended to set speed records, and the caching etc thing I devved around it also probably could use a few speed stripe stickers.
<flea86>
Richard_Simmons: If it's any comparison, I once ran an embedded mips core on ECP5 @ 125MHz. Then Lattice made their Diamond tools slower in subsequent tool builds and that went away :(
<SolraBiz1a>
but I'm too ashamed of what happened to the n in my name
<Richard_Simmons>
I was going to say, yeah that sounds like useful info maybe, it'd be up to.. and then SolraBiz1a spoke.
<Richard_Simmons>
I usually chase down information he needs even if I don't fully comprehend it. >.>
<SolraBiz1a>
I have the stupid idea of making an ATX motherboard with an ECP5 on the throne
<flea86>
SolraBiz1a: Needs a good single-cycle i586 SoC to go with it :)
<Richard_Simmons>
ATX, or ITX? ATX might be a bit ridiculous in cost.
<SolraBiz1a>
I just wish the FE310 supported some form of external main memory...
<Sprite_tm>
SolraBiz1a: Why doesn't it? Can't you just interface the internal memory interface with a cache and access external main memory through it?
cr1901 has joined ##openfpga
<flea86>
SolraBiz1a: No way of coaxing it at all?
<SolraBiz1a>
closest I was able to figure was hooking up an SRAM to its XIP dingus
<SolraBiz1a>
but that's QSPI, which is hecka slow, and (more importantly) its XIP dingus is read-only
<flea86>
SolraBiz1a: QSPI RAM is actually not terrible, but for the task at hand isn't ideal. I agree.
<flea86>
*it isn't
<Sprite_tm>
Cheap as chips, though. 8M for $0.60.
<flea86>
That's the other thing heh
<TD-Linux>
I guess my "litex for nmigen" question has now been answered
emeb_mac has quit [Ping timeout: 248 seconds]
<Sprite_tm>
Tbh, I'm thinking of increasing my bandwidth by just having a parallel path to a bunch of them... I mean, 8*4 is also 32, right? :P
<SolraBiz1a>
it is
<SolraBiz1a>
have you already looked at HyperRAM?
<flea86>
Sprite_tm: Cheap enough to have one for system RAM, one for video RAM :D
<TD-Linux>
hyperram bus interface would have to be done in software on the fe310. probably worse than the QSPI
<SolraBiz1a>
but its QSPI memory mapping dingus is read-only anyway
<TD-Linux>
yeah I was disappointed at that when I looked at the source :(
<flea86>
TD-Linux: Aye. Might be better off trying to bit-punch an SDRAM controller instead, assuming enough io pins
<flea86>
TD-Linux: I've actually done it before using a 180MHz 8051 + parallel 4MB SDRAM.
<TD-Linux>
flea86, now that's the type of offensive embedded development that I like
OmniMancer has joined ##openfpga
<flea86>
hahaha :D
<TD-Linux>
assuming the fe310's gpios can work close to core speed it's probably the fastest way
<tnt>
The fe310 is lacking in external IF option in general :/
<flea86>
TD-Linux: It was for an custom x86 emulator in fw
<flea86>
even more offensive ;P
<flea86>
I'd have to look at what kind of peak burst read rates I was getting
<tnt>
Errata: "The output enable signal for DQ[3] is not driven properly" .. oh well ok then. Not really a "Quad" spi then is it ...
<flea86>
TD-Linux: I was getting ~60MBytes/second peak rates from DRAM, with Burst mode = 4-byte burst.
<flea86>
Not outstanding, not terrible.
m4ssi has joined ##openfpga
<flea86>
obviously, this rate falls away once setup overhead is included
<flea86>
tnt :/
<tnt>
flea86: I was a bit quick, seems it's fixed in the -g002 revision, so ... get that one and not the -g000 :p
<flea86>
I read that as goop :D
<tnt>
gwyneth paltrow getting into riscv :p
<flea86>
lol
<flea86>
That may happen if riscv gets popular enough :)
<flea86>
sorry, I meant :\
rombik_su has joined ##openfpga
<TD-Linux>
flea86, I hope that was to execute real mode option ROMs or something
<flea86>
TD-Linux: The DRAM was used both as system RAM as well as VGA framebuffer memory.
<azonenberg>
SolraBiz1a: the f7's at least in larger packages have a full external bus interface
futarisIRCcloud has joined ##openfpga
<Richard_Simmons>
f7?
<flea86>
stm32f7 ;)
<Richard_Simmons>
oh. risc-v is a goal.
<flea86>
Yeah, figured. That F7 variant crossed my mind too.
<tnt>
I don't see a F7 on sifive website ?
<azonenberg>
stm32 i meant
<tnt>
oh ok :p
<TD-Linux>
shockingly I found a versa at the local flea market, so I get to try out heavyx tonight
<tnt>
an ecp5 one ?
<TD-Linux>
yeah
<daveshah>
Some flea market
<tnt>
you have nice flea markets :)
<flea86>
TD-Linux: Nice find. What were the odds heh.
Asu has joined ##openfpga
<flea86>
TD-Linux: Did the seller know what it was? :)
<TD-Linux>
silicon valley. original owner might have been using it for nextpnr even, didn't ask.
<flea86>
Ah
gsi__ is now known as gsi_
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 252 seconds]
wpwrak has quit [Ping timeout: 248 seconds]
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 272 seconds]
wpwrak has joined ##openfpga
ZombieChicken has quit [Quit: WeeChat 2.5]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rombik_su>
Is it safe to assume that nextpnr for ECP5 can be used for EPC5-5G for regular logic? Thinking about buying Versa-5G kit.
<daveshah>
Yes it can
<rombik_su>
Thanks
<daveshah>
Even if you just want regular logic, it's useful to note that the fabric of the 5G is about 20-30% faster than the non-5G because of the higher Vcore
<rombik_su>
Yep, that's nice
<flea86>
Ahh. so THAT explains why my Ohm prototypes ran F32C faster! :o
<flea86>
I always thought it was the toolchain
<flea86>
@daveshah
<daveshah>
There are also speed grades to consider for the non-5G parts (probably another 20-30% or so between -6 and -8 grades)
<flea86>
Aye. My initial Ohm prototypes used Engineering samples of 5G variant
<flea86>
They don't work with the free Diamond anymore, but I'm sure they'll work with Trellis.
<daveshah>
They do indeed
<daveshah>
(normal 5G at least)
<daveshah>
If the IDCODE is different for the ES then it can be overidden in ecppack
<flea86>
Okay. the achillies heel of my design was the FT230x for JTAG programming. I've fixed that now.
futarisIRCcloud has joined ##openfpga
zignig has joined ##openfpga
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 252 seconds]
Miyu is now known as hackkitten
rohitksingh_work has quit [Read error: Connection reset by peer]
genii has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
vonnieda has joined ##openfpga
emeb has joined ##openfpga
rohitksingh has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vonnieda has joined ##openfpga
carl0s has joined ##openfpga
Laksen has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
m4ssi has quit [Remote host closed the connection]
<kc8apf>
TD-Linux: electronics flea market?
rohitksingh has quit [Ping timeout: 248 seconds]
laintoo has quit [Quit: uptoots]
rohitksingh has joined ##openfpga
rombik_su has quit [Ping timeout: 272 seconds]
Laksen has quit [Quit: Leaving]
kem_ has quit [Quit: Connection closed for inactivity]
Zorix has quit [Ping timeout: 248 seconds]
rohitksingh has quit [Remote host closed the connection]
Zorix has joined ##openfpga
<TD-Linux>
kc8apf, yes
<TD-Linux>
inb4 I bought it from someone in this channel
<kc8apf>
I missed this month. :(
carl0s has quit [Quit: Page closed]
genii has quit [Remote host closed the connection]
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Asu has quit [Quit: Konversation terminated!]
vonnieda has joined ##openfpga
jcreus has quit [Ping timeout: 245 seconds]
jcreus has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Zorix has quit [Ping timeout: 250 seconds]
ZombieChicken has joined ##openfpga
mumptai_ has quit [Remote host closed the connection]