lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
mumptai has quit [Ping timeout: 272 seconds]
jimmythehorn has quit [Quit: jimmythehorn]
xiangfu has joined #milkymist
lekernel has quit [Ping timeout: 272 seconds]
fsk has quit [Quit: fsk]
gbraad has joined #milkymist
gbraad has quit [Changing host]
gbraad has joined #milkymist
lekernel has joined #milkymist
gbraad has quit [Ping timeout: 248 seconds]
hypermodern has joined #milkymist
hypermodern has left #milkymist [#milkymist]
digshadow has joined #milkymist
fsk has joined #milkymist
digshadow has quit [Read error: Connection reset by peer]
digshadow has joined #milkymist
xiangfu has quit [Ping timeout: 244 seconds]
digshadow has quit [Client Quit]
fsk has quit [Quit: fsk]
antgreen has quit [*.net *.split]
fpgaminer has quit [*.net *.split]
antgreen has joined #milkymist
fpgaminer has joined #milkymist
digshadow has joined #milkymist
xiangfu has joined #milkymist
xiangfu_ has joined #milkymist
mumptai has joined #milkymist
mumptai has quit [Ping timeout: 248 seconds]
Martoni has joined #milkymist
xiangfu_ has quit [Quit: leaving]
playthatbeat has joined #milkymist
Martoni has quit [Read error: Operation timed out]
Martoni has joined #milkymist
fsk has joined #milkymist
xiangfu has quit [Ping timeout: 255 seconds]
kristianpaul has quit [Quit: Lost terminal]
mumptai has joined #milkymist
<larsc>
more xilinx ranting: They made the XADC threshold interrupts level sensitive, as if I'm able to bring the temperature down again from within the interrupt handler.
qwebirc72236 has joined #milkymist
<qwebirc72236>
hiiiii
mumptai has quit [Ping timeout: 248 seconds]
<qwebirc72236>
@name vdmo
<larsc>
/name
digshadow has quit [Quit: Leaving.]
<qwebirc72236>
m3 status?
<lekernel>
qwebirc72236, are you the one who just sent me an email?
kilae has joined #milkymist
digshadow has joined #milkymist
digshadow has quit [Ping timeout: 260 seconds]
<GitHub110>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/ia8vZQ
<azonenberg>
Also, i may not keep that exact SRL structure
<azonenberg>
i'm in the process of experimenting with different options to allow reconfigurability while packing as many trigger controls as possible into one slice
<azonenberg>
i'm looking at options including SRLs, dual-port RAM, etc
<azonenberg>
Oh, and i still have to do the run-length encoding
<azonenberg>
the trigger logic is going to by necessity be quite specialized to the underlying FPGA slice primitives
<lekernel>
by necessity?
<azonenberg>
If i want to be able to run the LAs as fast as whatever input i throw at it
<azonenberg>
the LA has to be extremely efficient
<lekernel>
things like RLE rather sound like higher-level algorithms that would be better implemented with behavioral code
<azonenberg>
The trick is to switch the trigger block to edge detection (for RLE)
<lekernel>
well, when done right, synthesized netlists are extremely efficient
<lekernel>
portable
<lekernel>
and faster to write
<azonenberg>
My current thinking it so squeeze that into the last unused SRL32 primitive
<azonenberg>
the last input*
<lekernel>
what will you gain with that? 0.1ns of timing? 3 LUTs?
<azonenberg>
are you kidding me? more
<azonenberg>
even in -3 series s6 it's 210ps through one LUT
<azonenberg>
then routing delays
<azonenberg>
it'll probably be at least 500ps
<azonenberg>
which at 200 MHz is a 10% speedup for each LUT I can cut out of the critical path
<lekernel>
S6 is a slowness pig, just use kintex ...
<azonenberg>
My current platform is s6 based
<azonenberg>
I have an artix7 bord in the works
<azonenberg>
board*
<lekernel>
so you're planning to optimize each bit of your design like this, by hand?
<azonenberg>
No, just the LA
<lekernel>
but the rest won't catch up
<azonenberg>
the goal is for the LA to be fast enough to keep up with anything i can conceivably throw at it
<azonenberg>
artix7 in -1 spee is 130ps per LUT, lol
<azonenberg>
Double the LUT performance right there
<azonenberg>
kintex7 is 60ps, wow
<lekernel>
yeah I told you
<lekernel>
s6 is slow crap
<lekernel>
azonenberg, so after the trigger condition is met, you get 512 samples at the clock frequency?
<azonenberg>
lekernel: Right now, yes
<azonenberg>
The RLE version will give you 512 edges
<azonenberg>
as in, sample all signals whenever any one changes
<azonenberg>
Which will let you capture with long delays between bus cycles etc
<azonenberg>
or slow signals like a UART as long as there isnt fast stuff in the same capture
<azonenberg>
In the future i'll be making it parameterizable depth
<azonenberg>
and possibly with
<azonenberg>
width*
<azonenberg>
these are all in progress for v0.2
<azonenberg>
The code in that repo hasnt been touched in months
<lekernel>
parametrizable depth should be a < 10 line change, no?
<azonenberg>
It's not that simple because the new version is using my NoC protocol for reading data out over JTAG
<azonenberg>
and packets have a 512-word limit
<azonenberg>
so i'll need to add code to send multiple packets
<azonenberg>
Adding more depth to the actual capture core will be trivial
<azonenberg>
the wrappers, less so
<azonenberg>
The UART code in that version is buggy too
<azonenberg>
i need to rewrite it from scratch
<larsc>
if the rate of change is low enough do you think continuous streaming can be implemented?
<azonenberg>
larsc: High on my list of things to explore
<larsc>
cool
<lekernel>
and I suppose reusing the milkymist uart is not an option, right?
<azonenberg>
first thing to do is improve my JTAG code so i can get more than 80 Kbps
<azonenberg>
lekernel: the UART itself is fine
<azonenberg>
it's the code that talks to it
<azonenberg>
And if its wishbone based then no, not an option
<azonenberg>
as i'm not using wishbone
<azonenberg>
But my uart is being used in a lot of code and works fine
<azonenberg>
by several people
<azonenberg>
the binary protocol on the wire is horrible thoguh
<lekernel>
the new one is any bus standard you feed into the migen csr generator. but I guess you won't like migen either :)
<azonenberg>
pythin :p
<azonenberg>
python*
<azonenberg>
And that's the thing, it's not a bus
<azonenberg>
it's a network
<azonenberg>
the topology isn't flat
<wpwrak>
heh, 512 samples. and i thought i was doing poorly with my ben-based "LA" and its ~8000 samples :) (of course it's a little slower than the FPGA)
<azonenberg>
wpwrak: this is able to capture signals with data rates of over 200 MHz
<lekernel>
ah, it talks to the UART through the NoC?
<azonenberg>
lekernel: The old version did not
<azonenberg>
the new version is a NoC slave
<azonenberg>
you can have a softcore download trigger conditions and pull data off
<azonenberg>
or, as i'm doing now, use the NoC-to-JTAG debug bridge to control it from a PC
<azonenberg>
Once i work out a bug in the debug bridge i'll be all set
<wpwrak>
azonenberg: oh, i thought it would be faster. the ben goes up to 56 MHz, maybe even 84 MHz on a good day
<azonenberg>
wpwrak: This is the hgihest i've tested it at
<wpwrak>
(pure capture. no decoding or display)
<azonenberg>
i'm mostly limitd by spartan6 block RAM
<azonenberg>
when i move to 7 series i'll be able to go a lot higher
<wpwrak>
seems that lekernel is right about s6 being sluggish :)
<azonenberg>
s6 block ram maxes out at like 300ish MHz
<azonenberg>
i forget the exact number, 320ish?
<azonenberg>
I could potentially go faster by DDRing the RAM bank
<azonenberg>
have two ram blocks with 180 degree phase-shifted clocks
<wpwrak>
that sounds more like it. plus, you'd double the depth.
<azonenberg>
And also double the size of the core
<azonenberg>
Which is a real concern if you want it to be small
<larsc>
linear growth is ok
<larsc>
;)
<azonenberg>
But now the minimum size of the core in the smallest provisioned size is bigger
<azonenberg>
512 is a little shallow though so i plan to fix that
<azonenberg>
first step is to get rid of this jtag race condition
<wpwrak>
(plan to fix that) sometimes a design just really really wants to go in a certain direction :)
<azonenberg>
lol well i prioritize bug fixing over new features
<wpwrak>
how unprofessional ;-)
<larsc>
sometimes you could the impression, that you are quite alone with that in the software world
<larsc>
bug fixes don't sell
<larsc>
features do
<azonenberg>
lol
<azonenberg>
but i'm not trying to sell
<azonenberg>
i want to solve my own problem :p
<azonenberg>
and that means looking sexy isn't the first priority
<azonenberg>
working is :p
<larsc>
I bet we could convince wpwrak to become your product manager ;)