Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20705 Discussions

Big numbers of input, output ??

Altera_Forum
Honored Contributor II
2,172 Views

hello everyone, I am a newbie. After trying in 2 days,  

I can't do a thing to solve the following problem. 

 

My mp3 player design requires to transfer 576 integer number ( 576x32 bit ) 

among modules, but the Cyclone II EP2C70 on DE2 board only allows 622 I/O pins. Therefore, that is a compile error. How can I solve this problem ??? 

 

Is it possible to implement an shared memory to contain those 576 integer number 

so that other modules can read and write on that. If it is, please explain it in detail 

because I am quite new to FPGA design. 

 

Thank you very much. 

 

btw, I am using verilog HDL.
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
563 Views

It's very unclear from your post, what you are trying to achieve. Data "transfered between modules" would imply internal signals but no I/O pins at all, either if they use register cells, embedded memory or virtual signals (wires) only.

0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

It's very unclear from your post, what you are trying to achieve. Data "transfered between modules" would imply internal signals but no I/O pins at all, either if they use register cells, embedded memory or virtual signals (wires) only. 

--- Quote End ---  

 

 

I am sorry about that, I have little knowledge about using Quartus II and FPGA design. 

Embedded memory could be the best suitable for my project, but would you please explain 

the others ( register cells and wires) as long as they imply no I/O pins. Thanks. 

 

PS: I don't know how to make them imply no I/O pins.
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

You have been talking of transferring signals (integer numbers) between modules. This normally means, that the signal exist as an output in the interface of one module and as input at one or several other modules. In this case a signal of type wire would be used in the top module to connect the underlying modules. 

 

The technique is described in any Verilog textbook or tutorial and can be learned from design examples, I think. Verilog, unlike VHDL, doesn't allow array signals in module interfaces, so each number respectively bitvector has to be defined separately. Or the two-dimensional bitvector has to be mapped to a large one-dimensional one. This restriction is one reason, why I prefer VHDL for hierarchical designs. 

 

Physically, a signal has to be routed through the FPGA for each bit, so 576*32 bit is implying a considerable routing effort. There may be alternatives in design structure, depending on the purpose of the said signals. A key question is, if the numbers have to be accessed in parallel or may be transferred sequentially, at least in part. If the signals allow sequential access, they can be possibly stored in embedded RAM also.  

 

But this can't be decided without knowing the design purpose and functional details.
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

You have been talking of transferring signals (integer numbers) between modules. This normally means, that the signal exist as an output in the interface of one module and as input at one or several other modules. In this case a signal of type wire would be used in the top module to connect the underlying modules. 

--- Quote End ---  

 

 

Yes, that is exactly what I mean :)  

 

 

--- Quote Start ---  

The technique is described in any Verilog textbook or tutorial and can be learned from design examples, I think. Verilog, unlike VHDL, doesn't allow array signals in module interfaces, so each number respectively bitvector has to be defined separately. Or the two-dimensional bitvector has to be mapped to a large one-dimensional one. This restriction is one reason, why I prefer VHDL for hierarchical designs. 

--- Quote End ---  

 

 

Actually, I am using SystemVerilog and it can remove this restriction. 

 

 

--- Quote Start ---  

Physically, a signal has to be routed through the FPGA for each bit, so 576*32 bit is implying a considerable routing effort. There may be alternatives in design structure, depending on the purpose of the said signals. A key question is, if the numbers have to be accessed in parallel or may be transferred sequentially, at least in part. If the signals allow sequential access, they can be possibly stored in embedded RAM also. 

 

But this can't be decided without knowing the design purpose and functional details. 

--- Quote End ---  

 

 

It does allow sequential access.  

I understand what you mean now. I need to implement an common memory module ( like RAM) to store 576 integer numbers instead of transferring them. 

Thank you for your help, I will try this. 

 

BTW, Is it right to use megafunction plugin to create embedded RAM ?
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

BTW, Is it right to use megafunction plugin to create embedded RAM ? 

--- Quote End ---  

 

Yes, that's the most intuitive way to control all implementation details. Alternatively, embedded RAM can be infered from Verilog or VHDL, but this hasn't particular advantages except for writing more compact code.
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

Actually, I am using SystemVerilog and it can remove this restriction. 

--- Quote End ---  

 

 

Note that the ModelSim version provided by Altera has limited SV support. In particular it doesn't support unpacked arrays on module ports. 

 

The different SV support between Quartus and ModelSim can be a PITA. This is supposed to change in 8.1, when Quartus would upgrade ModelSim to a much newer version.
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

Note that the ModelSim version provided by Altera has limited SV support. In particular it doesn't support unpacked arrays on module ports. 

 

The different SV support between Quartus and ModelSim can be a PITA. This is supposed to change in 8.1, when Quartus would upgrade ModelSim to a much newer version. 

--- Quote End ---  

 

 

thank you, I will check the supported feature list of SV in Quartus' Handbook
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

thank you, I will check the supported feature list of SV in Quartus' Handbook 

--- Quote End ---  

 

 

Unfortunately, it is not very useful. 

 

There are many SV features implemented, but not mentioned in the documentation. And viceversa, some features are documented as implemented, but they are really not. 

 

The only conclusive way I found, is to just try. 

 

And the Quartus documentation doesn't cover ModelSim at all. Quartus does support packed arrays on ports, it is the Altera version of ModelSim the one that doesn't.
0 Kudos
Altera_Forum
Honored Contributor II
563 Views

 

--- Quote Start ---  

Unfortunately, it is not very useful. 

 

There are many SV features implemented, but not mentioned in the documentation. And viceversa, some features are documented as implemented, but they are really not. 

 

The only conclusive way I found, is to just try. 

 

And the Quartus documentation doesn't cover ModelSim at all. Quartus does support packed arrays on ports, it is the Altera version of ModelSim the one that doesn't. 

--- Quote End ---  

 

 

You are completely right.  

 

package definition; 

 

typedef struct packed { 

logic a; 

logic b; 

} fraction; 

 

typedef struct packed{ 

logic [3:0] scfsi; 

fraction [1:0] gr; 

} kkk; 

 

endpackage  

 

Compiling above example, I got this error: "error (10168): systemverilog declaration error at aaa.sv(11): prefix for packed array type does not refer to a packable type". Although fraction is declared as an packed structure. Quartus 8.0 seems not to support packed union inside an packed structure and packed array of packed structures as well.
0 Kudos
Reply