<kristianpaul>
Had you noticed i guess the CSR bus detect write cycles from wishbone
<kristianpaul>
I was trying to detect reads too
<kristianpaul>
but i dont know i guess i did, i met a race condition issue
<kristianpaul>
I was wondering you have some snipets about detecting read and writes cycles from master in wishbone
<kristianpaul>
argh, i will go for writing register to clear flags
<kristianpaul>
but i wanted clear after read,
<kristianpaul>
wich i still can do, but cheating using unique adress for both reading and writing
<kristianpaul>
even if we talk about same register !
<wpwrak>
if (csr_selected) { if (csr_we) data_reg <= whatever; csr_do <= data_reg; } ?
<wpwrak>
that way, you latch the new data with a write cycle and can then quietly read it afterwards
<kristianpaul>
sure, that works with csr_we coming from the csbridge FSM
<wpwrak>
yup
<wpwrak>
ah, and around the "whatever", you can also clear and so on
<kristianpaul>
yes but when writing (csr_we)
<wpwrak>
yup
<kristianpaul>
there is no csr_re for instance
<wpwrak>
no, there's not :)
<wpwrak>
but why do you want to do it all in one cycle ? do you have performance problems ?
<wpwrak>
i.e., no time for two cycles ?
<kristianpaul>
sure i could two cycles
<kristianpaul>
i just dont want break register compliance against namuru upstream
<kristianpaul>
later Artyom code,,, erghh and others
<kristianpaul>
but i wanted to clean up things a bit :)
<kristianpaul>
at least !
<kristianpaul>
but no no more
<wpwrak>
(compatbility) ah, that's why !
<kristianpaul>
and noticed this dint changed on migen, perhaps is milkymist way to go and i should break compatbility anyway
<wpwrak>
you can always worry about that later :)
<kristianpaul>
yes yes, i _know_ but i cant, argh
<kristianpaul>
anyway !
<kristianpaul>
i would worry
<kristianpaul>
later...
<kristianpaul>
seems thats the rule..
<wpwrak>
it helps you to avoid getting stuck on a problem for which you may find a better/easier solution later, without much effort
* kristianpaul
stuck
<kristianpaul>
OK
<kristianpaul>
Thanks werner !
<kristianpaul>
and gn8 ;)
<wolfspraul>
n8
<stekern>
kristianpaul: I'm not sure I understand the problem you are trying to solve, but to answer the question. in wishbone you detect a read cycle by stb & cyc & !we
<stekern>
so I guess for CSR you've got to do csr_selected & !we to detect a read
wolfspraul has joined #milkymist
wpwrak has joined #milkymist
lekernel_ has joined #milkymist
cladamw has joined #milkymist
mumptai has joined #milkymist
wolfspraul has joined #milkymist
voidcoder has joined #milkymist
wolfspraul has joined #milkymist
Martoni has joined #milkymist
cladamw has joined #milkymist
elldekaa has joined #milkymist
LmtdAt has joined #milkymist
elldekaa has joined #milkymist
<larsc>
you can't detect read cycles with CSR. You should always output the register value whenever csr_selected is true
elldekaa has joined #milkymist
<wpwrak>
larsc: i wonder what would happen if someone implemented stekern's idea. multiple read "strobes" in a single cycle ? stray "strobes" when not even reading ?
<wpwrak>
i.e., we keep on telling people it's wrong, but we don't tell them why it wouldn't work
<larsc>
wpwrak: well, it's undefined behaviour.
<larsc>
the problem is that we don't have any strobe signal at all
<larsc>
i think with the current implementation csr_selected & !we is true for multiple cycles
<larsc>
not sure about the milkymist-ng implementation though
<lekernel>
modify on read is evil anyway
<lekernel>
same
cladamw has joined #milkymist
voidcoder has joined #milkymist
voidcoder has joined #milkymist
<larsc>
basically you can't support any operations on a CSR bus which are not idempotent. doesn't matter whether it is read or write
elldekaa has joined #milkymist
elldekaa has joined #milkymist
elldekaa has joined #milkymist
elldekaa has joined #milkymist
cladamw has joined #milkymist
cozy has joined #milkymist
voidcoder has joined #milkymist
<wpwrak>
larsc: wait ... are you saying that we don't have a write strobe either ? i.e., if (csr_selected && csr_we) count <= count+1; wouldn't work as expected ?
<lekernel>
wpwrak: we do have a write strobe, and that would work as expected
<wpwrak>
lekernel: phew :-) thanks
<wpwrak>
lekernel: so what would happen in stekern's example ? would you just get multiple "strobes" per read ? or also "strobes" when there's no read ?
<lekernel>
you can get both multiple "read strobes" or stray ones
<lekernel>
when !csr_we & csr_selected, you are required to output valid data at all times, but there's no way to know if there was a legitimate read or not
<wpwrak>
okay. so it's as bad as possible. good. this should discourage everyone ;-)
<lekernel>
well it's meant to be used with actual _registers_
<lekernel>
the read implementation is just 1 mux + 1 FF
<lekernel>
you can hardly do any simpler
<wpwrak>
yeah :) it's a trap for people trying to implement something fifo-like, though.
<larsc>
lekernel: your csr spec doesn't really specify that a the we signal must only be asserted for one cycle
<wpwrak>
(well, until they learn how it works :)
<lekernel>
larsc: then it should :)
<larsc>
lekernel: ok
<lekernel>
but iirc it does say that all accesses complete in one cycle, and if you have two we assertions, you have two cycles ...
<larsc>
i thought that too, but couldn't find it in the spec
<larsc>
maybe it's in your thesis?
<lekernel>
hmm... not sure... anyway, it's in the IRC logs now =]
<larsc>
hehe
<kristianpaul>
true for multiple cycles, yes
<kristianpaul>
i was looking at uart core from lattice micosystem, it uses a separte always block with a sensitive list for we stb cyc
<kristianpaul>
and read both write and read strobes.. okay this could get worse, oh messy could get . :-|
voidcoder has joined #milkymist
<kristianpaul>
okay, interesting disccusion :-)
<kristianpaul>
Thanks for your feedback!!
<lekernel>
kristianpaul: anyway, the 'bank' module in migen generates this sort of things automatically now. you'll probably like it, since you are so lazy.
<stekern>
aha, I see there is no "none-selected". but what's the problem anyway, if you need some more complex functionality, just hook it straight up to the wb-bus then?
<lekernel>
yes
<lekernel>
nice: when you pass a pointer to vpi_put_value (which you do when writing more than 32 bits), the simulator only reads that pointer after the specified delay
<lekernel>
and it seems there's no way to specify a "free()" callback
<lekernel>
so... the usual round of bugs... when allocating that pointer on the stack, it intermittently writes garbage, if you reuse the structure, several signals get the same value when they should not, etc.
<lekernel>
guess it would have been too simple to let the simulator copy memory ...
<lekernel>
fortunately I only have delta delays here, so if I can't find anything better I'll just keep a linked list of malloc'd buffers to free at the next cycle ...
<larsc>
sounds like a lot of fun
<lekernel>
grmbl... in fact as per the VPI standard you can have a callback, but icarus verilog doesn't support it