Contributor
ContributorHi @YuanLi_S_Intel ,
>>1) But the .map file generated stated that all addresses in the .map file are byte addresses. Does it mean each address location contains a byte of data ?
>> It means the data of is stored from 0x00020000 to 0x0043241B. Each address has data.
So Initial address 0x00020000 stores 8bit of data
Next address 0x00020001 stores 8bit of data (ie for byte addressing, using address increments of 1)
etc up until address location 0x0043241B
1) Does the tool currently take special care when addressing the PFL / Flash which is 16bit data ?
Wrt Page 0: Start address: 0x00020000, End address: 0x0043241B (4.269083MB of data)
Do I then try to relate above addresses to the flash S29GL01GT/S29GL512T, 1-Gb (128 MB)/512-Mb (64 MB), GL-T MirrorBit® Eclipse™ Flash (cypress.com) Table1 as follows wrt start address 0x00020000 ?
The above Flash spec states for x16 it is possible to write from 1 to 256 words, anywhere within the Write Buffer (there look to also be 256 line buffers per sector) before starting a programming operation
Our address range for eg Page 0 is huge actual page contents of our .pof is 4.269083MB from the above address range.
I looks like it uses Sectors: 2 -> 67 (i.e 66 sectors)
66 sectors * 256 line buffers * 256 words per line buffer = 4.325376MB
(4.325376MB > 4.269083MB => ok ie can fit this requested data within 66 Sectors)
Is my assumption (ie calculation above) correct here ?
2) Ok thanks. My OPTI0N_BITS were reported with the <auto> selected
Will keep this as it is.
>> 3) Our system uses flash_addr(25:0) & flash_data(15:0). How will we address our PFL correctly ?
>> Are you saying hardware connection with flash? If it so, take a look below:
>> https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf (Page 14)
I noticed that figure. Since we are using Cypress Flash in 16-bit mode, address bits of PFL & Flash match exactly, so in our case we will have :
Wrt my question "How will we address our PFL correctly ?"
Our PFL is connected to the flash directly. We can program the flash with the current .pof generated by the 'Convert Programming files' tool.
3) To implement our own 'user logic' within the Cyclone V FPGA (and avoid using the Remote Update IP as discussed already) our option now is the FPGA to read in the updated .pof file via the I2C and then ?
One of your answers to my one of my previous ticket :
>> Our remote host I2C has just links to our FPGA Cyclone V (and not direct links to the CPLD (MAX V)) before the new application image data gets forwarded to the CPLD (MAX V) with the use of the PFL IP core to program the flash :
>> Can we just implement our own logic circuitry within Cyclone V FPGA (without the use of the Remote Update IP) to receive remotely the new application image data (just chunk bare data) from our external host via I2C serially (and also convert it from Serial-2-Parallel within the Cyclone V FPGA) and then be able to load/update/store it to the PFL (PFL is within CPLD MAX V) new sector location as parallel data ready to program the flash?
>> Yes, you can do that.
4) How can we implement the 'user logic' circuitry? FPGA can decode the stream of incoming .pof data from I2C byte at a time until the entire .pof file is been transmitted through. I'm I right to think this way?
How are we able to then load/update/store it to the flash via PFL? Your answer was we can do that but how?
We currently have a flow to program the flash via the USB blaster jtag with the current .pof file that is generated by the 'Convert Programming files' tool.
The new user_logic communication/interaction with the PFL / Flash is what I am trying to figure out (ie the interaction of the Flash (& not PFL as I originally thought) from the FPGA when forwarding/sending the updated .pof addr/data + other flash control info..
I am thinking breaking the current link of the PFL within the CPLD MAX V to the flash address/data & flash control signals via multiplexers. The multiplexer could then select 'User Mode control' (ie controlling the flash via the 'user logic' circuitry within the Cyclone V FPGA so that the flash can receive address / data & control signals from the FPGA) or 'Non User mode control' (ie the muxes will re-connect it as it is at the moment ie direct PFL-to-Flash connection to maintain this connectivity too during non-user mode control).
So basically, the direct connection of the PFL to Flash when forwarding the User addr/data & control signals via FPGA user logic will be accessed by the 'User logic' from the FPGA.
What is your opinion on this ? I'm I thinking in the right direction ? Please comment here
ContributorHi @YuanLi_S_Intel ,
The system did not allow me to edit my latest ticket. Last 3 paragraphs should have stated the following :
I am thinking breaking the current link of the PFL within the CPLD MAX V to the flash address/data & flash control signals via multiplexers. The multiplexer could then select 'User Mode control' (ie controlling the flash via the 'user logic' circuitry within the Cyclone V FPGA so that the flash can receive address / data & control signals from the FPGA) or 'Non User mode control' (ie the muxes will re-connect it as it is at the moment ie direct PFL-to-Flash connection to maintain this connectivity too during non-user mode control).
So basically, the direct connection of the PFL to Flash as it is at the moment will not be present when in User mode control & forwarding the User address/data (of the new POF file) & control signals via the FPGA user logic.
What is your opinion on this ? I'm I thinking in the right direction ? Please comment here
ContributorHi @YuanLi_S_Intel,
No reply received yet. Will appreciate your reply to this latest message.
Just had an automated message to say 'are you satisfied with the reply?'
Regards,
Kevin
ContributorHi @YuanLi_S_Intel ,
Very urgent. Please reply to 1) / 2) below. Thanks so far wrt your previous replies.
Sorry, the breaking of the the current link of the PFL within the CPLD MAX V to the flash address/data & flash control signals via multiplexers IS NOT A GOOD IDEA. My mistake here. Things will not work. We will still be using the PFL.
From FPGA we can process data and write it to the flash. Can have data ready from the FPGA I2C slave controller as RSU & need to make sure that we can write it into the flash in a way PFL can recognize. Basically, the structure in the flash is defined by the PFL.
1) Just need to know how the PFL data structure is implemented (flash is just secondary data that get stored in the correct Write buffers/sectors). Programming it in a structure that PFL recommends will be a good step forward.
2) Is there some header in each sector that needs to be taken care when we program or is it just pure data? If it's just pure data, how do we get the data into the flash, which sectors etc?
Why we are interested in this? If we are manipulating those pages we write with the loader next time when we boot up configuration will try to read those and if it does not find what it expects in that location at that address, it will not work.
So if we know what needs to be written and if we can change that data then that's it. That's the remote update.
----
Also, wrt one of your replies wrt OPTION_BITS :
>> Since the options bit will be generated by the IP and during POF file generating. I think what you need to take note is that when you are generating PFL IP. You are required to select the option bit storing address. Also, you need to put the correct option bit starting address when generating the POF file.
There was no option to select the option bit storing address when generating PFL IP.
When generating the .pof / .map files from .sof files using the 'convert programming files' and using <auto> the start address of the option bit was selected as 0x00000000 and end address as : 0x00000080 as follows :
BLOCK START ADDRESS END ADDRESS
Page_0 0x00020000 0x0043241B
Page_1 0x00440000 0x0085241B
Page_2 0x00860000 0x00C7241B
OPTION BITS 0x00000000 0x00000080
Page 0 start address was then @0x00020000. So there is alot of waste address space from 0x00000080 -> 0x00020000.
The Option bits was allocated to use the 1st 131,072 dec boundary (0 – 131,071 or 0x0000000 – 0x0001FFFF). The next boundary starts then @ 0x00020000 for Page 0.
To save waste space at the beginning wrt previous example, decided to add the OPTION BITS at the end and start Page_0 at 0x00000000 as follows without <auto> mode and specifying the right boundary <start> addresses :
BLOCK START ADDRESS END ADDRESS
Page_0 0x00000000 0x0041241B
Page_1 0x00420000 0x0083241B
Page_2 0x00840000 0x00C5241B
OPTION BITS 0x00C54000 0x00C54080
This generated also successfully the .pof file with the above Start manually entered Addresses and generated the above .map file
Regards,
Kevin
