memory init in Altera bitfiles, (like data2mem) is it possible?

This is all well and good, but even with smart compilation turned on, things don't work quite as well as they should. I'm designing my own CPU core, so I'm not using NIOS, but I still need to be able to update BRAM's with new program code.

I've already worked around (sort of) the fact that for some reason, Quartus won't properly update a BRAM from a .hex file. (.hex files work fine for compilation, but not a mif/hex update. So, I bring my .hex file into Quartus, and save it as a .mif file. This is annoying, since I can no longer automate the whole build process. At some point, when I get irritated enough, I'll write a program that converts hex to mif correctly, but I haven't had the time for much extra programming lately.

However, the MORE irritating problem I've run into is that if I repeat the mif/hex update process a second time, changing only the .mif file, Quartus launches into a full recompile anyway. This is a bit frustrating, since the "hardware" is stable at this point. I just need to test software. Perhaps I've missed something, but I've yet to find a way to avoid the full recompile on the second update.

Maybe this works correctly in the NIOS flow, but I don't have that tool available. I did try the NIOS eval, though, and I didn't see any new tools in it that looked like they would solve my problem.

Reply to
radarman
Loading thread data ...

What version of Quartus? Service pack? Critical update? Sounds like you were hit by that:

formatting link

BTW, if you want to minimize troubles please store you .hex files in Quartus project directory.

Reply to
already5chosen

I first noticed the problem in 5.1 SP2, but have since updated to 6.0 SP1. I already store the init files in the project folder - it's automatically copied as part of the build scripts.

Note, my projects aren't failing (they run properly), I just have to sit through a full recompile every second update.

However, this might explain some curious behavior I was seeing before I upgraded to 6.0. My processor would occasionally hang on the first JSR instruction after doing an incremental compilation. I suspected that the memory wasn't workiing correctly, but it never occurred to me that the tool might be at fault. I thougt that perhaps I had set something up incorrectly - since the ROM appeared to be working just fine. (my design has a 16kB instruction ROM, and 32kB data RAM - both megawizard created)

That support answer appears to explain what was going on.

Reply to
radarman

I'd recommend to drop your MIF workaround and return to the HEX-based flow. In theory, HEX and MIF are the same. In practice HEX-based updates are more likely to work correctly because they are part of normal Nios design cycle. I personally avoid unusual things even if in theory they are supposed to work. Don't want to waste my time debugging Altera tools. YMMV.

Reply to
already5chosen

Hi Antti,

(Sorry if someone else has already posted what I'm about to say). Sorry, I did not completely understand you the first time, but I did allude to what you need to do (or, well, part of it) in my post:

I've gone and found the missing step. These **should** work, but I don't have immediate access to verify in hardware right this moment. Please let me know if you run into trouble:

  1. Build your starting .elf, .sof as you are now
  2. Run elf2hex (see my note in my original post about using the IDE to learn the command line args of this tool) on the .elf. This will produce a hex file with memory contents for your software (code, data, basically anything linked into the .elf at the address span of the onchip ram you want to target.
  3. Run the following: quartus_cdb --update_mif .qpf quartus_asm .qpf

That's all there is to it. So, there are three commands to type, and not one (sorry), but this should accomplish what you want; there is no full re-compile (synthesis, fitting) of your software, just an "in place" update of memory contents.

Now for the caveat: The elf2hex command is pretty monolithic; if you have a multi-CPU system where each CPU linked code/data to a common memory you'd have problems since each .hex file is written out "for the whole ram". Hand editing solves this case, as does splitting up such a complex design into smaller individual onchip rams (which to me is the most logical approach).

While I cannot comment on specific future product plans, I will say that this has been noticed before and we'll certainly look at automating this.

Jesse Kempa Altera Corp. jkempa --at-- altera --dot--com

Reply to
kempaj

snipped-for-privacy@yahoo.com schrieb:

hi Jesse,

what you describes sounds like a process one step "too early".

in Xilinx flow it is possible to use bitgen (== quartus asm) for memory init. bitgen takes as input NCD file, not bitstream. but there is another tool data2mem, that takes the as input: bitstream and produces as output another bitstream.

so this flow *IS* missing in altera chain.

I want to run Quartus to produce SOF

the use this SOF __outside__ the project directory without any qaurtus intermediate files to be merged with software object to generate another SOF that now includes the software.

this sounds like not possible with altera tools

the opensource development is progress so maybe a 3rd party tool will be released before altera adds this option to the quartus flow.

[snipped here removed]

Antti

Reply to
Antti

Try the following from the command-line:

quartus_cdb --update_mif quartus_asm

where is the base name of your QSF file (i.e. the revision).

The --update_mif should take the post-fit results and update any MIF and/or HEX file(s). You then run the assembler to re-generate the SOF. So, at least from the command-line, you do not need to do a full compile and you do not need smart recompile.

If this does not work with HEX files (as it should), please file a service request or send me an email as we would need to debug and fix this. Thanks,

-David Karchmer Altera

radarman wrote:

Reply to
dkarchmer

snipped-for-privacy@gmail.com schrieb:

dont worry so much - Xilinx has been fixing issues with their data2mem for years and they still have not managed to get it right.

well data2mem like tool is completly missing in Altera flow so Altera cant have it wrong (as it is missing)

Antti

Reply to
Antti

Antii,

My reply was intended for radarman who seems to be trying to simply update the "db" with the modified HEX files, to later re-create the SOF with quartus_asm.

As for your original email, you are correct we do not have a way to update the SOF directly. Our flow assumes you are willing to use the "db" as the input. All I can say is that I am personally not aware of such request (until now).

Your feedback is well received.

-David Karchmer Altera

Antti wrote:

Reply to
dkarchmer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.