21–30 of 44 posts
Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?
I'm not sure about the trend in general, but it looks like SpinalHDL is a fork of Chisel, the 'other' Scala-based HDL.
Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem. The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?
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 inter…
Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?
Most of these DSLs tend to work at the level of RTL as opposed to something like "high level synthesis" where register usage is inferred, too (OpenCL, C, etc). So depending on how it's designed the results can be pretty close to hand-written code IME, without much overhead. They're more like "Super RTL" as opposed to real "high level" languages...
Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?
Everybody wants a new HDL but there's no standard yet. Embedding it in your favourite language is the obvious solution, and hence there will be at least one per language.
Earlier quoted context omitted.
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 inter…
Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?
Earlier quoted context omitted.
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 inter…
ARM has a patent on AXI bus, but sure if it's expired, but whoever uses AXI with this CPU may need a license.
Earlier quoted context omitted.
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 inter…
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...
Earlier quoted context omitted.
> You're overselling the complexity here. Yes: mating analog specifications to line drivers/receivers requires per-process design. And at the very top end of achievable technology (USB 3.1, PCIe 4, DDR4...) these designs are likely to be NDA-level IP you have to get from the fab or its partners. But come on, "slew rate" matching is a matter of looking up some capacitance and I/D curves and plugging them into a SPICE…
You've lost me on what you're arguing. I'm saying "we want to spend more time integrating open hardware designs into RISC-V devices and less time making new CPU cores in our fun new HDLs". And you're saying "we can't" because... why? I know that junk is there on OpenCores too. I've looked at it. I've synthesized some of it. No one uses it on silicon. That's the part we need to fix. And it's not because of SPICE param…
Why don't you quit being an arrogant armchair architect prick on Hacker News, telling everyone what they should and should not be doing, and do it yourself.
This is not an open hardware project, this is a soft CPU core intended for final use in an FPGA: that is, not intended for manufacture. The best memory controllers and GPIO on your FPGA are the ones which are burned in at the fab. Why spend precious time developing a memory controller which will ultimately underperform the one you already have as part of your FPGA? To satisfy some dood on HN?
If it's so important and you're so disappointed with the quality of published peripheral controller HDL, then surely it's your job to show us all the right way.
Earlier quoted context omitted.
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... )
Earlier quoted context omitted.
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... )
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