| GitHub31 | [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/tfBYMw | 10:47 |
|---|---|---|
| GitHub31 | migen/master b38818e Sebastien Bourdeauducq: examples/sim/fir: convert to new API | 10:47 |
| larsc | meh, no wifi in the hospital | 13:47 |
| lekernel | are you alright? | 13:50 |
| larsc | yes | 14:25 |
| 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. | 14:28 |
| larsc | It's just like a vacation, only the food isn't that great | 14:29 |
| larsc | and the view isn't either | 14:29 |
| _florent_ | Hi | 15:42 |
| _florent_ | I've just added some methods to migen fsm: | 15:42 |
| _florent_ | http://pastebin.com/n5m1QN2i | 15:42 |
| _florent_ | I'm using this to drive logic around the fsm according to the state. | 15:42 |
| _florent_ | lekernel: are you interested by this? | 15:43 |
| larsc | _florent_: btw. if you have issue with the adv7511, I wrote the Linux driver for it and worked on the HDL reference design | 15:44 |
| _florent_ | Hi larsc | 15:44 |
| _florent_ | thanks | 15:44 |
| _florent_ | for the moment I have to do more simulation | 15:45 |
| larsc | I'd call 'exiting' 'leaving' | 15:45 |
| _florent_ | yes maybe better | 15:45 |
| lekernel | _florent_, your core would support more boards (including any M1r4 variants) if it did TMDS directly | 15:45 |
| _florent_ | yes but for that I have to use a mezzanine | 15:46 |
| larsc | Well ideally the core wouldn't care what's used to transmit the data and you can plug different frontends ontop of it | 15:47 |
| 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 | 15:47 |
| lekernel | it actually works - even Xilinx did that to prototype TMDS on the S6 boards | 15:48 |
| _florent_ | hmmm ok | 15:48 |
| _florent_ | but I don't think I will loose so much time on the ADV7511 | 15:48 |
| lekernel | just don't hook up the 5V DDC directly... but for a HDMI *source* you can get away without DDC | 15:48 |
| _florent_ | and must of what will be developped can probably be reused | 15:49 |
| _florent_ | it's just the configuration of the ADV7511 that is painful... | 15:49 |
| _florent_ | but larsc will probably be able to help me on that | 15:50 |
| _florent_ | and I've found some work on it on the net | 15:50 |
| _florent_ | http://hamsterworks.co.nz/mediawiki/index.php/Zedboard_HDMI | 15:50 |
| _florent_ | and video on spartan 6 using tdms | 15:51 |
| _florent_ | http://hamsterworks.co.nz/mediawiki/index.php/Spartan_6_1080p | 15:51 |
| lekernel | nice hack | 15:53 |
| _florent_ | yes! | 15:53 |
| lekernel | I wonder why they have serializers at all | 15:53 |
| lekernel | you could solve this sort of problems without any messy stuff with the right software | 15:54 |
| _florent_ | for the serialized at the end of the chain? | 15:55 |
| lekernel | eg something like http://raintown.org/lava/ | 15:55 |
| lekernel | that builds serializer boxes | 15:55 |
| lekernel | yes | 15:55 |
| lekernel | but software doesn't seem to be something that any FPGA company does right... | 15:55 |
| _florent_ | hardware serializer are probably faster no? | 15:56 |
| 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 | 15:57 |
| _florent_ | Ah ok, I haven't read this one yet | 15:59 |
| 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 | 16:01 |
| lekernel | and maybe as fast if you try to optimize | 16:02 |
| lekernel | and you don't have to deal with any coregen mess or *_FIFO strange behaviour | 16:02 |
| _florent_ | but with that solution you have to constraint flip-flop placement | 16:03 |
| lekernel | the BUFGs are slow - they max out at 625MHz | 16:04 |
| _florent_ | yes | 16:04 |
| lekernel | so if you want to clock anything faster you should actually not use them | 16:04 |
| _florent_ | I was looking at it the other day | 16:04 |
| lekernel | and deal with the skew in routing | 16:04 |
| lekernel | should work fine for small circuits | 16:04 |
| _florent_ | trying to undestand what you wanted to do for the ddr3 controller | 16:04 |
| _florent_ | and found like you that bufg was too slow | 16:05 |
| lekernel | yes, such circuits need to have manual placement and possibly manual routing of course | 16:06 |
| _florent_ | but for such interface it not often plug and play and you often have to adapt constraints... | 16:07 |
| lekernel | you could try python -> xdl -> NMC hard macro | 16:07 |
| _florent_ | so it's maybe not more work that for classic solution | 16:07 |
| lekernel | then you can make it flexible | 16:08 |
| lekernel | assuming xdl actually works, which it doesn't always and xilinx refuses to fix bugs | 16:08 |
| _florent_ | seems interesting | 16:09 |
| _florent_ | but I haven't time for the moment to play with that! | 16:09 |
| _florent_ | and loose time on xilinx bugs ;) | 16:10 |
| lekernel | what are the use cases for the new fsm functions? | 16:18 |
| lekernel | hmm, I begin to wonder if it would make sense to add an external clock generator chip that replaces the PLL | 16:24 |
| lekernel | then you can solve the mentioned 175 ps!!!!! jitter and have a compliant 1080p signal out of (and perhaps into) a s6 | 16:25 |
| lekernel | (!!!! added because typical clock generator chips have like, 10ps jitter. S6 is always annoying when you want more than subpar performance) | 16:26 |
| _florent_ | for the fsm: | 16:28 |
| _florent_ | I want to be able to know in which state the fsm is | 16:28 |
| _florent_ | or to trigger actions when I'm entering a state or leaving a state | 16:29 |
| lekernel | for RX phase detection will be a mess though. the IODELAYS are also massive jitter generators. | 16:29 |
| lekernel | why not use regular control signals in fsm.act()? | 16:30 |
| _florent_ | that is what I was doing before | 16:32 |
| _florent_ | but with the methods it's easier to code and to read | 16:32 |
| _florent_ | http://pastebin.com/aEbZWjfR | 16:32 |
| _florent_ | an example of code where I use it | 16:33 |
| _florent_ | but I'm not sure I will be able to convince you ;) | 16:34 |
| lekernel | that doesn't look like much of a FSM anymore :) | 16:34 |
| lekernel | you could do the same with just a state register | 16:35 |
| lekernel | and replace the .act() which only do the state transitions with a sync += ... state.eq(some_other_state) ... | 16:35 |
| lekernel | the entering() can be useful though - but I'd like it better integrated into the FSM object | 16:37 |
| _florent_ | and on what kind of code are you using fsm? | 16:37 |
| lekernel | have it more like act() | 16:38 |
| lekernel | same for exiting()/leaving() | 16:38 |
| _florent_ | because my code is purely something to code with a fsm + some logic aroud | 16:39 |
| _florent_ | *around | 16:39 |
| lekernel | ongoing() does the same thing as act(), but in a messier way imo | 16:39 |
| lekernel | you can get control signals out of the FSM | 16:39 |
| 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 | 16:40 |
| lekernel | ? | 16:40 |
| lekernel | ie there are no latches etc. | 16:41 |
| _florent_ | yes | 16:41 |
| lekernel | combinatorial signals in migen go back to their reset value when nothing drives them | 16:41 |
| _florent_ | but I will have to declare those signas | 16:41 |
| _florent_ | *signals | 16:41 |
| _florent_ | anyway, it was just an idea | 16:43 |
| _florent_ | but I think it can be useful to have such methods | 16:43 |
| lekernel | moment, writing an example transformation of some of your code | 16:44 |
| _florent_ | ok | 16:45 |
| lekernel | http://pastebin.com/ZFR6xKbm | 16:46 |
| lekernel | much clearer imo | 16:46 |
| _florent_ | thanks, maybe yes | 16:49 |
| _florent_ | that's just that I wanted to have all logic out of the fsm | 16:50 |
| lekernel | why? FSMs are a convenient way to represent sequential logic | 16:51 |
| _florent_ | but fsm coding is always a different between designers and between compagnies | 16:51 |
| lekernel | with the #2 coding style, you see immediately what happens in each state | 16:52 |
| _florent_ | for example in some compagnies, you are not allowed to drive logic in the fsm | 16:52 |
| lekernel | you don't have to go back and forth in lots of different places of the code | 16:53 |
| _florent_ | you have to create an output process that will drive signals according to fsm state... | 16:53 |
| _florent_ | yes I agree with you | 16:53 |
| lekernel | yeah well, some coding styles also mandate that you must use #some_delay before the right hand side of all assignments | 16:53 |
| lekernel | some people will never get get the delta-cycle algorithm apparently | 16:54 |
| _florent_ | So ok for the ongoing, but for the entering/leaving it can still be useful | 16:56 |
| lekernel | there's nothing wrong with driving control signals from the same FSM decoder that computes the next state | 16:57 |
| 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 | 16:58 |
| _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.... :( | 17:00 |
| lekernel | but the entering()/leaving() should have a similar API as act() | 17:00 |
| lekernel | maybe when_entering and when_leaving are better names too | 17:01 |
| lekernel | fsm.when_entering(fsm.SOME_STATE, some_statement) | 17:02 |
| lekernel | and it does something like fsm.comb += If((_state != fsm.SOME_STATE) & (_next_state == fsm.SOME_STATE), some_statement) | 17:03 |
| lekernel | same for when_leaving() | 17:03 |
| _florent_ | ok I see | 17:04 |
| lekernel | also think about what happens with delayed_enters - or prevent altogether those functions to be used when the state is in delayed_enters | 17:04 |
| _florent_ | do you want I try to implement it? | 17:04 |
| lekernel | (don't implement things until you need them - and right now, no one uses delayed_enter with when_*) | 17:05 |
| lekernel | sure, I can see it as helping your and possibly other designs | 17:05 |
| lekernel | please send the patch after :) | 17:06 |
| _florent_ | ok | 17:06 |
| 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 | 17:21 |
| lekernel | that explains why my HDMI phase detector doesn't work | 17:22 |
| lekernel | is there any S6 feature that isn't crippled and a pain to use... | 17:22 |
| 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') | 17:29 |
| _florent_ | seems Spartan 6 is not your best friend these days... | 17:41 |
| lekernel | oh, and won't the circuit fig 2-22 of ug381 go metastable? | 17:42 |
| _florent_ | On another topic: I've bought the french magazine "Open Silicium" | 17:52 |
| _florent_ | and have done a comparaison of the ressources used on the De0 Nano with the OrpSoc and Milkymist-ng: | 17:52 |
| _florent_ | with almost the same peripherals: | 17:52 |
| _florent_ | Milkymist-ng @ 100MHz / OrpSoC @ 50Mhz: | 17:52 |
| _florent_ | Milkimist-ng use 20% of the chip. | 17:52 |
| _florent_ | OrpSoc is almost 45%! | 17:53 |
| _florent_ | ;) | 17:53 |
| lekernel | :) | 18:00 |
| lekernel | http://www.ti.com/product/cdcm61004 <= could be a nice replacement for the lousy S6 PLLs | 18:00 |
| _florent_ | on video design xilinx is generally using si5324 | 18:04 |
| lekernel | cdcm61004 is actually what they use for the LHC timing system :) | 18:06 |
| larsc | and how does OrpSoc compare feature wise to mm-ng? | 18:07 |
| _florent_ | on the feature, both have cpu + sdram controller + small peripherals | 18:09 |
| _florent_ | the only thing that is not implemented in my de0-nano port is the flash controller | 18:09 |
| _florent_ | but it should not use 25% of the chip | 18:10 |
| lekernel | were you using hpdmc, or the fancy asmi-based controller? | 18:11 |
| _florent_ | the asmi | 18:12 |
| --- Wed Mar 20 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!