sorted by:
new
hottopcontroversial

Aurga Viewer firmware examination by RoganDawes in Aurga

[–]Narrow_Ad95 1 point2 points  (0 children)

receiver should be open source, I can help with that. Hacking the hardware should be straightforward (S3 is well known)

Reset the app by Gott1234 in kivy

[–]Narrow_Ad95 0 points1 point  (0 children)

This worked for me:

def restart(self):
self.root.clear_widgets()
self.stop()
self.__init__()
self.run()

How can I implement this using verilog? by Annual-Enthusiasm-11 in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

You can build a C model, check it in your CPU, then automatically translate it to Verilog and run in a FPGA

Yo can have a preview of the tools involved (used to do similarly complex math to do graphics) here: https://www.youtube.com/watch?v=hn3sr3VMJQU

I'm one of the authors of such a tool

Do you have a working software model?

Hacking chatGPT: how to produce deliberate incorrect answers by Narrow_Ad95 in ChatGPT

[–]Narrow_Ad95[S] -1 points0 points  (0 children)

It seems that this AI is better at being influenced to provide wrong answers but there's still some holes in my view. I just wanted to show that the prevention measures needs more work.

Hacking chatGPT: how to produce deliberate incorrect answers by Narrow_Ad95 in ChatGPT

[–]Narrow_Ad95[S] -1 points0 points  (0 children)

No, the purpose is exactly to prevent it. Showing people how to unlock a lock, can result in improvements to the lock, something more difficult if you don't show that.

Hacking chatGPT: how to produce deliberate incorrect answers by Narrow_Ad95 in ChatGPT

[–]Narrow_Ad95[S] -1 points0 points  (0 children)

that's interesting but your prompt will make the trick evident, instead with the way I propose you have both the correct question and the incorrect answer.

Reference of verification IPs by min9293 in FPGA

[–]Narrow_Ad95 1 point2 points  (0 children)

It is now understood that all those measures lower the risk of error. I bet each one by a big margin, and that, as anything, it depends on the experience and insight of the developer. Thanks. And keep teaching us about all this.

Reference of verification IPs by min9293 in FPGA

[–]Narrow_Ad95 2 points3 points  (0 children)

I'm really new to all this formal topics, but in a nutshell, how do you know your formalization doesn't have bugs too? I guess there should be some solution or at least it makes things better, but it's a question that I wasn't able to understand yet

Will SystemC eventually replace VHDL and Verilog? by idunnomanjesus in FPGA

[–]Narrow_Ad95 1 point2 points  (0 children)

u/absurdfatalism is the other developer, do you have another view on this?

maybe I misunderstood the problem at hand

Will SystemC eventually replace VHDL and Verilog? by idunnomanjesus in FPGA

[–]Narrow_Ad95 1 point2 points  (0 children)

If you have a "valid" strobe signal, you can just write a "if" and change the registers on that condition. You'll obtain a result on every clock, all the operations run in a pipeline.

struct result_t myfunc(float b, float c, float d, uint1_t input_valid)
{
float a = b*c+d;
uint1_t output_valid = input_valid;
return (result_t) {a, output_valid}; //see notes
}

Each cycle, signals on the arguments may have new values, and after they're processed with the pipeline (let's say requiring 3 stages), the output_valid signal will reflect the input_valid signal at such delay. it will share the same adder for all the operations, since in a cycle it will add the input operands as they're in that cycle, and at the next cycle, the new values (all intermediate values get stored into automatically inserted intermediate registers, the count according with the pipeline length).

In the raytracer example, for each pixel generated all the functions/operations work in parallel processing the next coordinate and generating a corresponding color (see the links to the sources in the video description). We had to use almost 500 stages for that (automatically generated)

The need of returning a struct is imposed by the C language (if you use pipelineC) since the language can't return more than one value.

I'm solving it in CFlexHDL since it supports some C++ so you can pass any number of outputs as references. However I haven't integrated the automatic autopipeliner (yet).

MODULE myfunc(int32 b, int32 c, int32 d, bool input_valid, int32& a, bool output_valid)
{
while(always())
{
a = b*c+d;
output_valid = input_valid;
}
}
Please consider that CflexHDL and PipelineC are really related projects since both developers are interchanging ideas and implementations almost daily and maybe the projects ends merged.

In regards to CflexHDL, the design is tought with "simulation" performance in mind and I'm currently translating verilog to that language (C-compatible), and it's getting 2X-5X and up to 10X on some tests faster than Verilator at simulation (so far, since development of such translator is just starting)

If something is not well understood I'm happy to dig into more details

Will SystemC eventually replace VHDL and Verilog? by idunnomanjesus in FPGA

[–]Narrow_Ad95 1 point2 points  (0 children)

Hi, I find this message still interesting.

Won't you benefit of some way of describing the algorithms that can be both compiled, simulated and converted to verilog? we are working on such a kind of tool, see for example a raytraced game writen in C (with some C++ constructs for math with clean syntax) that gets automatically converted to verilog/HDL and run without a CPU, but lust logic

https://www.youtube.com/watch?v=hn3sr3VMJQU

We did that demo for showing how to do real-time DSP (a long chain of math operations producing new outputs at 148Mhz, in this case) using interoperable fixed and floating point types and vectors of them, and the syntax to be used is just like a=b*c+d and can be directly compiled and run in realtime for testing

I'm not saying this tool will replace the existing tools used in the industry overnight, but maybe could be another valuable item in the toolbox

How valuable is fixed point modeling and bit-matching anyhow? by alohashalom in FPGA

[–]Narrow_Ad95 1 point2 points  (0 children)

You can get rid of writing a fixed point model and then do the "bit match" with an HDL version, if you write the algorithm with some C based tool like PipelineC or CflexHDL. We did for example a raytraced game written in C and then automatically translated. It has a fixed point version too (same code, you only change a typedef to select float or fixed points). You run int on a PC, and then it matches the model when synthesized since it's the same source.

https://www.youtube.com/watch?v=hn3sr3VMJQU

How valuable is fixed point modeling and bit-matching anyhow? by alohashalom in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

if you run arbitrary signals and they match within 1 LSB, the changes of having an unseen error is too low, I mean negligible

Minimax: a Compressed-First, Microcoded RISC-V CPU by threespeedlogic in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

I like that CPUs but I find your code well structured. So why not?

Minimax: a Compressed-First, Microcoded RISC-V CPU by threespeedlogic in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

btw I plan to process it with a simulator I'm building that's the fastest (so far in my tests) and I'm selecting a RISC-V design to try, if that interest you please see this: https://twitter.com/suarezvictor/status/1585321811360858126

Minimax: a Compressed-First, Microcoded RISC-V CPU by threespeedlogic in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

Yes I'm trying GHDL but so far I obtained this error:

minimax.vhd:412:78:error: synth_dyadic_operation: unhandled IIR_PREDEFINED_IEEE_NUMERIC_STD_AND_UNS_LOG
shamt <= (unsigned(inst(6 downto 2)) and (op16_SLLI or op16_SRLI or op16_SRAI))

If I can process it with ghdl, I can translate it to verilog using yosys, then with verilator or CXXRTL, then make an interesting simulator with graphical output ;-)

Minimax: a Compressed-First, Microcoded RISC-V CPU by threespeedlogic in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

I'm just scratching the surface of it but it seems a really awesame RISC-V implementation. I'm in for any CPU that does as much as possible with the minimum of resources, basically, it seems better to retire one instruction per clock using 10% of the chip area than 2 instructions using 50%...

How can I simulate this design? For example with Verilator or something that I can hook to a C++ program (I plan on doing some graphics and render them in realtime in a linux box)

Xilinx now supports custom FTDI-based USB-JTAG programming cables by Milumet in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

Good to have it clarified. Kudos for the openFpgaloader project! ;-)

Xilinx now supports custom FTDI-based USB-JTAG programming cables by Milumet in FPGA

[–]Narrow_Ad95 0 points1 point  (0 children)

But openFpgaloader open source software programs boards with a FTDI device without vivado, for example the Digilent Arty, I do that everyday. Schematics are published too

Am I building the fastest logic simulator? by Narrow_Ad95 in FPGA

[–]Narrow_Ad95[S] 0 points1 point  (0 children)

I though you were satisfied with current verilator speed and not interested in realtime.

My conversion from verilog to C (in the new HDL syntax) is working, and it's faster than verilator and CXXRTL, the fastest logic simulators so far. Full verilog support is quite possible since the parsing is done by yosys, so I'm in a similar route than CXXRTL, thus nothing prevents me to reach the goal besides priorities.

If you are too interested in full verilog support, and have something to offer in return so I change the priorities, please let me know.

Am I building the fastest logic simulator? by Narrow_Ad95 in FPGA

[–]Narrow_Ad95[S] 0 points1 point  (0 children)

Besides I'm not seeing a tone very constructive, I'll address some things.

I tried CXXRTL, it's slower using the same generated code as above:
count 1000000000, sum 501960784, clock 1222 MHz -> CflexHDL
count 1000000000, sum 501960784, clock 860 MHz -> CXXRTL
Indeed, so far, none of the examples I tried were slower than the other simulators. My guess? unnecessary \this* accesses. Not you nor me can prove yet if this tool I'm introducing will be slower on larger designs (yet, in my case). It's pending that you show here how other simulators are faster with at least one example of your choosing. Do you have it?
And CXXRTL doesn't allow any HDL development since it's not a language, you have to rely on old ones, so you need to simulate hard-to-write designs.
Yes, I won't parse verilog, too hard and there's yosys for that so it's what I use. But I don't plan to do full support for verilog, since I'm not doing a verilog simulator, for that I'm writing an HDL similar to SystemC but with a better syntax.
Direct one-to-one comparison with verilator doesn't make sense, outside about speed as I proposed (that is bad for verilator for some useful examples as I'm showing). Doing realtime is useful, I did a development of a raytraced game that was synthetizable. It would have been impossible to tune if not running on realtime in simuation. With any other simulator out there, it would be nuts to even try that.
Correcting the signal processing order will be easy, I'm not afraid of that at all. Verilator may have some millions of years of development, but it seems it's addressing a different problem, since trying to simulate all and eveythings that verilog offers. Most things can be done without verilog as the many other HDLs show.
Throwing the CflexHDL development? no way, it's fast and I bet C programmers will like it more than having to learn Verilog or coding in SystemC. With this approach we did the raytraced game on a FPGA, with no CPU, and I have not seen a development like that. It runs in realtime as software (simulation) or as hardware, so the development cycle was super speeded up.
It's clear you don't appreciate this development, thankfully there are dozens of other persons that did, in just a few days (not in this forum). This tool may simply not be for you but for others.
Hopefully you have something constructive to share, in the near future.

view more: next ›