| --- Log opened Wed Aug 26 00:00:16 2015 | ||
| olofk | robtaylor: That's a great idea. Thanks | 06:26 |
|---|---|---|
| robtaylor | olofk: you'll like this read http://www.eetimes.com/author.asp?section_id=36&doc_id=1327291 | 11:48 |
| robtaylor | and http://www.eetimes.com/author.asp?section_id=36&doc_id=1327323 | 11:49 |
| latif | Hi all.. As some of you know I am still trying to solve the problems about the orpsocv3(fusesoc) on ATLYS board. Firstly, I can say that the bootrom.S code in orpsocv2 is used for these tries. I just wanted to put a led blinker assembly code in bootrom to see if it is working properly or not. Then, I can say that in orpsocv2 everything is normal. Leds are blinking even if you boot from spi flash or program fpga directly with a bit fil | 12:29 |
| latif | Again: I have tried both (from spi flash and directly programming FPGA) ways but I am now sure about that now: There is another issue with it. | 12:31 |
| latif | I think the biggest issue is that: Why we can not produce bit file from orpsocv3 (atlys)(fusesoc) without changing .ucf dvi_gen and clk_gen modules?? Some said me that It is about the Xlinix but I dont think so. Because I used differetn versions of Xlinix but the result is the same. Some of signals could not be routed and there are a few not-met timing constraints. So this cannot be a xlinix bug!! | 12:36 |
| latif | SO I dont think that we have a problem with bootrom codes. The problem is something bigger.! | 12:38 |
| latif | Hi all.. As some of you know I am still trying to solve the problems about the orpsocv3(fusesoc) on ATLYS board. Firstly, I can say that the bootrom.S code in orpsocv2 is used for these tries. I just wanted to put a led blinker assembly code in bootrom to see if it is working properly or not. Then, I can say that in orpsocv2 everything is normal. Leds are blinking even if you boot from spi flash or program fpga directly with a bit fil | 14:40 |
| latif | Again: I have tried both (from spi flash and directly programming FPGA) ways but I am now sure about that now: There is another issue with it. | 14:40 |
| latif | I think the biggest issue is that: Why we can not produce bit file from orpsocv3 (atlys)(fusesoc) without changing .ucf dvi_gen and clk_gen modules?? Some said me that It is about the Xlinix but I dont think so. Because I used differetn versions of Xlinix but the result is the same. Some of signals could not be routed and there are a few not-met timing constraints. So this cannot be a xlinix bug!! | 14:41 |
| latif | SO I dont think that we have a problem with bootrom codes. The problem is something bigger.! | 14:41 |
| bandvig | latif: please find whole my rom.v module on http://pastie.org/10377702 I use it for Atlys. Pay attention, I don't use `include "bootrom.v", but I use appropriate content explicitly. | 19:23 |
| andrzejr | Hi, I've pushed a number of cores for nexys4ddr system to https://github.com/andrzej-r/orpsoc-cores/tree/nexys4ddr | 19:43 |
| andrzejr | Wishbone adapter for DDR2 i/f and a nexys4ddr top-level will follow soon(-ish). | 19:44 |
| robtaylor | andrzejr: nice! | 19:44 |
| andrzejr | the modules in the repository can be used for experimenting with new fusesoc features - xsim/isim simulators, coregen code generator. | 19:45 |
| andrzejr | Also, I'm using a new systems/* directory layout with system-specific cores placed in the systems/nexys4ddr directory. The top-level will be just another core (a nice side-effect is that there may be more than one top-levels for this board). | 19:47 |
| andrzejr | I am also planing adding new fusesoc providers for wb_interconn and rom generators. Not sure how to handle the latter (should it just be a generic "make" provider?) | 19:49 |
| andrzejr | olofk^ ? | 19:49 |
| olofk | andrzejr: Not sure. Haven't given it any thought | 19:51 |
| olofk | And great work with the FuseSoC additions and Nexys4 support. Looking forward to take a look at your work when I can find a little tim | 19:51 |
| olofk | e | 19:51 |
| andrzejr | I've been looking into the bus issues - 7-series Xilinx FPGAs use a custom bus for interfacing to the DRAM controller, which is very similar to your bus. | 19:53 |
| andrzejr | It is very tempting to connect cache controller in Mor1kx directly to DDR controller, but it is a bit too much for me atm. | 19:54 |
| stekern | andrzejr: it probably shouldn't be too complicated to make a seperate bus interface for it | 19:56 |
| andrzejr | my current plan is to design a robust but not very efficient (no caching/prefetching) wishbone<->"ui bus" interface (almost done but there are still bugs in it). And, in a future version, connect mor1kx's cache controller directly to "ui bus". | 19:58 |
| andrzejr | stekern, yes, that would require a separate bus i/f. In fact, mor1kx should still have wishbone interface, which would be used when cache is not enabled. | 19:59 |
| andrzejr | the efficient bus only makes sense for asynchronous cache<->memory transfers, and only when cache controller acts as a bus master. | 20:00 |
| stekern | right | 20:02 |
| andrzejr | to be more specific, I meant a bus hierarchy like this: http://pastebin.com/gG51rp5V | 20:13 |
| andrzejr | where WB2Async bridge is a bidirectional bridge (can act as both master and slave for each bus) | 20:15 |
| olofk | andrzejr: That looks good | 20:31 |
| olofk | Is the "async" bus something similar to my proposal? | 20:31 |
| andrzejr | yes, although IMHO it should be wider than 32b | 20:32 |
| olofk | And the Xilinx UI bus has been one of the inspirations for my CAMD bus. | 20:32 |
| andrzejr | "UI bus" defaults to 128bits with 1/4 DDR clock rate | 20:32 |
| olofk | Yes. My CAMD bus was intended be as wide as it needs | 20:33 |
| andrzejr | the existing bridge(s) assume equal widths of WB and CAMD buses, but that could be changed. | 20:34 |
| olofk | I would vote for a separate resize component so that it can be reused in other places | 20:35 |
| andrzejr | My WB<->UI adapter is not very different from WB<->CAMD bridge. | 20:36 |
| olofk | No, I guess that would be pretty similar | 20:37 |
| andrzejr | not sure if it is easy to abstract out the "resizer" from a bridge. This function is pretty tightly coupled with the rest of the bridge. But the bridge with resizing could quite easily be configurable. | 20:38 |
| olofk | That's true. A generic one might lose performance | 20:38 |
| andrzejr | BTW, I am now supporting all transaction types but I gave up caching/prefetching. The reason is that performance sensitive traffic should not go through such bridge (should use CAMD/UI only) | 20:39 |
| andrzejr | One more question, should we support CDC in such bridge? | 20:40 |
| olofk | stekern has a nice component as part of wb_sdram_ctrl that introduces a multi-port cache | 20:40 |
| olofk | I've been trying to extract that with CAMD interface on the slave ports and the master port | 20:40 |
| olofk | To be used as a multi-port frontend/system level cache for DRAM interfaces | 20:41 |
| andrzejr | at the moment I assume separate but synchronous clocks. But we could just clock the whole system from a "UI clock" generated inside the DDR controller. | 20:41 |
| olofk | I like separate CDC components, but to make the top-level cleaner, a CDC component can be put inside the bridge | 20:42 |
| andrzejr | Still not sure about the cache - CAMD would be used for connecting *cache* to DRAM, so IMHO there is no need for extra caching. And prefetching would be better done inside the CPU's cache controller. | 20:43 |
| andrzejr | In nexys4ddr I was planning to assign wb_clk = ui_clk. It is the same frequency anyway and we could reduce the latency a bit. | 20:45 |
| olofk | Well, that's true | 20:45 |
| andrzejr | It is not a full CDC anyway - it assumes synchronous clocks so it relies on timing constraints (just makes sure there are no long combinational paths between domains) | 20:46 |
| olofk | But it could be useful when you have other masters in the system, such as ethernet or dvi | 20:46 |
| andrzejr | but why should it be handled by the bridge? Would CAMD/WB run at different rates? | 20:47 |
| olofk | Yes. Less clocks is always better :) | 20:48 |
| olofk | First FPGA I did at my first job had 180 clock domains. Crazy legacy telecom stuff | 20:48 |
| andrzejr | If it is just some peripherals imho they should handle CDC internally (either for WB or CAMD i/f) | 20:48 |
| andrzejr | my "crazy telecom ASIC" had only ~10 domains | 20:49 |
| andrzejr | Some of them synchronous, some offset by +/-200ppm | 20:50 |
| olofk | Yeah, that's probably nicer. Pushing I/O clock domains into their respective IP is better | 20:54 |
| olofk | Or a CDC just outside the core | 20:54 |
| olofk | Time for sleep now | 20:57 |
| -!- trevorman_ is now known as trevorman | 21:00 | |
| andrzejr | olofk, imho CAMD should have burst termination signals (like UI) or some other way of telling the receiver how much data should it expect. | 21:06 |
| --- Log closed Thu Aug 27 00:00:17 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!