Hacker News new | ask | show | jobs
by Dolu 3255 days ago
Yes, silicon implementation provide the JTAG, but it's very likely their implementation will not be reusable for FPGA project (including JTAG debug things) because of their over complicated (but powerfull) solutions which would consume way to much area and restrict the FMax.

Then this specific VexRiscv ecosystem also provide a basic SoC with an multi master AXI4 inteconnect, SDRAM controller, embedded ram, APB3 interconnect, some slave like GPIO, UART, Timer, VGA. It's not incredible, but it's already a starting point ^^ See https://github.com/SpinalHDL/VexRiscv#briey-soc

3 comments

For an FPGA implementation, it's often useful to hook the soft core into the FPGA's own JTAG controller, so that it's possible to program the FPGA and debug the core over a single connection. This is often not portable even between FPGAs, and certainly isn't portable to ASIC, but it makes development a lot easier, so...
Yes i agree, would have been more convenent to use the integrated jtag of the FPGA, but i focused on making an universal solution first :)
ARM has a patent on AXI bus, but sure if it's expired, but whoever uses AXI with this CPU may need a license.
Are you sure it need a license ? I were thinking that AXI usage is royalities free (https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_A...)
If there is a licensing problem with AXI, would Wishbone be a viable alternative [1]?

[1] https://en.wikipedia.org/wiki/Wishbone_(computer_bus)

Yes it would be, it is very easy to retarget the CPU to another memory bus.

Then the Wishbone one isn't "perfect" as it can't map memories which have latencies without performance penality. It would be oky for the data bus of the cpu with or without cache, but for the instruction, without instruction cache, peak CPI would be divided by the memory latency.

that's my understanding from talking to an engineer at Qualcomm,

however, if there's no need for a license, then it would make it lower cost to build SOC with off the shelf AXI IP

I've never understood why some people say a license is needed for something on which patents have expired. What's the legal basis, or is it bluff?

I can understand that copyright exists in the documentation that describes AXI, but that copyright covers only their documentation and not your own implementation (or is some derivation claimed?). I can understand that trademark might exist in the name "AXI", so don't use that name. Trade secrets seem to be moot, if you're not associated with whoever is keeping the secret. If none of the above apply, what basis is there for demanding a license?

Licenses still apply post-expiry, in the US, Australia and a few other places.

It didn't use to be this way, but around the 80s the big precedents for this.

Most of the time, if you were a licensee before the expiry, then you continue to be so post-expiry. If however, you were not, then you have no existing contractual obligation, and can use it.

However it is something you need to consult a lawyer on, before making any decisions, because this area of law is more complicated than most, and is growing in complexity.

Thanks. That makes sense, as a licensee signs a contract, so they will be governed by the terms of the contract, and the contract can presumably be written to outlast the patent. It suggests to me that when a patent expires then licensees are potentially disadvantaged compared to non-licensees. It highlights that one must make sure that licenses are written to terminate royalties on patent expiry, or think twice about licensing patents that are close to expiry.
Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?
They are usable externally. The Realview boards use it to connect a CPU chip with an external northbridge, but it's really rare. Even in that case, it's just because the Realview board is meant to prototype SoCs with the help of an FPGA.
Usable, but only barely. As AXI / APB3 are intended for on-die communications, they lack the line coding and error correction used by other busses like PCIe or SATA. On the upside, though, they take a lot less area to implement.
That's more a distinction between serial and parallel buses than on-chip/off chip. If you're not pumping a single signal to gbps speeds, you don't need the clock recovery and ECC that serdes style connections imply.

It all depends on your use case.

They aren't made for external com