cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
13,180 Views
Registered: ‎02-18-2013

ERROR: external reference <params.StartAddress> remains unresolved

Jump to solution

Hi all,

 

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

 

Regards,

Samuel

Tags (1)
0 Kudos
Reply
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
21,609 Views
Registered: ‎02-18-2013
thank you so much for your detailed explanation. I really appreciate !

Regards,
Samuel

View solution in original post

0 Kudos
Reply
7 Replies
Highlighted
Professor
Professor
13,174 Views
Registered: ‎08-14-2007

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.

-- Gabor
0 Kudos
Reply
Highlighted
Visitor
Visitor
13,172 Views
Registered: ‎02-18-2013

hi Gabor,

 

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.

 

Regards,

Samuel

0 Kudos
Reply
Highlighted
Professor
Professor
13,160 Views
Registered: ‎08-14-2007

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:

 

params.Startaddress

. . .

test_parameters_1 params();


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.

 

-- Gabor
0 Kudos
Reply
Highlighted
Visitor
Visitor
13,157 Views
Registered: ‎02-18-2013

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

 

Regards,

Samuel

0 Kudos
Reply
Highlighted
Professor
Professor
13,147 Views
Registered: ‎08-14-2007

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.

 

-- Gabor
0 Kudos
Reply
Highlighted
Visitor
Visitor
21,610 Views
Registered: ‎02-18-2013
thank you so much for your detailed explanation. I really appreciate !

Regards,
Samuel

View solution in original post

0 Kudos
Reply
Highlighted
Adventurer
Adventurer
10,325 Views
Registered: ‎05-27-2011

Hi All.

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...

 

 

0 Kudos
Reply