One other thought: the wrapping.
Is the "xxx" the verilog name or the VHDL name?
A simple test would be to just put a little dummy logic in the verilog
wrapper so it can stand by itself,
and see if the problem has anything to do with verilog wrapping vhdl.
Did you add the vhdl file to the source file list in your worker's Makefile?
We should definitely put in such a wrapping example in the normal
component library just to make sure it works as the tools evolve.
(assuming this is related to the wrapping).
Another red flag is that xxx/gen/xxx.v is being compiled.
The only file with the ".v" suffix that is generated is the skeleton
file, and it is copied to the directory above for editing.
When you build a worker for the first time, when you only have the
xxx.xml, it generates gen/xxx_skel.v, and makes a copy
in xxx.v.
You should edit xxx.v (in your case to make a wrapper).
So it would be interesting to find out how you ended up building against
gen/xxx.v - there should be an error to prevent that!
Jim
On 2/1/12 11:06 PM, Ziersch, Troy (Contractor) wrote:
UNCLASSIFIED
Hi,
I've been attempting to build an FPGA artefact with my own worker using
the Test Bias artefact as a template.
i.e. SMA->my worker->SMA
My worker is mixed language (VHDL wrapped with Verilog).
I've made it as for as map but running into two issues.
Firstly:
"Building application core "xxx" for target "virtex6""
fails with:
"ERROR:HDLCompiler:1654 - "xxx/gen/xxx.v" Line 82: Instantiating<xxx>
from unknown module<xxx>".
I've checked that the XST -sd flag includes the directories that the SMA
and my workers NCD files are in.
The sma core is found but my worker is not.
I've also checked that the worker pinout matches its instantiation in
the generated app core verliog file.
I'm able to work around this issue by putting a black box def of my
worker into the start of the generated app core verilog file.
With the above work around the build continues until the map stage where
there is an explosion of Dual Port Slice RAMs when compared to the Test
Bias case.
For comparison I've included the utilisation I get for the Test Bias
FPGA, my FPGA and my worker compiled by itself.
All builds are for the ml605 platform.
Anyone have any ideas where to look next to solve either issue?
Test Bias FPGA Design Summary
--------------
Slice Logic Utilization:
Number of Slice Registers: 16,119 out of 301,440 5%
Number of Slice LUTs: 22,609 out of 150,720 15%
Number used as logic: 18,208 out of 150,720 12%
Number used as Memory: 4,013 out of 58,400 6%
Number used as Dual Port RAM: 886
Number used as Single Port RAM: 0
Number used as Shift Register: 3,127
My FPGA Interim Summary
---------------
Slice Logic Utilization:
Number of Slice Registers: 23,267 out of 301,440 7%
Number of Slice LUTs: 140,332 out of 150,720 93%
Number used as logic: 46,103 out of 150,720 30%
Number used as Memory: 94,063 out of 58,400 161%
(OVERMAPPED)
Number used as Dual Port RAM: 90,928
Number used as Single Port RAM: 0
Number used as Shift Register: 3,135
My Worker Design Summary
--------------
Number of Slice Registers: 6,936 out of 301,440 2%
Number of Slice LUTs: 4,445 out of 150,720 2%
Number used as logic: 3,870 out of 150,720 2%
Number used as Memory: 8 out of 58,400 1%
Number used as Dual Port RAM: 0
Number used as Single Port RAM: 0
Number used as Shift Register: 8
IMPORTANT: This email remains the property of the Department of Defence
and is subject to the jurisdiction of section 70 of the Crimes Act 1914.
If you have received this email in error, you are requested to contact
the sender and delete the email.
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
