03-12-2013 07:55 AM
If there's anyone to assist me on this, I will appreciate it. I ran synthesis test on the verilog file attached to this message (it is for communicating with the ddr2 on a Spartan 6 FPGA), and it failed with a weird error that I can't resolve yet :
" ERROR: external reference <params.StartAddress> remains unresolved"
I also attached the synthesis report as a text file. Thank you in advance
03-12-2013 08:20 AM
I'm not sure that hierarchical references are valid for synthesis. It is more common to use an
include file for this sort of customization.
03-12-2013 08:27 AM
Thank you for the reply. I hope you won't mind if I ask what did you mean by Hierarchical references (base on the file I attached)?
Also it gives that error when it tries to impliment the for-loop; can you see anything wrong with the way I used the for-loop?
Once again thank you.
03-12-2013 08:53 AM
Looking a little closer, I see that your test bench is not in a separate module from
your synthesizable code. This is generally a bad practice, because none of the
test bench should be synthesized. So basically a lot of the things you can do in a
test bench (for simulation) are not allowed for synthesis. Among these are
loops with any sort of event in them.
You could place translate_off ... translate_on pragmas around the testbench so the synthesizer
ignores it, but a more normal approach is to make the test bench a separate module that
instantiates the synthesizable part of the design (and put it in a separate file as well).
Hierarchical references are things like:
. . .
Where in this case params is the hierarchical name of the instance of a test_parameters_1
module. So in effect you're accessing an object outside the scope of the current module.
That's not generally allowed for synthesis. It's fine for a test bench. So the bottom line is
don't try to synthesize your test bench.
03-12-2013 09:10 AM
once again thank you Gabor. I guess you can already infer that I am inexperienced with hardware programming.
The only issue that I am a bit concerned about is that, I want to implement this design on an FPGA (Hence the GPIO_BUTTONS I declared in the verilog file). Therefore if I can't synthesize my code, how can I compile and implement it?
Do I need to remove all the for&while loops then to be able to compile?
I really appreciate your help so far
03-12-2013 10:34 AM
It's not that you can't synthesize your code, you just can't synthesize the TestBench part of the
code. You need to understand the difference between code that gets implemented in the
hardware and the stimulus for simulation. As I said, it is not generally done the way you're doing
it with everything in one module.
That being said, I have not gone through all of your non-testbench code so I don't know what other
problems you'll run into. There are quite a few things that cannot be synthesized, but you can't
generalize that loops are not allowed. It depends on what the loop does. Synthesis allows the
use of loops as long as it can figure out how to "unroll" the loop into parallel hardware. This
generally precludes any loops that have event waits in them. i.e. the loop should all occur in
zero time in simulation. Synthesis also allows the use of functions in some cases, but again
not when they have event waits, so you can't use them for sequential logic.
I'd like to recommend a good book on using Verilog for synthesis, but unfortunately I don't
know of one. A lot of older books may be too restrictive in what they say is allowed, and
many more books really don't touch on the subject of synthesis very much at all.
So what you should start with is to remove the test bench code from the synthesizable
module. Then in the separate test bench, instantiate the module that will end up in
the hardware. Make sure that anything that needs to end up in the FPGA hardware is
in the synthesizable module, and anything that models the external hardware of the
board (clock oscillators, switches, etc.) is in the test bench. When you have that simulating
correctly, then you can try to synthesize the part that goes into the FPGA hardware.
If you have for and while loops in the synthesizable part of the code, you need to
think about how they would get turned into logic. If they are being used for something
sequential - i.e. something that takes real time to complete the loop - then you may
need to rewrite those parts of the code.
08-13-2015 08:29 AM
To weigh in to this thread. I had the same error when dealing with parameter passing from one module level to the next.
I found that it was simply the . (dot) in front of a parameter within the instancethat was the problem...