01-27-2014 04:06 PM
I have a Kintex 7 system with multiple picoBlazes.
As I read the JTAGLoader section of the KCPSM6 documentation, only one picoblaze can have it's JTAG_Loader enabled at a time.
So, my question is, do I have to recompile my whole FPGA to change which picoblazes' JTAG loader is enabled or is there an easier way to switch between which picoblaze gets updated?
This same design used to run on a Spartan3 (so KCPSM3) and on that design, we have a batch file that allows you to select which picoBlaze to update and then the batch file would search out the picoBlaze BRAM in the FPGA image and then it selectively replaces that BRAM area with the updated picoBlaze image and then creates a new .bit file.
Any idea if that method would work on a K7 part? Or do you know of any similar selective updater for a K7 device?
01-28-2014 10:07 AM
This is an interesting question as it has multiple possible solutions. However, before I even try to provide an overview of such solutions, I want to say that when I was preparing the KCPSM6 package and documentation I was very conscious of the fact that if I was to present every possibility then PicoBlaze could give the appearance of looking complicated. As such, I took the decision to bias the package towards first time users with the hope that it would make their first use of KCPSM6 straightforward and successful. As it happens, that also seems to cover most of the applications by most of the engineers so I’m happy! However, there are then what I call the ‘advanced and experienced users’ (and I’ve just put you in that category) that want to do more. The good news is that advanced users can typically take a few hints and then they run off implementing all sorts of things by themselves in a way that is perfectly tuned to their particularly needs. So with that in mind here are some suggestions.
JTAG Loader is definitely the fastest way to modify a program and is excellent whilst you are developing your code. I find it particularly useful that the rest of the design stays active as I often download test programs as well as developing my final application. Of course there comes a point where you need to solidify your design but running through the tools again (and probably removing JTAG Loader before going into production). As presented, you can only enable JTAG Loader on one program memory at a time. However, if you run ‘JTAG Loader –h’ the help gives you two clues...
JTAG Loader has a ‘-i’ option that allows you to specify a different ‘USER’ address for the BSCAN. The ROM_form template and the software have the default value of ‘2’ but you could copy the ROM_form template, modify the address and use that when assembling a second PicoBlaze program (see ‘JTAG Loader and BSCAN Users’ in the ‘READ_ME_FIRST’ file supplied in the KCPSM6 package for details). Just be aware that there are only four BSCAN primitives in a 7-Series device and other things like ChipScope will use those too ( I can see you know about that one from another posting on this forum).
JTAG Loader also has a ‘-b’ option. Once again the ROM_form template supplied and the software have a corresponding default value (‘0’). But if you open up the ROM_form template you will see that most of it defines the various ways to implement a dual port memory (for the various sizes and device architectures). The key point to notice is that only the connections to one port are brought out for you to connect to PicoBlaze. The connections are made to the instantiation of JTAG Loader which you will find towards the bottom of the template where you will also see the entity and definition of ‘JTAG Loader 6’ itself. Keeping everything internal and controlled by that one generic does make it clean and easy. However, you could tear the two apart and instantiate the memory and JTAG Loader separately in your design. Of course you will need to bring the connection to the second port of the memory out to achieve that but once you’ve made a template the assembler just uses it and you get HDL files with a second port every time. Now look closely at JTAG Loader and you will see that it has a ‘C_NUM_PICOBLAZE’ generic and various other generics and ports that support the connection and specification of up to 8 memories. So you can indeed connect up to 8 PicoBlaze memories to one JTAG Loader and the use the ‘-b’ option to specify which one you want to update (or read). Sounds great but there are practical issues. Firstly you need to make those connections from the PicoBlaze memories in your design back to the one instance of JTAG Loader. That’s not so difficult when the PicoBlaze processors are in the same area but often they can be working in isolation and in totally different parts of the design hierarchy. That also hints at the issues faced when the design is implemented in the device; Ok, when the connections are nice and local but can be horrible if the PicoBlaze memories are spread all over the device.
An alternative scheme (and the one I think you remember when using KCPSM3) involves using DATA2MEM to modify the contents of a block memory within a BIT file. This method avoids the need for any logic in the design and allows any memory, and any number of memories, to be modified. However, it does require the device to be reconfigured and that, and running DATA2MEM, can take quite a while especially with larger devices. It is also fair to say that DATA2MEM isn’t the easiest flow to set up and it also has its problems (e.g. I know for sure that DATA2MEM does not work properly with a Spartan-6 device). I have successfully used DATA2MEM to update 2K program memory in a 7-Series device and I could share the method I used to do that with you (and others) if you are interested in trying it yourself. I targeted a 2K program because that occupies one complete BRAM (36kb) and that natural fit gave me a fighting chance of success. I’ve yet to try a 1K memory that effectively uses half a BRAM or a 4K memory that uses 2 BRAM’s. If at some stage you modify your design and generate a new BIT file then you need to check if any of your program memories have moved location and make adjustments to the files used with DATA2MEM otherwise you may ‘miss the target’.
I hope this gives you some ideas and leads to further discussion. The one thing that is clear is that there is no perfect solution and each scheme has its advantages and disadvantages. It’s a good job we’re all engineers!
01-31-2014 12:53 PM
Thank you Ken, this is very helpful.
Full disclosure, I have 7 picoBlazes in my Kintex7 part.
So the 1 per JTAG channel is out as there are only 4 JTAG channels with one already used up for Chipscope.
Porting our Spartan 3 batch file over to K7 is an option I guess, but that already took a couple minutes on the S3 and, as you point out, the bigger (K7) will take even longer, so that gets a bit painful.
That brings me to your second option of splitting out the JTAG loader, connecting up to each one at the VHDL level, and using the -b option. You mention this could be horrible if picoBlazes are spread around (which I imagine they are/will be). Can you please elaborate on what "horrible" mean? (Hard to make timing, reduced JTag speeds, ???)
Would I have a chance with 7 picoBlazes spread around a K7 part??
02-03-2014 09:57 AM
I said ‘horrible’ in the pessimistic way that you should expect of a man that has been technically supporting customers for over 20 years. I just want anyone considering this scheme to do so with their eyes open to the potential issues and not to come complaining to me or anyone else should it cause issues.
The speed at which the JTAG Loader communicates with a memory is unlikely to result in any issues (i.e. JTAG has to shift in a whole pattern defining an address and data etc before it strobes the memory write enable so it is quite a ‘gear down’ from the actual JTAG communication rate). The potentially bigger issue is what effect the connections have on the ability of your actual design to place and route in a way that still meets timing. The address and data busses emanating from the JTAG Loader macro need to fan out to every memory (some of which may be formed of two BRAMs). It really just depends how challenging your design is to place and route anyway.
I’m not sure if you have noticed it before, but JTAG Loader also allows you to read back the contents of your memory (using the ‘-r’ command). This requires data bus connection back from each memory to the JTAG Loader macro which would further increase routing and with the potential to have a ‘pulling effect’ on the placement of the design as a whole. That connection would be optional if you didn’t need the read command. Ironically, once you have multiple memories and you start loading them with new contents it becomes more compelling to have a way to confirm that you have loaded the right memory with the right program.
It’s rather like the way that it is very difficult to measure anything without affecting the very thing you are trying to measure in the first place. In this case, good synchronous design techniques and a placement and routing that meets correctly specified timing should mean that there are no issues using this scheme at all. If using this scheme prevented the main design from meeting timing (or worst case, becoming un-routable) then it must just be considered inconvenient because it is only supposed to be a development tool and it can be scaled back again until it stops causing issues.
11-17-2014 11:55 AM
I would be very interested in learning more about the data2mem approach for loading PicoBlaze memories for the KCPSM6 using 7-series FPGAs. I recognize that it is much more inconvenient that using the jtagloader but I have a specific requirement that prevents me from using the jtagloader. Do you have a "readme" or tutorial that describes how to update a single memory for the KCPSM6 on a 7 series device?
11-18-2014 03:09 AM
I've attached my notes describing how I managed to use DATA2MEM in an ISE flow to change the contents of a 2K program memory. The 'kc705_kcpsm6_i2c_eeprom' reference design used in this example is provided in the 'I2C' directory of the KCPSM6 package.
Hopefully it will be adequate for your needs but, to set expectations, please understand that this is everything that I am able to provide you with. I'm not is a position to answer any further questions relating to the DATA2MEM flow so if you need to do something different to that described then it is a case of accepting this as a 'reference' and starting point for your own work.