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.

hello i when i compile in quartus i have to whait 5 hours and not done ?

Status
Not open for further replies.
There are a few reasons this could happen including: slow computer, quartus bug, complex design, over-constrained. You should check the log files to see what they're saying and what step its getting hung on.

But my main question is: has it always been this way? If not what changed.

It's very smart to do incremental design so when a problem does arise you can figure out what changed to cause the problem.
 

My only suggestion are the large ROM array's which are most likely not being implemented in a RAM block as ROM, that could easily explain the long compile times as a ROM implemented in logic (LUTs) will take a long time for the optimization to be done.

You should use an initial block and a $readmemh to load a hex file into an actual RAM. The key here is that the ROM needs to adhere to the RAM reading template to ensure it becomes a RAM initialized with the $readmemh data file.

Looking over rest of the code I don't see anything else that would result in long compile times. The way you wrote the inferred RAM in the FIFO is suspicious as there is a specific coding template for inferring RAM and it absolutely does not include anything like address calculations as part of it. This can and may be causing synthesis of the RAM blocks to flip-flops, but even if that is occurring there are only 64-bits in the RAMs, which would only have a minor impact on the compilation run time, but can adversely affect the designs performance due to the multiplexing done to emulate a RAM.

Go on Intel's site and look for their HDL coding guidelines and read it over, that document should discuss how to infer RAM/ROM and various other primitives in HDLs.
 

There are a few reasons this could happen including: slow computer, quartus bug, complex design, over-constrained. You should check the log files to see what they're saying and what step its getting hung on.

But my main question is: has it always been this way? If not what changed.

It's very smart to do incremental design so when a problem does arise you can figure out what changed to cause the problem.


hello
i have 100gb and 4gb ramand dual processor 2.2ghz
but there is no problem, something have to do with font rom(I THINK), because when i remove the font_table is working direct i mean compilation but
not working, and i have fpga de0 develompent i think ram is 550kb and 4 pll ....

thnx

- - - Updated - - -

My only suggestion are the large ROM array's which are most likely not being implemented in a RAM block as ROM, that could easily explain the long compile times as a ROM implemented in logic (LUTs) will take a long time for the optimization to be done.

You should use an initial block and a $readmemh to load a hex file into an actual RAM. The key here is that the ROM needs to adhere to the RAM reading template to ensure it becomes a RAM initialized with the $readmemh data file.

Looking over rest of the code I don't see anything else that would result in long compile times. The way you wrote the inferred RAM in the FIFO is suspicious as there is a specific coding template for inferring RAM and it absolutely does not include anything like address calculations as part of it. This can and may be causing synthesis of the RAM blocks to flip-flops, but even if that is occurring there are only 64-bits in the RAMs, which would only have a minor impact on the compilation run time, but can adversely affect the designs performance due to the multiplexing done to emulate a RAM.

Go on Intel's site and look for their HDL coding guidelines and read it over, that document should discuss how to infer RAM/ROM and various other primitives in HDLs.

hello
i think you are right something have to do with font_table rom i try to to find about ram and rom to learn and to change

thank you
 

It makes sense to pay attention to the compilation warnings

Info (276007): RAM logic "char_ram" is uninferred due to asynchronous read logic
Info (276007): RAM logic "single_cycle_cpu_io:cpu|regfile" is uninferred due to asynchronous read logic
Info (276004): RAM logic "ps2_keyboard:kbd|fifo" is uninferred due to inappropriate RAM size
The last isn't really critically, only caused by the very small fifo. RAM inference be still forced by synthesis attributes or global settings.

But the first two warnings indicate that the design hasn't been written for FPGA synthesis. All recent FPGA families have synchronous block RAM. It can be only used if read and write operations are performed on a clock edge (and some other requirements fulfilled in addition).
 

Not sure what you tried to compile, there's no project file in the repository. I guess display_scan_codes.v

It compiles for CycloneV A7 in about 45 minutes on a 2.5 GHz I7 with 16 GB RAM. I didn't add anything, e.g. timing constraints.

I think this is an educational project demonstrating processor implementation in HDL, not suited for FPGA synthesis. It may be rewritten respectively, I doubt that it's worth the effort.
 
Not sure what you tried to compile, there's no project file in the repository. I guess display_scan_codes.v

It compiles for CycloneV A7 in about 45 minutes on a 2.5 GHz I7 with 16 GB RAM. I didn't add anything, e.g. timing constraints.

I think this is an educational project demonstrating processor implementation in HDL, not suited for FPGA synthesis. It may be rewritten respectively, I doubt that it's worth the effort.


thank you for time you lose for me....
thank you.

- - - Updated - - -

It makes sense to pay attention to the compilation warnings


The last isn't really critically, only caused by the very small fifo. RAM inference be still forced by synthesis attributes or global settings.

But the first two warnings indicate that the design hasn't been written for FPGA synthesis. All recent FPGA families have synchronous block RAM. It can be only used if read and write operations are performed on a clock edge (and some other requirements fulfilled in addition).

hello

thank that you try to compile

but i still dont understand what is the problem
is FIFO small or i have small memory of luts in my fpga

- - - Updated - - -

happy wekend to all
 

The small FIFO isn't the problem. The problem is that asynchronous read of regfile and char_ram prevents block ram usage, the RAM function has to be implemented in registers with asynchronous readout logic, very ineffective.
 

The small FIFO isn't the problem. The problem is that asynchronous read of regfile and char_ram prevents block ram usage, the RAM function has to be implemented in registers with asynchronous readout logic, very ineffective.

hello
i will try to do it. becauses i i need ;-)
thank you ;-)
goodnight
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top