| --- Log opened Tue Dec 06 00:00:15 2016 | ||
| kc5tja | Oh, heh, the B4 specifications changed the name to "Dataflow" configuration. Wise idea. | 00:59 |
|---|---|---|
| shorne | kc5tja: where did you see that news about wishbone? | 06:22 |
| ZipCPU|Laptop | kc5tja: I missed your last comment last night. Looking back now, shorne's comment makes sense. Where'd you see the name change from 'pipeline' to dataflow'? | 09:34 |
| ZipCPU|Laptop | kc5tja: One other question, are you familiar with the pipelined wishbone to AXI bridge I built and posted on GitHub? | 09:35 |
| ZipCPU|Laptop | I'd really like to do an AXI to Wishbone pipelined bridge, but ... I don't have any AXI masters to test it with. ;) | 09:35 |
| kc5tja | shorne: In the B3 specs, the "dataflow" connection was labeled "pipeline". In B4, it's labeled "dataflow". | 10:40 |
| kc5tja | ZipCPU|Laptop: Why not have two bridges back to back? Wishbone -> AXI -> AXI -> Wishbone All the bus transactions should come out the same on both ends of the interconnection. | 10:41 |
| ZipCPU|Laptop | kc5tja: While that would be easy enough to do, it isn't a representative test. AXI allows for, as you've been noting, multiple independent transactions to fly through the bus at any given time. | 10:44 |
| ZipCPU|Laptop | AXI allows for one read and one write transaction to be issued on every clock. Wishbone only allows one of those two. | 10:44 |
| kc5tja | Yes, but as a basic "minimum viable functionality" test, I think it's a good foundation. If it can't be used back-to-back, it is guaranteed it'll fail under more sophisticated use-cases. | 10:47 |
| kc5tja | But, I understand the need for a real AXI master. | 10:47 |
| --- Log closed Wed Dec 07 00:00:16 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!