<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_>
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>
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: