MicroBlaze

Hello,
Do you know any sample EDK project
that demonstrates the MicroBlaze usage
with XEM3001(v2) module.

sinan

Not yet, but we should have one soon!

Garrick

I have found it possible to bring the OK entities into the EDK environment, using wrappers. Looks like it should be pretty straight-forward to hook something up to one of the buss interfaces.

Bill

I am still working with Garret’s stuff, but I managed to build out a really simple app with EDK.

I started up a basic microblaze project. For each of the black boxes I created a peripheral under EDK to create the default peripheral structure. I probably could have just created one and copied it for each black box. Then I went and cut out the appropriate part of the OK vhdl library to create wrappers for each section, with it’s own .ngc file. Then I re-loaded each peripheral.

It took me a long time, and lots of back and forth with Xilinx to figure out that to get around the ti-data tri-state problem, just don’t list the ti-data bus as external…

Then just for kicks I deleted all the Microblaze blocks, and I can now pull in any or all, in any quantity OK blocks and hook them together using the EDK tools… It all compiles, and it is really simple in the end…

Bill

Bill,

That’s pretty cool that you managed to get around the tri-state stuff. I just threw it all into a single peripheral, but this is much more flexible.

So, the ti lines are never external? In otherwords, is okHostInterface is also setup as a “peripheral” as well? I sort of wanted the ti lines pulled out of the MicroBlaze core so that users could have non-MicroBlaze components that still use the host interface, but this would be much better for people who don’t need/want to do that and you could accomplish much more within EDK.

If you want to share any source or more specifics, that would be great. I could post it to our wiki (under Support now). It will probably go under user contributed items, but linked to the MicroBlaze stuff.

I have some other improvements in mind for the future. I want to try setting up our new Block Throttled pipes with a medium sized FIFO, flow control logic between the two, and connect them to an FSL port for very fast streaming.
I haven’t use an FSL peripheral yet, but it should work and it should be fast.

Garrick

Hi Garrick,

Well I thought I was all done, and it was all my own misunderstanding, but after you suggested I could share an example, I started to put together something a little more comprehensive than the super simple test case I put together for Xilinx… And I’m back to the multiple driver errors… And I’ve opened up a new case with Xilinx.

The case I described earlier was instantiated with ok_host_interface, ok_wire_in, and ok_wire_out. I got this to work with multiple instances also… just like what you would expect. Then when I added triggers, it all fell apart again…

My argument with Xilinx goes like this, if it compiles under ISE, why won’t it compile under EDK? Also, I think that like you said, the port should be externally viewable, and interactive. The purpose of the tri-state construct is to simplify the bus access design for the designer so that all the glue logic to implement multiple drivers on a bus, is hidden. But it looks to me like it doesn’t work right somewhere, annd to emphasis that I have an earlier EDK project I am trying to port to present versions, that used to compile, but gives me the multiple driver error also…

So anyway, I’ll just have to go through it again with another Xilinx person…

Also, I would upload my project files in case you are interested… as they are… note that the triggers don’t work yet… at least not with the wires…, but the files are 20MB or about 10x you max file size…

Bill

Bill,

It’s great that you’re trying to figure out the tristate EDK stuff. I gave up on it very easily. I’ll send you information for you to send large files when you have a project you would like us to share.

We are also entering the second phase of our FrontPanel 3 beta. Hopefully, not having the tristate bus to the sub-modules will help greatly. I have a rough draft of my okMicroInterface peripheral done for EDK 8.2 and FrontPanel 3 which I hope to post on online soon.

I was also hoping to be able to distribute EDK board support packages for our boards that performs initial setup parameters and adds the peripheral. However, I wasn’t able to have the package / EDK detect a peripheral in a user repository during the project creation wizard. One more problem to shoot to Xilinx I guess. Actually, maybe this was fixed in 8.2.

Garrick

Hi Garrick,

It seems to me that the tri-state is integral to everything EDK. And I have other projects with similar problems. To that end, it should be clear and seamless to the user, how to wortk with it. But it is not… so I’ll get to the bottom of it eventually. However I get a feeling that Xilinx knowsw more than they are saying, and may be working on this as we speak… guess I could always go stir the pot on the FPGA forum…

BTW, I am using 8.2, and it appears that anything put into the pcores directory is automatically made a peripheral. If you add pcores as a repository it will get listed twice. Everything just has to conform to the directory structure as follows:

Project
__xps
blkdiagram
data
etc
hdl
implementation
pcores
ok_buffered_pipe_in
ok_buffered_pipe_out
ok_host_interface_core
ok_pipe_in
ok_pipe_out
ok_trigger_in
ok_trigger_out
ok_wire_in
ok_wire_out
data
ok_wire_out.bbd
ok_wire_out.mpd
ok_wire_out.pao
devl
projnav
_xmsgs
xst
doc
FrontPanel-UM.pdf
hdl
vhdl
ok_wire_in.vhd (or)
okLibrary.vhd
netlist
okWireIn.ngc
ppc405_0
Projnav
synthesis
TestApp_Memory
TestApp_Peripheral
NextProject

This will give you a set of OK peripherals…

Bill

Arggggg… lost all my formating…

Hi Garrick,

I was going through your okMicroInterface code, and I could not get it to compile… there seem to be a lot of ngdBuild “structural” errors throughout. Did you get a chance to look at the project I sent you? I like your approach of building the ok_mico_interface block, and just letting the optimizer get rid of everything that isn’t used… It would be one way around the tri-state problem, but you need to make everything conform first, directories etc., and like not using caps (what a pain), using the correct module names and arcitecture structure, etc…

I would maybe start with the project I sent you…

Bill

Bill,

I’m a bit lost on what you did in your main project you sent me. There is no main MicroBlaze structure to the project, it’s entirely external ports and peripherals. It’s good to see the creation of a “peripheral” that isn’t connected to a MicroBlaze bus though, but I’m curious how you route data to the OPB bus (or FSL). I don’t think I fully understand what’s going on here.

Have you tried creating your “peripherals” in an external User Repository? It might clear up some of the doubling issues.

How many times in this type of process is okLibrary.vhd instantiated? They all have okHostInterface entities and you certainly don’t want more than one okHostInterface in a single FPGA project.

Have you gone through my tutorial on using my MicroBlaze peripheral/implementation?
[URL]http://opalkelly.com/wiki/microblazev1[/URL]

A few others have successfully compiled things. I don’t know where your ngdbuild errors are coming from. Where you compiling it within the EDK?

Garrick

Hi Garrick.

You are quite right, there is no processor. It is not required to create an EDK type design! I found that out when trying to boil my design down to the minimal required to demonstrate the problem to Xilinx. Reallly, in my view, all the EDK design is is the equivalent of a top level VHDL architecture, to tie all the signals together however the designer wants. In fact, most of the VHDL keywords seem to work here… which is kind of cool. The fact that you can enter data in the MHS file and have it pop out on the architecture view is also nice, since pointy clicky data entry can get cumbersome at times…

Did you compile everything? notice that you can have as many intances of each type as you want, but when you add more than one set of types to the Host interface than the multiple driver problem occurs… still waiting to hear back from Xilinx about the multiple driver problem… at least I have two “clear” examples for them to work with to demonstrate the problem.

As for yoiur comment about routing data to the opb or other busses, this was an “as simple as you can get it” exercise to prove operation and connectivity. Connecting to opb, or whatever, should be as easy as connecting up the signals, and letting the tool figure out how to do the bi-directional stuff (which is where it is failing (in fact it is looking to me that this is a new problem, that used to be solved)). Certainly you can easilly make a new peripheral (give it a new name by copying the directory to a new name) then when going through the import peripheral process you can take care of adding additonal portsfor the opb, etc.

As for OkLibrary.vhd, I should have removed it, it is redundant. You should notice that I created a new ok_wire_in.vhd or equivalent for each peripheral. If you look at each of these files you will notice that it contains the same information as in the OkLibrary.vhd, but instantiates only once. I actually doubt whether the DK actually uses the vhd file for anything other than a rought check against the .ngc netlist I/O definitions, which are then used to generate the .mpd files which are what are referanced by the overal .mhs file.

Boy I wish Xilinx had documented all this…

Now that I look back through all the file structures in trhe EDK, I’m getting a better and better picture about how it all ties together, and the file structure is really important…

So back from the aside, I noticed that your structures do quite equate since you didn’t build and place you peripherals in same manner I did. I was thinking you might explore this a little bit, but oh well.

So, no, I was not sucessful in building your code as per your instructions. I got several errors, including a deprecated build error. Note that I am using the latest tool, so this may be new since your tool. It appeared to me that most of these problems might go away with a structural cleanup, but now over a week later I will need to go through this all again.

So anyway, starting with part l, and reopening the project, I first note that the latest version replaced the CPU core w/ version 1.01…

After opening and closing the MHS file the errors go away (I think due to a new version of something…) It would be good if you could include a copy of your MHS file in an appendix to your instructions???

So starting with step 3 step 1. (most usually would use a.) note I can do this, but it is clearly labled as “DEPRECATED”

In step 3 step 2 there is the _HS vs _HZ typo…

In Step 4 I get the warning message “This flow is deprecated in XPS. Recommended flow is to instantiate XMP as a source in Project Navigator. Do you want to continue?” to which I answer yes…

I have a note that the first time I went through this I had too change the debug address because it interfered with theOK_micro address…

So it compiles with warnings “not verified on hardware for architecture ‘spartan3’!” for the microblaze and the memory controllers, along with the XPS/XMP warning again.

Ok, on to part II, I already copied all the files, note the typo okLibrary_v2.vhd should be okLibrary.vhd so I start up the project in ISE, and verify all the files are correct and in place. there is one note… I have changed the ucf file and the device type throughout all this to reflect a 3001 board… no problem so far… so anyway, now I try to build all this with the generate programming file command… and I get 4 errors and lots of warnings. The last and fatal error is:

ERROR:NgdBuild:604 - logical block ‘ok_hi’ with type ‘okHostInterface’ could not
be resolved. A pin name misspelling can cause this, a missing edif or ngc
file, or the misspelling of a type name. Symbol ‘okHostInterface’ is not
supported in target ‘spartan3’.

The other errors are:

Processing BMM file …
ERROR:NgdBuild:927 - Failed to process BMM file
C:/Projects/LincolnLaser/OKBlaze/Sample1/implementation/system.bmm

Checking expanded design …
ERROR:NgdBuild:604 - logical block
‘microcore/okmicrointerface_0/okmicrointerface_0/USER_LOGIC_I/fifoIn’ with
type ‘fifo16x1024_to_32x512’ could not be resolved. A pin name misspelling
can cause this, a missing edif or ngc file, or the misspelling of a type
name. Symbol ‘fifo16x1024_to_32x512’ is not supported in target ‘spartan3’.
ERROR:NgdBuild:604 - logical block
‘microcore/okmicrointerface_0/okmicrointerface_0/USER_LOGIC_I/fifoOut’ with
type ‘fifo32x512_to_16x1024’ could not be resolved. A pin name misspelling
can cause this, a missing edif or ngc file, or the misspelling of a type
name. Symbol ‘fifo32x512_to_16x1024’ is not supported in target ‘spartan3’.

I do a search for ok_hi… not to be found.

Now I find that your stub file calls out okHostInterface instead of okHostInterfaceCore. OkI fixed that one…

now I get:

ERROR:NgdBuild:76 - File
“C:\Projects\LincolnLaser\OKBlaze\Sample1\projnav/okHostInterfaceCore.ngc”
cannot be merged into block “okHI” (TYPE=“okHostInterfaceCore”) because one
or more pins on the block, including pin “ti_clk”, were not found in the
file. Please make sure that all pins on the instantiated component match
pins in the lower-level design block (irrespective of case). If there are
bussed pins on this block, make sure that the upper-level and lower-level
netlists use the same bus-naming convention.

so I open up okHostInterfaceCore.ngc and guess what… there is no ti_clk…

OK, I go edit the stub file again… are we really sure this ever worked?

We can put hi_clk on ti_clk for the interface…

OK now I compile down to the two fifo errors, the bmm process error, and still an unknown okHostInterfaceCore error…

You know what… I think it is time for you to debug your own code, clean all this up, and then get back to me…

Bill

Wow, nice long post Bill. Plenty of food for though.

You are really trying to do things with the XPS environment that perhaps Xilinx didn’t full intend (but which should be supported). I really tried to stay within the context of the standard peripheral structure with my work and didn’t travel outside the lines except to get everything (including ModelSim simulation) as a stub project. Initializing the block ram data in a simulated stub project wasn’t trivial but I got it working.

I’m sure your persistance and discovery will make the EDK more flexible and open. You hopefully have some gears turning at Xilinx.

There may indeed be some residual structure issues with compiling my peripheral in one of your projects. Things appear to get “gunked” up fairly easy and I would clean and rebuild all the HDL from time to time during my experiments. I haven’t compiled my work in EDK 8.2 but I will try it soon.

I actually did start working in 8.2, but my work was on the new version of the peripheral for FrontPanel 3 that is tri-state free and uses the block-throttled pipes for streaming. I should check my previous work, however.

Eventually, I would like to try some of you techniques on the new modules.

Garrick

Bill,

I’ve started playing with EDK 8.2i and was shocked to see that they’ve deprecated the “Export to Project Navigator Flow” as this is how I setup my example. Rubbish. I see you noted that above. It’s still supported right now, but it will probably completely disappear in EDK 9.xi.

I’m glad you sent me your stuff with your “simple” peripherals. Did you generate them completely by hand or did you use the tool to generate a bus-centric peripheral and then rip it apart?

I need to figure out the cleanest way to generate these “non-EDK” peripherals because I would like our example to highlight how to get MicroBlaze + FrontPanel 3 to work easily with other “external” HDL as well.

Maybe this will be better in the long run, but without a simple, documented way to do this within the EDK, I don’t think Xilinx should have deprecated anything yet.

Thanks,
Garrick

Hi Garrick,

At least these guys don’t change as fast as Windows… This isn’t the only project that has the “deprecated” problem. I think the easriest way around is to just make everything fit into peripherals, and let the XST do it’s thing, once they iron out the tri-state bug… They still don’t have an answer for me at Xilinx (I’m really starting to think they are stalling… they couldn’t find the projects I uploaded to them was the latest…) I gues I will have to hit the FPGA forum, if I can’t get an answer soon…

Anyway, I had to run the projects through the pripheral creator/importer twice to generate the peripherals correctly. Xilinx need to fix that because the firsty time through with create, it forces you to connect to a bus… no choice. Probably could just import and do it once, but the create got me the correct directory structure etc. I found that I could just use the okLibrary.vhd, with the proper .ngc file, but then I got fancy and just striped out whatever was required to make a proper .vhd file for each peripheral. It really was quite trivial, and only by chance that I found you could strip the microblaze out of the build…

It looks like just having the proper directory structure and files present in the pcores directory in the project is sufficient for EDK to find and include the peripherals, so it should be simple for you to build a peripheral set that you just copy into each project. In fact you should probably be able to build your interface the same way, and maybe get around the tri-state problem that way…

Anyway, I think I will put this away for a bit while I get my main code going with the version 3 stuff from Jake. I’ll let you know when Xilinx has an answer…

Bill

I got the following message back from a Xilinx FAE regarding the deprecated “export to ISE” function in the EDK:

— Begin quote from ____

[FONT=Arial][SIZE=2][COLOR=#0000ff]The “Implement Design with ISE” was deprecated because Xilinx came up with a better way to combine EDK and ISE projects. Start from your ISE project, then ADD SOURCE, and select the EDK project file (typically system.xmp). This will add the MicroBlaze system to your design as an additional top level hierarchical node. [/COLOR][/SIZE][/FONT] [LEFT][FONT=Arial][SIZE=2][COLOR=#0000ff]
When the project file is added to ISE, the EDK project settings are checked against the ISE project settings, and if anything is different (device type, for example), you will be given an option to make the EDK settings match the ISE settings. Once everything checks out, the EDK project is run and checked for other errors.[/COLOR][/SIZE][/FONT][/LEFT]

[FONT=Arial][SIZE=2][COLOR=#0000ff]Within the ISE project GUI, you can select the EDK project in the Sources window, and the processes window will change context and allow you to launch EDK from within ISE (the process is labeled “Manage Processor Design”).[/COLOR][/SIZE][/FONT]

[FONT=Arial][SIZE=2][COLOR=#0000ff]Give this a try, and you should find this is a much more integrated approach to include a processor system with other, unrelated logic in your FPGA design.[/COLOR][/SIZE][/FONT]

— End quote

[FONT=Arial][SIZE=2][COLOR=#0000ff]
[/COLOR][/SIZE][/FONT]Sounds good to me. I look forward to getting some time to try this…

Garrick

Been a while, what with vacation and all that…

Yes, this works very nicely! And this would be one way around the integration problems with EDK, just hookup to one of the EDK interfaces in ISE. However I am still grinding away at this problem, and XIlinx has been very slow to respond. Perhaps your FAE could take a look at “Case # 660506 8.2isp1 EDK - Continued Problems related to 652178”, and get something going to resolve the matter which has been going on for months now!

Bill

Hi Garrick,

I’m including the final reply from Xilinx in this matter, as well as my comment back to the FAE. Bottom line is that Xilinx does not seem to be interested in fixing the problem, and, looking at what they are now doing with EDK, I suspect it may become more relegated to configuration only than a real interface tool. Anyway here is the response, again, maybe you should get your own FAE involved, since you guys use more chips than I do…

Bill


Hi Michael,

So I guess what I am to conclude is that there is no solution or workaround for dealing with tri-state hdl synthesis in EDK, and no plans to change this.

Leaves me thinking that EDK is to be treated as more like a toy, than a real tool… I guess I kind of realized this when Xilinx changed the EDK interface to be called from under ISE in 8.2, and not the reverse.

Bill Hart

-----Original Message-----
From: Michael Ye [mailto:[email protected]]
Sent: Monday, January 08, 2007 2:15 AM
To: [email protected]
Subject: 8.2isp1 EDK - Continued Problems related to 652178

Hi Bill,

I have forwarded your information to development. Please refer to the reply.
If you plan to achieve the on chip bus, I suggest you refer to our OPB or PLB bus to achieve it not use tristate. The tri-state is suitable to off chip bus.
We hope our suggestion help you go on the right way and achieve the design efficient.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

  1. Yes, I would not expect a “two way” or multi-drive capable bus on an FPGA chip. However, I expect EDK to be able to handle this for me, in same way ISE handles the problem.

Inside of ISE, you deal mainly with HDL files as design entry sources to your project The ISE project is compiled as a single synthesis run so the synthesis tool is aware of your HDL files and all of the connectivity. The synthesis tool will only be able to manage tri-states if you have properly declared them in the HDL code which you appear to have done.

  1. I consider the fact that MPD and MHS synthesis rules cannot handle tri-state properly to be a bug, since Xilinx never states that the MPD and MHS cannot handle tri-state synthesis.

Inside of EDK there are more design entry files which include (but not limited to) the MPD and MHS files. MPD and MHS can handle tri-states in an analogous way that synthesis tools can handle tri-states. You have to first properly declare them. Platgen reads in the MPD and MHS files and then creates wrapper HDL files connecting all of the blocks together. Platgen is not an HDL synthesis tool but rather a tool that connects all of the processor IP together. This tool has its own unique files and syntax so that the cores can be connected. Please refer to the Platform Specification Format Reference Manual for information on proper syntax for tri-states ports.

  1. If the “workaround” you are talking about has to be performed manually each time you recompile software, then it is a pretty poor work-around. Note that I will want to open this issue up again in the other support case.

If I understand your project correctly, the work around should be to add the properties on the tri-state ports for your cores. Once this is done your design will only have to be modified when the ports on the pcores have changed.

If you would rather have the tools automatically connect the tri-states based off of your HDL code then you need to be working in an environment where HDL files are the main design entry sources in which case having only an ISE project would be the suitable course of action.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Best wishes,

Bill,

Well, that sucks but you gave it a shot. I’ve learned a few more things about EDK from your posts and code and something about persistance. I quit on the tri-state issues early on in my EDK experiments and went right to a single peripheral design.

I’m almost done with a slightly improved EDK peripheral for Front Panel 3 that I hope to add to our support pages in the next 1-2 weeks. I just need to test it a bit more.

I may also try to break out the okHostInterface into its own seperate peripheral with your “technique” so people may add extra peripherals if necessary - should be possible since FP3 has no bi-directional busses. I’ll still use the one mega peripheral I created for WireIn, WireOut, TriggerIn, TriggerOut, and two Block Throttled Pipes, but I could perhaps add more pipes if needed, and perhaps even add an FSL Pipe peripheral. Or, maybe even a OPB Pipe based peripheral with DMA access to the system SDRAM.

Anyway, more to do…

Garrick

If there are issues adding multiple peripherals with tristates to the MB bus, why not just roll them all up into one peripheral as we’ve done?

Apparently this is a feature Xilinx has chosen not to support but it really isn’t necessary anyhow. We’re not aware of any bugs in this setup. It may be worth requesting the feature from Xilinx, but since we have a reasonable workaround, it’s a pretty low priority.