lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
pablojavier has joined #milkymist
pablojavier has left #milkymist [#milkymist]
antgreen has quit [Ping timeout: 252 seconds]
xiangfu has joined #milkymist
xiangfu has quit [*.net *.split]
barmstrong has quit [*.net *.split]
barmstrong has joined #milkymist
xiangfu has joined #milkymist
antgreen has joined #milkymist
playthatbeat has quit [Read error: Operation timed out]
playthatbeat has joined #milkymist
larsc has quit [Ping timeout: 272 seconds]
larsc has joined #milkymist
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 245 seconds]
aeris has quit [Quit: en a pas]
xiangfu has joined #milkymist
mumptai has joined #milkymist
aeris has joined #milkymist
xiangfu has quit [Read error: Connection reset by peer]
lekernel has joined #milkymist
mumptai has quit [Ping timeout: 268 seconds]
xiangfu has joined #milkymist
<larsc>
hm, I keep forgetting this. What's the difference between a bram where the output is clock and one where it is not and when do you want to use one or the other?
<lekernel>
you mean registered?
<larsc>
probably. basically the difference between data = ram[raddr] and @(posedge clk) data <= ram[raddr]
<lekernel>
all BRAMs have 1-cycle latency. you can optionally add another output register that improves the clock-to-output delay, but on slowtan6 the performance is less than registering in the fabric so you should never use it (as performance optimization is always the target due to the inherent slowness of the silicon)
<lekernel>
if you have an asynchronous read, you cannot map to BRAM
<lekernel>
unless the synthesizer moves some other design register into the memory via retiming
<larsc>
ok, I see
<larsc>
thanks
<lekernel>
you can still have the form
<lekernel>
@(posedge clk) addr_registered <= addr
<lekernel>
assign data = ram[addr_registered]
<lekernel>
which describes a write-first memory mappable to block RAM
<lekernel>
as opposed to @(posedge clk) data <= ram[raddr]
<lekernel>
which is read-first
<larsc>
so only if the address is combinatorial logic I won't be able to map it to a BRAM?
<lekernel>
and if you can't register the data either
<lekernel>
Xst will generally try to extract a register from the address generation logic, or the data processing logic, and put it into the BRAM. but a) it's only so smart b) in some cases, extracting the register would lead to disasterous timing
<larsc>
but for a fifo with a read counter I should be fine I guess?
<lekernel>
try synthesizing it and look at the netlist
<lekernel>
it's not always that clear
<lekernel>
depends how your fifo works :)
<larsc>
It will probably be fine since the output will eventually be a register again, but in a different core
<larsc>
the FF will probably explode if it does not work
<larsc>
FF count
<lekernel>
distributed RAMs are never mapped to FFs - they use the LUTs themselves as storage (with read-write capability), in a special mode
<larsc>
ok, so the lut cound will explode
<larsc>
good to know: "INFO: [Common 17-86] Your PlanAhead license expires in -127 day(s)"
<larsc>
;)
<lekernel>
DRM failing in that direction is unusal, but less bothersome :)
<larsc>
looks as if I got a BRAM
<larsc>
I wonder how you go about implementing a stb-ack style handshaking for a read-first BRAM, since you essentially need to increment the address one cycle before ack is asserted.