Jump to content
  • 0

Generate .mcs file without Vivado


smarano

Question

Hi,
I have a question, it's possibile to create a script to generate an .mcs file without using Vivado?
Now i follow this procedure.
 

- open Vivado hardware manager 

- in the tcl console put the following command :

 write_cfgmem -format mcs -size 4 -interface spix1 -loaddata "up 0x300000 Hello/data.txt up 0x20000 Hello/firm.srec" -loadbit "up 0x0 Hello/download.bit" -force Hello/firm

- in this way an mcs file is generated and i can program my fpga.

My question is, there is a way to do the same thing without using Vivado and hardware manger? The best solution for me consists in a script that takes the input files and generates the .mcs file. So, the procedure and the commands are hidden 

 

Ty
Stefano

Link to comment
Share on other sites

12 answers to this question

Recommended Posts

@smarano,

This sort of sounds like a backwards way to solve a problem.  If you aren't going to use Vivado, then why use their format for programming the flash?  There are plenty of other ways to do it.  For example, I've now programmed the flash on my devices with configurations, data, and program instructions and I don't think I've ever used an .mcs file to do it.  Most recently, I think I've found the ELF format to be most valuable, but I've used others.

Dan

Link to comment
Share on other sites

There are a lot of problems @D@n :) my boss ask me to find another way to programm my CMOD A7 without Vivado but i can't find nothing to do this. Impact doesn't support this board, Digilent Adept 2 too. Another problem is that he want to do a demostration where : 
- someone can program the fpga with a generic firmware (firmware.srec + download.bit) without showing all the process. This generic firmware must be a single file so i use 

write_cfgmem procedure to generate .mcs file. In this way i generate a single file that anyone can flash on my board with a simple procedure 
(using Vivado in this case unfortunately). I can generate the .mcs file before the demostration and i can bypass the topic problem. 

- the second stage of this demostration consists in generate the user data with own procedure. The output of this own procedure is a crypted file.txt, now we need to flash this file in front of partners. Now he won't show the procedure to transform .txt file in .mcs file to programm the fpga. So he ask me to create a script that take this .txt file and generate the data.mcs file. 

i don't know if it is possible or if there is another way to do this.  

Link to comment
Share on other sites

@smarano,

So here's where I'm at: I don't know or understand the MCS format, so I wouldn't know how to break it apart.  (Sorry ...)

However, the bit file format is pretty simple: strip off the header and write it straight to flash.

The ELF file format that the firmware file should be in (or at least was at one point) is simple enough that you can read that with libelf and know where to place items in the flash.

I built a flash loader that does both of the above, so it's quite doable.  You can find examples of such a flash loader here for the CMod S6, here for the Arty, and here for a more generic board (S7 should fit here, but I don't have one to prove it).  All of these flash loaders, though, depend upon having a particular load within the FPGA to work.

Hope that helps.  Let me know if not,

Dan

Link to comment
Share on other sites

@smarano,

Just to add on top of the above ... you can also switch bit files using the ICAPE2 interface on any 7-series part.  The wbicapetwo core shows one example of the logic necessary to do this.  I've now used this logic on all of my 7-series FPGA's.

Here's the business case and why it matters: imagine you deploy some firmware on your 7-series part--such as the Artix-7 on the CMod A7 in this case.  Some time after deploying this firmware to the customer, you want to deploy an update.  The customer, though, doesn't have the extra piece of hardware necessary to load the device (i.e., no Vivado, no JTAG Adept loader, etc).  How do you then update the customers hardware (i.e. the config and firmware file(s)), without adding to your bottom line cost and delivering additional physical hardware or Vivado licenses to do the task?

Xilinx discusses how to do this in their configuration guide.  Look over the chapter on reconfiguration and multiboot. 

It basically works like this: You create two configuration locations on the flash.  One configuration starts at the first address on the flash, and contains the "good" or "golden" configuration.  This configuration is known to work from the factory (i.e. your office), and it allows you to load the second configuration--the "updated" configuration--into the flash.  When you are ready to switch configurations, you set the warmboot register (WBSTAR) to point to the alternate configuration, and then you give the FPGA the command to reload its configuration from that address (IPROG).  If there's a problem with the new configuration, the configuration loader will automatically fall back to the first configuration on the flash--allowing your software access to the FPGA to "fix" things and try again.

You can also create in your .bit file instructions to jump to your alternate (customer reconfigured) configuration immediately, rather than going through the first config to get there.  If it fails to load this bit file, then it will go back and load the "golden" configuration (first address on the flash) to allow you to resolve whatever issue and go back to the first.  (It's in the config guide, I haven't tried this though.)

Another thing I haven't tried using is the watchdog timer implemented as part of the configuration interface as well.  Using the watchdog timer, you can force the FPGA to go back to the golden configuration if your software hasn't sufficiently loaded itself far enough to reset the watchdog--at least, that's what I think the capability provides.  I haven't tried that part to know for certain and in depth.

From a software standpoint, you can read from the ICAPE2 interface to determine whether the last configuration was loaded validly, whether or not it was an alternate configuration, or whether there was some problem loading a configuration (BOOTSTS register, IIRC).

Incidentally, this is how I loaded firmware and bit files onto my Basys3 board.  I would load the first configuration via a USB stick, and I would recover the FPGA via the USB stick in case anything went wrong updating the "golden configuration" or changing/updating my serial-port to wishbone bus interface.  Ever after, though, I could use the serial port to pass data to the flash, load new configurations onto the device, etc.  This allowed me to load presentation slides onto the Basys-3 device for use with the VGA port, as well as software for processing a GPS NMEA stream and PPS input from the PModGPS.

Dan

Link to comment
Share on other sites

On 6/27/2017 at 7:41 PM, D@n said:

@smarano,

Just to add on top of the above ... you can also switch bit files using the ICAPE2 interface on any 7-series part.  The wbicapetwo core shows one example of the logic necessary to do this.  I've now used this logic on all of my 7-series FPGA's.

Here's the business case and why it matters: imagine you deploy some firmware on your 7-series part--such as the Artix-7 on the CMod A7 in this case.  Some time after deploying this firmware to the customer, you want to deploy an update.  The customer, though, doesn't have the extra piece of hardware necessary to load the device (i.e., no Vivado, no JTAG Adept loader, etc).  How do you then update the customers hardware (i.e. the config and firmware file(s)), without adding to your bottom line cost and delivering additional physical hardware or Vivado licenses to do the task?

Xilinx discusses how to do this in their configuration guide.  Look over the chapter on reconfiguration and multiboot. 

It basically works like this: You create two configuration locations on the flash.  One configuration starts at the first address on the flash, and contains the "good" or "golden" configuration.  This configuration is known to work from the factory (i.e. your office), and it allows you to load the second configuration--the "updated" configuration--into the flash.  When you are ready to switch configurations, you set the warmboot register (WBSTAR) to point to the alternate configuration, and then you give the FPGA the command to reload its configuration from that address (IPROG).  If there's a problem with the new configuration, the configuration loader will automatically fall back to the first configuration on the flash--allowing your software access to the FPGA to "fix" things and try again.

You can also create in your .bit file instructions to jump to your alternate (customer reconfigured) configuration immediately, rather than going through the first config to get there.  If it fails to load this bit file, then it will go back and load the "golden" configuration (first address on the flash) to allow you to resolve whatever issue and go back to the first.  (It's in the config guide, I haven't tried this though.)

Another thing I haven't tried using is the watchdog timer implemented as part of the configuration interface as well.  Using the watchdog timer, you can force the FPGA to go back to the golden configuration if your software hasn't sufficiently loaded itself far enough to reset the watchdog--at least, that's what I think the capability provides.  I haven't tried that part to know for certain and in depth.

From a software standpoint, you can read from the ICAPE2 interface to determine whether the last configuration was loaded validly, whether or not it was an alternate configuration, or whether there was some problem loading a configuration (BOOTSTS register, IIRC).

Incidentally, this is how I loaded firmware and bit files onto my Basys3 board.  I would load the first configuration via a USB stick, and I would recover the FPGA via the USB stick in case anything went wrong updating the "golden configuration" or changing/updating my serial-port to wishbone bus interface.  Ever after, though, I could use the serial port to pass data to the flash, load new configurations onto the device, etc.  This allowed me to load presentation slides onto the Basys-3 device for use with the VGA port, as well as software for processing a GPS NMEA stream and PPS input from the PModGPS.

Dan

Hi,

i want to dump code in arty broad through Ethernet (remote update)........ for that first convert  ( download.bit + my.elf ) in my.mcs file ........than my.mcs to my.bin file through promgen......... and send to arty by ethernet using IPERF  utility... ..... than i try to write flash using isf_write() api ...... but this process not work .. so please help me for that .....

Link to comment
Share on other sites

16 hours ago, kwilber said:

The website FPGA Cores has IP that allows remote programming of .bin files over ethernet that I have used on my Arty. It might be worth a look.

hello kwilber thanks for reply and it also help full for me,

i need to know, how to store code in FLASH..... and multiple boot image in single flash memory, and boot form different address by assigning different base address for each boot image ......

Link to comment
Share on other sites

The FPGA Cores solution does program the flash, but I have only used it to program single images into the Arty's Quad-SPI flash. 

Multiboot may be beyond scope of the FPGA Cores solution as listed on their website. You would have to contact FPGA Cores directly to inquire about multiboot capability.

Link to comment
Share on other sites

32 minutes ago, kwilber said:

The FPGA Cores solution does program the flash, but I have only used it to program single images into the Arty's Quad-SPI flash. 

Multiboot may be beyond scope of the FPGA Cores solution as listed on their website. You would have to contact FPGA Cores directly to inquire about multiboot capability.

thank for reply

Link to comment
Share on other sites

Quoting from the FPGA Cores website "Currently we support Xilinx 7 Series (Artix, Kintex, Zynq and Virtex)". 

That being said, to use the IP,  the board has to have the required components, eg a serial flash and an Ethernet PHY with either a MII or RMII interface to the MAC.

I would again suggest you contact FPGA Cores directly. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...