lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs :: Mixxeo preorder lists.milkymist.org/pipermail/devel-milkymist.org/2013-May/003344.html
antgreen has quit [Read error: Operation timed out]
antgreen has joined #milkymist
mumptai has quit [Ping timeout: 246 seconds]
kristianpaul has quit [Ping timeout: 248 seconds]
jevin has quit [Read error: Operation timed out]
jevin has joined #milkymist
antgreen_ has joined #milkymist
antgreen has quit [Ping timeout: 246 seconds]
Martoni has joined #milkymist
lekernel has joined #milkymist
[florian] has quit [Ping timeout: 245 seconds]
[florian] has joined #milkymist
mumptai has joined #milkymist
bhamilton has joined #milkymist
mumptai has quit [Ping timeout: 276 seconds]
lekernel has quit [Ping timeout: 264 seconds]
lekernel has joined #milkymist
_whitelogger__ has joined #milkymist
sh4rm4 has quit [Ping timeout: 240 seconds]
sh4rm4 has joined #milkymist
antgreen_ has quit [Ping timeout: 248 seconds]
ohama has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.90.1 [Iceweasel 17.0.7/20130626001350]]
Martoni has joined #milkymist
kristianpaul has joined #milkymist
antgreen_ has joined #milkymist
antgreen_ has quit [Ping timeout: 240 seconds]
bhamilton has left #milkymist [#milkymist]
<davidc___>
lekernel: Hey; I think I've found a bug in AsyncFIFO - not sure if it is by design or not so I wanted to bounce it off you before submitting a patch
<davidc___>
lekernel: specifically; AsnycFIFO uses a synchronous read of the storage SRAM; which means that the read access pattern is:
<davidc___>
1. assert RE
<davidc___>
2. [readable changes if that was the last word in fifo]
<davidc___>
3. fifo.dout becomes valid
<davidc___>
whereas for a synchronous fifo; the pattern is 1. assert RE, 2 readable changes if necessary and fifo.dout changes to the new value
<lekernel>
yes, there's probably a bug in ayncfifo ;) I noticed it behaved strangely, haven't had time to look at it yet
<lekernel>
your description could very well explain the problems I noticed
<GitHub5>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/fuQFhg
<GitHub5>
migen/master faa8b7c David Carne: fhdl/tools: clock domain merging for clock renaming
<davidc___>
lekernel: Ok. The easy fix is to just change the read-synchronous to read-asynchronous on that SRAM read port
<davidc___>
lekernel: but I'm not sure how that will affect your existing designs timing wise
<davidc___>
lekernel: Actually; maybe I'll create a patch with a 'tune' parameter that either designs the fifo with an asynchronous read; or with a synchronous read from consume_next [IIRC; don't have the source here]
<davidc___>
lekernel: so its right either way; but you can choose whichever is better timing-wise
<lekernel>
synchronous read is always better; otherwise the memory can't be mapped to block RAM unless the synthesizer is smart enough to move a design's register into the memory
<lekernel>
so if you have a design with synchronous read, we use that and forget about the asynchronous one
<davidc___>
lekernel: I can fix it up tonight probably [+8h]
<davidc___>
lekernel: Also; I realized my patch from this morning doesn't fully solve clock domain renaming - for example; if you do {'foo':'bar', 'bar':'quux'}; its still nondeterministic depending on dict ordering [not to mention, what exactly is the intent of such a statement :)]
<davidc___>
Anyhow; I'll think about a better fix and send something to the list for comment
<lekernel>
yeah, python's non-deterministic dictionaries are a pain
sh4rm4 has quit [Ping timeout: 240 seconds]
<davidc___>
lekernel: BTW - do you prefer patches to the ML; pull requests to the ML; or just github pull requests? [or pull-req-via-irc ;)]
<lekernel>
patches to ML
<lekernel>
with git format-patch if possible
playthatbeat has quit [Ping timeout: 240 seconds]
<davidc___>
Ok, will do.
playthatbeat has joined #milkymist
sh4rm4 has joined #milkymist
<lekernel>
davidc___, async_read fixed two bugs that have been bothering me for a while. thx ;)
<davidc___>
lekernel: no problem. I wrote a heinous workaround for the problem on my design then eventually decided "there's no way this can be by design... it has to be a bug"
<GitHub74>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/2nBxJQ
<larsc>
"Industry’s First ASIC–class All Programmable Architecture", hm whatever that means
Scopeuk-AFK is now known as Scopeuk
<davidc___>
larsc: that we'll see it sometime around 2043
<larsc>
Xilinx just anounced their series 8 with that headline
<larsc>
well 'just'
<davidc___>
larsc: heh; and the 7-series is still vaporware for most users
<larsc>
yea, exactly my thought, the press release said 'available this year' and I though 'How about fixing 7-series first?'
<davidc___>
I mean; I've seen real 7-series chips (big kintex parts); but the Artix-7 SL / Artix-7 SLT parts don't actually exist AFAICT
<larsc>
SL = slim?
<davidc___>
larsc: SL is just logic, no transceivers. They don't actually tell you what SL stands for; that wouldn't be market-droid-enough
<davidc___>
larsc: Also, all of the 7-series parts are BGA only
<davidc___>
which is understandable; but all the cheap devices are 0.8mm BGA or smaller
<davidc___>
so $$$ protos
<larsc>
I have a couple of 7-series boards at work
davidc___ is now known as davidc__
<larsc>
hm, I wonder if the SLs are just ink on plastic
<davidc__>
larsc: on paper; you mean? :P
<larsc>
yea that too, maybe the yield is just so good that they didn't need to label them as SLs ;)
<davidc__>
larsc: hah. Its more that the SL parts are smaller logic-wise
<davidc__>
I don't have huge logic designs; I just want my small designs to run faster :P
<davidc__>
Its just that dropping $130 on an XC7A100T [or $60 at volume / whatever it is] completely blows the BOM for most of the things I want to build with em
<larsc>
yea
<davidc__>
Not to mention the cost of the 8 layer microvia board to route the damn thing out
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]]