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

Hi,

I do, which chip do you intend to use ?

the sof is really easy to parse, it's a sequence of option number / option length / option data:

typedef struct _bitstream_option { uint16_t option; /* le */ uint32_t length; /* le */ char data[]; } PACKED bitstream_option_t;

The RAM data is the option code 19, IIRC. The only hard part is figuring how to generate the CRC (option 8, seems like a CRC32, but...).

JB

Hi Antti,

Not sure if this helps but I use Altera's altsyncram memories in my design which I pre-load using some generics

init_file => "..\cpu8088\nios_board\bootloader\mon86.hex"

then when the design is loaded I can change the memory contents on the fly using the Quartus "In-System Memory contents editor". You do need to set some more generics in advance to make this work:

lpm_hint => "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=RA86",

Regards, Hans

jbnote schrieb:

thanks JB

well the ram data is 21 and the CRC is 16 bits, but otherwise it looks like doable to task to reverse the format

Antti

Antti,

Others have commented on the general-purpose case, but since you made a specfiic reference to processors its worth discussing the soft-CPU flow for placing your code/data into onchip ram.

No, this wasn't forgotten. In fact, support for doing this has been around about as long as Nios I/Nios II have been (6+ years now?). There are even several ways to accomplish the task:

- If you are building your Nios II software in the IDE, it will take any coce/data linked into an onchip memory peripheral and use the elf2hex command to create a hex initialization file. The onchip RAM RTL generated by SOPC Builder is written out to be initialized this way; if you compile your design w/o any software having been built, memory will be left un-initialized, while if you first compile your software and then (re)compile in quartus, the .hex file(s) are used to initialize the memories.

If you turn on verbose command line output from the IDE (window ->

preferences -> nios II), you'll see the precise commands fly by on the console for future reference and command- line use.

- Although the IDE-based flow doesn't do this now, you can even update your .sof file very quickly with onchip ram contents without risk of triggering an entire re-compile. I cannot recall the exact syntax of the command but I believe the compilation step is the Quartus Assembler (quartus_asm)

- The "small" example design that ships with Nios II uses the above IDE-based method to initialize onchip RAM and as I recall the design's readme and other literature discuss this.

Note that there are exclusions to what I've said, specifically for the types of onchip ram (m-ram blocks in Stratix, Stratix II) that cannot be initialized until runtime. The wizard to create an onchip ram in SOPC Builder allows you to choose which type of ram block will be used, if you desire, to ensure that you can pre-initialize contents if that is what you need to do.

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

snipped-for-privacy@yahoo.com schrieb:

even

Dear Jesse,

I know about all you said above. but you missed the point.

in Xilinx flow you can run a tool like:

data2mem system.bit software.elf download.bit

it will take the FPGA design (with soft cpu) and merge the elf file __into__ it.

in Lattice flow you *can* do the same.

in Altera flow this is ASFAIK __not_possible__ at all.

What I need a very simple thing

my_design.sof + my_software.elf => my_ready_to_program.sof

I see no other way as doing full RE on the SOF to accomplish that. its stupid, and I would REALLY like to use Altera tools to do that, but if Altera is not able to provide such an important tool/option then someone has todo it (I really would prefer to spend my time with other things than doing RE on altera file formats)

Antti

Hi Antti,

are you using "Smart Compilation" ?

Plain Quartus: If you have a design compiled with "Smart Compilation" enabled, and then change just a memory-content-file and restart compilation, a magic "MIF/HEX Updater" (or similar) appears after the Fitter-process (which is skipped by smart compilation) and does what you want. I suppose this is also doable on the command-line. But don't ask me about the NIOS-tool-flow, you know, I am using ERIC5 ;-)

Thomas

"Antti" schrieb im Newsbeitrag news: snipped-for-privacy@f16g2000cwb.googlegroups.com...

Thomas Entner schrieb:

Thomas, I dont want smart recompile! I want NO COMPILE.

Compile once.

Merge new ELF file into the SOF file n - times.

Antti

I think Antti is after a solution that does not need Full Quratus, but is just a 'insert code' step. As he says, simple enough, and surprising it is not there aready.

There must be many teams, where the software is separate from the FPGA development, and it is both quicker and safer to avoid any rebuild of the FPGA.

Maintenance/version control, is another area where this ability gets important.

Could you not find the portion of Quartus that Jesse mentioned ? Amongst the choices, he said: " you can even update your .sof file very quickly with onchip ram contents without risk of triggering an entire re-compile. I cannot recall the exact syntax of the command but I believe the compilation step is the Quartus Assembler (quartus_asm)"

- and hopefully, that command line is both a small EXE, and not needing a license install :)

-jg

"Antti" schrieb im Newsbeitrag news: snipped-for-privacy@m7g2000cwm.googlegroups.com...

OK, I think I just realized what you are looking for (it's late...): precompiled bitstream you give to the user, where the user's custom firmware can be merged into... (I asume for your MicroFPGAs, originally I was thinking you just want to save compile-time). Don't know... With ERIC, I have the programm in a part of the configuration-SPI-Flash, as the internal RAM is quite small anyway. But I can see your point, as you have only the CPU in the FPGA... Maybe quartus_asm can help you in a way (as Jesse mentioned above), but I am afraid, it will rely on some contents of the db-subdirectory?

Thomas

Jim Granville schrieb:

Jim,

you are right I am looking for a solution that can update the generated .SOF file with the content of software object without *any* FPGA toolflow except "SOF patching". Of course it has to work without the need of license for a given part - the SOF is generated with licensed tools, afterwards only GNU GCC compiler and sofpatcher are used.

I just generated 29 .BIT files for all known Virtex-4 device-package combinations - now the MicroFpga user can just run GCC and he has working FPGA bit file even for Virtex LX200 or FX140, without the need to have FPGA toolchain license to those devices or MicroBlaze EDK license !

just for info generating 29 (actually 29+3) BIT files for ALL V-4 device-packages did complete in just about 5 hours. Not so bad at all, I was calculating with more compile times.

Antti

Hello,

You can do a pseudo "No-recompile" in the altera flow by doing back-annotation on your design. This will allow you to store the full PAR results of your design, quite similar to the XDL format. This is available on the command-line as

quartus_cdb design_name --back_annotate=lab (get back mapping / placing in the ".qsf", IIRC) quartus_cdb design_name --back_annotate=routing (get back routing in a ".rcf" file)

Then recompile by specifying to use these constraints files. This is done in the qsf file by specifying: set_global_assignment -name ROUTING_BACK_ANNOTATION_MODE NORMAL set_global_assignment -name ROUTING_BACK_ANNOTATION_FILE design_name.rcf

However, I have only tried this on very small designs, but I think this may be effective on bigger ones too. I'm interested in your results if you go this way ! (and i'll investigate precise RAM init in the sof soon).

JB

jbnote schrieb:

hi JB,

this is something that is really interesting for some purposes, but currently I really am looking for solution to have NO compile, only sof and elf merging...

here is dump of the SOF parser:

Version: Quartus II Compiler Version 6.0 Build 202 06/20/2006 Service Pack 1 SJ Full Version Device: EP1C6Q240C6 OCP: (V6AF7P00A2;V6AF7PBCEC;V6AF7PBCE1;) Option 18: FF00FFFF Option :19 (?) 16 Option :17 (logic) 139900 Option :21 (ram) 433 Option 29: 20006E00,CF19B6F1 CRC16: FE54

Antti

I suspect that there is another layer of parsing involved. Here's what I'm getting from a relatively complex model that we are using:

Quartus II Compiler Version 5.0 Build 171 11/03/2005 Service Pack 2 SJ Full Version Device: EP2S60F1020C3 OCP: (V6AF7PBCEC;V6AF7PBCE1;) Option 18: FF00FFFF OPT:19 16 1073124: 00 00 00 00 20 00 20 00 - 00 00 01 00 FF FF FF FF .... . .........

OPT:17 1923240 1073124: 00 00 00 00 00 00 DC C4 - EA 00 01 00 00 00 00 00 ................

OPT:21 6928 1073124: 00 00 00 00 00 00 1C D8 - 00 00 01 00 00 00 00 81 ................

Option 23: 2 CRC16: 83F8 ok

However, thanks for the start.

Now, to dig into the RAM

DaR

Dennis Ruffer schrieb:

hum - you are already calculating the CRC16?

if you can light on details either here or private I want mind ;)

I keep digging too, of course..

Antti

Antti, You appear to care too much about how things called. Does it matter if the thing is called "Smart Recompile" or "No compile"? Does it matter if the thing is called "merge" or "assemble"? Does it matter if the command line is "data2mem" or "quartus_cdb"? IMHO, the answer to all questions is "No, as well as they do the same thing".

Now, does they do the same thing?

liking, but it is not really slow. On the modern PC it takes about 1min for the big Stratix2-130; many times faster for smaller chips. The time seems to be independent of complexity of design.

development machine I fear the answer is "No". You need the license. [rant on] Altera Nios tools are really stupid in that regard. There are too many dependencies between Nios2 software development tools and Quartus/SOPC hardware development tools starting from the fact that you can't even

*install* Nios2 tools on the machine without Quartus. Seem Altera didn't realize yet that hardware and software development more often than not is done by different persons and the later can't care less about the tools of the former. Actually, I suspect that their treatment of Nios2 tools is pretty close to violation of GPL, but I am no lawyer. [rant off]

I, too, am interested in how you compute the CRC.

Beware though, I'll soon be releasing this in GPL code :)

JB

Hi Dennis, Antti,

I'm currently looking at a : EP2C35U484C6 bitstream.

On these bitstreams, the CRC16 is a simple crc-ccitt:

crc16 = ~crc_ccitt(0xffff, (uint8_t *)start_of_file + 1, file_length -

3);

or, if you want to check the CRC on the whole bitstream:

assert( crc_ccitt(0xffff, (uint8_t *)start_of_file + 1, file_length -

1) == 0xF0B8).

(this is _not_ endian-clean -- but you get the point, on x86...)

Can you confirm this is what you used on yours ?

JB

I spoke too fast, you need to checksum the whole file:

crc16 = ~crc_ccitt(0xffff, (uint8_t *)start_of_file, file_length - 2);

assert( crc_ccitt(0xffff, (uint8_t *)start_of_file, file_length) ==

0xF0B8).

JB

I'm sorry if I misled anyone, but no, I was not calculating the checksum, only reporting it. As I said, I need to figure out the data section format before any of this of any use. I see patterns, but so far, my data alludes me.

DaR