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
<GitHub110> migen/master c10622f Sebastien Bourdeauducq: fhdl/verilog: insert reset before listing signals
qwebirc72236 has quit [Ping timeout: 245 seconds]
jimmythehorn has joined #milkymist
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has joined #milkymist
lekernel has quit [Ping timeout: 248 seconds]
fsk has quit [Quit: fsk]
lekernel has joined #milkymist
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]]
digshadow has joined #milkymist
digshadow has quit [Client Quit]
mumptai has joined #milkymist
mumptai has quit [Quit: Verlassend]
<lekernel> azonenberg, your cmakefile still generates a makefile when gtkmm is not found
<lekernel> (and then the build fails)
<lekernel> for red tin
<azonenberg> lekernel: Hmm, i'll fix that
<azonenberg> The stuff in the google code repo is actually somewhat out of date
<azonenberg> version 0.2 is in the repo with my thesis
<azonenberg> it uses a lot of the same build infrastructure
<azonenberg> and i havent had the time to split it off and push back
<lekernel> where can I find that new repo?
<azonenberg> It's not public at the moment because my VPS provider is oversubscribing me and i dont even have enough capacity for myself
<azonenberg> i'm in the process of changing hosts
<lekernel> Project and inventory management system written in PHP [END OF LIFE] << lol
<lekernel> just use github
<azonenberg> i'm still SVN based
<lekernel> why write "module(some_signal); input wire some_signal;" instead of "module(input some_signal);" ?
<lekernel> btw I think you can infer SRLC32E and get rid of xilinx-specific code
<azonenberg> I need detailed control over the primitives in order to do the partial reconfig properly
jimmythehorn has quit [Remote host closed the connection]
<azonenberg> i have to make sure it's exactly one level of logic
jimmythehorn has joined #milkymist
<azonenberg> anyway the JTAG stuff (not in that code version) is inherently xilinx specific
<lekernel> you can describe the reconfiguration behaviour
<lekernel> and Xst should pack it into a SRLC32E correctly
<azonenberg> I've had bad experiences with inference in such cases
<azonenberg> In order to get maximum speed i'm pretty sure that device-specific optimizations are necessary
<azonenberg> i plan to make an altera port at some point too
<azonenberg> with the same capabilities
<azonenberg> and probably re-using a lot of the logic
<lekernel> if you use the correct code patterns, you should get *exactly* the same SRLC32E
<azonenberg> i've been able to infer fixed-address shift registers
<lekernel> plus, it's easier to simulate, and it will work to some extent on non-xilinx fpgas
<azonenberg> but not variable-address ones
<lekernel> according to the xilinx libraries guide, the variable address one can be inferred to
<lekernel> too
<azonenberg> i'll look, i just know that i've had difficulty convincing the tools to do it
<azonenberg> bear in mind that code that infers properly for xilinx may not infer properly on altera
<azonenberg> and thus still need vendor-specific tuning
<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 ;)
<wpwrak> heh ;-)
jimmythehorn_ has joined #milkymist