pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
bvernoux has joined #nmigen
bvernoux has quit [Quit: Leaving]
<lkcl>
mwbrown: there is a dreadful hack that i have used for "returning" information from yield-generators, but huge warning: it's a technique that is seriously never recommended in normal programming practice because it's considered dangerous and misleading
<lkcl>
store the "return" result in a member class instance
<lkcl>
after "yielding" from a given generator the "result" can be picked up, self.{insertinstancename}
<lkcl>
if you use that technique i strongly, STRONGLY recommend that you put in code comments each and every time explaining what is going on
bvernoux has joined #nmigen
emeb has joined #nmigen
<d1b2>
<ronyrus> hi. is there a good way to debug high utilization (TRELLIS_SLICE: 11425/12144 94%)? I'm guessing that's due to a bad design/decisions of the logic, but how to I understand which parts?
<gatecat>
ronyrus: you can run synth_ecp5 with '-noflatten' to get a hierarchical usage report out of Yosys
<d1b2>
<ronyrus> is it something that I pass through NMIGEN_ENV_Trellis? I need to add it into nextpnr_opts iiuc, but not entirely sure what's the easiest and the preferred option.
<hve>
Vendor backend can than try to solve te rest:
<hve>
setup configuration and supplying a lock singnal if so requested...
<hve>
based no target freq it can decide if it has to implement HS or LS plls ...
<hve>
I have seen 425 an such a thing cannot be done lightly in order to keep things clean...
<hve>
maibe experiment a bit with a few of the proposals in nmigen.__expiremental__ ?
<hve>
m.domains += ClockDomainDerived( ... )
<vup>
Apart from some minor inconveniences you can just start prototyping something like this out of tree
<vup>
doing it in-tree seems like a unnecessary maintance burden imo
<hve>
Forget about doing in tree, I am not concerned about about that.
<hve>
This is more of a brainstorm on what would be good language construct.
<vup>
Also I am not convinced ClockDomainDerived is right interface. For example, if my platform has a dynamically configurable PLL, how do I obtain the configuration interface that belongs to the PLL that was used by my ClockDomainDerived call?
<vup>
I think the first step would be a abstraction around the available PLLs of the different platforms that gives you something like a PLL module with a common interface between all platforms
<hve>
Yes not thought about that. Maybe you could store something of a manager construct?
<vup>
after that one can think about adding helpers like ClockDomainDerived, but I am not even convinced such helpers will be very useful in general, as (atleast for the designs where I used PLLs) one usually needs very specific PLL / clocking setups and not just some arbitrary thing that gives you the correct frequency / phase
<hve>
Can you give an example?
<vup>
anything that uses a serdes that needs a word clock and a bit clock for example usually want both of these clocks generated by the same PLL
<vup>
things get even more complex for platforms like ECP5 where there are actual primitives seperate from PLLs to generate the word clock for a serdes
<vup>
should that be covered by the API or not?
<hve>
You could call ClockDomainDerived(cd ..) Multiple times with different patrameters...
<vup>
would that interface guarantee that it will use the same PLL?
<vup>
what if i created 5 other clock domains that would not necessarily need to use the same PLL, but now I want a sixth clock domain that uses the same PLL as the first clock domain, but my PLL only supports five outputs?
<hve>
I think yes, as it will pass back control to the manager and it will see that th clock is derived from the same CD
<vup>
in general this interface seems like it could change the clocking structure dramatically depending on which modules you include in your design, or even the order in which you do, which seems suboptimal
<whitequark>
I concur with vup
<whitequark>
these are the reasons such an abstraction doesn't exist
<hve>
Of course if you want more control you will have to specify more attributes... Nothing is for free..
<hve>
Similar with the resource allocation...
<whitequark>
that is, doesn't exist now. something like it may appear in the future
<whitequark>
but it's very tricky to design such that it will be useful
<hve>
I know
<hve>
Just looking at the ecp5 plls they seem pretty simple, I have seen worse..
<d1b2>
<zyp> a generic abstraction would simplify trivial stuff, but as soon as you start getting some complexity you need to start making architectural considerations
<whitequark>
it's possible to make a useful abstraction that takes architecture into account
<whitequark>
not to hide the details of platform-specific PLLs; but to unify them
<hve>
I think so too.
<hve>
I think that before migen nobody could have imagined how far we have come today. The OS synt. tools are just amazing!
<hve>
Something like an out of tree experiment would be usefull. I used the ECP5PLL contruct from Litex which was quite usefull..
<hve>
It could be improved though, both in terms of configuration and I dislike the fact that it is non generic.
<hve>
Thanks for sharing your thoughts gents!
<vup>
sure I also would like something generic and with easy configuration, it just has to be usable with more complex setups aswell, or atleast on prevent one from creating more complex setups by hand
<vup>
if you start creating something more generic feel free to share it, I am very interested with what you come up
<hve>
Thanks Vup, would be helpfull if there are some examples of these complex setups.
<hve>
For the initial setup I will already be happy if i can control frequency and phase within acceptable limits. These dynamic designs migth be tricky I have never used them.
<hve>
Also might need to resort to manual configuration for some usecases, but lets hope tha over time they become less and less :)
hve has quit [Quit: Leaving]
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 240 seconds]
<vup>
things I can think of:
<vup>
1. access to the dynamic reconfiguration port or dynamic phase configuration
<vup>
5. potentially support for using simpler primitives instead of a PLL (for example if just division by 2 or 4 is needed use a BUFR on 7series)
<vup>
3. support for chained PLLs, for example some frequencies might not be able to be generated by using one PLL, but can be generated by chaining two PLLs, (this again has constraints on which ports might be used, for exampte on 7series on can only cascade using CLKOUT0 through 3)
<vup>
2. support for non equal PLL output ports, for example the first output of the 7series MMCM PLL has a fractional divider, the others not. If I first request some domains that don't need the fractional divider and then one that does it would be nice if that would actually work. (this seems like it would need to collect all the requested domains and then try to find a solution for the requested problem)
<vup>
4. support for forcing two requested domain to use the same PLL
<vup>
6. spread spectrum clock generation
<vup>
7. anything to do with (custom) feedback paths
<vup>
8. correct clock buffer insertion for certain setups (like deskew setups), where the feedback clock should go through the same buffer as the output clock (for example a BUFH on 7series)
bvernoux has quit [Quit: Leaving]
emeb_mac has joined #nmigen
emeb has quit [Ping timeout: 240 seconds]
emeb_mac has quit [Ping timeout: 250 seconds]
emeb_mac has joined #nmigen
emeb has joined #nmigen
emeb has quit [Ping timeout: 245 seconds]
emeb_mac has quit [Ping timeout: 252 seconds]
emeb has joined #nmigen
emeb_mac has joined #nmigen
pftbest has quit [Remote host closed the connection]