lkcl | Chips4Makers, appreciated the heads-up there. i read a JTAG spec and wondered about the VHDL. that was before i could read VHDL easily though :) | 11:01 |
---|---|---|
* lkcl taking a look at the sdram_dq_oe this morning | 11:39 | |
lkcl | Chips4Makers: sorted | 12:06 |
lkcl | ./run_iverilog_ls180.sh passes | 12:06 |
Chips4Makers | lkcl: hooray | 12:20 |
lkcl | yeah :) | 12:56 |
Chips4Makers | lkcl: Where did the DMI come from ? I don't anything online on this implementation. I only find direct media interface and differential memory interface. | 13:42 |
Chips4Makers | I'm not convinced to upstream it. It would seem straight forward to implement a (zero waitstate) WB2DMI bridge in nmigen-soc and only keep Wishbone master in JTAG. | 13:42 |
lkcl | Chips4Makers, it's a standard interface, named "Debug Module Interface" | 14:55 |
lkcl | https://github.com/lowRISC/opentitan/blob/master/hw/vendor/pulp_riscv_dbg/doc/debug-system.md | 14:56 |
lkcl | https://github.com/lowRISC/opentitan/issues/892 | 14:58 |
lkcl | it's as ubiquitous and general-purpose as Wishbone - just not very well-known | 14:59 |
Chips4Makers | So you implemented the registers in libre-soc as specified by the standard ? Then it makes sense to upstream, maybe with having the register bank included. | 15:59 |
lkcl | Chips4Makers: for RISC-V there exists a DMI standard. and for other processors as well | 16:01 |
lkcl | sorry: the DMI standard *is* a standard | 16:02 |
lkcl | for RISC-V, there exists a defined set of DMI addresses, as specified by the RISC-V Foundation Debug Working Group | 16:02 |
lkcl | in the case of OpenPOWER, nobody has done that job | 16:02 |
lkcl | therefore, Microwatt defined their own: we copied them. | 16:02 |
lkcl | therefore, those DMI addresses also effectively become a standard | 16:03 |
lkcl | however, none of these DMI address register standards have anything to do with the fact that DMI *itself* is a recognised industry standard, just like Wishbone. | 16:03 |
Chips4Makers | Was asking because the document you linked defined the widith of the address of the DMI interface. | 16:04 |
lkcl | which is defined exactly as Wishbone address is defined... or not defined | 16:05 |
lkcl | the equivalence between DMI standard and Wishbone standard is one-to-one | 16:05 |
lkcl | as in: neither the DMI standard nor the Wishbone standard *demand* a specific address width. | 16:05 |
lkcl | ... but that is not a reason to say "wishbone should be removed from C4M-JTAG because the Wishbone address is not defined" | 16:05 |
Chips4Makers | So can you point me to a DMI document that says this ? | 16:06 |
lkcl | no, i can't, because i don't know where one is | 16:06 |
lkcl | i can take a look and see if one exists | 16:06 |
Chips4Makers | So it is not a standard in my opinion | 16:06 |
lkcl | https://www.google.com/search?q=debug+module+interface+DMI+standard | 16:07 |
lkcl | it's implemented in Microsemi hardwar | 16:07 |
lkcl | ee | 16:07 |
lkcl | SiFive products | 16:08 |
lkcl | OpenTitan | 16:08 |
lkcl | Ariane | 16:08 |
lkcl | lowRISC | 16:08 |
lkcl | it's a standard - nobody actually says or explains where they got it from. | 16:09 |
lkcl | it's just... a standard | 16:09 |
Chips4Makers | OK, actually the spec does not define the physical bus interface (in section 3.1): "The Debug Module Interface can be a trivial bus withone master and one slave, or use a more full-featured bus like TileLink or the AMBA AdvancedPeripheral Bus. The details are left to the system designer.". So Wishbone could also be used. I'm not saying the simple implementation doesn't make sense, just that I want to look further into thi | 16:15 |
lkcl | it's extremely basic: what you actually put *on* the DMI interface is entirely up to the implementor. | 16:20 |
lkcl | just as with wishbone, what is put onto the wishbone bus (and at what width in terms of address and data) is also entirely and completely up to the implementor | 16:21 |
lkcl | if you hard-code *any* of those width parameters - simply because the RISC-V Sub-committee decided to define some particular choices | 16:21 |
lkcl | it would be as if you had said, "ah because opencores.org wishbone product XYZ hard-codes Wishbone address @ 9 bits and data @ 8 bits, all other Wishbone addresses and data widths are PROHIBITED by C4M-JTAG" | 16:22 |
lkcl | just as wishbone c4m-jtag is extremely simple, so is the dmi adaptation extremely simple. | 16:23 |
lkcl | it was literally a cut-and-paste | 16:23 |
lkcl | because the concepts are identical and equally general-purpose | 16:24 |
lkcl | i literally took the c4m-jtag "add_wishbone()" function and did a verbatim global search/replace "wishbone" --> "dmi" | 16:26 |
lkcl | DMI is effectively "a slightly simpler version of wishbone" | 16:27 |
lkcl | it's probably based on the SRAM interface. | 16:27 |
lkcl | there's a "req" line, a "wen" line, address, and data in/out. | 16:28 |
lkcl | req must be raised for only one cycle (just like wishbone) | 16:29 |
lkcl | there must be 1 clock delay | 16:29 |
lkcl | then "ack" must be asserted (with data) | 16:29 |
lkcl | it's *almost* identical to wishbone. | 16:29 |
Chips4Makers | I disagree, have you actually read the 3.1 section (Debug Memory Interface) of the riscv-debug-spec ? It specifically does not discuss the physical implementation of the interface. | 16:34 |
Chips4Makers | And it does specify that the address space has to start with a 32-bit register bank. | 16:35 |
lkcl | that's the RISC-V implementor's decision | 16:57 |
lkcl | we are talking at cross-purposes. | 16:57 |
lkcl | imagine this was wishbone that we were discussing to add | 16:57 |
lkcl | when you say "have you read the 3.1 secction of the riscv-debug spec" it is as if you had said, "have you read the Opencores I2C wishbone implementation source code" | 16:58 |
lkcl | or some other implementation. | 16:58 |
lkcl | i will try to track down a RISC-V JTAG-to-DMI adapter somewhere | 16:59 |
lkcl | to see if it is the same as the microwatt one | 16:59 |
lkcl | https://github.com/lowRISC/ariane/blob/master/src/debug/dmi_jtag.sv | 17:01 |
Chips4Makers | No, riscv-debug-spec is the source definition of DMI, it is _the_ document that defines what DMI means. It is like the Wishbone Rev3 and Rev4 spec. | 17:01 |
lkcl | Chips4Makers, that makes no sense, because Microwatt has also implemented DMI, and it has nothing to do with RISC-V | 17:04 |
* lkcl still investigating - you could well be right. i need to look further | 17:05 | |
lkcl | ariane uses SV so i need to track down where the type "dmi_req_t" and "dmi_resp_t" are defined | 17:05 |
lkcl | found them | 17:10 |
lkcl | https://github.com/lowRISC/ariane/blob/master/src/debug/dm_pkg.sv#L206 | 17:10 |
lkcl | that's defined as 6-bit DMI address and 32-bit DMI data | 17:11 |
lkcl | but | 17:11 |
lkcl | in microwatt | 17:11 |
lkcl | https://github.com/antonblanchard/microwatt/blob/master/wishbone_debug_master.vhdl#L13 | 17:11 |
lkcl | it's a 2-bit address and 64-bit data | 17:12 |
lkcl | 1 sec that's not correct | 17:12 |
lkcl | give me a second, wrong file | 17:12 |
lkcl | core_debug.vhdl | 17:13 |
lkcl | https://github.com/antonblanchard/microwatt/blob/master/core_debug.vhdl#L18 | 17:13 |
lkcl | that's better. | 17:13 |
lkcl | the microwatt team decided to go with a 4-bit DMI address and a 64-bit DMI data bus | 17:13 |
lkcl | riscv-debug-spec defines what widths the *RISC-V* DMI end-point chose to go with. | 17:14 |
lkcl | they chose to go with a 6-bit DMI address and a 32-bit DMI data width | 17:14 |
lkcl | this does not *define* that DMI *must* be 6-bit data and 32-bit addr | 17:15 |
lkcl | any more than choosing those widths would define that Wishbone must be those exact widths | 17:15 |
lkcl | unfortunately, i believe it is a standard that is in common use, and, clearly, the bus data/addr widths are general-purpose and arbitrary, but DMI is not common enough for someone to have actually written a document like the WB v3/4 spec | 17:17 |
lkcl | bit annoying | 17:17 |
Chips4Makers | Maybe you could ask Microwatt guys on history of DMI interface ? | 17:21 |
lkcl | yeah good idea | 17:21 |
lkcl | it's easter at the moment and i think a lot of them are away on holiday | 17:22 |
lkcl | might be a few weeks | 17:22 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!