lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
jimmythehorn has quit [Quit: jimmythehorn]
gbraad has joined #milkymist
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #milkymist
antgreen_ has joined #milkymist
antgreen has quit [Ping timeout: 245 seconds]
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
xiangfu has quit [Ping timeout: 256 seconds]
xiangfu has joined #milkymist
_whitelogger has joined #milkymist
_whitelogger_ has joined #milkymist
_whitelogger_ has joined #milkymist
_whitelogger_ has quit [Remote host closed the connection]
mumptai has joined #milkymist
lekernel has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
mumptai has quit [Ping timeout: 272 seconds]
<GitHub31> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/tfBYMw
<GitHub31> migen/master b38818e Sebastien Bourdeauducq: examples/sim/fir: convert to new API
xiangfu has quit [Ping timeout: 240 seconds]
xiangfu has joined #milkymist
antgreen_ has quit [Ping timeout: 245 seconds]
xiangfu has quit [Ping timeout: 248 seconds]
xiangfu has joined #milkymist
<larsc> meh, no wifi in the hospital
<lekernel> are you alright?
xiangfu has quit [Ping timeout: 245 seconds]
xiangfu has joined #milkymist
<larsc> yes
<larsc> I'm going to have surgery tomorrow. They are going to cut a bit of tissue out of me. But I'm not in pain and the mind in is fit as well.
<larsc> It's just like a vacation, only the food isn't that great
<larsc> and the view isn't either
gbraad has quit [Ping timeout: 264 seconds]
xiangfu has quit [Ping timeout: 245 seconds]
xiangfu has joined #milkymist
robmyers_ has joined #milkymist
qi-bot0 has joined #milkymist
playthatbeat has quit [*.net *.split]
qi-bot has quit [*.net *.split]
robmyers has quit [*.net *.split]
qi-bot0 is now known as qi-bot
playthatbeat has joined #milkymist
_florent_ has joined #milkymist
<_florent_> Hi
<_florent_> I've just added some methods to migen fsm:
<_florent_> I'm using this to drive logic around the fsm according to the state.
<_florent_> lekernel: are you interested by this?
<larsc> _florent_: btw. if you have issue with the adv7511, I wrote the Linux driver for it and worked on the HDL reference design
<_florent_> Hi larsc
<_florent_> thanks
<_florent_> for the moment I have to do more simulation
<larsc> I'd call 'exiting' 'leaving'
<_florent_> yes maybe better
<lekernel> _florent_, your core would support more boards (including any M1r4 variants) if it did TMDS directly
<_florent_> yes but for that I have to use a mezzanine
<larsc> Well ideally the core wouldn't care what's used to transmit the data and you can plug different frontends ontop of it
<lekernel> well, you can get a $15 LPC connector from Samtec plus a 2E hdmi cable, cut the latter in half, and solder it to the LPC
<lekernel> it actually works - even Xilinx did that to prototype TMDS on the S6 boards
<_florent_> hmmm ok
<_florent_> but I don't think I will loose so much time on the ADV7511
<lekernel> just don't hook up the 5V DDC directly... but for a HDMI *source* you can get away without DDC
<_florent_> and must of what will be developped can probably be reused
<_florent_> it's just the configuration of the ADV7511 that is painful...
<_florent_> but larsc will probably be able to help me on that
<_florent_> and I've found some work on it on the net
<_florent_> and video on spartan 6 using tdms
<lekernel> nice hack
<_florent_> yes!
<lekernel> I wonder why they have serializers at all
<lekernel> you could solve this sort of problems without any messy stuff with the right software
<_florent_> for the serialized at the end of the chain?
<lekernel> eg something like http://raintown.org/lava/
<lekernel> that builds serializer boxes
<lekernel> yes
<lekernel> but software doesn't seem to be something that any FPGA company does right...
<_florent_> hardware serializer are probably faster no?
<lekernel> nope. http://hamsterworks.co.nz/mediawiki/index.php/Spartan_6_1080p describes a soft serializer which is almost 50% faster than the hard one
<_florent_> Ah ok, I haven't read this one yet
<lekernel> similarly, if you want to receive DDR3 data, sending DQS to local interconnect (as opposed to BUFG) and then to the clock pins of flip-flops seems to work almost as fast as the IN_FIFO and OUT_FIFO of the 7-series
<lekernel> and maybe as fast if you try to optimize
<lekernel> and you don't have to deal with any coregen mess or *_FIFO strange behaviour
<_florent_> but with that solution you have to constraint flip-flop placement
<lekernel> the BUFGs are slow - they max out at 625MHz
<_florent_> yes
<lekernel> so if you want to clock anything faster you should actually not use them
<_florent_> I was looking at it the other day
<lekernel> and deal with the skew in routing
<lekernel> should work fine for small circuits
<_florent_> trying to undestand what you wanted to do for the ddr3 controller
<_florent_> and found like you that bufg was too slow
<lekernel> yes, such circuits need to have manual placement and possibly manual routing of course
<_florent_> but for such interface it not often plug and play and you often have to adapt constraints...
<lekernel> you could try python -> xdl -> NMC hard macro
<_florent_> so it's maybe not more work that for classic solution
<lekernel> then you can make it flexible
<lekernel> assuming xdl actually works, which it doesn't always and xilinx refuses to fix bugs
<_florent_> seems interesting
<_florent_> but I haven't time for the moment to play with that!
<_florent_> and loose time on xilinx bugs ;)
<lekernel> what are the use cases for the new fsm functions?
<lekernel> hmm, I begin to wonder if it would make sense to add an external clock generator chip that replaces the PLL
<lekernel> then you can solve the mentioned 175 ps!!!!! jitter and have a compliant 1080p signal out of (and perhaps into) a s6
<lekernel> (!!!! added because typical clock generator chips have like, 10ps jitter. S6 is always annoying when you want more than subpar performance)
<_florent_> for the fsm:
<_florent_> I want to be able to know in which state the fsm is
<_florent_> or to trigger actions when I'm entering a state or leaving a state
<lekernel> for RX phase detection will be a mess though. the IODELAYS are also massive jitter generators.
<lekernel> why not use regular control signals in fsm.act()?
<_florent_> that is what I was doing before
<_florent_> but with the methods it's easier to code and to read
<_florent_> an example of code where I use it
<_florent_> but I'm not sure I will be able to convince you ;)
<lekernel> that doesn't look like much of a FSM anymore :)
<lekernel> you could do the same with just a state register
<lekernel> and replace the .act() which only do the state transitions with a sync += ... state.eq(some_other_state) ...
<lekernel> the entering() can be useful though - but I'd like it better integrated into the FSM object
<_florent_> and on what kind of code are you using fsm?
<lekernel> have it more like act()
<lekernel> same for exiting()/leaving()
<_florent_> because my code is purely something to code with a fsm + some logic aroud
<_florent_> *around
<lekernel> ongoing() does the same thing as act(), but in a messier way imo
<lekernel> you can get control signals out of the FSM
<lekernel> have you noticed that when you do some_signal.eq(1) in act(), then some_signal has always the value 0 except when the FSM is in that state
<lekernel> ?
<lekernel> ie there are no latches etc.
<_florent_> yes
<lekernel> combinatorial signals in migen go back to their reset value when nothing drives them
<_florent_> but I will have to declare those signas
<_florent_> *signals
<_florent_> anyway, it was just an idea
<_florent_> but I think it can be useful to have such methods
<lekernel> moment, writing an example transformation of some of your code
<_florent_> ok
<lekernel> much clearer imo
<_florent_> thanks, maybe yes
<_florent_> that's just that I wanted to have all logic out of the fsm
<lekernel> why? FSMs are a convenient way to represent sequential logic
<_florent_> but fsm coding is always a different between designers and between compagnies
<lekernel> with the #2 coding style, you see immediately what happens in each state
<_florent_> for example in some compagnies, you are not allowed to drive logic in the fsm
<lekernel> you don't have to go back and forth in lots of different places of the code
<_florent_> you have to create an output process that will drive signals according to fsm state...
<_florent_> yes I agree with you
jimmythehorn has joined #milkymist
<lekernel> yeah well, some coding styles also mandate that you must use #some_delay before the right hand side of all assignments
<lekernel> some people will never get get the delta-cycle algorithm apparently
<_florent_> So ok for the ongoing, but for the entering/leaving it can still be useful
<lekernel> there's nothing wrong with driving control signals from the same FSM decoder that computes the next state
<lekernel> yeh, sometimes you need to do something at all times before entering/when leaving some state, and ensuring that manually is tedious and sometimes you forget - that's how bugs appear
<_florent_> I know that there is nothing wrong with driving control signals in the fsm, that just some DO254 codings rules that are beginning to pollutes me.... :(
<lekernel> but the entering()/leaving() should have a similar API as act()
<lekernel> maybe when_entering and when_leaving are better names too
<lekernel> fsm.when_entering(fsm.SOME_STATE, some_statement)
<lekernel> and it does something like fsm.comb += If((_state != fsm.SOME_STATE) & (_next_state == fsm.SOME_STATE), some_statement)
<lekernel> same for when_leaving()
<_florent_> ok I see
<lekernel> also think about what happens with delayed_enters - or prevent altogether those functions to be used when the state is in delayed_enters
<_florent_> do you want I try to implement it?
<lekernel> (don't implement things until you need them - and right now, no one uses delayed_enter with when_*)
<lekernel> sure, I can see it as helping your and possibly other designs
<lekernel> please send the patch after :)
<_florent_> ok
<lekernel> ah, the spartan 6 IODELAYs, on top of generating massive jitter and having a PVT factor of 300%, can only delay signals by one bit period maximum
<lekernel> that explains why my HDMI phase detector doesn't work
<lekernel> is there any S6 feature that isn't crippled and a pain to use...
<lekernel> (it's actually even worse than 300%: they are specd for a 'maximum' delay, and then a footnote in the datasheet says 'minimum delay is *typically* 30% of maximum delay')
<_florent_> seems Spartan 6 is not your best friend these days...
<lekernel> oh, and won't the circuit fig 2-22 of ug381 go metastable?
antgreen_ has joined #milkymist
<_florent_> On another topic: I've bought the french magazine "Open Silicium"
<_florent_> and have done a comparaison of the ressources used on the De0 Nano with the OrpSoc and Milkymist-ng:
<_florent_> with almost the same peripherals:
<_florent_> Milkymist-ng @ 100MHz / OrpSoC @ 50Mhz:
<_florent_> Milkimist-ng use 20% of the chip.
<_florent_> OrpSoc is almost 45%!
<_florent_> ;)
<lekernel> :)
<lekernel> http://www.ti.com/product/cdcm61004 <= could be a nice replacement for the lousy S6 PLLs
antgreen_ has quit [Ping timeout: 256 seconds]
<_florent_> on video design xilinx is generally using si5324
<lekernel> cdcm61004 is actually what they use for the LHC timing system :)
<larsc> and how does OrpSoc compare feature wise to mm-ng?
<_florent_> on the feature, both have cpu + sdram controller + small peripherals
<_florent_> the only thing that is not implemented in my de0-nano port is the flash controller
<_florent_> but it should not use 25% of the chip
<lekernel> were you using hpdmc, or the fancy asmi-based controller?
<_florent_> the asmi
antgreen_ has joined #milkymist
xiangfu has quit [Ping timeout: 264 seconds]
antgreen_ has quit [Ping timeout: 245 seconds]
antgreen_ has joined #milkymist
mumptai has joined #milkymist
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
bhamilton has joined #milkymist
antgreen_ has quit [Quit: Leaving]
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
_florent_ has quit [Quit: Page closed]
bhamilton has quit [Quit: Leaving.]
lekernel has quit [Ping timeout: 255 seconds]
kyak has quit [Read error: Operation timed out]
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 264 seconds]
mumptai has quit [Ping timeout: 264 seconds]