// ROM must be read unconditionally to infer dual port ROM
As this is the first post in a new thread it would be useful to know which other post you are referring to.As explained in another post,
Partial RAM tables (e.g. quarter wave) can be used, you need to learn the prerequisites of RAM/ROM inference. Your code is probably not complying with the RAM/ROM design templates.I tried, it works, it makes a sine wave from a quarter of a
sine wave, but no internal RAM is used, RAM Can't be used, apparently.
3. Coarse tables with linear interpolation are a frequently used option. Unfortunately you need to access to consecutive
table values for one interpolated value.
Even without actually instantiating NCO IP for test, just studying the manual can give you many insights.
This is the wrong way to "fix" the wires vs regs. It will result in warnings in a language compliant simulator as reg is not the same as wire even in Systemverilog. It seems to me that Quartus is taking the allowed usage of logic and making reg the behave exactly the same way, which is incorrect. logic can be used in places where it can be like reg or like wire as "wire logic" or logic for short.NB: I had many problems with wires vs regs, so I remembered one of the first posts. I think it was
from Fvm who said that it compiles perfectly in system verilog. So this time I used a .sv file and
it's a lot better, the compiler stopped nagging about details and I don't need any wire in the whole
program.
you should learn soon the expected syntax that doesn't bring up confusing warnings.
You perform verification of the design before you build a physical version of it. What you are doing is testing unverified code on hardware.Verification? Yes, I verify what I do with an oscilloscope, but I think there is another meaning.
Should read as "the myth of system verilog as being a verification only language."The paper linked by ads-ee talks about the myth of system verilog as a verification language.
Verification has nothing to do with language it has to do with proving you did a design that meets the requirements and performs all of its intended functions, before you create a physical copy of it. That is why verification languages exist, to build test code to exercise your design before you build it.So verification has something to do with language, but let's be frank, I don't know what it
is, and I don't feel the need for it right now because I operate exactly like for microprocessors.
- Edit a program
- Compile it
- Plug the emulator (or whatever is is, the USB blaster for Altera)
- Load and run
- Observe the results on the scope.
Fine put your blinders on, but I'm sure you will regret developing those bad methodology habits in the long run. IMO it is better to develop good habits early so you don't have to change those habits later (which is much harder to do).Maybe it works for the time being because I'm using 1% of the FPGA, and maybe I will run into trouble when the source expands, but as long as it works, I will probably not feel the need to change my method.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?