<_florent_>
for now it only support serial, but I will add ethernet support
<_florent_>
it's also interesting to write software I think
<_florent_>
to port OS...
<sb0>
awesome!
<sb0>
_florent_ is on fire =]
<_florent_>
yes!
FabM has joined #m-labs
FabM has quit [Ping timeout: 245 seconds]
FabM has joined #m-labs
<GitHub103>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/x80S
<GitHub103>
migen/master 58290f3 Florent Kermarrec: lasmi: simplify usage for the user (it's the job of the controller to manage write/read latencies on acks)
<GitHub102>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/x80A
<GitHub102>
misoc/master 6d83a11 Florent Kermarrec: lasmi: simplify usage for the user (it's the job of the controller to manage write/read latencies on acks)
<sb0>
_florent_, er, didn't we talk about this before already?
<_florent_>
yes, you're not OK with that?
<_florent_>
it does not change performance or logic utilization
early has quit [Ping timeout: 245 seconds]
<_florent_>
it's just easier for the user
<_florent_>
instead of managing latency on ack outside the controller (is by the user), it's done inside
<_florent_>
dat_w_ack = present write data
<_florent_>
dat_r_ack = read data is valid
early has joined #m-labs
<sb0>
this does impact performance as you are now unable to switch to a different master (to get new requests) during the read/write latency
<sb0>
if you're doing that, you might as well use wishbone and minicon.
<_florent_>
no since there is no modification on ack of the requests
<_florent_>
for me it's exactly the same behaviour as before, just that you don't have to manually shift the ack
<sb0>
hmm...
<_florent_>
With the old behaviour:
<_florent_>
dat_ack is generated when the command is sent to the DRAM
<_florent_>
the user of the LASMI port then have to calculate when it must send write data
<_florent_>
of when the read data is valid
<_florent_>
the only thing that my modification does is remove this task for the user by doing it internally
<_florent_>
it does not change anything on the ack of the requests
<_florent_>
and before dat_ack where delayed everytime
<_florent_>
in dma_lasmi there was a loop to delay acks
<_florent_>
and on wishbone2lasmi there was a delay between fsm states
<_florent_>
I can do memtest measurements with the old and new code tomorrow if you want :)
<sb0>
hmm, isn't dat_ack used somewhere else than the code that your patch modifies?
<sb0>
well I guess not since you renamed it
<sb0>
should be good then.
<_florent_>
no the only 2 modules I know that are using directly lasmi are dma_lasmi and wishbone2lasmi
<sb0>
I mean, there's also the controller itself, and the crossbar
<_florent_>
no but dat_ack is generated in bank machines
<_florent_>
and this signal is used directly in the crossbar
<_florent_>
and only here
<_florent_>
and the crossbar expose it to the user
<_florent_>
I just have to update the simulations
<sb0>
oh I see you are delaying each master ack in the crossbar, and after the arbitration
<sb0>
I was confused by your "it's the job of the controller" comment. I thought you had the controller/PHY delay the acks, which would require arbitration locking.
<sb0>
yes. what you did works.
<sb0>
it removes the possibility to trigger long pipelines in advance in the masters, but I guess that's unimportant
<_florent_>
:) I did it just because I think it's easier to manage for the user, and it will ease things if I do Avalon/AXI adapters
_florent_ has quit [Quit: Leaving]
mumptai has quit [Remote host closed the connection]