_florent_ | Hi | 13:11 |
---|---|---|
_florent_ | a small question about mibuild: | 13:11 |
_florent_ | when defining for example a led bus constraint, I can use: | 13:12 |
_florent_ | solution 1: | 13:12 |
_florent_ | ("led", 0, Pins("X"), IOStandard("X")), | 13:12 |
_florent_ | ... | 13:12 |
_florent_ | ("led", N, Pins("X"), IOStandard("X")), | 13:12 |
_florent_ | or solution 2: | 13:12 |
_florent_ | ("led", 0, Pins("X0", ..., "Xn"), IOStandard("X")), | 13:13 |
_florent_ | Advantage of solution 1 is that I can connect individually each led | 13:13 |
_florent_ | but when I want to use led as a N bits bus, I was expecting mibuild to assign each led bus bit to the individual constraints. | 13:13 |
_florent_ | It seems it is not the case or I'm miss understanding something... | 13:13 |
_florent_ | Is this behaviour implemented in mibuild? | 13:13 |
lekernel | unless there is a bug somewhere, #2 works | 13:26 |
lekernel | I'm doing that on rhino and m1 (but xilinx fpgas) | 13:27 |
_florent_ | using solution 1 with a bus? | 13:27 |
lekernel | solution 2 | 13:28 |
_florent_ | ah ok | 13:28 |
lekernel | eg https://github.com/milkymist/mibuild/blob/master/mibuild/platforms/m1.py#L17 | 13:28 |
_florent_ | in fact I want advantage of both : declaring as solution 1 and using it with individual signal or bus ;) | 13:28 |
lekernel | ah sorry, I misunderstood your question | 13:29 |
_florent_ | no pb | 13:29 |
lekernel | no, there is nothing implemented for obtaining part of a resource | 13:30 |
_florent_ | hmm ok, do you want that I try to implement it? | 13:31 |
lekernel | I like the simplicity of the current solution, but if you feel there's a real need for that, you can try proposing something else... | 13:32 |
lekernel | you could also just have some "resource builder" functions... that return solution 1 | 13:33 |
_florent_ | I can try that | 13:34 |
_florent_ | that's just that I do want to change the platform file according design I'm implementing | 13:35 |
lekernel | anyone has done tests on the hard IOB and routing switching limits? | 20:33 |
lekernel | connect output pin to input pin, and increase frequency until the fpga can't keep up | 20:33 |
lekernel | considering that the PLLs have a VCO with 8 phases that goes over 1 GHz, if you can manage skew, jitter and IOB/routing switching you should be able to sample IO over the 950MHz offered by ISERDES | 20:36 |
_florent_ | the implementation of what I was asking in the afternoon: | 20:46 |
_florent_ | https://github.com/Florent-Kermarrec/mibuild/commit/cd64b55fadd188cf28cc90444402ed5ace719d16 | 20:46 |
_florent_ | with that you can declare bus as individual constraints and use them as bus in the build.py | 20:47 |
_florent_ | and about the fsm we were talking yesterday: | 20:49 |
_florent_ | https://github.com/Florent-Kermarrec/migen/commit/3d38b370f76e551d925c66a245740b0d35e3bf2d | 20:49 |
lekernel | this code is modifying the platform description | 20:50 |
lekernel | _ressource_regroup(self.description, r) then description.remove(ressource) | 20:50 |
lekernel | request() should only register requests, not do any actual matching | 20:50 |
lekernel | and then, even _match doesn't modify the platform description | 20:51 |
_florent_ | yes that's maybe not very clean, you see a better place to do it? | 20:52 |
lekernel | to be honest I don't see a need for that, you can simply call request() in a loop when you need to do this sort of thing (which probably isn't often, I think) | 20:54 |
_florent_ | iirc it was not working with a loop | 20:56 |
lekernel | for i in range(8): plat.request("led", i, leds[i]) - you may need to make it accept signal slices | 20:56 |
_florent_ | slice object was not working iirc | 20:57 |
lekernel | for i in range(8): self.comb += plat.request("led", i).eq(leds[i]) would definitely work | 20:58 |
_florent_ | ok thanks | 20:59 |
_florent_ | for the moment I will use my solution, but if I realize I don't really need it I will switch to yours | 21:01 |
lekernel | why use last_state instead of next_state? | 21:02 |
lekernel | https://github.com/Florent-Kermarrec/migen/commit/3d38b370f76e551d925c66a245740b0d35e3bf2d#L0R60 -> iteration order on dicts isn't deterministic, so this will generate a different (but equivalent) code each time it's run | 21:05 |
lekernel | and you don't need a dict, you can iterate on self.when_entering_actions directly | 21:06 |
_florent_ | for last_state vs next_state, I'm executing the actions only when I am in the state and when I'm out of the state, but it's maybe better with next_state | 21:08 |
_florent_ | since when_entering is executed in my code when I'm already in | 21:08 |
lekernel | yes, there is a one clock cycle difference | 21:09 |
lekernel | and with last_state it results in shorter combinatorial paths which is always good eg when using slowtan 6 | 21:09 |
lekernel | but it takes one more register | 21:10 |
lekernel | both solutions are ok, I just want to make sure we understand the difference | 21:10 |
_florent_ | my need for when_entering is generally to trigger an action on the first clock cycle of a state | 21:11 |
lekernel | so 1) remove the when_entering_cases/when_leaving_cases dicts and iterate on the lists directly 2) remove the old entering()/leaving() functions | 21:11 |
lekernel | and it's ok | 21:11 |
lekernel | alternatively, make everything dicts in the first place (you can use defaultdict(list)) | 21:12 |
_florent_ | just that I'd like to keep the entering & leaving since It can be useful for others needs... | 21:13 |
lekernel | but you'll need to order by key when adding to the comb list, otherwise there will be non-determinism problems | 21:13 |
lekernel | no, all code that doesn't have an actual use case should be removed | 21:14 |
_florent_ | I'm using it ;) ( I found it useful, just want to keep it in my fork, but I understand if you don't want it) | 21:18 |
lekernel | how about you just reference _state etc. directly? | 21:18 |
lekernel | and why not replace with when_* functions? | 21:19 |
_florent_ | and use it like: | 21:21 |
_florent_ | when_entering(fsm, fsm.WRITE)? | 21:21 |
lekernel | I'm also wondering how the synthesizers (which do FSM extraction and optimization) like the last_state register ... | 21:21 |
lekernel | have you done some testing on that? | 21:21 |
_florent_ | It's working on board for my test, but I haven't look at ressources | 21:22 |
lekernel | look especially at timing, FPGAs are reasonably large, but painfully slow | 21:23 |
_florent_ | ok I'll try to have a look at this | 21:25 |
_florent_ | about using the functions, what were you describing exaclty? | 21:26 |
_florent_ | what I said: | 21:26 |
_florent_ | when_entering(fsm, fsm.WRITE)? | 21:26 |
_florent_ | or something else | 21:26 |
lekernel | it's fsm.when_entering(fsm.STATE, ...) no? | 21:27 |
_florent_ | ah sorry I miss understand your question about that | 21:29 |
_florent_ | the thing is that if I want to make a synchronous assignement, I'm not able to use when_* functions and will need to use an intermediary signal | 21:30 |
_florent_ | but I don't want to bother you with that... | 21:31 |
lekernel | you can use a control signal instead | 21:31 |
lekernel | btw - if synthesizers fail to deal with the extra register correctly, then the solution is to make the FSM object insert extra "transition" states | 21:36 |
lekernel | ah, he left | 21:37 |
_florent_ | I have to go | 21:38 |
_florent_ | gn8 | 21:38 |
Fallenou | slowtan 6 : lol | 22:10 |
Action: Fallenou backing up his SSD using Ubuntu ... | 22:10 | |
Fallenou | Ubuntu was able to repair HFS+ partition =) | 22:10 |
GitHub167 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/S09m4Q | 23:47 |
GitHub167 | milkymist-ng/master 0a14c37 Sebastien Bourdeauducq: dvisampler: software controlled phase detector | 23:47 |
--- Thu Mar 21 2013 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!