Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.
Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.
Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.Well there is the Phase Locked Loop
Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.Well there is the Phase Locked LoopOr its just a stupid "argument" to stir the pot. For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/
I use them pretty regularly for all sorts of functions that other people would/could/did write out as repetitive verbose error prone structures. The only difference is that the are always parallel/concurrent evaluations of the loop, no possibility of putting a wait inside there for synthesis yet delays inside for loops are pretty routine for simulation (where until and always loops are very common).
Keep in mind that:
- FPGA is not software. You do not write "programs" for FPGA, you write schematic, with flip-flops and logic gates and so on, except you'll use text to describe the schematic, instead of drawing lines like you do with other electronic schematics.
- you'll need to know/learn digital design, meaning logic gates, flip-flops, multiplexers, counters, state machines, Mealy Moore state machines, synchronous design techniques (e.g. clock domain crossing, metastability, etc.) and so on. It's not software, it's hardware. It's all digital schematics written in text, and called HDL (Hardware Design Language). For example, Quartus still retains a graphic editor, where you draw flip-flops, and logic gates, and circuits from the 400 TTL family to design your schematic instead of describing your schematic wit VHDL or Verilog "code".
Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
Well there is the Phase Locked LoopOr its just a stupid "argument" to stir the pot.
Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
ACC_Zero <= '1' when ACC = "0000000000000000" else '0';
This piece of code, in my case, is near the top of the code, after the declarations but before I get into the messy stuff. It just sets up a signal to indicate the accumulator is zero. I never look back at that code while I consider how my FSMs deal with it. It exists, it is guaranteed to be available under all conditions and anywhere I want to use it. I can pass it as an input to other components, whatever. It simply exists and is constantly evaluated. If I do some operation that affects the accumulator, the ACC_Zero signal will follow along without my having to reevaluate it. It just happens because it is nothing more than a really wide NOR gate following synthesis....(I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
Because a software programmer is generally looking at a single line of code being executed and then the next line, etc. Clearly, threads expand this view but not all that much.
HDL programmers understand that thousands of lines of code are executing concurrently. Consider:Code: [Select]ACC_Zero <= '1' when ACC = "0000000000000000" else '0';
This piece of code, in my case, is near the top of the code, after the declarations but before I get into the messy stuff. It just sets up a signal to indicate the accumulator is zero. I never look back at that code while I consider how my FSMs deal with it. It exists, it is guaranteed to be available under all conditions and anywhere I want to use it. I can pass it as an input to other components, whatever. It simply exists and is constantly evaluated. If I do some operation that affects the accumulator, the ACC_Zero signal will follow along without my having to reevaluate it. It just happens because it is nothing more than a really wide NOR gate following synthesis.
The thought process changes substantially between hardware and software.
Well there is the Phase Locked LoopOr its just a stupid "argument" to stir the pot.It was just a joke, but apparently not a good one
Well there is the Phase Locked LoopOr its just a stupid "argument" to stir the pot.It was just a joke, but apparently not a good oneYour joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.
Well there is the Phase Locked LoopOr its just a stupid "argument" to stir the pot.It was just a joke, but apparently not a good oneYour joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.
Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.
Well there is the Phase Locked LoopOr its just a stupid "argument" to stir the pot.It was just a joke, but apparently not a good oneYour joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.Your short one liner makes a broad and misleading generalization. There are loops, they are almost exactly the same as C. Understanding the difference between synthesizable and non-synthesizable constructs/features is the underlying matter. You're just as wrong as the people who try and make generalizations about resets.
VHDL/Verilog can be used as high level languages, but there isnt a readily available or open source library ready to go as the OP specifically asks about (in reference to Audrino). At which point pretty much every single thing you said is incorrect:
Whether or not a "library" (to use your word) is or isn't open source is irrelevant.
Of course there are loops in HDLs. But if they aren't synthesisable they aren't in FPGAs.
If loops are synthesisable, then their semantics are very different to those in C.
For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/
For loops in synthesizable code are used to expand replicated logic.
QuoteFor loops in synthesizable code are used to expand replicated logic.It is not the for loop itself that is synthesized. It is the logic in it that is implemented repeatedly.
Wat one has to understand as a difference between it running on a processor or a FPGA is that on the processor it is a sequential evaluation of the if statements and takes the given number of loops to come to the result, where as, if I'm not mistaken, in the FPGA it happens "instantaneous" meaning all the if's are evaluated concurrently.
We can trivially point to synthesiable loops, in C syntax, as I already did:For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.
For loops in synthesizable code are used to expand replicated logic. They are simply a way of shrinking the amount of code that is written by the hardware designer. Again, until you understand how exactly this expansion of replicated logic works, do not use for loops.
We can trivially point to synthesiable loops, in C syntax, as I already did:For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.
You misunderstood. That's a quote from the link you posted:QuoteFor loops in synthesizable code are used to expand replicated logic. They are simply a way of shrinking the amount of code that is written by the hardware designer. Again, until you understand how exactly this expansion of replicated logic works, do not use for loops.
To make an analogy, that type of "for" loops are rather like the preprocessor directives for C (if it were to make a parallel with C). I wouldn't say C has an "#include" or a "#define" keyword. Those directives are for the preprocessor, not for the C compiler.
I'm thinking about a "for" in a HDL in a similar way I'm thinking about a macro in C. Except in HDL the macro is usually in the same HDL language as the synthetisable HDL parts.
I wouldn't say a macro in C is to be compiled, I'll say is to be expanded/transformed into more C code, then compiled. Same with the "for" loops in HDL. Those are not turned directly into gates and flip-flops. Those "for" loops are expanded (unrolled) into more HDL source code, and only after that the HDL is synthesised into interconnections between gates and flip-flops in the FPGA, just like a macro would be in C.
If one uses C macros as if it were C code, that will get unpredictable results, or compiling errors. Same in HDL with the "for" loops, which should be considered rather a macro for HDL, and not like synthetizable code.