Microblaze gone wild

Are you sure your design meets timing? It may be a bit that does not change fast enough. You should review your timing constraints, and build with -timing option

Best regards,

Zara

Yup, my design does fail timing. However all failed timing constraints go through the PLB, more precisely the signal PLB_abort, which has fanout 52. Maybe you can give me a hint regarding how to fix this problem.

Thanks, e

PLB in microblaze? Do you mean LMB?

Anyhow, using the correct timing constraints in UCF, running a timing driven map should usually be enough. I do also use

-ignore_keep_hierarchy for map.

But if the signla that is failing constraints is something called whatever_abort, I am more inclined to think that timing constraints are not tight enough for your design

You clock input should be set to Nominal frequency + tolerance (or nominal period -tolerance), and it should also be given the maximum jitter possible with your oscillator

For instance, for a square 25 MHz clock, +/-20 ppm, with 100 ppm jitter, data should be like:

NET "CLOCK" TNM_NET = "MY_CLOCK"; TIMESPEC "TS_MY_CLOCK" = PERIOD "MY_CLOCK" 399997 ps HIGH 50 % INPUT_JITTER 0.40 ns;

Best luck,

Zara

Actually I do mean PLB, you see I have a PLB with 2 PPC connected to it and a Microblaze connected to OPB and a BGI & BGO.

The system should work at 100 Mhz. Forcing the PLB_Abort to be open i.e. writing this to the mhs: ... PORT PLB_Abort ... 'solves' the timing problem. But I get into another problem, namely the PPC won't start up. I use the debugger to download program to a sdram and run the processors first for ppc0, then ppc1. The Microblaze code is downloaded with the bitstream. Now the mb and ppc1 start, it turns out that ppc0 when running the __eabi function jumps to some address and gets stuck there. So, I replaced the __eabi function, now ppc0 starts, but even without changes to ppc1 this doesn't start anymore.

It's SO much fun...

Regards, e

Hi.

I'm quite unexperienced with PLB still. But my understanding is that PLB_Abort is a "late" signal, ie the sender can decide quite far into a cycle to abort the cycle. If you have lots of logic levels on your side of PLB_Abort (as your high fanout suggests), the timing closure will fail.

Fortunately, the PLB seems to be designed with this in mind. It is possible to implement all bus transactions, without having to react on PLB_Abort immediately. That is, there is no need to stack up your logic levels with those of the sender (in the same bus clock cycle).

In my PLB implementations, I ignore PLB_Abort and just register it with the bus clock. This gives the whole clock period to the sender logic and routing into my peripherial. Then, in the next bus clock cycle, I check the registered version of PLB_Abort if there was an abort "in the previous cycle". If there was, I correct my state machine and outputs accordingly.

This relaxes PLB_Abort timing and creates the necessary room for your logic levels. Both sender and your peripherial can use a full clock period for decision logic, each!

Kind regards, Marc