<GitHub32>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/-XFwbQ
<GitHub32>
artiq/master 7c4450a Sebastien Bourdeauducq: time_to_cycles: round instead of flooring
<ysionneau>
sb0 : for spi flash erasing I guess we need to put some CSR register to trigger it, like writting the block address and maybe the number of contiguous blocks
<sb0>
no, put all that under CPU control
<sb0>
like it's done on the M1/mixxeo
<sb0>
we're executing from SDRAM when writing to the flash, so it doesn't matter if SPI reads do not work for a while
<ysionneau>
when I meant CSR reg I meant that it would be triggered by the cpu
<ysionneau>
by writting to the CSR reg
<ysionneau>
but I don't know how it's done on M1 yet, I will have a look
<sb0>
can't use wishbone writes like it's done for NOR?
<sb0>
for NOR, writing (and everything else) is done with a sequence of cycles that are just like the reads, but with special addresses/data
<sb0>
and WE asserted
<ysionneau>
ah ok, so no erase then writting for the CPU point of view
<ysionneau>
any write will do both 1°) erase then 2°) write
<sb0>
with those flashes, you need to erase to set 0->1 for a whole block, and you can set 1->0 individually with write commands
<sb0>
that's independent of parallel/serial
<ysionneau>
yes
<sb0>
and that should be under CPU control, yes
<ysionneau>
I agree that a CPU wishbone write access should trigger a flash write
<ysionneau>
but how can the CPU say it wants to erase a block?
<sb0>
if the write/erase sequences are significantly different from the reads, a CPU bit-banged interface is also fine
<sb0>
with the parallel NOR, this is done (at the flash chip level) by writes at particular addresses with particular data
<sb0>
idk about serial flashes
<ysionneau>
ah ok so it could be just like a write
<ysionneau>
ok I have to dig into this then
<ysionneau>
thanks
<sb0>
the nor core simply maps the cpu writes one-to-one to flash bus-level writes
<ysionneau>
ok got it
<ysionneau>
so in case it is not a normal write command to erase, you prefer bit banging from the CPU rather than just adding a memory mapped register which would trigger a FSM that would do the erase command sequence?
<sb0>
yeah. we're writing < 1KB data, so it doesn't matter if the whole thing is very slow
<ysionneau>
ok
<sb0>
and erases are slow anyway, can take dozens/hundreds of ms
<sb0>
(from the flash)
<ysionneau>
yes
<sb0>
sometimes bit-banging in C is a pain, but I consider that a programming language problem
<sb0>
ysionneau, btw can you get the runtime to initialize the UART at 3Mbps after startup and modify corecom_serial to use 3Mbps too?
<ysionneau>
yes, is that to do before for instance adding write support for the flash?
<sb0>
"the 64-bit address space version of OpenRISC, hardware implementations and software stacks are still not available"
<sb0>
there are currently zero usable implementations of risc-v, so...
<ysionneau>
I think someone ( stekern ? ) told me that in fine they are not interested in implementations
<ysionneau>
their work is on ISA
<ysionneau>
so they try to design a good ISA but they don't care about implementation that much
<ysionneau>
oh and they are using CAM for their TLB which takes a lot of room in FPGA because it does not map to blockram
<ysionneau>
I've heard their tlb+caches take ~8k LUT
<ysionneau>
so in fine their pipeline takes 8k LUT which is still big
<ysionneau>
(if the entire design is 16k LUT)
<sb0>
I heard the same "we focus on the isa" about openrisc a few times. result: it took more than 10 years before there was one halfway decent implementation...
<sb0>
so the reason for the 12-bit immediates is extensions. well, why not...
<ysionneau>
sb0: something I didn't understand in the Blinkie SoC example, why is the 32 bits CSR that controls the led blinking frequency cut into 4 addresses aligned at 4 bytes boundaries?
<ysionneau>
each address can only address 8 bits on CSR bus ?
mumptai has joined #m-labs
kristianpaul has quit [Ping timeout: 258 seconds]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
<rjo>
ysionneau: the csr bus data width is 8 bits. yes.
<rjo>
ysionneau: i assume there is an optimal data-width/address-width tradeof value for typical csr bus sizes. a plot of luts vs data width would be interesting.
<rjo>
ysionneau: did you also physically move to .hk?