5 ms·

Slightly off-topic: I see lots of learning resources for FPGAs appearing that explain how to "think parallel", but are there good resources that explain how to

by moring 4y ago

Slightly off-topic: I see lots of learning resources for FPGAs appearing that explain how to "think parallel", but are there good resources that explain how to deal with practical problems such as badly-documented primitives (looking at you, ECP5) or how to debug a non-working design (1), or how to find what causes the synthesis tool to segfault? 1 involving multiple primitives and you can't attach a signal logger to the signal between them because the FPGA doesn't have a path there to use. The situation somewhat reminds me of the earlier LaTeX days when every tutorial started with "I'm assuming you have already installed LaTeX" as if that wasn't the biggest problem for most users, and then continues explaining the easy stuff that you can easily learn by trial and error.

dayjaby 4y ago
> how to debug a non-working design In LiteX, an open source toolset for making FPGA designs, you can embed an oscilloscope into your FPGA: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To...
- moring 4y ago
  How does it solve the problem that the FPGA doesn't have a path from the signal-to-observe to the logic blocks?
  - dayjaby 4y ago
    You can specify the list of signals to observe, which is built into the gateware. As memory is also limited, you specify a condition like if signal A becomes 0x1234, then log the aforementioned signals for N cycles.
    - moring 4y ago
      I have to admit I still don't get it. When I try to log the signal using my own signal logger (which I guess is somewhat like that "virtual oscilloscope"), the synthesis tool rejects the design and tells me that I cannot use that signal as an input because the FPGA doesn't have a path from there into the logic blocks. What does LiteX do differently to observe a signal that my own gateware cannot access?
      - proto_lambda 4y ago
        What kind of primitives are you talking about here? In my experience you don't really have to manually instantiate anything other than a PLL or maybe a multiplier unless you're doing something very specialized.
        moring 4y ago
        I was specifically thinking about DDR3 related primitives.
  - simne 4y ago
    Only simulator could check signal to which could not connect physically. But, you could split project into small parts, connected by some interface (could use triggers or 2-way ram cells), and debug them separate. Sure, you will loss some capacity, but this is life. This is not equal to test real solution, because physical arrangement matter, but most probably, you will find most obvious mistakes.
CorrectHorseBat 4y ago
>1 involving multiple primitives and you can't attach a signal logger to the signal between them because the FPGA doesn't have a path there to use. Does the problem not arise in simulation?
- moring 4y ago
  I don't have simulation models for the primitives, and I can't write them due to the lack of documentation. One of the downsides of working purely with the free / open-source toolchain, I guess. edit for clarification: The lack of simulation models is due to the free toolchain. The documentation is fully available, it's just so bad that you don't even know what some of the primitives are meant to do.
krapht 4y ago
You're not gonna like this answer but every time I've had some issue like that at work the answer is: file a ticket with your local Xilinx field applications engineer. Are you a hobbyist? Ha, have fun. Digging through the Xilinx forums is also productive. Edit: I see you're strictly working with only free/open source tooling. I commend your patience. I also don't see the point. It's not the right choice for either learning or getting things done at the current moment.
- misnome 4y ago
  > You're not gonna like this answer but every time I've had some issue like that at work the answer is: file a ticket with your local Xilinx field applications engineer. Basically this. I've been using the Intel OneAPI tools to write for their FPGA's in SYCL, and seem to have run into a large number of fundamental bugs (including plain routing errors) that makes me wonder how many other people are actually using the tools.
  - krapht 4y ago
    Well, now you know the answer is almost nobody :). Xilinx and Altera have been promising efficient high level C++/openCL/CUDA -> FPGA compilation for decades now and almost everybody I know has been burnt by it at work, so thanks for confirming my bias, I'll avoid OneAPI too for the present. Guess VHDL and Verilog and the old standard tooling will live for another 10 years. Everything is always amazing for the first 80% but the last 20% is impossible to fix and you end up not saving any dev time at all.
    - misnome 4y ago
      > I'll avoid OneAPI too for the present. I wouldn't write it off _completely_, for everyone. Compiler bugs notwithstanding, it seems to work reasonably well if you don't mind extremely long compiler cycles for running on the hardware. It gives you pretty reasonable emulation tooling to work out how well it runs, whether things are pipelined and, efficient if you know what you are looking at - but it doesn't seem to save you actually having to learn how the FPGAs work and model data flow. Of course, you are also beholden on drivers/adaptors being written to actually be able to use them.... which at this point is two chipsets, the newer of which has just been deprecated. Evaluating Xilinx HLS is next on my list, at least it seems to have the benefit of being around for much longer, and we have collaborators who have had success with the tooling.

by moring 4y ago

dayjaby 4y ago

> how to debug a non-working design In LiteX, an open source toolset for making FPGA designs, you can embed an oscilloscope into your FPGA: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To...

moring 4y ago
How does it solve the problem that the FPGA doesn't have a path from the signal-to-observe to the logic blocks?
- dayjaby 4y ago
  You can specify the list of signals to observe, which is built into the gateware. As memory is also limited, you specify a condition like if signal A becomes 0x1234, then log the aforementioned signals for N cycles.
  - moring 4y ago
    I have to admit I still don't get it. When I try to log the signal using my own signal logger (which I guess is somewhat like that "virtual oscilloscope"), the synthesis tool rejects the design and tells me that I cannot use that signal as an input because the FPGA doesn't have a path from there into the logic blocks. What does LiteX do differently to observe a signal that my own gateware cannot access?
    - proto_lambda 4y ago
      What kind of primitives are you talking about here? In my experience you don't really have to manually instantiate anything other than a PLL or maybe a multiplier unless you're doing something very specialized.
      - moring 4y ago
        I was specifically thinking about DDR3 related primitives.
- simne 4y ago
  Only simulator could check signal to which could not connect physically. But, you could split project into small parts, connected by some interface (could use triggers or 2-way ram cells), and debug them separate. Sure, you will loss some capacity, but this is life. This is not equal to test real solution, because physical arrangement matter, but most probably, you will find most obvious mistakes.

CorrectHorseBat 4y ago

>1 involving multiple primitives and you can't attach a signal logger to the signal between them because the FPGA doesn't have a path there to use. Does the problem not arise in simulation?

moring 4y ago
I don't have simulation models for the primitives, and I can't write them due to the lack of documentation. One of the downsides of working purely with the free / open-source toolchain, I guess. edit for clarification: The lack of simulation models is due to the free toolchain. The documentation is fully available, it's just so bad that you don't even know what some of the primitives are meant to do.

krapht 4y ago

You're not gonna like this answer but every time I've had some issue like that at work the answer is: file a ticket with your local Xilinx field applications engineer. Are you a hobbyist? Ha, have fun. Digging through the Xilinx forums is also productive. Edit: I see you're strictly working with only free/open source tooling. I commend your patience. I also don't see the point. It's not the right choice for either learning or getting things done at the current moment.

misnome 4y ago
> You're not gonna like this answer but every time I've had some issue like that at work the answer is: file a ticket with your local Xilinx field applications engineer. Basically this. I've been using the Intel OneAPI tools to write for their FPGA's in SYCL, and seem to have run into a large number of fundamental bugs (including plain routing errors) that makes me wonder how many other people are actually using the tools.
- krapht 4y ago
  Well, now you know the answer is almost nobody :). Xilinx and Altera have been promising efficient high level C++/openCL/CUDA -> FPGA compilation for decades now and almost everybody I know has been burnt by it at work, so thanks for confirming my bias, I'll avoid OneAPI too for the present. Guess VHDL and Verilog and the old standard tooling will live for another 10 years. Everything is always amazing for the first 80% but the last 20% is impossible to fix and you end up not saving any dev time at all.
  - misnome 4y ago
    > I'll avoid OneAPI too for the present. I wouldn't write it off _completely_, for everyone. Compiler bugs notwithstanding, it seems to work reasonably well if you don't mind extremely long compiler cycles for running on the hardware. It gives you pretty reasonable emulation tooling to work out how well it runs, whether things are pipelined and, efficient if you know what you are looking at - but it doesn't seem to save you actually having to learn how the FPGAs work and model data flow. Of course, you are also beholden on drivers/adaptors being written to actually be able to use them.... which at this point is two chipsets, the newer of which has just been deprecated. Evaluating Xilinx HLS is next on my list, at least it seems to have the benefit of being around for much longer, and we have collaborators who have had success with the tooling.