Tip:
Highlight text to annotate it
X
In this demo, I'm going to run through the new facilities
introduced in XJDeveloper release 2.6 onwards.
I'm going to do that by working through the
"Categorise Devices" screen for the Demo board setup.
The 2.6 release introduces using BOM data to match components
in your design to device descriptions
in a newly added integrated library.
Intelligent processing of BOM data
and the new "Suggest Categorisation" feature in 2.6
makes board setup faster and easier.
For this to work, of course you do need to
make the BOM data available to XJDeveloper.
Here, I'm using the ODB++ description of the board,
which has the BOM data embedded.
You can still import the BOM in other formats, if you want to.
To save time here, I have already set the Power/Ground Nets
and I've also worked through the JTAG setup screen.
By the way, the new integrated library helps out during chain setup
by offering appropriate definitions for any series resistors, jumpers etc.
But it is in the "Categorise Devices" screen that
you'll see the most benefits from the new feature.
On the left, you'll see a list of devices unassigned to any category.
The checkbox "Only Show Accessible Devices" means
we only see the devices that are accessible
either directly or indirectly from a JTAG device pin.
To get the new suggest feature to categorise as much as possible,
select "All Components" and then click on "Any" in the "Suggest" select box.
That will ask XJDeveloper to try to match every component on the list
to the most likely device, searching all parts in the library.
And here we have it.
In the "Definition" column, you can see that many of the components
match uniquely with the definition file from the library.
For example, IC6, the ADC - the match found looks good
so we'll just leave the box checked and that's job done.
Looking at IC7, the I2C EEPROM,
it has a unique match to a generic definition.
The EEPROM definition covers different memory size options
so double-click that to configure for the size we are using.
On the Demo board we are using a 128 bit EEPROM.
I will select that and click OK.
The 7400 logic device at IC8 requires the correct package to be selected
because it is available in either a 14-pin or a 20-pin package.
It is actually the SSOP14 package we want here.
Moving down, IC9. It's the SOT23-5 package we need for that one.
Now looking at IC4, the 74245 device,
its package selection has defaulted to DIP20.
The default is safe because XJDeveloper sees that
although there are other packages available,
in this case they all have the same pinmapping.
So for a quick trial setup I could leave the DIP20 selected
and it wouldn't effect the test results.
Since I know it is a TSSOP20 package we're using
I'll set that as the correct part.
Let's move onto IC3, the Flash device.
Currently, it is only logic device files
that support multiple package footprints from within the same single file.
Here, for the Flash and SRAM parts
there is a separate device file for each package variant
and for different PCB trackout options, if there are any.
For IC3, the Flash part, we are using a 48-pin TSOP package in BYTE mode.
That's just 8 out of 16 data lines tracked out.
I will select that from the dropdown list.
As with the EEPROM, there are various configuration options
that need to be set. All the information you need to do this
should be in the manufacturer datasheet.
For the Demo board the manufacturer is AMIC.
The device ID code is 0xB5.
The Flash architecture is asymmetric.
In other words it has block of different sizes.
The block size at the start of memory is 8kB
and there are 8 of these blocks.
The block size at the end of memory is 64kB
and there are 7 of these blocks.
The device does support block locking.
The device has been programmed with data in many blocks,
so a simple read test of data will find most faults.
We will enable flash programming.
Finally, from the data sheet,
the programming method is Word-by-word with bypass.
Click OK to complete that.
Moving to IC5. That matches two package types in the library
and for the Demo board it is the TSOP that we need.
Now, let's deal with the remaining Passives.
Most of the resistors have been suggested as series or pull-resistors
and the suggested categorisations look good.
It is just R22 that doesn't have a unique suggestion against it
because the information available to XJDeveloper is slightly ambiguous.
Let me explain that.
R22 is connected between a JTAG accessible I/O and the GND rail.
So that configuration would fit with R22 being a pull-down resistor.
Except that, on the other hand, R22 has a low value of 51ohms.
If we classified it as a pull resistor, we would certainly
get a false test fail reporting a short circuit to GND.
So XJDeveloper asks the user to intervene.
In this case we must set R22 as a series resistor.
XJDeveloper will then view the I/O as connected to GND.
It will check that it is low, but it will not try to drive it high.
Now that we have reviewed, configured and okayed
all the suggested categorisations, click OK on the form
and XJDeveloper goes away to process all of that.
In the status bar, you should see that
the number of uncategorised devices has dropped from 29 to 16.
After running the "Suggest Categorisation" feature for the first time,
you will often find that further parts have become accessible.
For example, through a logic device or a series resistor
that you categorised on the first time around the loop
and then these in turn will also need to be classified.
Well, that's the case here.
But from this point on, rather than running a "Suggest" loop again,
it is probably going to be quicker to mop up
these newly accessible devices just by doing a manual assign.
Looking at the Suggested Series Resistors, I will select those.
Now, I can pick up the correct library definition,
it is right there in the recent Passives, in the box on the top right.
Click on that.
Suggested Other Resistors.
R25 is a 1M resistor, so I can certainly put that into the "Ignore" category
because the value is too high to affect any testing.
Select it and hit the "Ignore" button.
The "Suggest" button has done a lot of the hard work for us,
but there are still some parts that were not matched.
That doesn't necassarily mean that there isn't an appropriate device file
in the library - just that a match wasn't made.
As time goes by, the matching will only improve
as we add more parts and more name associations to the library.
For example, the LEDs were not matched even though
there is a suitable library definition.
That's a good opportunity to show how to
browse the library and to do a manual assign.
To manually assign from the library,
click "Assign As" > "Test" device,
then "Other Defintion" > "From Library".
That takes us to the new Library Browser screen.
There's a couple of different ways to use the browser.
You can either drill down into the directory tree on the left
or you can use a fragment of the manufacturer part number
or keyword within the search box right at the top.
Just while we are here.
For example, the Flash memory we were working with a few moments ago,
I know the part number contains the number 29.
I just type that into the search box.
You can see the search tree now started to narrow.
You get the idea.
There's the Flash definition that we actually used.
Now back to the LEDs.
Part numbering for LEDs tends to be more generic
so I'll just try my luck with "LED" and type that into the search box.
There's the file we want.
I'll click Select, OK the assign form and that's done.
Back to "Unassigned Devices", "Suggest Ignore Capacitors".
These will certainly go into "ignore" because they are
small value capacitors that will not affect the testing.
Select those and "Ignore".
Same thing with "Suggested Connectors",
these will have no effect on the testing so again,
select them and hit the "Ignore" button.
Now we're down to the last few devices to categorise.
We have got Y1, the crystal.
Again, I know there is a suitable test device definition in the library.
Again, "Assign As" > "Test" devices,
then "Other Definition" > "From Library".
This time I'll drill down into the directory tree.
In "Clocks & Oscillators" you'll see a file,
Crystal.xje and that's the one we want.
Select and OK the assignment.
Same for the push button.
I'll just work through that one. Same procedure.
This time it's going to be in "Switches & Indicators"
and the one we want is pushbutton.xje.
Select that and click OK.
We're down to the very last part now.
JP1 is the fault creation jumper.
This is a "special" for the demo board so it's not going to be in the Library.
We could now go away and create an appropriate definition file for that,
but to save time here I've already put a suitable file in the project directory.
So this time it's going to be "Assign As" > "Passive" device.
We want "From File" and that defaults to the project directory.
Select that.
Job done there.
If I expand the entries on the right hand side of the screen,
now we can see that all the accessible devices
have been correctly categorised.
That's the setup done to the point where
we could do a DFT Analysis, if we wanted to.
That completes this review of the key enhancements
in XJDeveloper release 2.6 onwards.
Notably, the Integrated Library and Suggest Categorisation features.
Thank you for watching and listening.