Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

VHDL array port map assigment

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
X is an input port to an entity. It's defined as a custom type of an unsigned vector array.
Y is a signal defined as an unsigned vector.

When doing port map assignments - is it legal to write:
Code: 
X=> ( others => Y ) ;
?
 

Compilation fails with an error - without pointing to a specific line.
 

shaiko said:
X is an input port to an entity. It's defined as a custom type of an unsigned vector array.
Y is a signal defined as an unsigned vector.

When doing port map assignments - is it legal to write:
Code: 
X=> ( others => Y ) ;
?
Click to expand...

- Both the port X and the signal Y would have to be constrained.
- The port X would have be defined as an array of the same type as Y. (i.e. X: arr_unsigned where type arr_unsigned is array(natural range <>) of unsigned. signal Y: unsigned(...))

Under those conditions, then yes the port map will work. If it's not working for you, then you need to post complete code clearly defining X, Y and the instantiation of the entity that has the port map.

Kevin Jennings
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
The files are attached.
The forum doesn't allow *.vhd files, so I changed the extension to *.txt.
The error occurs when I try to compile the file named: "fifo".
 

Attachments

  • controller_read_fifo.txt
    11.3 KB · Views: 70
  • controller_write_fifo.txt
    11 KB · Views: 75
  • fifo.txt
    20.2 KB · Views: 63
  • memory.txt
    7.5 KB · Views: 64
  • package_definitions_memory.txt
    512 bytes · Views: 67
  • package_functions_general.txt
    16.9 KB · Views: 72
  • tb_fifo.txt
    9.1 KB · Views: 67

Took a look at a couple of files and my first thought was...Are you using a 4K ultra HD monitor? I looked at the file on a full HD monitor and the text goes off the edge of the screen even at an 8pt fixed width font. :-(

Besides that the files are full of a mixture of tabs and spaces, good thing I have my tabs set to 2 some of those lines would have to wrap at least 3 times if I set it to 4.8-O
 

Sorry for that.
With notepad++ v5.9.2 the code looks nicely indented and very well arranged.

The names are a little long though...
 

shaiko said:
The files are attached.
The forum doesn't allow *.vhd files, so I changed the extension to *.txt.
The error occurs when I try to compile the file named: "fifo".
Click to expand...
I see what you mean by it compiling, saying there is an error but not pointing to anything. For me, it pointed to the last line in the file. What I found is...
- controller_read_fifo.vhd didn't compile because you did not include std_logic_1164 (this was the easy one)
- fifo.vhd didn't compile and didn't point to any specific line. What I did was to comment out all of your component definitions and change all of the instances to direct entity instantiation. So where you had this...
Code: 
controller_write_fifo_to_fifo : controller_write_fifo
I changed it to this
Code: 
controller_write_fifo_to_fifo : entity work.controller_write_fifo
All of the instances were uncommented with the exception of the instance of controller_read_fifo (because of the previously mentioned lack of including std_logic_1164).

After doing this, fifo.vhd compiled without any complaint. You might want to submit this as a ticket to the Modelsim folks (either through Mentor Graphics if you purchased from them; Altera if you got Modelsim from them, etc.). On the surface it appears that your code is valid.

I'll try to attach my edited fifo.vhd file.


Kevin Jennings
 

Attachments

  • fifo.vhd.txt
    20.7 KB · Views: 47
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Kevin,
Thanks a lot for the effort.

The std_logic_1164 is actually included in the original files - I removed it accidently before uploading the files here.

The only problem I had was with the "fifo" file.

BTW:
This design fails also fails Quartus synthesis with a crush.
I contacted Altera and opened a ticket.
I was told is that the failure was due to the use of VHDL 2008 nested "if generate".

Apparently Quartus (14.0) has very poor 2008 support...
 

Both altera and xilinx have little to no 2008 support. Best to stick with 93 for synthesis for the foreseeable future.
 

And I doubt that they'll ever have dependable 2008 compatibility.
This is the response I got from Altera:

Hello,
There is major upgrade to our code extraction going on that mostly a full release on 15.0. We plan to fix this crash in this new extractor but it is targeted on new family “arria 10”. We do not have plan to fix the nested generate statement related issue on older family like cyclone IV.

Thanks.

Best Regards,

Choon Hee
Click to expand...
 

All that's needed is a big enough customer that will make the jump to xilinx unless this feature is added. But you can guess how often that's happened.
 

shaiko said:
Kevin,
The only problem I had was with the "fifo" file.

BTW:
This design fails also fails Quartus synthesis with a crush.
I contacted Altera and opened a ticket.
I was told is that the failure was due to the use of VHDL 2008 nested "if generate".
Click to expand...
Actually, the problem I found is that it is limited to if you instantiate something within an 'elsif generate' like you are doing. I ran into this bug and reported it a couple of months ago. The fact that you ran across the same thing and reported it means there are at least two people reporting the same error.

Apparently Quartus (14.0) has very poor 2008 support...
Click to expand...
Unless your complaint is that here it is 2014 and 2008 features are still not quite working, it would seem kind of harsh to say that they have very poor 2008 support just because you ran across a bug. Some of the things that I've seen and use from 2008 are:
- process(all)
- unconstrained of unconstrained (as are you in your posted design)
- elsif generate (albeit not if I have to embed an entity for now).
- Reading entity outputs

Kevin Jennings

- - - Updated - - -

TrickyDicky said:
All that's needed is a big enough customer that will make the jump to xilinx unless this feature is added. But you can guess how often that's happened.
Click to expand...
I've found Altera tools to be much better than Xilinx tools to the point that I basically don't bother with X anymore.

Kevin Jennings

- - - Updated - - -

shaiko said:
And I doubt that they'll ever have dependable 2008 compatibility.
This is the response I got from Altera:
Click to expand...
Did you open a ticket with Modelsim? They didn't compile the original files either.

Kevin Jennings
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Unless your complaint is that here it is 2014 and 2008 features are still not quite working
Click to expand...
Yes, this is exactly my complaint...but it isn't limited to Altera.

It just seems that most of the effort is going into OpenCL & "Matlab to RTL" products - it's a free market and the choice is theirs to make. But for the sake of credibility, I expect the vendors not to claim support for an HDL standard before it's fully tested and debugged. Or at least publish a proper errata.

Did you open a ticket with Modelsim? They didn't compile the original files either.
Click to expand...
Not yet. Will do.
 

K-J said:
I've found Altera tools to be much better than Xilinx tools to the point that I basically don't bother with X anymore.

Kevin Jennings
Click to expand...

I have known about alteras limited support for a while. Comically, they supported parts of 2008 before modelsim did. And altera have always had a much better compiler than x.

Unfortunately, I work where I use both a and x and ask code needs to be as portable as possible, so I'm stuck with 93 for a long time yet....
 

[OT]
guys
do you compare vivado or planahead with quartus ?
in our company we use altera and xilinx but as we stopped on spartan-6 family (powered by planahead) so on that basis altera sofware >> xilinx. Xilinx says vivado is much faster + got completely rewritten syntheser part but never tested it in real project.
[/OT]

as for topic in company we got license for 8.0 alder-hdl and it also do not support 2008 completely (no double unconstrained arrays) ;/
 

Afaik, vivado still doesn't Have much in the way of 2008 support. Having used it it is much nicer to use, has some things quartus doesn't and some features quaetus can do better.
 

interestingly enough Vivado seems to have quite a bit of "hidden" support for System Verilog. It's certainly not promoted as existing from a documentation standpoint, but I did add -sv switches to some of the commands and they were accepted and worked. I was told that they were adding support for sv but it wasn't completely tested.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top