Matthew's Mumblings

Mapping the Absolute Addresses of Registers from a C Header

2011-08-08T23:18:00.004+01:00

Why am I doing this, you may ask? Doesn't the microcontroller manufacturer provide the absolute addresses of the registers? Well in this case, no they don't and I need them to complete the plugin for the Keil µVision debugger which will make them visible and editable via human readable names.

There are a number of ways of mapping hardware into C but due to the limitations of the const keyword [did you know you can cast the const away? add it to the list of things in C like = actually being assign, declare a pointer with * and then deference it's content with *, etc., etc.] most microcontroller manufacturers end up using #define statements as they can be made to result in fixed numeric constants that can then be optimized.

[For a quick counter example create a function that accesses a global const pointer, call it and then look at the ASM. Does that look optimal to you? But don't blame the compiler - it can't assume you haven't messed with the const pointer with casts! A good discussion is here.]

Anyway the normal way is to begin with several layers of #defines. The reason is for maintainability and portability. Typically the registers for a microcontroller peripheral are created at a fixed offset from a base and typically they will want to use the peripheral in several micros. So this is how they arrange things for the USB module in the Fujitsu MB9BF506R, an ARM Cortex M3 based microcontroller:

#define FM3_PERIPH_BASE    (0x40000000UL)



...



#define FM3_USB0_BASE      (FM3_PERIPH_BASE + 0x42100UL)

So the USB peripheral is actually to be found starting at address 0x40042100UL. However the actual device registers are laid out by a C struct. The struct creates the offsets for the individual registers internally and maps them to the human readable names.

Structs have several rules imposed on them by the C standard and also have a few gotchas so please treat these header files with great care when used with a different compiler UNTIL you have verified it. The rules are:

The named elements of a struct will be in the same order as declared in C .
Suitable padding may be included between elements to speed access to the data.

For more information refer to this article: http://www.eventhelix.com/RealtimeMantra/ByteAlignmentAndOrdering.htm.

[If you don't want suitable padding to be added then consider using the pack attribute, e.g. in gcc #pragma pack. This can have terrible performance consequences so as always, know what you are trying to achieve.]

Here is a fragment of C from the mb9bf506r.h header file which creates the C symbols for the appropriate registers:

typedef struct

{

  union {

    union {

      __IO uint16_t HCNT;

      stc_usb_hcnt_field_t HCNT_f;

    };

    struct {

      union {

        __IO  uint8_t HCNT0;

        stc_usb_hcnt0_field_t HCNT0_f;

      };

      union {

        __IO  uint8_t HCNT1;

        stc_usb_hcnt1_field_t HCNT1_f;

      };

    };

  };

...

So following the rules of struct's in C we have the first element being an unsigned, 16 bit long register called HCNT at the first address of this struct, 0x40042100UL. Note the use of unions to allow the same address in memory to be accessed several different ways. In this case it is enabling HCNT to be accessed as a 16 bit wide register and as two separate 8 bit ones called HCNT0 and HCNT1.

Lets look at the same piece but with the next register's definition included:

...

  union {

    union {

      __IO uint16_t HCNT;

      stc_usb_hcnt_field_t HCNT_f;

    };

    struct {

      union {

        __IO  uint8_t HCNT0;

        stc_usb_hcnt0_field_t HCNT0_f;

      };

      union {

        __IO  uint8_t HCNT1;

        stc_usb_hcnt1_field_t HCNT1_f;

      };

    };

  };

        uint8_t RESERVED0[2];

  union {

    __IO  uint8_t HIRQ;

    stc_usb_hirq_field_t HIRQ_f;

  };

  union {

    __IO  uint8_t HERR;

    stc_usb_herr_field_t HERR_f;

  };

        uint8_t RESERVED1[2];

...

The line of real interest is uint8_t RESERVED0[2]; between the two 16 bit registers. ARM devices' memory map is byte addressing, i.e. each byte attracts a unique address number. So the 16 bit variable is sitting across two 8 bit numbers (which the union allows individual access to). However the main memory of an ARM system is typically organized on 32 bit words, i.e. two 12 bit words and four 8 bit words. The uint8_t RESERVED0[2]; array of two 8 bit words 'pushes' the next register (the 8 bit HIRQ) to the start of the next 32 bit word. This means that the HCNT is at 0x40042100UL while the HIRQ is at 0x40042104UL, 4 bytes offset from the USB peripheral base.

The External Memory Interface as an Educational Tool

2011-07-24T04:24:00.002+01:00

In a recent email conversation with an engineer I ended up discussing the advantages of an external memory interface (EMI) over general purpose I/O (GPIO) on a microcontroller for the purposes of education. This short piece comes from that discussion.

The question posed was this:

"What advantages does an external memory interface have over driving a peripheral with GPIO?"

... which immediately brings out the question, what do I mean by an external memory interface and what do I mean by GPIO?

General Purpose Input Output (GPIO)
This typically refers to a pin of the chip which is not necessary for any of the operations of the chip but is available to a system designer using the chip. Put another way if none of the GPIO are used then the chip will function just fine. The pins are under software control and can be turned into either inputs allowing data to be read from the outside world or outputs pushing data to the outside world.

External Memory Interface
In modern digital computer architecture the standard method of connecting a processor core to the outside world is with a memory interface. This is typically formed from an address bus, a data bus (either bi-directional or two uni-directional ones) and some control lines to indicate whether data is being written or read.

Normally this is present inside the chip but forever hidden from the designer inside and only a few designs allow it to be exposed. Those that do allow extra RAM or ROM memory to be added to the fixed amount of a normal microcontroller design.

Engineering Advantages of EMI

Direct memory mapped busses has a couple of advantages over GPIO so, as usual, it depends what you are doing as to whether you care (typical engineers comment!). Here are the two main differences:

Native machine code access. Grants speed, reduced code size and I would guess lower power? No extra instructions to drive the GPIO and turn the bus around to slow you down. Simply create pointers and data structures as usual and prod the linker to place them in the external chips. Or use explicit addresses.
Code execution from external memory. Related to the above.

1. is only an issue when speed is at stake, really. Code size isn't that big a problem most of the time and the software wrapper around GPIO won't be very large. Certain ADC's and DAC's (usually video or software radio) pretend to be SRAM for extremely quick access and would really require this method of access to function effectively.

2. only matters if you have run out of on-chip non-volatile memory and have to move sections of your program off chip.

[Just speculating re. 2. code execution: you could change the compiler to emit instructions to drive a GPIO for data memory accesses in a certain range. However I can't work out how to do a native instruction fetch from the external memory without a little code in internal flash copying it to an area of RAM first. Perhaps a block copy strategy held in flash as a bootloader type thing could minimize the pain of this if it was invoked as appropriate by a compiler or linker? Note that in the world of computers I have discovered that someone has always built an implementation of just about every whacky idea. If you know of a system that uses this paradigm then please let me know. PC's don't count.]

In a final summary if you are accessing a data storage area or a peripheral occasionally and don't care about 1. or 2. then a simple software wrapper around GPIO would do just fine and be relatively efficient. I would guess 3 to 5 times slower?

Educational Advantages of EMI

From an educators point of view when teaching computer architecture and interfacing and EMI is gold in terms of hammering what is happening inside all general purpose computers into the heads of students. I mean simply this basic idea:

"A CPU issues an address onto the bus with control signals and writes or reads data."

This very basic idea is surprisingly poorly understood by many students as it is completely hidden from them inside micros or PCs. In many EE or even CompE courses the students never actually physically observe it in action or build their own peripheral and code software to drive it. As long as it remains a mental exercise a substantial portion of the students will not really understand it and without understanding it their ability to understand computers and software suffers.

Myself and colleagues (past and present) have gone to great lengths to try to give them some practical experience at it - I first encountered a softcore PIC in an FPGA used to expose its pipeline and memory and databusses for the students to observe and extend. We moved to an Atmel part (an ATmega128) with a real external memory interface instead when it became available. Multiplexed address + data but designed so it could drive an 74 series 8 bit latch to generate the full bus. Much improved from our softcore PIC! We would set them the task of mapping an 8k SRAM and an 8 bit input and 8 bit latched output into the memory map of the microcontroller.

I am looking forward to developing similar exercises with a more advanced external memory interface (called the EBI, external bus interface) found on Fujitsu FM3 ARM Cortex M3 based microcontrollers. It has the following neat features, and is really designed to drive FLASH memories transparently which is no mean feat:

It does have an external wait input which could prove very useful
for custom peripherals.
It has a basic SRAM mode with configurable timing for read and write strobes.
It can transparently split and rebuild data from 32 bit to bus widths 8 bits (or 16)
on the fly by issuing the correct sequential addresses.
It can natively drive various types of FLASH memory including NAND block erase and NOR page reads etc. while pretending to be normal memory to the software.

Supporting a Microcontroller Course with Hardware

2011-07-12T03:30:00.006+01:00

If you have come to this article for a prescription then I am afraid you are in the wrong place. I have structured this piece as a list of questions you need to answer to obtain the microcontroller that really suits your wants and needs. I have included the answers that work for me at the end to show how I have answered my needs.

Teaching microcontrollers always starts with the architecture. Sadly this is hardly ever a process that starts with a clean sheet. Each university or company typically has historical investments in a few preferred architectures and sticks to them like glue. Opportunities to change existing courses should always be carefully weighed for the costs and benefits.

If you are starting from a clean sheet, or reconsidering existing teaching let me urge you to consider the ARM architecture for one incredibly good reason: the prediction that one ARM processor will be manufactured per person per year by 2014 (EE Times). There are already billions out there in the world. If you are not teaching ARM consider very carefully whether you are doing the right thing by your students by leaving this very valuable training out of their studies. If you want other reasons consider you can get ARM powered chips for the same prices as 8 and 16 bit microcontrollers with comparable peripherals that have 32 bit datapaths and high clock speeds from many manufacturers! Access to development kits mounting ARM Cortex-M devices with programmers/debuggers can cost as little as $12.

[It should be no secret that I am an admirer of ARM cores and have been working with ARM for some time now]

What are the course choices?

Excluding budget constraints and existing equipment and if the number of hours in the course is fixed then we can classify courses into three types. These types are based on where the weight of the learning outcomes are placed as well as the existence of suitable hardware and software support. The three categories are:

"Bare metal" (bare chips and a programmer/debugger) - This is one of the best ways of achieving learning outcomes that include basic hardware requirements of microcontrollers i.e. clocks, resets, capacitive decoupling, etc. Coding will consider the booting of the microcontroller as well as code to support any peripherals.
Interfacing (a PCB with a few LEDs and switches, probably a clock crystal) - Learning outcomes mainly consist of building interfaces to other peripherals and hardware and advanced coding to support the peripherals.
Embedded Software (a loaded PCB where every interface or IO connected to an appropriate demonstration peripheral) - This emphasizes coding, probably including a suitable RTOS or algorithms development for embedded systems.

No matter what level of course you decide to support there is one basic point that I think needs to be addressed right now:

On Chip Debugging. Can the actual ASM code and data in RAM be observed while the microprocessor is executing software?

It can be very easy to end up with hardware that will not support any visibility into the microprocessor/microcontroller as its executes software. In my opinion this damages and interferes with your student's ability to understand and experiment with code inside the microcontroller. In my opinion on chip debugging is a basic pedagogic requirement for any course, not a "value added extra" [NB It is possible to design courses around this limitation but, really, in the 21^st century why should you have to? And why should your students be limited in this way?]

Practical considerations when choosing a course

The main point when considering the three main levels of microcontroller courses you are thinking of teaching is whether you have any electronic laboratory capability, i.e. lab equipment (PC, oscilloscope, function generator, power supply and parts) and trained teaching and support staff or not.
If you have a lab then you can look at implementing any of the levels. If not then go for Embedded Software straight away or establish the lab later. "Bare Metal" and Interfacing are not for you!
As a practical point for "Bare Metal" courses if chips are not available or convertible to a DIP package choose another architecture to teach.
If you have the lab then the investment in development kits may be a factor. The fully featured kits necessary for Embedded Software are the most expensive, and the least effective at supporting the Interfacing course. At best a few GPIO are available for your students to play with.
Homebrew hardware/Custom hardware or commercial? This is always a tricky one and best left to your judgment. A few points to consider are:

Have you used the micro before? If not a commercial kit may help, at least for the first few years.
Do you really need a custom system? If you are doing something specialist or have an existing investment in expansion hardware then a custom system can be a part of a really interesting and challenging course.
Custom hardware needs designing and then supporting i.e. repairing, updating, etc. and often proves much more expensive over time than commercial kit.

Which architecture should be taught?

Bear in mind the three "levels" of course I have just discussed then we can seriously look at which architecture we should support from two points of view: Pedagogic (teaching) and Practical.

Pedagogic

Are the functions of the CPU core easy to separate into a simple subset? All real cores tend to have advanced features and blend certain activities due to the need for speed but for training purposes can you keep them separate?
Memory access. This is pretty important and in my opinion it should be a single memory space not paged and the ability to directly execute on data in the memory should be limited - i.e. register math
Is the architecture RISC or CISC? Teaching any CISC architecture is typically only sensible from a software programmers point of view and even then it doesn't lend itself to a structured course. I would firmly suggest that a RISC form the basis of your courses

Basically I am a RISC fan from a teaching point of view. As I have to teach fundamentals of hardware structure and design as well as software starting from a RISC is a huge help to my students. [As a cheeky point most CISC designs these days suggest a limited subset of functionality be used for speed so teaching that subset is a great idea.]

Practical

Confidence/Experience - If you have had success with a design or device then a new device represents a big unknown in terms of software and hardware. Remember those unexpected Errata?
Documentation - Typically for a university a huge amount of existing documentation and notes that have built up around the architecture. Think of all the tutorials and lectures that need rewriting!
Staff training - Your lab helpers have to know how things work, i.e. does the debugger connect every time? Do you have to reboot the PC if the thing hangs? Does the software have any quirks? (perhaps what quirks does the software have)

These reasons are also very true for companies but I would suggest that the documentation point would be replaced with code libraries when a commercial client is involved.

What hardware?

Here are the factors that I think are most important in choosing a development kit. This is where ARM technologies really score - compared to proprietary architectures there is a real diversity of choice of chip manufacturer with about every possible peripheral included:

Cost - labs full of development kit adds up pretty pricey
Programmer/debugger cost - see above. Don't forget that many programmer/debuggers are NOT bundled with the development boards. Also if you want your own students to have their own personal boards they are going to need programmer/debuggers.
Software - how easy is it to access the compilers and debuggers
Robustness - students are pretty hard on kit. How much work are you going to have to do to harden the boards electronically and physically?
On chip peripherals - if you are going to teach standard peripherals like USARTs or I²C then make sure they are included in your micro

What software?

We then need to consider the programming environment. Again ARM has a real breadth of choice of IDEs and compilers for ARM based microcontrollers. The following points should be born in mind:

Is there a free version for students, and if so how limited is it?
Is the full version terribly expensive and under what conditions can it be accessed? Hardware companies have an easier choice when software than purely software companies as for them the software is not their core business.
How easy is it to support? There are plenty of development IDEs that require Administrator access to run or access the debugger and are often very unstable or full of bugs*.

[*IDEs with bugs can be a problem for a professional engineer but for students this can be a showstopper. It is often hard enough for them to grasp the correct operation of an IDE/micro/debugger system let alone diagnose a faulty one. Also imagine a whole lab full of machines with full admin access in the hands of students? Note I am painfully experienced in getting limited admin access for certain programs, but really, why would I want to?]

My choices

[These choices are influenced by my relationship with ARM but they may help you work through your own choices. It is important to declare interests.]

The two courses I am planning to support are two Interfacing courses. I also have an eye on project work which involves microcontrollers. Both courses are established and apply different requirements on the hardware that is going to be used.

What architecture?

Looking at ARM architectures for what I wish to achieve it is clear that we should be looking at the current generation of cores, i.e. the Cortex M or A series. The M stands for microcontroller or mixed signal and A for application. From an architectural point of view the simpler M series are clearly preferable. We are looking at Interfacing and the available M series parts are much more suited to that goal in terms of their peripherals. For Embedded Software high end M parts or A parts would be just fine. For bare metal work there are some small pin count M parts which can be adapted to a DIP pinouts but it is more challenging to use ARM for that type of course.

IDE, compiler & debugger

I am looking at using the uVision IDE from Keil (owned by ARM) because:

It is compatible with a very wide range of devices from many manufacturers so you are not tied to any one single company. This will allow a lot of reuse of notes if the target microcontroller is withdrawn or updated
It has compilers, assemblers, and on chip debugging facilities
There is the essential free version for anyone with code size limits which are well under anything you are likely to need - 32kb of code max (MDK-ARM Lite). [ARM typically have always supported universities strongly so a donation of the full version for internal use in teaching and research may be very possible - talk to them]
Keil tools are also pretty well behaved as windows programs and receive regular updates to fix bugs. Other IDEs I have used don't even regard some problems as bugs at all!
Keil donations are accessible via ARM which doesn't have the sale of development software as its core business with the implications for donations.

This IDE will support both courses quite happily as well as scaling to include larger student projects. This will reduce the amount of repeated documentation needed across the two courses as we will be supporting one IDE.

Development kits

The two courses have quite different requirements. One course needs two boards:

One for the students to own by themselves - cost is a very important consideration
One with a large amount of IO for the labs and direct access to a memory mapped IO space
Both should not have too many built in demonstration hardware (it pushes up the cost and wastes valuable IO capability)

The other course needs a board with native USB connectivity and as much raw access to IO as possible. Both courses need all the boards to be compatible with the Keil uVision IDE/compiler/debugger suite.
Resources to help find suitable ARM development platforms can be found on the university program section of ARM's website. Here are the highlights of the development boards I have considered:

Low cost student owned development board

The winner: ST STM32VL-Discovery

Micro is the ST STM32F100RB, a Cortex-M3 running at 24MHz with 128kb of flash and 8kb of RAM
On chip peripherals: 1x ADC, 2x DAC, Timers, 2x I2C, 3x USART, 2x SPI and something called CEC. There is also a DMA unit
The programmer/debugger is an ST-Link built onto the top section of the board. It can also be used to program and debug other ST STM32 ARM based microcontrollers using the ARM Serial Wire Debug (SWD) bus
The ST-Link is Keil uVision compatible for programming and on chip debugging
$12 as of the 11^th of July from DigiKey

Honourable mention: NXP LPCXpresso

LPCXpresso is both an IDE (powered by code_red technology) and a set of development boards for NXP's LPC ARM based microcontrollers
Supports various LPC families of microcontrollers based on the ARM Cortex-M3 and simpler Cortex-M0
Built onto a (one time detachable) NXP LPC-Link programmer/debugger that is supported by the code_red based IDE
$29.95 as of the 11^th of July from DigiKey. Note the variety of parts available as well as more complex and higher cost LPCXpresso compatible boards

For consideration: ARM NXP mbed

Needs no special programming hardware or any locally installed software as it is programmed from the mbed website using a web browser. Appears to the PC as a USB stick where if you place a file on it and press a button it programs itself
Seriously limited for my purposes by the lack of On Chip Debugging and simplified programming system [NB not due to the NXP micro but due to the requirement to not need locally installed software]
This was not a serious candidate for the level of education that I wish to engage in however is a very serious player for courses in high school or the first year of University
Does not come with a "standard" programmer/debugger
$60 as of the 11^th of July from DigiKey

Lab board with native USB connectivity and external memory interface
[NB This board is a Keil product due to my relationship with ARM, not that there are not excellent candidates from other providers.]
[NNB Keil does make excellent boards though!]

The winner: Keil MCB9B500 Evaluation Board

Micro is the Fujitsu FM3 MB9BF506, a Cortex-M3 running at 80MHz with 512kb of flash and 64kb of RAM
Full physical access to each and every pin on the device
On chip peripherals: USB2.0 Device and Host, 2x CAN, 8 channel DMA, External Bus IF supporting 8/16 bit SRAM, NOR and NAND flash with up to 8 chip selects, 8x USART/CSIO/LIN/I2C Serial ports, 8x Timers, 2x Multi-Function Timers, CRC Accelerator and 3x 16 channel ADCs
Apart from a few LEDs, switches, one potentiometer and the USB device and host port all the rest of the IO is accessible via the two fantastic 0.1" pitch dual row sockets. 0.1" pitch headers are the best educational header being sufficiently small to be convenient but strong to take abuse and rough handling
Programmed and debugged by the ULINK-ME programmer from Keil (not shown). [NB This is not available for general purchase, only with new kits so be sure to make sure it is included]
Compatible with uVision IDE from Keil [NB Obvious, perhaps]
$100 as of the 11^th of July from DigiKey (I haven't linked it here as DigiKey doesn't seem to sell the version with the bundled ULINK-ME but I can't be sure. Buyer Beware)

[All pictures are copyright their respective owners and are reproduced here for convenience. For owner information consult the images ALT text. ARM, Cortex, Keil, uVision, mbed, LPC, ST-Link, LPC-Link, Fujitsu FM3 and ST Discovery are probably all trademarks of their respective companies.]

I have moved to Purdue in the USA!

2011-03-16T20:37:00.002Z

Following on from a madly busy time at Southampton, UK, I am now working for Purdue University in the USA, which should be a lot of fun!

The future of computing? The SpiNNaker million processor computer

2010-06-29T22:41:00.011+01:00

The future of computing is a very big claim. However if anything the future of computing does not lie in a common time, unified shared memory system - this pretty well describes every multicore computer made at the moment. The trouble is once you go to more than a few thousand cores the shared memory - shared time concept falls to bits. It just doesn't scale. Where then should we look for a new model other than biology? The brains of living creatures are capable of phenomenal processing power and yet have almost none of the features of the computers we build today. Don't you find this odd?

Lets look at how brains do it:

Does each neuron have a sense of the passage of time? Not in the traditional sense and maybe not at all. If it does it will probably only be only vague ordering.

Does a neuron share a memory space with every other neuron? No. The closest concept is an area effect of diffusion of chemicals which affect neighbours (which may not be synaptically connected) but that is very far from a shared memory concept.

Is each neuron connected to every other neuron? They have many connections to close neurons and some connections to neurons further away best described by a statistical distribution but otherwise, again, no.

So clearly modern computing bears as relation to a brain as sudoku does to quantum mechanics. The closest we get are the datacenters of a company such as Google but they enjoy far too much connectivity to be a good model.

Enter the world of academia because no commercial company would be stupid enough to commit the resources we can into a project like this (and all the ones before it which make it possible) - it is unlike anything that has come before and it is risky (i.e. it may not work!).

Project SpiNNaker

This revolutionary idea is nothing less than a plan to put together a computer of approximately 1 million cores with no common clock or shared memory and which can route messages with a model that approximates a neurological system.

Born in the University of Manchester's Advanced Processor Technologies Group the SpiNNaker project has taken shape in collaboration with the University of Southampton's School of Electronics and Computer Science (where I work), the Engineering and Physical Science Research Council and two enlightened commercial companies: ARM (for the processor IP) and Silístix (for their Network on Chip expertise).

SpiNNaker is a child of many parents, each a vital step on the path to it's genesis:

AsipIDE GALS Design and Co-Simulation Framework - A hardware/software co-design and debugging framwork
Transactional Memory - A new locking strategy which massively simplifies the ability to lock data to pass information between processes
TERAFLUX: Exploiting Dataflow Parallelism in Teradevice Computing - A pan-european project looking at computers with massive numbers of cores
The Balsa Asynchronous Synthesis System - A language and compiler targetting asynchronous, handshake driven logic design

The main centrepiece of the SpiNNaker project is a special System on Chip, the SpiNNaker SoC. Inside are 18 processors asynchronously connected via a blindingly fast network-on-chip and communicating with the other SoCs via hundreds of megabit links to the other SpiNNaker SoCs. With these SoCs it will take only 56,000 chips to reach the target of 1 million. The cores are ARM968 series processors capable of significant independent computation while communicating with their neighbours or the 1GBbit DDR SDRAM available to each SoC. Even within a SoC the cores do not share a common clock and communicate by passing messages which are routed to each other or outside to another SpiNNaker SoC.

A seriously ambitious project you say? Absolutely right. Vapourware or a dream? Hell no! Feast your eyes on this:

This is the first generation of SpiNNaker SoCs on a test board - there are four dual processor SoCs on this board each next to its accompanying 1Gbit ram chip (click on the picture for a very high resolution version). This board already holds 8 processors asynchronously interconnected with all the necessary debug hardware to perfect the design of the next generation.

Who ever said British Science was dull?

BIG DISCLAIMER: I am not one of the great minds trying to change the world with this project. At best I have helped a couple of people around the edges. I am a very big fan, however!

A fixed OpenSPARC T2 build for Design Compiler 2009....

2010-04-22T13:54:00.000+01:00

Just a very quick note to say that we have fixed the compile problems for the OpenSPARC T1 processor when building it with modern versions of Design Compiler (any > 2007).

More information, including sizes and speeds on the Synopsys 90nm EDK to follow. Bear in mind it is missing the PLL and a couple of other small modules.

We will, of course, push this upstream.

Current activity with the EVE ZeBu Hardware/Software Co-Verification Environment

2010-03-31T17:46:00.000+01:00

The title is a fancy way of referring to the EVE ZeBu accelerators (much more information on their website). I previously posted on our acquisition of a UF-2 (I should mention we liked it so much we now have 2!) so I am taking a moment to show what we are up to with this wonderful technology. I have broken it into research and teaching topics.

Research
Behavioural Simulation and Synthesis of Biological Neuron Systems using VHDL
The investigation of neuron structures is an incredibly difficult and complex task that yields relatively low rewards in terms of information from biological forms (either animals or tissue). The structures and connectivity of even the simplest invertebrates are almost impossible to establish with standard laboratory techniques, and even when this is possible it is generally time consuming, complex and expensive. Recent work has shown how a simplified behavioural approach to modelling neurons can allow “virtual” experiments to be carried out that map the behaviour of a simulated structure onto a hypothetical biological one, with correlation of behaviour rather than underlying connectivity. The problems with such approaches are numerous. The first is the difficulty of simulating realistic aggregates efficiently, the second is making sense of the results and finally, it would be helpful to have an implementation that could be synthesised to hardware for acceleration. In this paper we present a VHDL implementation of Neuron models that allow large aggregates to be simulated. The models are demonstrated using a synthesizable system level VHDL model of the C. Elegans locomotory system.
The role of the EVE in this specific project is verifying and executing the largest of the neural net models functionality using your cosimulation replacing previous, limited, technology based around a FPGA board using a probe program.
Publications
Bailey, J., Wilson, P., Brown, A. and Chad, J. (2008) Behavioural Simulation and Synthesis of Biological Neuron Systems using VHDL. In: BMAS. (In Press)
Bailey, J., Wilson, P. R., Brown, A. D. and Chad, J. (2007) Behavioural Simulation of Biological Neuron Systems using VHDL and VHDL-AMS. In: IEEE Behavioural Modeling and Simulation, Sep 2007, San Jose, USA. pp. 153-158.

Architectures for Numerical Computation

Since the 1960s, the observation that has become known as Moore’s Law has become a self-fulfilling prophecy. Processing power doubles every two years because of the advances in CMOS technology. There are clear signs, however, that these technological advances are coming to an end. The eco- nomics of pushing CMOS technology to its physical limits will eventually halt further development.
If it is no longer feasible to increase computing power through smaller, faster transistors, the al- ternative is massive parallelism. This progression is already apparent. Multi-core and multi-threaded processors are now common. Although modern operating systems are able to use multiple cores, with few exceptions, programs are confined to single cores. The challenge facing software engineers is to make best use of multiple cores.
A significant amount of processing power is concerned with numerical computation. Consumer applications, such as image and audio processing are fundamentally numerical. Similarly, engineering applications, such as simulation and optimization rely on numerical calculations. At this point, we should distinguish between consumer and desktop applications and High-Performance Computing (HPC) tasks that rely on clusters of dedicated processors. It is not our intention to move into the HPC world at this time.
While using multiple cores can accelerate many numerical algorithms, far greater speed-up would be possible using more specialized forms of hardware, such as GPUs and FPGAs. A further consideration is power consumption (and the related problem of heat dissipation). Custom hardware can reduce power consumption by an order of magnitude or more. The key, of course, is to use the resources in the best possible way. In the context of the work proposed here, there are two aspects to this problem. First, we need to make the best division between hardware and software and second, we need to design an appropriate overall architecture.
The obvious role of the EVE platform in this research field is to support the research into specific computing pipelines, fine grain computation blocks and architectures as well as enabling the development of some 16 lane PCIe computation accelerators.

Teaching
Hosting a Complex SoC on the EVE Platform
This project was a proof of concept and de-risking of the EVE transactor flow using a large SoC. The SoC in question was chosen to be the Gaisler-Aeroflex LEON3 (http://www.gaisler.com). The LEON3 SoC is based around a SPARC v8 compatible CPU and is written in VHDL. The minimal LEON3 SoC was built using the EVE support for memory to model the processor cache along with the transactors for DRAM and UARTs. This work will be extended to include the VGA, Ethernet and USB transactors on the hardware side it and include support for the Snapgear Linux version for the LEON3.

Verification of a highly integrated ASIC
A large masters level project framework will produce a heterogeneous multicore ASIC to perform processing on HD video data streams. It will bundle an 32 bit microcontroller core, on chip SRAM, our custom geometric processor along with a multilayer AMBA bus architecture optimised for power and contention. The EVE will be an invaluable support to the simulation and verification of the final design before it is sent for manufacture.

So there you have it - quite a lot going on, all of which is really fascinating and fun!

EWME2010 and Synopsys' EDK

2010-03-17T11:44:00.000Z

Firstly EWME 2010 is coming in May. It is the European Workshop on Microelectronic Education which along with its sister conference in the USA, Microelectronic Systems Education (MSE), is pretty much unique in the world.

If you need help or advice on starting a programme at your institution then this is a great opportunity to meet a very cohesive, dedicated group of educators.

EWME and MSE are characterised by fair and honest discussions on the challenges and tools available to educators in this sphere, along with a showcase of our best student projects and modules. Papers detail how to run the course administratively as well as the practical aspects. We also get a few vendors who are always pleased to get you into contact with the appropriate University Programmes.

Secondly the Synopsys 90nm EDK and our experiences with it. We have been users of this EDK for about a year now and it forms a great basis for working with our students. Partially because of the established notes and curriculum resources make it very quick to get off the ground with several complex areas. Compared to the IDESA Advanced Digital Physical Implementation Flow course which promotes the TSMC 90nm deisgn kit this one is far more student friendly with a lower startup cost (it also doesn't require attendance to get the notes and access to the labs). [However for research the IDESA course is a fantastic introduction to 90nm and below.]

See you at EWME 2010 in Darmstadt!

IBM PowerPC™ 405-S: Verification of the Gate Level Netlist with the supplied Artisan SRAMs

2010-01-27T22:21:00.000Z

[Please note that these instructions reference the 1.00a version of the Synopsys PowerPC™ 405-S coreKit which is the version provided in the University IP package from IBM. There are updated versions available from Synopsys.]

This is the fourth article in this series (click here for the series index) describing the IBM PowerPC™ 405 synthesizable core and peripherals and will cover functionally and formally verifying the synthesized gate-level structural Verilog netlist.

Firstly let us look at the two main classes of verification:

Formal Verification
Functional Verification

In a sentence, functional verification tests if a circuit executes one or more testcase(s) correctly while formal verification attempts to show that two circuits are mathematically equivalent (for a certain value of equivalent).

Luckily for us the coreKit provides scripts and support for automating both activities. The completed netlist (with scan chains, more on their importance later) can be put into the same simulation framework that verifies the RTL is fully functional. The completed netlist can also be formally verified against the source RTL by using Synopsys Formality™.

Formal Verification

The relevant part of the instruction manual (docs/405_ivug.pdf) is:

Chapter 9: Gate-Level Verification

So for the following process assume you have used this series of articles to synthesize a PowerPC™ 405-S core with scan chains using the Artisan PDK and the files in the list below are in their correct locations.

You will need the following:

A synthesized gate level netlist in structural verilog (typically ./dc/netlist/PPC405F5V1_dft.v)
Your technology library in Synopsys DB form (if you are following the supplied Artisan flow with SRAMs it is ./tech_lib/artisan_13lvfsg/syn/slow.db)
Synopsys Formality™, Synopsys' premier formal equivalence checker

Command:
From the ./fm directory in the current workspace:

./run_fm.gate ../src/ ../tech_lib/artisan_13lvfsg/syn/slow.db ../dc/netlist/PPC405F5V1_dft.v $SYNOPSYS

Output:
Assuming you entered the command correctly Formality™ should start and the process will begin by synthesising the original RTL. This will produce a large number of warnings but in this case this is normal and expected.

It then sets a few constants disabling the scan mode in the design:

set_constant ref:/WORK/$MODULE/TESTC405SCANENABLE -type port 0
Set 'ref:/WORK/PPC405F5V1/TESTC405SCANENABLE' to constant 0
1
set_constant impl:/WORK/$MODULE/TESTC405SCANENABLE -type port 0
Set 'impl:/WORK/PPC405F5V1/TESTC405SCANENABLE' to constant 0
1

It now checks the designs and issues warnings for the RAM models.
[A “black box” is the term for a section or module of the circuit that is not visible to the tool so it is warning that it cannot verify the contents.]

Status:  Checking designs...
    Warning: Design ref:/DATARAM_64X34/dataram_64X34 is a black box and there are cells referencing it (FM-160)
    Warning: Design ref:/SRAM256X46/sram256x46 is a black box and there are cells referencing it (FM-160)
    Warning: Design ref:/SRAMBYTWR512X128/sramBytWr512x128 is a black box and there are cells referencing it (FM-160)
    Warning: Design ref:/SRAM512X8/sram512x8 is a black box and there are cells referencing it (FM-160)

And finally compares the design at the matching points, producing this worrying looking output:

Status:  Verifying...
....
    Compare point C405TESTSCANOUT0 failed (is not equivalent)
    Compare point C405TESTSCANOUT1 failed (is not equivalent)
    Compare point C405TESTSCANOUT2 failed (is not equivalent)
    Compare point C405TESTSCANOUT3 failed (is not equivalent)
    Compare point C405TESTSCANOUT4 failed (is not equivalent)
    Compare point C405TESTSCANOUT5 failed (is not equivalent)
    Compare point C405TESTSCANOUT6 failed (is not equivalent)
.
    Compare point C405TESTSCANOUT7 failed (is not equivalent)
.

********************************* Verification Results *********************************
Verification FAILED
   ATTENTION: RTL interpretation messages were produced during link
              of reference design.
              Verification results may disagree with a logic simulator.
   ATTENTION: 8 failing compare points have unmatched undriven signals in their
                reference fan-in.  To report such failing points, use
                "report_failing_points -inputs unmatched -inputs undriven".
              8 such failing compare points are directly undriven primary output ports.
              To report directly undriven failing primary output ports, use
                "report_failing_points -point_type directly_undriven_output".
              To suppress verification of directly undriven primary output ports, use
                "set_dont_verify_point -directly_undriven_output".
              To read about undriven signal handling, use
                "man verification_set_undriven_signals".
----------------------------------------------------------------------------------------
 Reference design: ref:/WORK/PPC405F5V1
 Implementation design: impl:/WORK/PPC405F5V1
 16662 Passing compare points
 8 Failing compare points
 0 Aborted compare points
 0 Unverified compare points
----------------------------------------------------------------------------------------
Matched Compare Points     BBPin    Loop   BBNet     Cut    Port     DFF     LAT   TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent)        1204       0       0       0     578   14679     201   16662
Failing (not equivalent)       0       0       0       0       8       0       0       8
Not Compared
  Clock-gate LAT                                                               1       1
****************************************************************************************
Info:  Formality Guide Files (SVF) can improve verification success by automating setup.
0

However, don't be downhearted! All Formality™ has done is its job and spotted a difference: the scan chains you inserted during the compile are not present in the source RTL. So ignoring the scan chains, as far as the tool can tell, this is the design you wanted the synthesis tool to manufacture!

Functional Verification

This is described in the same section of the manual as Formal Verification. The prerequisite is a fully functioning RTL verification environment - if it didn't work on the RTL it isn't going to on the netlist.

The relevant files are:

sim/testbench/p405s_test_top.v - this is the Verilog file containing the top level testbench. It contains a very useful parameter: parameter simulation_cycle = 100; near the top of the file which sets the whole simulation speed in terms of the clock applied to the CPU (not the PLB). It is also sensitive to a parameter called GATE_SIM. This changes the behavior of the testbench to accommodate the gate-level netlist
sim/scripts/run405.config - this file contains the parameters of the simulation "run" about to take place and needs editing to support the gate-level netlist simulation

Modifications to scripts/run405.config

This is the key script which needs a couple of modifications to simulate the netlist and not the RTL. It is a list of parameters organised into blocks which are read by the Perl script scripts/runTB. scripts/runTB then builds and executes the correct command line to run a particular simulation in your chosen simulator.

Open the script scripts/run405.config in your favourite text editor and look for the second block:

searchpath
./../src/rtl
./../src/mem_models
$SYNOPSYS/packages/gtech/src_ver
$SYNOPSYS/dw/sim_ver
./testbench
./vera/ver_shell
end

As you can see a 'block' has a header identifying it and is closed by an end keyword. The modification to this block is to comment out the ./../src/rtl by adding a # in front of the line like so:

searchpath
#./../src/rtl
./../src/mem_models
$SYNOPSYS/packages/gtech/src_ver
$SYNOPSYS/dw/sim_ver
./testbench
./vera/ver_shell
end

By doing this we exclude the unsynthesised RTL from being discovered by the simulator which is what we want. The netlist should contain the complete circuit.

Take a look at the third block:

differentfile
./../src/rtl/p405s_params.v
end

In this block we need to explicitly tell the simulator to compile the simulation models for the Artisan PDK cells from the technology library, the synthesised netlist itself and a wrapper called PPC405F5V1_soft.v:

differentfile
./../src/rtl/p405s_params.v
./../src/rtl/PPC405F5V1_soft.v
./../dc/netlist/PPC405F5V1_dft.v
./../tech_lib/artisan_13lvfsg/verilog/tsmc13_hs_modified_new.v
end

and finally we need to add the GATE_SIM variable already mentioned above. This makes the testbench behave slightly differently. When simulating the RTL the testbench forces the state of certain internal registers to 0 at the start of every run. With a gate-level netlist those registers may no longer exist, and certainly may not exist with the same name or hierarchy. To achieve the same effect when the GATE_SIM variable is defined at the start of each run the testbench places the chip into scan mode and clocks 0's through the scan chains forcing all flops to have a starting value of 0.

The correct place to set GATE_SIM depends on your simulator so have a look at the blocks in the bottom of this file:

# This is a string appended to the MTI invocations
mtioptions
+define+UNITSIM +nospecify +define+GATE_SIM
end

# This is a string appended to the NC invocations
ncoptions
+define+UNITSIM +define+SYN_RTL +nospecify
end

These two example blocks (there are others) refer to Mentor Graphic's ModelSim (mtioptions) and Cadence's NC Verilog (ncoptions). To add the define change the line to read as follows:

# This is a string appended to the NC invocations
ncoptions
+define+UNITSIM +define+SYN_RTL +nospecify +define+GATE_SIM
end

You should now be ready to fire up coreConsultant and begin.

[Note: You can run the tests outside of coreConsultant but it won't generate the nice, navigable HTML reports. To do this use the command runtest from the sim directory.]

Changes in coreConsultant

1) Run core consultant by running the command coreConsultant in a terminal window.

2) Open the workspace you created to run the RTL functional verification from the previous article and you should see the window below:

Don't press 'Apply' until the last step at the bottom or it will start the simulation immediately and there are other settings to change!

3) Ensure the settings are correct in the 'Simulator' selection before moving on to 'Select Test Options'

4) In 'Select Test Options' choose Run_Gate_Sims. Move onto 'Select Testsuite'.

5) In 'Select Testsuite' set the path to the Netlist and the simulation library:

6) You are all done. Click 'Apply' to start the simulations

The results of the running simulations are visible in the test.log file which can be monitored in realtime by executing the following command in a terminal window from the sim directory:

tail -f test.log

Studying this file you should see the following (for NC Verilog but each simulator will issue warnings of this kind):

During the compilation you will get a lot of complaints about unconnected nets. This is only sensible as the individual cells from the cell library have a fixed number of outputs, especially the flops, that cannot be removed. They come with the cell:

TLATNX8HS LOCKUP1 ( .D(dp_scReg_icuStatus1_regL2[5]), .GN(sc), .Q(scan_out2)
                  |
ncelab: *W,CUVWSP (../dc/netlist/PPC405F5V1_dft.v,123147|18): 1 output port was not connected:
ncelab: (../tech_lib/artisan_13lvfsg/verilog/tsmc13_hs_modified_new.v,28144): QN

After the compilation things should settle down into a format similar to this, one per test:

ncsim: 08.10-s006: (c) Copyright 1995-2008 Cadence Design Systems, Inc.
Loading snapshot worklib.p405s_test_top:v .................... Done
=== Verilog with Synopsys Vera ===
ncsim> source /home/esdcad/software/cadence/linux/ius81/tools/inca/files/ncsimrc
ncsim> run
 ++---------------------------------------------------------------------++
 ||                     VERA System Verifier (TM)                       ||
 ||        Version: A-2007.12 () -- Wed Dec  9 17:15:27 2009            ||
 ||             Copyright (c) 1995-2004 by Synopsys, Inc.               ||
 ||                      All Rights Reserved                            ||
 ||                                                                     ||
 ||      For support, send email to vera-support@synopsys.com           ||
 ||                                                                     ||
 ||  This software and the associated documentation are confidential    ||
 ||  and proprietary to Synopsys Inc.  Your use or disclosure of this   ||
 ||  software is subject to the terms and conditions of a written       ||
 ||  license agreement between you, or your company, and Synopsys, Inc. ||
 ++---------------------------------------------------------------------++
Vera: Loading main "p405s_top_vera" (path = "p405s_test_top.top_vera")
Vera: Loading ../../vera/lib/p405s_top.vro..
Vera: Loading ../../vera/lib/p405s_memory.vro..
Vera: Loading ../../vera/lib/p405s_slave.vro..
Vera: Loading main "p405s_dcrmon" (path = "p405s_test_top.dcrmon_model")
Vera: Loading ../../vera/lib/p405s_dcrmon.vro..
Vera: Loading main "p405s_dcr" (path = "p405s_test_top.dcr_model")
Vera: Loading ../../vera/lib/p405s_dcr.vro..
Vera: Loading main "p405s_isocm" (path = "p405s_test_top.isocm_model")
Vera: Loading ../../vera/lib/p405s_isocm.vro..
Vera: Loading main "p405s_dsocm" (path = "p405s_test_top.dsocm_model")
Vera: Loading ../../vera/lib/p405s_dsocm.vro..
Vera: Loading main "p405s_intr_ctrl" (path = "p405s_test_top.intr_controller")
Vera: Loading ../../vera/lib/p405s_intr_ctrl.vro..
Vera: Loading main "p405s_jtag" (path = "p405s_test_top.jtag_controller")
Vera: Loading ../../vera/lib/p405s_jtag.vro..
Vera: Loading main "p405s_monitor" (path = "p405s_test_top.monitor_slave_side")
Vera: Loading ../../vera/lib/p405s_monitor.vro..
>> Setting TEST_c405ScanEnable = 1 <<
Entering the PLB Initialization sequence time=0
Entering Reset delay sequence time=1000
Completing Reset delay sequence time=2999000
>> Setting TEST_c405ScanEnable = 0 <<
>> Forcing Reset of D-CACHE Tags <<
3002000 info: Slave0: is in Reset

3003000 info: Slave0: is in Reset

3004000 info: Slave0: is in Reset

3005000 info: Slave0: is in Reset

3006000 info: Slave0: is in Reset

3007000 info: Slave0: is in Reset

3008000 info: Slave0: is in Reset

3009000 info: Slave0: is in Reset

3010000 info: Slave0: is in Reset

3011000 info: Slave0: is in Reset

3012000 info: Slave0: is in Reset

3013000 info: Slave0: is in Reset

>> Forcing Reset of D-CACHE Tags <<
DCRMON (3797000): DCR Write : Addr = 44 WData = bfff0000
DCRMON (3907000): DCR Write : Addr = 0 WData = 0
DCRMON (3922000): DCR Write : Addr = 11 WData = 0
DCRMON (3977000): DCR Write : Addr = 8 WData = 0
DCRMON (3997000): DCR Write : Addr = 1 WData = 0
DCRMON (4001000): DCR Write : Addr = 9 WData = 0
DCRMON (4005000): DCR Write : Addr = a WData = 0
DCRMON (4014000): DCR Write : Addr = 20 WData = 0
DCRMON (4028000): DCR Write : Addr = 3 WData = 0
DCRMON (4109000): DCR Write : Addr = b WData = 0
DCRMON (4113000): DCR Write : Addr = c WData = 0
6488000 info: Slave0:  MasterId=1  Request for Write addr=00000010

6488000 info: Slave0: 1 to MultiByte Write

TESTCASE took 3474 Clocks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TESTCASE "addfvt" PASSED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vera: finish encountered at time 6493000 cycle    6494
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 10739
                      expect: 0
                      sample: 49891
                        sync: 16493
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 6493
                      expect: 0
                      sample: 3199836
                        sync: 607518
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 19494
                      expect: 0
                      sample: 64898
                        sync: 32462
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 6517
                      expect: 0
                      sample: 32469
                        sync: 19482
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 3882
                      expect: 0
                      sample: 56947
                        sync: 12987
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 11903
                      expect: 0
                      sample: 43549
                        sync: 12987
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 6737
                      expect: 0
                      sample: 33265
                        sync: 13564
Vera: finish encountered at time 6494000 cycle    6495
        total       mismatch: 0
                   vca_error: 0
              fail(expected): 0
                       drive: 1
                      expect: 0
                      sample: 140
                        sync: 108
TESTCASE "addfvt" PASSED

You can see the Vera banner at the top, the individual Vera modules loading. The only difference to the RTL simulations are the following two lines:

>> Setting TEST_c405ScanEnable = 1 <<

and

>> Setting TEST_c405ScanEnable = 0 <<

which are found after the last Vera module loads at the start of the simulation. This is the effect of the GATE_SIM define added earlier and is showing the activation of the scan chains to zero the flops internally.

And finally you should be greeted with a report in coreConsultant that looks like this:

There, you have now formally and functionally verified your very own PowerPC™ 405-S netlist. All it needs is to be placed and routed (and finally functionally and formally verified again) and you are good to go!

Published with permission from IBM and Synopsys

A word from a Lecturer on the use Wikipedia to students everywhere

2010-01-15T22:29:00.002Z

The use of Wikipedia as a reference is a depressingly common crime committed by students but it is spreading to professional areas as well.

Wikipedia is an excellent introduction to a topic, but never a reference source. I often look up things on Wikipedia but I never use it as a reference or for something important without confirming it by some real, named, published and reviewed document.

The best summation of the structural issues of Wikipedia come from the Sheldon cartoon by Dave Kellett (with the authors permission, http://www.sheldoncomics.com/archive/071213.html):

(... and outside academia, God help you if your boss has found you have bet the company or a product on data gathered from Wikipedia that you haven't confirmed via other research.)

Real life works on named sources that are reliable, not ephemera.

IBM PowerPC™ 405-S: Synthesis of the RTL with the supplied Artisan Cell Library

2009-12-04T14:44:00.002Z

[Please note that these instructions reference the 1.00a version of the Synopsys PowerPC™ 405-S coreKit which is the version provided in the University IP package from IBM. There are updated versions available from Synopsys that address several of the issues outlined below. These are specifically commented on where known.]

This is the third article in this series (click here for the series index) describing the IBM PowerPC™ 405 synthesizable core and peripherals and will cover taking the IP through RTL synthesis and scan chain insertion with the modern versions of the Synopsys tools using the supplied Artisan Library. Integrating a custom library will be addressed in a future article.

This article assumes you have used the previous articles to unpack and install the software to create a functioning simulation environment.

Getting Started: Understanding the Problem

The relevant part of the instruction manual (docs/405_ivug.pdf) is:

Chapter 6: RTL-to-Gates Synthesis

In this chapter we are going to assume that the default Core clock of 250MHz and PLB clock of 125MHz are acceptable, along with the 130nm Artisan library designed for TSMC processes.

Synthesis Scripts
Entering the dc subdirectory of the workspace shows the files in place however a little more digging and we can see that the dc/scripts directory is missing. Using an identical technique to the previous article we can create and populate it.
[Note, in a similar vein to the last article all of the changes will be summarised in a script and instructions at the end]

cd dc

mkdir scripts

cd scripts

ln -s ../../../DW_ppc405-FS_iv_1.0a_AV/dc/scripts/* ./

The script system automates the flow from RTL, Constraints and Cell Library to a gate level netlist:

run_compile.csh - as the "master" script it sets environment variables and then executes the desired tool, sourcing the setup.tcl script and the appropriate stage script where the stages are "elaboration", "synthesis" and "design for test"
scripts/p405s_elab.tcl - reads the environment variables set and executes Design Compiler to elaborate the design and save it in a .db file
scripts/p405s_compile.tcl - reads the environment variables set and executes Design Compiler on the elaborated design to synthesize the design and save the resulting netlist, reports and other useful outputs
scripts/p405s_dft.tcl - reads the environment variables set and executes Design Compiler on the synthesized design to stitch the scan chains together and enable design for test strategies

Constraints
This scripting system relies on reading design constraints held in another directory:

dc/constraints

A design without appropriate constraints is basically useless as RTL is insufficient to create a functional circuit. The constraints for this processor are complex due to the presence of 3 clock domains (core, peripheral bus and JTAG) and two test modes. The constraint files contain the following information:

PPC405F5V1_capture.cons - This is responsible for creating environment variables containing data on the various clock speeds and parameters. It also identifies the clock ports in the design. It also specifies some of the different clock domains.
PPC405F5V1_clock.cons - This file uses the variables calculated in the constraint file PPC405F5V1_capture.cons to apply constraints to the clocks in the design.
PPC405F5V1_compile_directives.cons - Instructs Design Compiler to fix multiple port nets, optimise a group of paths at a time for slack as opposed to one path at a time. It also enables a check on clock gating.
PPC405F5V1_drc.cons - This file constrains the fanouts of the nets and sets attributes on some of the clock control logic so it will pass DRC.
PPC405F5V1_functional.cons - Creates false paths and multicycle paths through the RAM BIST and Debug sections of the design to allow efficient synthesis.
PPC405F5V1_group_paths.cons – Only two constraints are added here grouping all the inputs and all the outputs together for efficient synthesis.
PPC405F5V1_in_out.cons – This applies driving gates to all inputs and loads to all outputs, again to improve the synthesis and increase the accuracy of the reporting Design Compiler is able to achieve. Importantly the characteristics of the clocks are further constrained in this file. Finally more false paths are assigned to the BIST structures, JTAG and test ports.
PPC405F5V1_shift.cons – This sets the period on the various clock lines of the design when the design is in one of its test modes.
PPC405F5V1_test.cons - This contains the complex constraints which drive Test Compiler when it inserts scan chains and test modes automatically. It includes defining the scan in/out ports and the state of the various pins in test mode. This presents a particular issue which will be addressed later as the syntax and capabilities of Deign Compiler have changed very significantly.

Getting Started: Planning the Solution

The first priority for us is that Design Compiler no longer supports saving the design in .db form so we need to repurpose the scripts to store the design in a more modern database. Design Compiler has also changed clock gating and operand isolation commands and compilation to accomodate modern 90nm and below CMOS. Considering that a major rebuild is necessary I am going to show you how to synthesis the design preparing for the use of Milkyway Databases and the Design Compiler Topographical feature. This will enable the porting of this design to 90nm CMOS and below in the future.

In the current system each tool is setup to use files from the Artisan library in the synthesis flow by a single Tcl script which detects what tool is running the script and then configures variables appropriately. This script is called at the start of each specific tool script. There is a lot of useful help in the current scripts as the series of improvements to Design Compiler rely on physical information from the cell library to improve its decisions. The major improvement for sub 90nm CMOS is done by the logic synthesis tool performing a quick preliminary cell placement so it can better model delay, capacitance and power costs of the design during synthesis (topographical mode).

In the following sections the updates required to each individual script are discussed.

Primary Stage Scripts

The main changes to all scripts was a change to save and load the design using the more modern .ddc database format.
[A normal Synopsys flow would store the design in the Milkyway database alongside physical data from the Cell Library but this version of the IP was not designed for this.]

Control Script: run_compile.csh

The master control script parses flags given to it on the command line and then executes Design Compiler in the tcl shell mode running the appropriate stage script. The only change to this script is:

Added a flag -topo to run Design Compiler in topological mode which will enable the use of Milkyway databases in Design Compiler.

[That being said if you are going to use the -ultra flag or the -topo flag you might want to edit the line dc_shell-t -topo -f ./scripts/p405s_compile.tcl | tee logs/p405s_compile.log to include the correct -num_cpus X where X matches the number of processors and licenses you have for faster compiles. This isn't trivial to add as an option to the .csh script without introducing a dependency on the getopts binary so I have left it undone.]

Setup: scripts/setup.tcl

The setup script is run at the start of each and every stage. It pulls in the libraries and sets up a few global variables.

The main changes needed to bring this script into line with modern tools is to include information that would normally be used by Physical Compiler in Design Compiler to support its Topological mode when the -topo mode is specified. This is necessary to manage the shift of importance away from gates (in 130nm and above) to wire lengths (in 90nm and below) which begin to dominate the performance of a design. The physical information is used to perform a rough placement allowing wireloads to be estimated much more accurately. It also has allowed the introduction of novel features such as congestion aware routing which will attempt to address routing issues at a netlist level.

This information is already in there as it was used by the static timing analyses and power estimation tools, but it needs to be enabled when the new topological flag is asserted.

Elaboration: scripts/p405s_elab.tcl

Elaboration consists of reading in HDL files and constructing a representation of the design using components from the cell libraries, i.e. parsing the source code into a generic technology (GTECH) gate-level netlist which is then saved.

The main improvements to the p405_elab.tcl scripts are:

Removal of obsolete commands
Conversion of the HDL commands from acs type to analyze types
Rewriting of the scan chain insertion script section to remove obsolete commands set_scan_signal with set_dft_signal and moving them into the p405s_compile.tcl script

Compilation: scripts/p405s_compile.tcl

This stage reads in the gate netlist created in the previous elaboration phase and maps it to the specific gates from the chosen cell library, applies constraints and synthesizes an actual working gate level netlist using the target technology.

Replacement of the -ultra flag with the compile_ultra command
Force the use of the compile_ultra command when in topographical mode
Modification of the compile command to insert the scan flops
Removal of nested if's by building a compile string which is evaluated

Design for Test: scripts/p405s_dft.tcl

In this phase the scan chains are built from the scan flops inserted into the design in the previous script. The design is then incrementally recompiled to minimize the scan logic and the appropriate reports and the test strategies are generated. Note that while few changes were needed to this script the scan constraints and options were completely replaced.

The script now preserves the use of the -high flag from synthesis to increase the effort of the incremental recompile

Constraints

There were only two constraint files that needed updating but one needed a complete rebuild to support the new syntax of Test Compiler.

constraints/PPC405F5V1_functional.cons

This file requires a slight modification to cope with a change in Design Compiler's internal bus naming style from signal[0] to signal<0>.

constraints/PPC405F5V1_test.cons

This file required a complete rebuild to manage the syntax changes in the new version of Test Compiler. The major changes are:

Replacement of create_test_clock, set_scan_signal, set_signal_type and set_test_hold with appropriate set_dft_signal
declarations
Replacement of set_dft_optimization_configuration with set_dft_insertion_configuration
Reworking of set_scan_configuration flags

Synthesis: Solved

There is one script to link the needed files and one unified patch file which will update all the relevant tool scripts and constraint files to work correctly.

1) Open your favorite text editor and paste in the following script:

#!/bin/bash
#
# fix_dc_dir.sh
#
#Copyright Matthew Swabey (matthew@swabey.org).
#
#You are licensed to use this file in conjunction with the IBM PowerPC 405 coreKit and to make modifications as needed to this script as long as this copyright notice is kept.

#This script should be executed from the the new workspace after you have installed it with coreConsultant.

UNPACKED_COREKIT_DIR=/export/fastcad/disktmp/mas/IBM_PUB3/DW_ppc405-FS_iv_1.0a_AV

#Link the script files needed to synthesise the PPC405 into the workspace from the installed coreKit
cd dc
mkdir scripts
cd scripts
ln -s $UNPACKED_COREKIT_DIR/dc/scripts/* ./
cd ..

cd ..

#Apply the unified patch to update the build scripts and constraint scripts
patch -u -p0 < `dirname $0`/fix_dc.diff

2) Edit the top variable, UNPACKED_COREKIT_DIR to have the absolute path to the unpacked coreKit directory. There should be no spaces in the paths.

3) Save this file with a suitable name (e.g. fix_dc_dir.sh) in the new workspace you have created. Make the script executable using the command chmod u+x "filename".

4) Open a new blank file and paste in the following unified diff:

diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/constraints/PPC405F5V1_functional.cons ./dc/constraints/PPC405F5V1_functional.cons
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/constraints/PPC405F5V1_functional.cons 2005-10-17 16:31:05.000000000 +0100
+++ ./dc/constraints/PPC405F5V1_functional.cons 2009-11-09 18:18:07.608824678 +0000
@@ -3,6 +3,9 @@
 #
 #  Copyright (c) International Business Machines Corporation, 2005.
 #
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
+#
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
 #  protected by copyright and other intellectual property rights and shall
@@ -49,9 +52,9 @@
 #core|cpu_topSch|exe_topSch|loadSteeringSch|ocmData_NEG[*]  I _ _ * GPRWT+R
 #core|cpu_topSch|exe_topSch|gprLpIn[*]  I DC DC GPRWT+R _
 set DCU_DATA_NEG_PINS  [remove_from_collection [get_pins core/cacheMMUSch/DCU_data_NEG*] \
-                                               [get_pins "core/cacheMMUSch/DCU_data_NEG[16] \
-                                                          core/cacheMMUSch/DCU_data_NEG[17] \
-                                                          core/cacheMMUSch/DCU_data_NEG[18]"]]
+                                               [get_pins "core/cacheMMUSch/DCU_data_NEG<16> \
+                                                          core/cacheMMUSch/DCU_data_NEG<17> \
+                                                          core/cacheMMUSch/DCU_data_NEG<18>"]]
 set OCMDATA_NEG_PINS [get_pins core/cpu_topSch/exe_topSch/loadSteeringSch/OCM_dsData*]

 set_false_path -through $DCU_DATA_NEG_PINS -through [get_pins core/cpu_topSch/exe_topSch/loadSteeringSch/gprLpIn*]
@@ -83,11 +86,11 @@
 # Input of the mux(s) are DCU_data_NEG*
 #
 for {set x 0} {$x<32} {incr x} {
-  set_false_path -through core/cpu_topSch/exe_topSch/loadSteeringSch/DCU_data_NEG[$x] \
+  set_false_path -through core/cpu_topSch/exe_topSch/loadSteeringSch/DCU_data_NEG<$x> \
                         -through [get_pins core/cpu_topSch/exe_topSch/loadSteeringSch/dRegBypass*]
 }
 for {set x 0} {$x<32} {incr x} {
-  set_false_path -through core/cpu_topSch/exe_topSch/loadSteeringSch/DCU_data_NEG[$x] \
+  set_false_path -through core/cpu_topSch/exe_topSch/loadSteeringSch/DCU_data_NEG<$x> \
                        -through [get_pins core/cpu_topSch/exe_topSch/loadSteeringSch/gprLpIn*]
 }

diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/constraints/PPC405F5V1_test.cons ./dc/constraints/PPC405F5V1_test.cons
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/constraints/PPC405F5V1_test.cons       2005-10-17 16:31:05.000000000 +0100
+++ ./dc/constraints/PPC405F5V1_test.cons       2009-11-10 23:17:36.560210767 +0000
@@ -3,6 +3,9 @@
 #
 #  Copyright (c) International Business Machines Corporation, 2005.
 #
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
+#
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
 #  protected by copyright and other intellectual property rights and shall
@@ -17,13 +20,17 @@
 #
 # This file sets up the scan constraints
 #
+
 #============================================================================
 # Create Test Clocks
 #============================================================================
-create_test_clock CPMC405CLOCK        -waveform {60.0 70.0} -period 100.0
-create_test_clock CPMC405PLBSYNCCLOCK -waveform {60.0 70.0} -period 100.0
-create_test_clock JTGC405TCK          -waveform {60.0 70.0} -period 100.0
-create_test_clock TESTC405BISTCE0STCLK -waveform {60.0 70.0} -period 100.0
+
+set_dft_signal -view existing_dft -type ScanClock -port CPMC405CLOCK -timing [list 60.0 70.0]
+set_dft_signal -view existing_dft -type ScanClock -port CPMC405PLBSYNCCLOCK -timing [list 60.0 70.0]
+set_dft_signal -view existing_dft -type ScanClock -port JTGC405TCK -timing [list 60.0 70.0]
+set_dft_signal -view existing_dft -type ScanClock -port TESTC405BISTCE0STCLK -timing [list 60.0 70.0]
+
+#set_dft_equivalent_signals [list CPMC405CLOCK CPMC405PLBSYNCCLOCK JTGC405TCK TESTC405BISTCE0STCLK]

 #============================================================================
 #    Define scan ports
@@ -33,20 +40,14 @@
 set test_scan_in_port_naming_style "scan_in%s"
 set test_scan_out_port_naming_style "scan_out%s"

-## DFT DRC currently (2003.12) has a problem infering resets, so do it explicitly
-#if {[get_ports -quiet test_async_rst_n] == ""} {create_port test_async_rst_n}
-#set_signal_type test_async_inverted test_async_rst_n
+set_dft_signal -view existing_dft -type TestMode -port [get_port TESTC405TESTMODE] -active_state 1
+set_dft_signal -view existing_dft -type ScanEnable -port [get_port TESTC405SCANENABLE] -active_state 1
+set_dft_signal -view spec -type ScanEnable -port [get_port TESTC405SCANENABLE] -active_state 1

-set_dft_signal  test_mode        -port TESTC405TESTMODE
-set_scan_signal test_scan_enable -port TESTC405SCANENABLE
 for {set x 0} {$x<8} {incr x} {
-       set_scan_signal test_scan_in     -port TESTC405SCANIN${x}
-       set_scan_signal test_scan_out    -port C405TESTSCANOUT${x}
+       set_dft_signal -view spec -type ScanDataIn -port [get_port TESTC405SCANIN${x}]
+       set_dft_signal -view spec -type ScanDataOut -port [get_port C405TESTSCANOUT${x}]
 }
-#for {set x 0} {$x<32} {incr x} {
-#      set_scan_signal test_scan_in     -port TESTC405SCANIN${x} -chain scan${x}
-#      set_scan_signal test_scan_out    -port C405SCANOUT${x} -chain scan${x}
-#}

 #============================================================================
 #    Set up test protocol
@@ -68,16 +69,16 @@
 set_scan_element false [get_cell core/cacheMMUSch/icu_topSch/icuRamDataFlow/tagArray_Sch/icu_tag/tagSram]

 # Assert these input ports to specified values during test mode
-set_signal_type "test_asynch" RSTC405RESETCORE
-set_test_hold 1 TESTC405BISTCE1MODE
-set_test_hold 1 TESTC405BISTCE1ENABLE
-set_test_hold 1 TIEC405CLOCKENABLE
-set_test_hold 1 TIEC405DUTYENABLE
-set_test_hold 1 TESTC405TESTMODE
-set_test_hold 1 JTGC405TRSTNEG
-set_test_hold 1 CPMC405CPUCLKENCCLK
-set_test_hold 1 CPMC405TIMERCLKENCCLK
-set_test_hold 1 CPMC405JTAGCLKENCCLK
+set_dft_signal -view existing_dft -type Reset -port -active_state 1 [get_port RSTC405RESETCORE]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port TESTC405BISTCE1MODE]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port TESTC405BISTCE1ENABLE]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port TIEC405CLOCKENABLE]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port TIEC405DUTYENABLE]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port TESTC405TESTMODE]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port JTGC405TRSTNEG]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port CPMC405CPUCLKENCCLK]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port CPMC405TIMERCLKENCCLK]
+set_dft_signal -view existing_dft -type Constant -active_state 1 -port [get_port CPMC405JTAGCLKENCCLK]

 ## Set the default test parameters
 set test_default_period        100
@@ -88,19 +89,21 @@

 set test_stil_netlist_format verilog

-set_dft_optimization_configuration -preserve_design_name true
+set_dft_insertion_configuration -preserve_design_name true
 set_scan_configuration -style multiplexed_flip_flop
-set_scan_configuration -methodology full_scan
-set_scan_configuration -dedicated_scan_ports true
+set_scan_configuration -create_dedicated_scan_out_ports true
 set_scan_configuration -add_lockup true
 set_scan_configuration -clock_mixing mix_clocks
-set_scan_configuration -rebalance false
-set_scan_configuration -internal_clocks false
+set_scan_configuration -internal_clocks none
 set_scan_configuration -hierarchical_isolation false
 set_scan_configuration -create_test_clocks_by_system_clock_domain false
-set_scan_configuration -disable true
-set_scan_configuration -bidi input
-set_scan_configuration -insert_end_of_chain_lockup_latch true
+#set_scan_configuration -disable true
+set_dft_configuration -fix_bidirectional enable
+set_dft_configuration -fix_clock enable
+set_dft_configuration -fix_reset enable
+set_dft_configuration -fix_bus enable
+#set_scan_configuration -insert_end_of_chain_lockup_latch true
+set_scan_configuration -insert_terminal_lockup true

 ## Need to specify the number of chains.
 set_scan_configuration -chain_count 8
@@ -108,5 +111,5 @@

 # set the latches in the design to transperent mode
 # Make sure that your latch variable is set in the setup.tcl file
-set_scan_transparent true ${LIBRARY_NAME}/$LATCH_NAMES -existing
+#set_scan_transparent true ${LIBRARY_NAME}/$LATCH_NAMES -existing

diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/run_compile.csh ./dc/run_compile.csh
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/run_compile.csh        2005-10-17 16:31:05.000000000 +0100
+++ ./dc/run_compile.csh        2009-11-09 18:08:54.904611366 +0000
@@ -3,6 +3,9 @@
 # **************************************************************************
 #
 #  Copyright (c) International Business Machines Corporation, 2004.
+#
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
 #
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
@@ -43,6 +46,7 @@
 setenv scan_switch true
 setenv bist_switch false
 setenv ultra_switch false
+setenv topo_switch false
 setenv high_switch false
 setenv Test_lic true
 setenv Power_lic true
@@ -55,6 +59,7 @@
    echo "  -synth       : synthesize; will elaborate if elab switch is on or no elab db exists"
    echo "  -dft         : Stitches scan chain; valid only if a synthesis is completed first"
    echo "  -ultra       : use Ultra options that require an Ultra-Opt license"
+   echo "  -topo        : use Topographical synthesis"
    echo "  -high        : high effort compile"
    echo "  -bist        : Add Memory BIST to the design"
    echo "  -no_scan     : Do not use -scan with the compile options that require a Test-Compiler license"
@@ -100,6 +105,9 @@
        case x-ultra:
            setenv ultra_switch true
            breaksw
+       case x-topo:
+           setenv topo_switch true
+           breaksw
        case x-high:
            setenv high_switch true
            breaksw
@@ -115,6 +123,7 @@
            echo "  -bist               : Add Memory BIST to the design"
            echo "  -no_scan            : Do not use -scan with the compile options that require a Test-Compiler license"
            echo "  -ultra              : use Ultra options that require an Ultra-Opt license"
+           echo "  -topo               : use Topographical synthesis"
            echo "  -no_scan            : Do not use -scan with the compile options that require an Test-Compiler license"
            echo "  -no_power           : Do not use Power Compiler to add clock gating to the design"
            echo "  -clean_all          : Deletes all reports and dbs in the pass directories"
@@ -125,6 +134,7 @@
            echo "  -synth              : synthesize; will elaborate if elab switch is on or no elab db exists"
            echo "  -dft                : Stitches scan chain; valid only if a synthesis completed first"
            echo "  -ultra              : use Ultra options that require an Ultra-Opt license"
+           echo "  -topo               : use Topographical synthesis"
            echo "  -bist               : Add Memory BIST to the design"
            echo "  -no_scan            : Do not use -scan with the compile options that require an Test-Compiler license"
            echo "  -no_power           : Do not use Power Compiler to add clock gating to the design"
@@ -167,7 +177,11 @@
      echo "Elaborating Design"
      echo "##########################################################"
      echo ""
+  if ($topo_switch == true) then
+     dc_shell-t -topo -f ./scripts/p405s_elab.tcl | tee logs/p405s_elab.log
+  else
      dc_shell-t -f ./scripts/p405s_elab.tcl | tee logs/p405s_elab.log
+  endif
      echo ""
      echo "##########################################################"
      echo "Finished Elaboration"
@@ -182,7 +196,11 @@
      echo "Synthesizing Design"
      echo "##########################################################"
      echo ""
+  if ($topo_switch == true) then
+     dc_shell-t -topo -f ./scripts/p405s_compile.tcl | tee logs/p405s_compile.log
+  else
      dc_shell-t -f ./scripts/p405s_compile.tcl | tee logs/p405s_compile.log
+  endif
      echo ""
      echo "##########################################################"
      echo "Finished Synthesis"
@@ -197,7 +215,11 @@
      echo "Stitching scan chains"
      echo "##########################################################"
      echo ""
+  if ($topo_switch == true) then
+     dc_shell-t -topo -f ./scripts/p405s_dft.tcl | tee logs/p405s_dft.log
+  else
      dc_shell-t -f ./scripts/p405s_dft.tcl | tee logs/p405s_dft.log
+  endif
      echo ""
      echo "##########################################################"
      echo "Finished Stitching scan chains"
@@ -214,6 +236,7 @@
 unsetenv scan_switch
 unsetenv bist_switch
 unsetenv ultra_switch
+unsetenv topo_switch
 unsetenv high_switch
 unsetenv Test_lic
 unsetenv Power_lic
diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_compile.tcl ./dc/scripts/p405s_compile.tcl
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_compile.tcl      2005-10-17 16:31:05.000000000 +0100
+++ ./dc/scripts/p405s_compile.tcl      2009-11-20 20:04:16.248225918 +0000
@@ -3,6 +3,9 @@
 #
 #  Copyright (c) International Business Machines Corporation, 2005.
 #
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
+#
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
 #  protected by copyright and other intellectual property rights and shall
@@ -22,6 +25,7 @@
 set scan_switch  [getenv scan_switch]
 set high_switch  [getenv high_switch]
 set ultra_switch [getenv ultra_switch]
+set topo_switch  [getenv topo_switch]

 set SCRIPT compile

@@ -49,9 +53,9 @@
 # Read in elaborated design
 #
 #=================================================================================
-       set INPUT_DB "./db/${TOPDESIGN}_elab.db"
+       set INPUT_DB "./db/${TOPDESIGN}_elab.ddc"
         if { [file readable $INPUT_DB ] == 1} {
-          read_db $INPUT_DB
+          read_ddc $INPUT_DB
         } else {
           puts "FAILURE: Failed to find $INPUT_DB"
           exit 0
@@ -94,6 +98,7 @@
 # At this point we no longer need to suppress the non-unate clock warning
 # and we want to know if it happens after the compile.
 set suppress_errors {CMD-041 TIM-134}
+
 #=================================================================================
 #
 # Uniquify
@@ -101,7 +106,7 @@
 #=================================================================================
         uniquify
        link
-       write_file -format db -hier -o ./db/${FILENAME_PREFIX}_pre_compile.db
+       write_file -format ddc -hier -o ./db/${FILENAME_PREFIX}_pre_compile.ddc

 #=================================================================================
 #
@@ -129,28 +134,29 @@
 # Compile
 #
 #=================================================================================
-       if {$ultra_switch == "true"} {
-               set_ultra_optimization true -force
+       set COMPILE_STRING ""
+        if {($Power_lic == "true")} {
+          append $COMPILE_STRING " -gate_clock"
+       }
+       if {$scan_switch == "true"} {
+          append $COMPILE_STRING " -scan"
        }

-       if {$high_switch == "true"} {
-               if {$scan_switch == "true"} {
-                       echo "** compile -scan -map_effort high **"
-                       compile -scan -map_effort high -boundary_optimization
-               } else {
-                       echo "** compile -map_effort high **"
-                       compile -map_effort high -boundary_optimization
-               }
+       if {$ultra_switch == "true" | $topo_switch == "true"} {
+          set COMPILE_STRING "compile_ultra ${COMPILE_STRING} "
+          echo "** " ${COMPILE_STRING} " **"
+          eval ${COMPILE_STRING}
        } else {
-               if {$scan_switch == "true"} {
-                       echo "** compile -scan **"
-                       compile -scan -effort medium -boundary_optimization
-               } else {
-                       echo "** compile  **"
-                       compile -effort medium -boundary_optimization
-               }
+          if {$high_switch == "true"} {
+            set COMPILE_STRING "compile ${COMPILE_STRING} -map_effort high -boundary_optimization"
+            echo "** " ${COMPILE_STRING} " **"
+            eval ${COMPILE_STRING}
+          } else {
+            set COMPILE_STRING "compile ${COMPILE_STRING} -map_effort medium -boundary_optimization"
+            echo "** " ${COMPILE_STRING} " **"
+            eval ${COMPILE_STRING}
+          }
        }
-
         current_design ${TOPDESIGN}
         link

@@ -163,9 +169,8 @@
                source ./scripts/verilog_name_rules.tcl
                verilog_name_rules
                change_names -rule verilog_name_rule -hierarchy -verbose
-               change_names -rule verilog_name_rule -hierarchy -verbose
        }
-       write_file -format db -hier -o ./db/${FILENAME_PREFIX}.db
+       write_file -format ddc -hier -o ./db/${FILENAME_PREFIX}.ddc
        write -f verilog -hier -o ./netlist/${FILENAME_PREFIX}.v

 #=================================================================================
diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_dft.tcl ./dc/scripts/p405s_dft.tcl
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_dft.tcl  2005-10-17 16:31:05.000000000 +0100
+++ ./dc/scripts/p405s_dft.tcl  2009-11-20 20:58:02.696428891 +0000
@@ -3,6 +3,9 @@
 #
 #  Copyright (c) International Business Machines Corporation, 2005.
 #
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
+#
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
 #  protected by copyright and other intellectual property rights and shall
@@ -17,6 +20,7 @@
 #=================================================================================
 # This script inserts scan
 #=================================================================================
+set high_switch  [getenv high_switch]

 #=================================================================================
 #
@@ -43,9 +47,9 @@
 # Read in elaborated design
 #
 #=================================================================================
-       set INPUT_DB ./db/${TOPDESIGN}_compile.db
+       set INPUT_DB ./db/${TOPDESIGN}_compile.ddc
         if { [file readable $INPUT_DB ] == 1} {
-          read_db $INPUT_DB
+          read_ddc $INPUT_DB
         } else {
           puts "Error: Failed to find $INPUT_DB"
           exit 0
@@ -53,7 +57,7 @@

         current_design ${TOPDESIGN}
         link
-        echo "INFO: Elaborated DB file for ${TOPDESIGN} linked at [exec date]"
+        echo "INFO: Elaborated DDC file for ${TOPDESIGN} linked at [exec date]"

         # Check the design
         echo "INFO: link and check_design output for module ${TOPDESIGN}\n" > \
@@ -82,6 +86,10 @@
 # Insert DFT
 #=================================================================================

+if {$high_switch == "true"} {
+    set_dft_insertion_configuration -map_effort high
+}
+
 insert_dft
 # check_dft  -verbose  > ./reports/${FILENAME_PREFIX}.check_dft.post.rpt
 dft_drc -verbose > ./reports/${FILENAME_PREFIX}.dft_drc.post.rpt
@@ -97,7 +105,7 @@
                change_names -rule verilog_name_rule -hierarchy -verbose
                change_names -rule verilog_name_rule -hierarchy -verbose
        }
-       write_file -format db -hier -o ./db/${FILENAME_PREFIX}.db
+       write_file -format ddc -hier -o ./db/${FILENAME_PREFIX}.ddc
        write -f verilog -hier -o ./netlist/${FILENAME_PREFIX}.v

 #=================================================================================
@@ -126,5 +134,6 @@

 date

+
 exit

diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_elab.tcl ./dc/scripts/p405s_elab.tcl
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_elab.tcl 2005-10-17 16:31:05.000000000 +0100
+++ ./dc/scripts/p405s_elab.tcl 2009-11-09 18:17:58.598880874 +0000
@@ -3,6 +3,9 @@
 #
 #  Copyright (c) International Business Machines Corporation, 2005.
 #
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
+#
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
 #  protected by copyright and other intellectual property rights and shall
@@ -21,9 +24,7 @@
 set bist_switch  [getenv bist_switch]

 set template_naming_style "%s_%p"
-set hdlin_enable_vpp TRUE
-set hdlin_preserve_vpp_files true
-set compile_delete_unloaded_sequential_cells false
+#set compile_delete_unloaded_sequential_cells false

 sh rm -rf ./ppc405
 define_design_lib ppc405 -path ./ppc405
@@ -48,16 +49,26 @@
 set TOPDESIGN $design_name
 set FILENAME_PREFIX ${TOPDESIGN}_${SCRIPT}

+
 #=================================================================================
 #
 # Read in design files
 #
 #=================================================================================
 # read all files in ppc_405s_cpu directory except the following behavioral models
-set acs_exclude_list [concat $acs_exclude_list "PPC405F5V1_soft.v SRAM_256wordsX44bits.v"]
+set RTL_SRC_PATH ../src/rtl/
+set RTL_SRC_LIST [list]
+foreach FILE [glob -nocomplain -type f -directory $RTL_SRC_PATH -tails *.v] {
+  lappend RTL_SRC_LIST $FILE
+}
+
+set RTL_SRC_LIST [ lsearch -all -inline -not -exact $RTL_SRC_LIST PPC405F5V1_soft.v ]
+set RTL_SRC_LIST [ lsearch -all -inline -not -exact $RTL_SRC_LIST SRAM_256wordsX44bits.v ]

 # if bist enabled
 if {($bist_switch == "true")} {
+       echo "NOT UPDATED YET"
+       exit
        echo "** BIST ENABLED **"
        set acs_exclude_list [concat $acs_exclude_list "p405s_DCU_parityRAM.v"]
        set acs_exclude_list [concat $acs_exclude_list "p405s_DCU_ram16K.v"]
@@ -79,9 +90,10 @@
 # if the User Specific RAMs option is set in the Configure Activity
 set memory_wrappers " "
 set memory_wrappers [concat ../src/mem_models/p405s_dataram_64X34_wrapper.v  ../src/mem_models/p405s_sram256x46_wrapper.v ../src/mem_models/p405s_sram256x48_wrapper.v ../src/mem_models/p405s_sram512x128_wrapper.v ../src/mem_models/p405s_sram512x32_wrapper.v ../src/mem_models/p405s_sram512x8_wrapper.v ../src/mem_models/p405s_sramBytWr512x128_wrapper.v]
-set acs_hdl_source [concat $memory_wrappers ../src/rtl/p405s_params.v $acs_hdl_source "../src/rtl"]
+set RTL_SRC_LIST [concat $memory_wrappers ../src/rtl/p405s_params.v $RTL_SRC_LIST]

-acs_read_hdl -recurse -format verilog -library ppc405 -verbose $TOPDESIGN -no_elaborate
+lappend search_path ../src/rtl
+analyze -library ppc405 -format verilog $RTL_SRC_LIST

 #=================================================================================
 #
@@ -133,28 +145,14 @@
 # Elaborate the design
 #
 #=================================================================================
-if {($Power_lic == "true")} {
-  elaborate -library ppc405 -gate_clock $TOPDESIGN
-} else {
-  elaborate -library ppc405 $TOPDESIGN
-}

-#=================================================================================
-#
-# Connect the scan enable port to control the gated clock cells
-#
-#=================================================================================
-if {($Power_lic == "true")} {
-   set_scan_signal test_scan_enable -port [get_port TESTC405SCANENABLE]
-   set_dft_signal test_mode         -port [get_port TESTC405TESTMODE]
-   hookup_testports -verbose
-}
+elaborate -library ppc405 $TOPDESIGN

 #=================================================================================
 #
 # Write out elaborated design
 #
 #=================================================================================
-write -f db -hier -o $acs_work_dir/db/${FILENAME_PREFIX}.db
+write -f ddc -hier -o ./db/${FILENAME_PREFIX}.ddc

 exit
diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_zerowlm.tcl ./dc/scripts/p405s_zerowlm.tcl
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/p405s_zerowlm.tcl      2005-10-17 16:31:05.000000000 +0100
+++ ./dc/scripts/p405s_zerowlm.tcl      2009-11-20 20:04:35.505970139 +0000
@@ -45,9 +45,9 @@
 # Read in elaborated design
 #
 #=================================================================================
-       set INPUT_DB "./db/${TOPDESIGN}_elab.db"
+       set INPUT_DB "./db/${TOPDESIGN}_elab.ddc"
         if { [file readable $INPUT_DB ] == 1} {
-          read_db $INPUT_DB
+          read_ddc $INPUT_DB
         } else {
           puts "FAILURE: Failed to find $INPUT_DB"
           exit 0
@@ -55,7 +55,7 @@

         current_design ${TOPDESIGN}
         link
-        echo "INFO: Elaborated DB file for ${TOPDESIGN} linked at [exec date]"
+        echo "INFO: Elaborated DDC file for ${TOPDESIGN} linked at [exec date]"

         # Check the design
         echo "INFO: link and check_design output for module ${TOPDESIGN}\n" > \
@@ -104,7 +104,7 @@
 #=================================================================================
         uniquify
        link
-       write_file -format db -hier -o ./db/${FILENAME_PREFIX}_pre_compile.db
+       write_file -format ddc -hier -o ./db/${FILENAME_PREFIX}_pre_compile.ddc

 #=================================================================================
 #
@@ -159,7 +159,7 @@
                change_names -rule verilog_name_rule -hierarchy -verbose
        }
        write -f verilog -hier -o ./netlist/${FILENAME_PREFIX}.v
-       write_file -format db -hier -o ./db/${FILENAME_PREFIX}.db
+       write_file -format ddc -hier -o ./db/${FILENAME_PREFIX}.ddc

 #=================================================================================
 #
diff -ru ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/setup.tcl ./dc/scripts/setup.tcl
--- ../../IBM/DW_ppc405-FS_iv_1.0a_AV/dc/scripts/setup.tcl      2005-10-17 16:31:05.000000000 +0100
+++ ./dc/scripts/setup.tcl      2009-11-09 18:17:58.609879585 +0000
@@ -3,6 +3,9 @@
 #
 #  Copyright (c) International Business Machines Corporation, 2005.
 #
+#  Modified by Dr Matthew Swabey matthew@swabey.org to support the modern
+#  synopsys design tools and techniques.
+#
 #  This file contains trade secrets and other proprietary and confidential
 #  information of International Business Machines Corporation which are
 #  protected by copyright and other intellectual property rights and shall
@@ -10,7 +13,7 @@
 #  or used for any purpose except as specifically authorized in writing by
 #  International Business Machines Corporation. This notice must be
 #  contained as part of this text at all times.
-#
+#
 # **************************************************************************
 #
 #===========================================================================
@@ -128,30 +131,46 @@
 #  create the MilkyWay database.
 #----------------------------------------------------------------------------
 set lib_path ../tech_lib
-#set MW_REF_LIB [list ${lib_path}/artisan_13lvfsg/astro/artisan_13lvfsg_mdb \
-#                     ${lib_path}/artisan_13lvfsg/syn/dataram_64X34 \
-#                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram256x46 \
-#                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram256x48 \
-#                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram512x128 \
-#                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram512x32 \
-#                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram512x8 \
-#                     ${lib_path}/memories/artisan_13lvfsg/mdb/sramBytWr512x128 ]
+set MW_REF_LIB [list ${lib_path}/artisan_13lvfsg/astro/artisan_13lvfsg_mdb \
+                     ${lib_path}/artisan_13lvfsg/syn/dataram_64X34 \
+                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram256x46 \
+                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram256x48 \
+                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram512x128 \
+                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram512x32 \
+                     ${lib_path}/memories/artisan_13lvfsg/mdb/sram512x8 \
+                     ${lib_path}/memories/artisan_13lvfsg/mdb/sramBytWr512x128 ]
 set MW_TECH_FILE ${lib_path}/artisan_13lvfsg/apollo/tf/tsmc13fsg_hs_6lm.tf
-set MAX_TLUPLUS ${lib_path}/star-rc/t013s6ml_lowklv.tluplus
-set NOM_TLUPLUS ${lib_path}/star-rc/t013s6ml_lowklv.tluplus
-set MIN_TLUPLUS ${lib_path}/star-rc/t013s6ml_lowklv.tluplus
-set MAP_FILE    ${lib_path}/star-rc/plib2itf.map
-#
+
+set MW_DESIGN_LIBRARY ./mw.db
+
+echo $MW_REF_LIB
+
+if {$synopsys_program_name == "dc_shell"}  {
+  if {[shell_is_in_topographical_mode]} {
+    if {[expr {![file isdirectory $MW_DESIGN_LIBRARY ]}]} {
+      echo "INFO: Milkyway libary not found. Creating a new one."
+      create_mw_lib -technology $MW_TECH_FILE -mw_reference_library $MW_REF_LIB $MW_DESIGN_LIBRARY
+    }
+    open_mw_lib $MW_DESIGN_LIBRARY
+    check_library
+  }
+}
+
 #----------------------------------------------------------------------------
 # Use TLUPlus for RC Computation
-# If you do not have TLUPlus, Comment out the following lines
+# If you do not have TLUPlus, Comment out the following
 #----------------------------------------------------------------------------
-# -tech2itf_map  $MAP_FILE
+set MAX_TLUPLUS ${lib_path}/star-rc/t013s6ml_lowklv.tluplus
+set NOM_TLUPLUS ${lib_path}/star-rc/t013s6ml_lowklv.tluplus
+set MIN_TLUPLUS ${lib_path}/star-rc/t013s6ml_lowklv.tluplus
+set MAP_FILE    ${lib_path}/star-rc/tf2itf.map
+
 if { [info exists synopsys_program_name] } {
-   if { [regexp {^psyn} $synopsys_program_name] } {
+   if { [regexp {^psyn} $synopsys_program_name] | [shell_is_in_topographical_mode] } {
        set_tlu_plus_files -max_tluplus $MAX_TLUPLUS \
                         -min_tluplus $MIN_TLUPLUS \
-                       -plib2itf_map $MAP_FILE
+                       -tech2itf_map $MAP_FILE
+       check_tlu_plus_files
    }
 }

5) Save this file as fix_dc.diff in the same directory as the script - they must be in the same directory for this to work.

6) Open a terminal and cd into the top of the workspace you have created. Execute the script and you should see the following output:

patching file ./dc/constraints/PPC405F5V1_functional.cons
patching file ./dc/constraints/PPC405F5V1_test.cons
patching file ./dc/run_compile.csh
patching file ./dc/scripts/p405s_compile.tcl
patching file ./dc/scripts/p405s_dft.tcl
patching file ./dc/scripts/p405s_elab.tcl
patching file ./dc/scripts/p405s_zerowlm.tcl
patching file ./dc/scripts/setup.tcl

7) cd into the dc directory of your workspace and run the following command: ./run_compile.csh -elab -synth -dft

8) Eventually you should have a lovely PowerPC™ 405 gate level netlist in ./dc/netlist ...

9) ...

10) Profit!

Published with permission from IBM and Synopsys

IBM PowerPC™ 405-S: Verification of the RTL with the supplied Artisan SRAMs

2009-11-06T17:52:00.012Z

[Please note that these instructions reference the 1.00a version of the Synopsys PowerPC™ 405-S coreKit which is the version provided in the University IP package from IBM. There are updated versions available from Synopsys that address several of the issues outlined below. These are specifically commented on where known.]

This is the second article in the series (click here for the series index) describing the IBM PowerPC™ 405 synthesizable core and peripherals and will cover what needs to be done to take the IP and get the RTL simulating with the modern versions of the necessary Synopsys Tools and a simulator of your choice.

Initial Unpacking
When you first unpack the DesignWare PowerPC405-S™ implementation view coreKit (the archive is called DW_ppc405-FS_iv_1.0a_AV.tar.gz) it expands to a directory DW_ppc405-FS_iv_1.0a_AV.

The first thing you should do is begin reading the excellently written User Guide (docs/405_ivug.pdf) which provides the suggested flows along with the Release Note (docs/iv_rn.pdf) that specifies the tools and environment with which you need to build the processor.

However the software versions requested by the release note to simulate the RTL is problematic. I have listed below the required software in black, the lowest version available in red and the highest version available at time of writing in blue:

Required:

Synopsys coreConsultant, Version V-2004.03-CT4.4.2 Z-2007.06-SP5 C-2009.06-3
Synopsys Vera System Verifier, Version 6.3.0 Z-2006.12 A-2007.12-12
Synopsys Design Compiler, Version U-2004.06-SP2 Z-2007.03-SP2 C-2009.06-SP2

One of:

Synopsys VCS, Version 7.1 Y-2006.06-SP1 C-2009.06-1
Mentor Graphics ModelSim, Version 5.7g 6.5c
Cadence NC-Verilog, Version 5.1 8.1

As you can see the specified tool versions are simply not available.
[Note: at the time of publication the current commercial coreKit is version 3, not the version 1.0a discussed here and supports the current generation of tools.]

In the following sections I will describe how to get the PowerPC 405 verified with the following tool set:

coreTools C-2009.06
DC Ultra B-2008.09
DesignWare 2009.06a
vera A-2007.12
NC-Verilog (Integrated Unified Simulator) 8.1

Before you proceed further be sure that all the necessary environment variables from the documentation are set and the correct executables are the in the path.

Getting Started

The educational distribution doesn't come packaged as a single coreKit file but as a compressed, already installed, coreKit directory. To get started fire up coreConsultant and select File > New Workspace. Point the installed coreKit path at the unpacked .tar.gz and choose a directory as the root and a new name for the Workspace. In the following examples we will use the workspace RTLVerification created in the same directory as the unpacked coreKit.

You should now have a directory tree in this root beginning with the name of the workspace. It is similar to the unpacked .tar.gz and populated with symlinks to some of the original files.

Choose the built in Artisan 130LVFSG RAM models and proceed to the simulation stage (I will discuss integrating custom SRAMs in a later article).

Verification by Simulation: Initial Experiences

When you have successfully moved onto the "Verify Component" stage things are not so simple. As we are going to use NC Verilog be sure to choose NC_Verilog as the simulator and ensure the relevant paths are set correctly. Leave the rest of the options at their default values.

[Note: All the issues listed here (and some more of the same) are solved with one comprehensive script and a few instructions in the section below. This section is here to detail what kind of issues you may face and how to solve them to allow you to debug your own installations should this be necessary.]

Building the Vera Objects

The design of the simulation/test environment uses Vera testbench tool to provide compiled simulation objects that surround the Verilog core and a few other Verilog modules and test vectors. We need to compile these Vera objects and we do that by opening a terminal in the Workspace directory we have created (RTLVerification). Then execute this series of commands in the terminal:

cd sim/vera/src

./build_vro

The script will generate several screens full of output with no errors (a few warnings do appear). You can check the content of the sim/vera/lib directory and see the compiled .vro objects.

Running the Simulation

When you hit "simulate" you are faced with the following error message:

For some reason several script files are not correctly linked into the RTLVerification/sim/ directory, but it is easy to fix.

Open the terminal and navigate into the sim/ directory:

cd sim/

ln -s ../../DW_ppc405-FS_iv_1.0a_AV/sim/build_pli_* ./

[Note that you must have the directories setup as discussed or change the command to where the you unpacked the original coreKit directory]

Unfortunately we are not quite out of the woods yet, as the build_pli_nc.sh has to be run by hand to build the binary link between Vera and NC_Verilog. If your environment variables are set correctly then this will complete without error leaving behind the binary file libpli.so.

[Note that you need to have a 64 bit version of Vera for a 64 bit simulator and 32 bit for 32 bit. If you are building for a 32 bit simulator and 32 bit Vera on 64 bit linux edit the pli script to add an -m32 immediately after "gcc" in the compile line and "gcc" in the link line, e.g.:

elif [ `uname` = "Linux" ]; then
     gcc -m32 -fPIC -c -I$VERA_HOME/lib/vlog -I$CDS_INST_DIR/tools/verilog/include $VERA_HOME/lib/vlog/veriuser.c
     gcc -m32 -shared -o libpli.so veriuser.o $VERA_HOME/lib/vlog/libSysSciTaskpic.a

]

Retrying the simulation in the coreConsultant GUI produces the following result almost instantly:

Now I think NC Verilog is an excellent simulator however simulating an entire core in a few seconds? No.

Delving into the scripts reveals another missing file: sim/runtest. By using the same procedure as before we can link it in:

cd sim/

ln -s ../../DW_ppc405-FS_iv_1.0a_AV/sim/runtest ./

Unfortunately this script is also not in a working condition: It depends on the perl distributed by Synopsys but it is hardcoded to try one only available within IBM. However fortunately Synopsys ships this perl with coreTools. Open the file sim/runtest in your favorite text editor and change the first few lines from:

#!/afs/raleigh/cadtools/synopsys/dc/2005.09/linux/bin/snpsperl
require 5.004;
BEGIN { @INC = ( "/afs/raleigh/cadtools/synopsys/dc/2005.09/linux/lib" ); }

to:

#!$YOUR_PATH_TO_CORETOOLS/linux/dware/bin/snpsperl

require 5.004;

BEGIN { @INC = ( "$YOUR_PATH_TO_CORETOOLS/linux/dware/lib" ); }

replacing "$YOUR_PATH_TO_CORETOOLS" with the absolute path in your installation.

Trying to simulate again produces the "instant success" we will come to know and love.

Another missing file that needs to be linked into our workspace is the Makefile used to run these simulations:

cd sim/

ln -s ../../DW_ppc405-FS_iv_1.0a_AV/sim/Makefile ./

Unfortunately this Makefile has a similar problem with hardcoded paths that need correcting, as does Report.pl, runTB and hexFormal.pl. There are also numerous files that are not linked in. These issues arise from the coreKit being delivered in an installed from compressed into an archive rather than as a .coreKit file. To save you the effort of solving every one of these issues have a look at the next section. :

Verification by Simulation: Solved
[Ensure you have followed the instructions in "Getting Started" above. You should have installed a new workspace and have completed "Specify Configuration" and moved onto "Verify the Component"]

1) Open your favorite text editor and paste in the following script:

#!/bin/bash
#
# fix_sim_dir.sh
#
#Copyright Matthew Swabey (matthew@swabey.org).
#
#You are licensed to use this file in conjunction with the IBM PowerPC 405 coreKit and to make modifications as needed to this script as long as this copyright notice is kept.

#This script should be executed from the the new workspace directory after you have installed it with coreConsultant and progressed past specifying the SRAM technology.

UNPACKED_COREKIT_DIR=/export/fastcad/disktmp/mas/IBM_PUB2/DW_ppc405-FS_iv_1.0a_AV
SNPS_PERL_EXE=/home/esdcad/software/synopsys/linux/coreTools_B-2008.12-SP1/linux/dware/bin/snpsperl
SNPS_PERL_LIB=/home/esdcad/software/synopsys/linux/coreTools_B-2008.12-SP1/linux/dware/lib

#Build the vera objects with the version of vera installed
cd ./sim/vera/src
./build_vro
cd ../../..

#Link in the files needed to build the simulation of the PPC and run the testbenches
ln -s $UNPACKED_COREKIT_DIR/sim/build_pli_* ./sim/
ln -s $UNPACKED_COREKIT_DIR/sim/Makefile ./sim/
ln -s $UNPACKED_COREKIT_DIR/sim/runtest ./sim/
ln -s $UNPACKED_COREKIT_DIR/sim/Report.pl ./sim/
ln -s $UNPACKED_COREKIT_DIR/sim/scripts/hexFormat.pl ./sim/scripts/
ln -s $UNPACKED_COREKIT_DIR/sim/scripts/run405.config ./sim/scripts/
ln -s $UNPACKED_COREKIT_DIR/sim/scripts/runTB ./sim/scripts/
mkdir ./sim/testsuite
ln -s $UNPACKED_COREKIT_DIR/sim/testsuite/* ./sim/testsuite/
ln -s $UNPACKED_COREKIT_DIR/sim/testbench/*.v ./sim/testbench/
ln -s $UNPACKED_COREKIT_DIR/sim/testbench/*.inc ./sim/testbench/
ln -s $UNPACKED_COREKIT_DIR/src/rtl/*.v ./src/rtl/

#script files needing corrected perl paths separated by a space.
TO_BE_FIXED='./sim/Makefile /sim/runtest ./sim/scripts/hexFormat.pl ./sim/scripts/runTB ./sim/Report.pl'

function fix_perl_paths {
#Fix the afs paths for snpsperl
sed -i "s:/afs/raleigh/cadtools/synopsys/dc/2005.09/linux/bin/snpsperl:${SNPS_PERL_EXE}:g" $1
sed -i "s:/afs/raleigh/cadtools/synopsys/dc/2005.09/linux/lib:${SNPS_PERL_LIB}:g" $1
#Fix added for runTB
sed -i "s:/global/freeware/SunOS/5.8/perl-5.6.1/bin/perl:${SNPS_PERL_EXE}:g" $1

}

for file in $TO_BE_FIXED; do fix_perl_paths "$UNPACKED_COREKIT_DIR/$file"; done

#End of script

2) Edit the top three variables, UNPACKED_COREKIT_DIR, SNPS_PERL_EXE & SNPS_PERL_LIB to have the absolute paths to the appropriate executable or directory. There should be no spaces in the paths.

3) Save this file with a suitable name (e.g. fix_sim_dir.sh) in the new workspace you have created. Make the script executable using the command chmod u+x "filename". When you run it you should see an output that looks like this (but with many more Vera banners):

++---------------------------------------------------------------------++
 ||                     VERA System Verifier (TM)                       ||
 ||        Version: A-2007.12 () -- Thu Oct  8 11:35:39 2009            ||
 ||             Copyright (c) 1995-2004 by Synopsys, Inc.               ||
 ||                      All Rights Reserved                            ||
 ||                                                                     ||
 ||      For support, send email to vera-support@synopsys.com           ||
 ||                                                                     ||
 ||  This software and the associated documentation are confidential    ||
 ||  and proprietary to Synopsys Inc.  Your use or disclosure of this   ||
 ||  software is subject to the terms and conditions of a written       ||
 ||  license agreement between you, or your company, and Synopsys, Inc. ||
 ++---------------------------------------------------------------------++
Warning: async drive on skewed signal jtag_o.tdi, at 78 in ./p405s_jtag.vr
Warning: async drive on skewed signal jtag_o.tms, at 79 in ./p405s_jtag.vr
Compilation errors: 0
 ++---------------------------------------------------------------------++
 ||                     VERA System Verifier (TM)                       ||
 ||        Version: A-2007.12 () -- Thu Oct  8 11:35:39 2009            ||
 ||             Copyright (c) 1995-2004 by Synopsys, Inc.               ||
 ||                      All Rights Reserved                            ||
 ||                                                                     ||
 ||      For support, send email to vera-support@synopsys.com           ||
 ||                                                                     ||
 ||  This software and the associated documentation are confidential    ||
 ||  and proprietary to Synopsys Inc.  Your use or disclosure of this   ||
 ||  software is subject to the terms and conditions of a written       ||
 ||  license agreement between you, or your company, and Synopsys, Inc. ||
 ++---------------------------------------------------------------------++
Compilation errors: 0
 ++---------------------------------------------------------------------++
 ||                     VERA System Verifier (TM)                       ||
 ||        Version: A-2007.12 () -- Thu Oct  8 11:35:39 2009            ||
 ||             Copyright (c) 1995-2004 by Synopsys, Inc.               ||
 ||                      All Rights Reserved                            ||
 ||                                                                     ||
 ||      For support, send email to vera-support@synopsys.com           ||
 ||                                                                     ||
 ||  This software and the associated documentation are confidential    ||
 ||  and proprietary to Synopsys Inc.  Your use or disclosure of this   ||
 ||  software is subject to the terms and conditions of a written       ||
 ||  license agreement between you, or your company, and Synopsys, Inc. ||
 ++---------------------------------------------------------------------++
Compilation errors: 0
ln: `./sim/testbench//p405s_rambist_tb.v': File exists
ln: `./sim/testbench//tb_p405s_dataram_64X34_wrapper.v': File exists
ln: `./sim/testbench//tb_p405s_sram256x46_wrapper.v': File exists
ln: `./sim/testbench//tb_p405s_sram256x48_wrapper.v': File exists
ln: `./sim/testbench//tb_p405s_sram512x128_wrapper.v': File exists
ln: `./sim/testbench//tb_p405s_sram512x32_wrapper.v': File exists
ln: `./sim/testbench//tb_p405s_sram512x8_wrapper.v': File exists
ln: `./sim/testbench//tb_p405s_sramBytWr512x128_wrapper.v': File exists
ln: `./src/rtl//PPC405F5V1_soft.v': File exists

At this point the script will have built the vro objects using Vera, linked in all the missing files and corrected the paths in the scripts for you.

4) Enter the ./sim directory in the workspace and run the build_pli_nc.sh script by hand to build the binary link between Vera and NC_Verilog. If the environment variables are set correctly then this will complete without problem leaving behind the binary file libpli.so
[Note that you need to have a 64 bit version of Vera for a 64 bit simulator and 32 bit for 32 bit. If you are building for a 32 bit simulator and Vera on a 64 bit computer edit the scripts to add an -m32 immediately after "gcc" in the compile line and "gcc" in the link line:

elif [ `uname` = "Linux" ]; then
     gcc -m32 -fPIC -c -I$VERA_HOME/lib/vlog -I$CDS_INST_DIR/tools/verilog/include $VERA_HOME/lib/vlog/veriuser.c
     gcc -m32 -shared -o libpli.so veriuser.o $VERA_HOME/lib/vlog/libSysSciTaskpic.a

]

5) Return to the coreConsultant GUI, check you have selected the correct test suite, simulator and other variables and click "Apply" to be rewarded with:

This will take quite a while, so enjoy a well earned cup of tea/coffee/other until it completes:

6) Check the reports for anything interesting or anomalous

7) ...

8) Profit!

Published with permission from IBM and Synopsys

IBM PowerPC™ 405-S: Getting started

2009-11-06T17:37:00.009Z

Synthesizable RTL versions of IBM's excellent embeddable PowerPC™ line of processors (the 405, 460 and the 460 FPU) are available to SoC designers from Synopsys' Star IP Program and this Star IP PowerPC™ 405-S is also available to Educators. Further embeddable PowerPC™ cores for synthesis are also available from AMCC.

In a series of articles I will show how to take the educational soft IP download, verify the 405 core and put it to work bonded to some of Synopsys' DesignWare IP.

Currently the articles in this series are:

1) Getting started with the synthesizable IBM PowerPC405™ (this article)
2) Verification of the RTL with the supplied Artisan PDK (now owned by ARM)
3) Synthesis of the RTL with the supplied Artisan PDK
4) Verification of the Gate Level Netlist

It was with great excitement that I received the educational IP by electronic transfer. As is typical with this kind of IP the full details remain secret until the licenses are signed, but with the kind permission of IBM and Synopsys let me lift the veil a little bit for you:

Here is what you get:

Synopsys PowerPC™ 405-S Design View CoreKit v1.00a - This enables full, accurate simulations to be carried out to allow evaluation of the core running a software stack
Synopsys PowerPC™ 405-S Implementation View CoreKit v1.00a - This bundle contains the verilog RTL of the actual core itself along with a demonstration technology library and the verification tools to enable its functionality to be fully exercised and guaranteed. This view also contains implementation scripts to build the design from RTL through synthesis, DFT, floorplanning, placement and clock tree expansion.
Specifications - An essential set of manuals describing the exact operation of the core
DDR2 Memory Controller - IBM's PLB DDR2 SDRAM memory controller to allow attachment of off chip SDRAM
SRAM Memory Controller - This allows a number of internal SRAM (not SDRAM!) blocks to be presented as one continuous memory space on the PLB bus to a master
PCIX Controller - IBM's PLB to PCIX controller
PLB Crossbar Arbiter - This enables the connection of a large number of PLB masters to one or more slave busses. With this block very complex multicore/multimaster bus structures can be created within an SoC
DMA Controller - a standard component allowing DMA transfers between peripherals and memory and vice versa
UIC Controller - This is the Universal Interrupt Controller, an essential device for any SoC
PLB to AHB Bridge - This is bundled in with the core but is well worth noting - this allows the use of DesignWare IP blocks which are based around the AMBA bus specification
Artisan PDK - For simulation purposes an Artisan 130nm LV PDK is supplied
IBM RISCWatch - A JTAG debugger to allow full trace and debugging functions on the PowerPC core

As you can see it is an embarrassment of riches - a near complete set of IP enabling a basic single core to a complex multicore PowerPC™ 405 based SoC to be realized with only the basic IO IPs outstanding (e.g. no serial port or GPIO).

Again I should like to say a heartfelt thankyou to IBM and Synopsys for making this IP available to Universities to drive our research and educational programs forward. It is also available to drive commercial embedded designs forward after licensing.

Note: As it is a Synopsys Star IP this distribution is designed for a number of industry standard simulators and the Synopsys Implementation and Signoff tool suite. The package contains pure Verilog RTL so it is technically possible to use another vendor's synthesis tool but that is well outside the scope of this series of articles (as well as being a very big job).

Published with permission from IBM and Synopsys

How to Re-Analyze the DesignWare Building Blocks in Synopsys Design Compiler

2009-11-04T23:46:00.003Z

Design Compiler, sometimes misnamed as dc_shell, includes a selection of datapath primitives called DesignWare Building Blocks (DWBB). Sometimes after a patch or new installation you may find these complaints in your logs:

Error:   Source file for 'DW01_SUB' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_DEC' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_INC' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_ADD' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_INC' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_INC' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_ADD' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_INC' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)
Error:   Source file for 'DW01_INC' was not analyzed by this release of the compiler; re-analyze it. (ELAB-343)

They mean the compiled DWBB library is now out of date in relation to the version of Design Compiler you have. To cure them cd to $SYNOPSYS, then

cd dw/scripts/
./dw_analyze_syn.csh

and pretty soon you will have a lovely, shiny, new set of DesignWare Building Blocks!

[Note that this information also applied to VCS but use

cd dw/scripts/
./dw_analyze_sim.csh

]

"Transmute" - Design Philosopies

2009-09-25T15:18:00.003+01:00

I realized that I had forgotten to describe a very, very important step: Philosophy. In this case I am using the word incorrectly. It is actually World View that I mean. From Wikipedia:

"A comprehensive world view (or worldview) is the fundamental cognitive orientation of an individual or society encompassing natural philosophy, fundamental existential and normative postulates or themes, values, emotions, and ethics."

Now what has this to do with chip design? Well you might ask! In this case it is the fundamental underpinnings and assumptions that surround the design.

The world view is formed from facts and opinions and our emotional reaction to them.

So here is the list of suitable facts for the "Transmute" project:

We have only built cell based custom digital cores
None of our typical projects are as large as this
The design flows are not stable - considerable development will be required
Several custom digital modules will be required to interfaced to licensed IP
We can experiment with power saving strategies
We are very experienced with custom analogue blocks

What, as a designer, is my emotional reaction to this? Simply this: Excitement and Concern. There are a lot of unknowns.

Hence our design World View (although a different design will have a different world view):

Digitally Conservative
Analogue Progressive

One you articulate this World View clearly you realize that this is the guide for your choices, in our case:

Hard IP: Eliminates the risk from core synthesis
Digital part to be separable from the analogue part so we can drive them separately. This will minimize the cost in case of failure or error - we would get at least one working part from the chip
Digital power saving strategies to be applied only after a high confidence in non-power saving digital structures obtained
It must be possible to disable the digital power saving structures if they are added
Flow decisions should favour tools which we have experience with

These decisions then guide the rest of the design flow. Also new choices can be matched against the worldview ensuring consistency.

Just bear in mind, your world view for this design may need modifying as the project progresses however if it does then you need to reconsider most of the work you have already carried out. This is typically far more important if your original plan was aggressive and you move to conservative - check work and assumptions already made!

The next SoC design - working title "Transmute" begins

2009-09-16T17:29:00.009+01:00

I have a fun new hobby - designing the digital part of a new, mixed signal SoC which we are building here. It is my intention to blog the full design flow discussing the various challenges and issues as we encounter them.

Design Basics

Foundry
Technology
IP
Flow

The importance of these choices of these depends on the following thoughts:

What have we done before
Who have we worked with before
What have we got that works
What we need to do and what we would like to do

Planning a chip begins after you decide the basics above, i.e. foundry, technology and the needed parts and finally tool support. Sometimes in industry you have the luxury of a couple of other choices e.g.:

Cell library (we use the ST supplied one but there are others, Faraday for example)

Basic Overview Spec

Two full custom ADCs for testing and evaluation
A single core SoC to test our mixed signal integration and apply tests
Simple connectivity to the SoC

Initial Decisions

In our case after some mulling over our experiences we decided on:

ST Microelectronics via the Circuits Multi-Projets MPW broker
Their HCMOS9 130nm process
IP Blocks (see below)
The flow, more on that later

IP Blocks

As a university our access to IP is somewhat limited. Making a SoC requires quite a few modules like memory controllers etc.

However to the rescue rides Synopsys' DesignWare Library. It includes a basic selection of AMBA AHB/APB bus connected peripheral set and a memory controller which supports SDRAM and Flash.

To drive the the DesignWare library is the coreTools GUI (which is surprisingly hard to find) which in a nice graphical environment enables you to construct AMBA bus structures containing DesignWare peripherals. So this drives our choice of some of the tools (coreTools and DesignCompiler Ultra) as well as their DesignWare basic IP.

Onto a much more interesting question. What core to use? Considering our other IP is AMBA an ARM is the most likely choice however there are others we might use:

The LEON3 from Aeroflex is a Opensource (GPL), VHDL 32 bit SPARCv8 CPU with an AMBA bus. It is, however, very much bound to its peripheral library and autoconfiguration so would take a lot of work. It would also need to be customised to use the HCMOS9 SRAM blocks
The IBM PPC 405 is a 32 bit PowerPC core designed for embedding which is licensed to universities for teaching and education. It is the distribution created for the Synopsys flow which allows easy integration with AMBA peripherals. It is a softcore, i.e. it would need to be synthesised from RTL

In this case we wish to reduce our risk and design effort. Licensable from CMP is a foundry guaranteed ARM946E-S hard IP (i.e. they have already synthesized it and checked it) on their 130nm process. So we are going ahead with DesignWare soft IP surrounding a hard IP ARM946E-S. The benefits of hard IP are that ST have de-risked the design for us.

The features of the ARM946E-S are:

Excellent compiler/OS/application support. ARM is one of the best supported architectures in both Opensource and commercial software
Small and quick, approximately 3mm² and clocking at 200MHz (both of these are significantly derated estimates at this stage of the design
MMU allowing full OS support

In addition we need the following types of IP:

A PLL - this is pretty much required for any SoC these days (available from CMP)
Level shifters and isolators - needed to try advanced power saving strategies in digital logic

The current initial design of the digital segment of our chip is best shown in a block diagram below:

We will talk of flows and the analogue integration later.....

The sheer size of an old Sun "midrange" server

2009-09-03T09:35:00.008+01:00

This one is going back a bit but I have obtained it for legacy support. Its a Sun V880 with 6x UltraSPARC III 750MHz processors and 12GB of RAM. Still a computer to be reckoned with [Update: Spent $50 on a new CPU/RAM board to take it to 8x CPU and 16GB RAM. eBay is great for this kind of thing]

Its as high as my desk, as large as a fridge lying on its side and sounds like a very loud aircon. [Update: When it is running under an OS at low load it throttles the fans and becomes quite quiet]

This one was going to be built with Solaris 10 on a software mirrored root using UFS but the new spin of Solaris 10 allows installation and booting off ZFS. A much more sensible choice when I have 6x 36GB disks.

Modding an HP Proliant DL585 to take an EVE Zebu UF2

2009-08-20T15:58:00.002+01:00

I am the proud "controller" of an EVE Zebu UF2 emulation accelerator (a big PCI card covered in FPGAs). One of its biggest selling points is their Transactors which allow you to present your design with the interfaces it would experience if it were real, completely abstracting away the PCI bus.

However when I say big I mean triple height and full length. It uses 64 bit PCI/66. (For those considering purchasing a UF4 card most PCs can't fit it as it is larger still).

So I need a computer to host it in!

Enter the HP DL585 - a lovely machine. Built as solidly as a tank and everything is terribly easily accessible either from the front or the top. Everything. At a push I think I could swap out the motherboard and be back up and running in 30 minutes from cracking the case.

The original engineers designed it for cable-less operation (and very nearly succeeded!) but the EVE ZeBu-UF needs power from a 4 pin molex (found on most pre-SATA HDDs).

So what to do? Spotting this SCA backplane and knowing that HDDs take 12V, 5V and 3.3V power I had my solution. Mod a molex connector onto the pins on the back of one of the SCA sockets.

Firstly I checked the specifications for the ZeBu: 25W at 12V which is a current of 2.08A. Secondly I checked the specifications of the SCA2 connector: Section 6.4.1 of the SFF-8046 standard specifies a surge current of 5A and a constant supply of 2.5A. This means that one socket can supply the necessary power.

However, several provisos first: This will void your warranty. The SCA-2 connector transfers power to the drive using several pins for each voltage (12V, 5V and 3.3V) to reduce their resistivity to high current. By design the clusters of pins supplying the same voltage are next to each other making it easier. Probe for the resistance between the pins you think are the right ones - it needs to be zero.

The mod requires soldering the little clusters of pins together with fine wire (get some strands out of a multistrand wire) and then attached the cables. Note - don't include the Precharge pins - wiring them to the rest of the supply could cause unexpected operation as they will no longer function correctly when you insert a HDD in the front. After you are done, check, double check and triple check. Use a magnifier/microscope to check the soldering. Clean the area of any bits of solder. Probe the resistivity again. This could be an expensive mistake if there is a problem!

Power on (fingers crossed) and bingo - 12V and 5V.

Here is a photo of the modded card in position:

...and a photo of the UF2 in the PCI bay (I have two power connectors just in case I can get another UF2 - wishful thinking I know):

Loading new maps into Nokia Maps on an N95 without a cable or bluetooth

2009-07-23T17:12:00.001+01:00

Foolishly I arrived in San Francisco for MSE without loading the California maps into my phone.

This presented me with a pretty conundrum. Nokia's recent upgrade to Ovi Maps meant that the new maps uploader wanted a phone connected with Nokia PC Suite via the USB-A to Mini-B cable or bluetooth in PCSuite mode.

However without a cable or bluetooth (I have my old IBM X31 laptop, hand upgraded with Intel 2200BG Wifi) what can you do?

Turn to an almost forgotten technology: IrDa. The N95 8GB has a 115200 IrDa port on it and the Thinkpad X31 has a 4Mbps one.

Download the old "Nokia Map Loader" - this talks to the phone as a mass storage device.
Connect the phone via IrDa to the PCSuite.
Run the Nokia Map Loader

Upload the maps - took a very long time!

[An alternative to doing this is use the following blog post to download the maps directly. This can even be done on your mobile!]

Off to Microelectronic Systems Education

2009-07-17T19:35:00.000+01:00

...in sunny San Francisco.

MSE Conference (and its partner EWME) provide a fantastic venue to explore and demonstrate novel ways to teach complex system-on-chip designs.

I shall also be attending the tutorials - One on the Cypress PSoC platform, a fascinating combination of a digital microcontroller, a programmable logic device and a section of programmable analogue logic. The second will be on several techniques from Synopsys:

Fix for amanda 2.5.1p1 on MacOSX PowerPC

2009-07-12T16:03:00.000+01:00

Bug causes the following error message in the following stable releases 2.5.1p1, 2.5.1p3, 2.6.1p1

Amanda Backup Client Hosts Check
--------------------------------
ERROR: NAK mac-mini: user backup from hs-dhgl7ce.msindustries.com is not
allowed to execute the service noop: /Users/amandabackup/.amandahosts:
owned by id 5000, should be 529288
Client check: 1 host checked in 0.859 seconds, 1 problem found

There is no user of UID of 529288 on the machine.

Here is a snip of the amandad log after a modification to add Print statements printing the UID as dereferenced from the pointer in check_user_amandahosts() in common-src/security-util.c


amandad: time 0.187: sec: calling accept_fn
Print uid: 5000
Print UID on entry now: 5000
check_user_amandahosts(host=hs-dhgl7ce.msindustries.com, pwd=0x100400, remoteuse
r=backup, service=selfcheck)
amandad: bsd: processing file: /Users/amandabackup/.amandahosts
amandad: bsd:                  owner=amandabackup group=wheel mode=600
Print UID after stralloc: 529288
Print UID after fopen: 529288
Print sbuf.st_uid now: 5000
Print UID after fstat: 529288
amandad: bsd: processing line: hs-dhgl7ce.msindustries.com backup="" amdump=""
amandad: bsd: comparing "hs-dhgl7ce.msindustries.com" with

The bug has been fixed by caching the pwd->ps_uid at the start of the function and using the test against that. Also note that the bug behavior changed at some point as the UID changed from 529288 to 0. Suggests a buffer overrun, endianness or thread issues.

Here is the modified check_user_amandahosts() security-util.c (don't forget to modify the top of the file to enable secprintf().


/*
 * Check to see if a user is allowed in.  This version uses .amandahosts
 * Returns -1 on failure, or 0 on success.
 */
char *
check_user_amandahosts(
    const char *        host,
    struct in_addr      addr,
    struct passwd *     pwd,
    const char *        remoteuser,
    const char *        service)
{
    char *line = NULL;
    char *filehost;
    const char *fileuser;
    char *ptmp = NULL;
    char *result = NULL;
    FILE *fp = NULL;
    int found;
    struct stat sbuf;
    char n1[NUM_STR_SIZE];
    char n2[NUM_STR_SIZE];
    int hostmatch;
    int usermatch;
    char *aservice = NULL;

    uid_t tmp_pw_uid = pwd->pw_uid;
    secprintf(("Print UID on entry now: %d\n",pwd->pw_uid));

    secprintf(("check_user_amandahosts(host=%s, pwd=%p, "
                "remoteuser=%s, service=%s)\n",
                host, pwd, remoteuser, service));

    ptmp = stralloc2(pwd->pw_dir, "/.amandahosts");
#if defined(SHOW_SECURITY_DETAIL)                               /* { */
    show_stat_info(ptmp, "");;
#endif                                                          /* } */
    secprintf(("Print UID after stralloc: %d\n",pwd->pw_uid));
    if ((fp = fopen(ptmp, "r")) == NULL) {
        result = vstralloc("cannot open ", ptmp, ": ", strerror(errno), NULL);
        amfree(ptmp);
        return result;
    }
    secprintf(("Print UID after fopen: %d\n",pwd->pw_uid));

    /*
     * Make sure the file is owned by the Amanda user and does not
     * have any group/other access allowed.
     */
    if (fstat(fileno(fp), &sbuf) != 0) {
        result = vstralloc("cannot fstat ", ptmp, ": ", strerror(errno), NULL);
        goto common_exit;
    }
    secprintf(("Print sbuf.st_uid now: %d\n",sbuf.st_uid));
    secprintf(("Print UID after fstat: %d\n",pwd->pw_uid));

    /*if (sbuf.st_uid != pwd->pw_uid) {*/
    if (sbuf.st_uid != tmp_pw_uid) {
        snprintf(n1, SIZEOF(n1), "%ld", (long)sbuf.st_uid);
        snprintf(n2, SIZEOF(n2), "%ld", (long)pwd->pw_uid);
        result = vstralloc(ptmp, ": ",
                           "owned by id ", n1,
                           ", should be ", n2,
                           NULL);
        goto common_exit;
    }

Synopsys Designware System Level Library Compiled

2009-06-24T09:44:00.000+01:00

Rebuilding everything from scratch with a clean install, and setting the following environment variables:


CC /usr/local/gcc/3.3.6/bin/gcc
CXX /usr/local/gcc/3.3.6/bin/g++
LD /usr/local/gcc/3.3.6/bin/g++

and look

Synopsys DWSLL still won't compile even with gcc-3.3.6 [FIXED]

2009-06-23T19:40:00.000+01:00

[see above post, must have had a broken systemc install left lying about]

Having built a version of gcc-3.3.6 that compiles correctly and passes the tests I now get a new (and unpleasant) build error:

/usr/local/gcc/3.3.6/bin/gcc  -o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/vptest .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/CoreManager.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/IntCtrl.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/MuxRoutingView.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/Tester.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/UART.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/powerDashboard.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/registerView.ctor.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/vptest.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/vptest_sc_main.o .vptest//linux/dwsll/gcc-3.3.6/osci-2.2.0/VT100.ctor.o -L/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib -llt-O -g -fPIC -Wl,-Bsymbolic   /opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/snps_tlm.a -L/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib -L/opt/fastcad/software/systemc/systemc-2.2.0/lib-linux -L/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/../runtime/Shared/Debuggers -lpthread -lsystemc -lqt-mt -lvdidll -ldl -rdynamic /opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/libsimdll.a 2>&1 | c++filt
/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/snps_tlm.a(simlog.o)(.text+0xc88): In function `Simlog::Abort(IUnit*, char const*, ...)':
: undefined reference to `typeinfo for unsigned'
/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/snps_tlm.a(snps_tlm_imemory_tlm2.o)(.gnu.linkonce.r._ZTIPN8snps_tlm20vre_config_extensionE+0x0): undefined reference to `vtable for __cxxabiv1::__pointer_type_info'
/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/snps_tlm.a(snps_tlm_manager.o)(.text+0x3aa5): In function `snps_tlm::manager::SimMain()':
: undefined reference to `typeinfo for int'
/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/snps_tlm.a(snps_tlm_manager.o)(.gcc_except_table+0x48c): undefined reference to `typeinfo for int'
/opt/fastcad/software/synopsys/linux/dw_sys-l-lib_2008.12/linux/dwsll/gcc-3.3.6/osci-2.2.0/lib/snps_tlm.a(snps_tlm_manager.o)(.gnu.linkonce.r._ZTIP15ManagerListener+0x0): undefined reference to `vtable for __cxxabiv1::__pointer_type_info'
/opt/fastcad/software/systemc/systemc-2.2.0/lib-linux/libsystemc.a(sc_main_main.o)(.gcc_except_table+0x38): undefined reference to `typeinfo for char const*'
collect2: ld returned 1 exit status

Synopsys Innovator and Designware System Level Library II

2009-06-23T18:47:00.000+01:00

More things to do with Synopsys Designware System Level Library.

Just so you know:

When they say use gcc-3.3.6, they mean gcc-3.3.6. RHEL3 shipped with gcc-3.2.X and RHEL4 with gcc-3.4.X. Both build models without errors but when executed segfault.

I am building a copy of gcc-3.3.6 now following this excellent guide by Tellurian.

More to follow.

MSc Dissertation Titles for 2009

2009-06-19T15:50:00.000+01:00

1. An OpenSPARC with Hypertransport
Add a memory mapped Hypertransport port to an OpenSPARC processor.

2. SystemC to Reality
Take the Synopsys innovator SystemC based example of an MP3 player and
convert as much as possible to real hardware to assess the accuracy of
the Virtual Platform Model using the EVE accelerator.

3. Accelerating Geometric Mathematics
Taking the departments Geometric Maths co processor design and attaching
it to an IBM PowerPC 405 processor (either memory mapped or via the
coprocessor port) as efficiently as possible.

4. Hardening Soft Cores, the advantages and problems
Take the LEON3 opensource Sparc v8 processor and the IBM PowerPC 405
processor softcores (one is VHDL, one Verilog) and study them for speed
and size optimisations using blocks inside an FPGA like embedded
ram/multipliers. The LEON3 is already optimised and will serve as an
example.

5. Bi-width Processing for Sensor Applications
Research and design a processor with 2 data word widths - 8bits for low
power mode and an additional 32 bits when turned into high power mode.

Research the LEAP architecture first and try to improve it.

Synopsys Innovator and Designware System Level Library

2009-04-26T17:14:00.000+01:00

THESE PROGRAMS ARE DEFINITELY 32 BIT

SystemC is perfectly happy on x86_64 however the pre-compiled libraries shipped inside the Designware System Library are not. Ah-ha, you say, "I shall compile them in 32 bit mode". However there is a problem: they depend on qt-devel.i386 which can't be installed on the same system as qt-devel.x86_64. So there.

Another word of warning for the clever:

THE BUILD SCRIPTS WILL WORK, BUT GENERATE EXECUTABLES THAT SEGFAULT.

Make/g++ don't quit on the qt linking error. Several hours of condensed hacking wasted as I didn't spot it. Another reason to use virtual machines to avoid these kinds of problems when using CAD tools. [see above for more details on the segfault issues]

DATE2009

2009-04-26T17:12:00.000+01:00

What a great conference. I attended the workshop on Embedded Multicore computing as well as a similar tutorial.

Lots of very good people here with good ideas. Got the chance to get some real IC architecting off the ground and acquired a lot of good material for the SystemC based architecture course.

Installing Synopsys Synthesis and IC Compiler in the same directory

2009-04-08T22:58:00.001+01:00

These are also known as syn and icc and include the all important executables and libraries to run dc_shell and icc_shell. These are part of the Galaxy platform. Synthesis provides tools for turning HDL into PDK specific netlists and IC Compiler for place and routing.

You can install Synthesis and IC Compiler for different operating systems into the same directory

As they are part of the same system (Galaxy) they can be installed into the same directory to save space and simplify installations scripts.
Be sure to get the same release and service pack from EST into the same directory.
Retrieve the common files and all the OS/Architecture specific parts you want (for example linux and amd64)
Run the installer on the directory and you will be able to select syn and icc and subsequently the architecture specific versions.

Hope this helps keep things simple.

The Buffalo Linkstation Live (v2) - Unbricking

2009-02-08T01:12:00.000Z

I just managed to get my Buffalo Linkstation (running Debian based Freelink) to brick in a new way: it would pull the kernel and initrd by tftp over and over again or it would appear to have loaded them but simply stop.

After trawling the forums I have salvaged the situation by mounting the HDD on a linux system and erasing and rebuilding the default /dev/sda1 partition.

I have also recorded how to do it in the relevant wiki article like a good boy:

http://buffalo.nas-central.org/wiki/Revive_your_arm9_box_from_scratch#Troubleshooting

Linkstations and similar Linux based NAS devices make fantastic home servers - mine draws ~13W under load providing daap, DHCP, NTP, apache, NFS, samba and AFS. Beats the hell out of an always on home Intel server.

How can I allow users to run a script as root?

2009-01-27T14:28:00.000Z

I am glad you asked me that question!

In this case I need a user to nuke a process related to themself but executing as 'nx'. So to kill it they would have to be root (or nx). Killing the process and the related cleanup requires a script to automate it so I need to make a script run as root.

I can do that by making the scripting language interpreter (e.g. perl, python, etc) always run as root ("setuid"). This means that all scripts executed by that interpreter run as root.... oops. Ok bad idea as anyone can run any script they write as root. I know, I shall make the kill command always run as root. Anyone can now kill any process .... oops. Ok bad idea, slightly less a security risk though.

The solution to the above class of problems is called a 'shim' after small bits of metal. Go look the reference up if you care. The solution is make a tiny C program that when executed by a user runs as root ("setuid") and then executes the script, sanitising and passing any necessary arguments.

So here is a trivial C program to execute a single script (nxclean.c):


#define PATH "/usr/local/sbin/nxclean"
#define BUF_SIZE 10000

#include <stdio.h>
#include <unistd.h>
#include <sys.h>

int main(void)
{
uid_t user;
char user_str[BUF_SIZE] = {'\0'};

//      printf("My UID is: %d\n", getuid());
//      printf("My EUID is: %d\n", geteuid());
user = getuid();
snprintf(user_str, BUF_SIZE, "%d", user);
//      printf("My UID is: %s\n", user_str);
setuid(geteuid());
//      printf("My UID now is: %d\n", getuid());

execl(PATH, PATH, user_str, (char *) 0);
}

So what is going on here? Firstly a couple of #DEFINE's to save typing. Note that the buffer sizing and the initialisation of the whole buffer to '\0'. Remember this is a program that is going to run as root. It takes no command line arguments, simplifying things, but it is taking things from the underlying OS so be sure to be safe. If you are taking command line arguments then check them every which way, run regex's, size checks, the works. Otherwise kiss your security goodbye.

In this case it stores the UID of the current user as it needs it later, makes itself root via the setuid(geteuid()); line and then executes the script (now as root) passing arguments created from the UID collected earlier.

Note this only works if you have set the little executable this compiles into to run as root. Google "setuid".

DATE09 TPC finished and went well - linksys WRT54GLs are awesome!

2008-11-07T19:16:00.000Z

Arrived at the IET on the evening of Wednesday with my team this week and immediately got the benefit of the IET's professional staff. Within 1 hour I had the server running a custom software package crafted specifically for DATE to manage the submissions.

Imagine trying to manage 900 submissions on paper + email? Impossible.

In the initial hour I also deployed 4 wifi routers, all linksys WRT54GL's to manage the 190 members who review the papers in groups organised by topics.

On Thursday under peak load the WRT54GL's were handling 43 WPA encrypted connections simultaneously (note that the SPI was disabled and also note a CPU monitor would be very helpful to gauge the CPU load).

They worked all day with only 5 laptops unable to connect, and considering the fact that wifi with encryption isn't a very well adhered to standard (lots of bugs) that is just noise. Even that was resolved with a driver update to a 2200BG card from Intel.

It all had to work, and it all came together.

Synopsys Babbage Grant Proposal In!

2008-11-02T11:12:00.000Z

It has been a most incredible slog getting the grant proposal out of the door. But now it is all done and I am really thankful. DATE2008 TPC here I come.

The love affair with freenx is over.... time to make the marriage work

2008-10-17T07:39:00.000+01:00

It seems that not much survives contact with students!

Basically if the freenx session isn't correctly terminated or established then desktop processes and a nx process are left running to the server which will prevent them logging in again.

However I am not the first person to notice this:

PSI Labs who use the technology have developed a RPM of scripts to manage this properly called nxcleanup. A user session has the standard number of processes for the desktop however there is an associated nx process that the student doesn't own. So the script nxclean would need to be run as root.

How do I enable a student to run a script as root that wipes out processes of an arbitary user?

Simple: Use a setuid "shim"! Write a trivial C program that takes no inputs (or has very, very thorough sanity checking!) which identifies the current user using posix calls and then exec's the script after passing it the current username. Nifty eh? This is a standard way of making scripts run safely as root. I'll post it as soon as I am done.

NX Technology Makes Remote X Possible

2008-10-08T21:22:00.000+01:00

I implemented NX technology on our linux CAD servers some time ago.

NX has enabled a whole distance learning class from America using some really poorly coded CAD tools (some are windows GUIs run under emulation).

It made it like using them over the LAN!

If you have remote UNIX application needs then please consider this technology.

I am more than happy to consult on your CAD architectures.

AVR Studio and WinAVR as C teaching tools...

2008-10-08T21:12:00.000+01:00

AVR Studio when run in combination with WinAVR (packaging avr gcc, avr-libc and all the other gubbins) provides an awesome 1st learning environment for people learning C for the first time

Completely free, for students and staff
Traffic light graphical message highlights: Green spots next to messages when things went right, yellow for warnings and red for errors. Instantly understandable!
Graphical indication of the current location in the program with autostep to move step by step through the program - outlines the flow immediately.
Processor window showing the program counter, cycle counter (how much time has your program taken?). Turning ints to floats added 4000 cycles to a simple test program.
Internal processor registers very visible
I/O View graphically highlights ports and pins with a row of 8 squares which are filled when the bit is set. Instant graphical Hex to Binary

I really think that this is an ideal learning environment, not too big and not too small.

Router Resurrection....

2008-09-30T11:22:00.000+01:00

Just fixed a Linksys BEFSR41 v2. Seems that the power brick had a standard cylinder DC plug however the central bore was about 1mm larger than the socket's central pin. I originally thought that I just had a 3rd party powerbrick, however a colleague of mine recognised the router and explained that it was a similar problem for him. Maybe a dodgy batch? Anyway the DC socket was a standard part, the warranty was void through age anyway so a cheap replacement, £1.11, has fixed the problem.

Better than new.

Firefox disrespecting your download preferences on MacOSX?

2008-09-19T08:53:00.000+01:00

On OSX (Apple Macintosh Leopard, 10.5) does firefox ignore your download directory and constantly dump files on the desktop? Does your desktop get incredibly cluttered?

In all likelihood you have updated to the version of OSX you have now. And it has left behind a piece that is ruining your day: ~/Library/Preferences/com.apple.internet.plist

Copy this to your Desktop, download something and test it out. You should suddenly find that the firefox is honoring its preference.

ESSCIRC Summary...

2008-09-19T08:40:00.001+01:00

Sorry for the lack of daily updates. What can I say? Every day was an 8:30 start, finishing at 18:00 sometimes. This is without anyone leaving in the sessions I was in, which if you have ever been to a conference is really unusual.

An interesting combination of academic, student and company presentation. Interestingly the companies typically showed much more finished products.

Anyway it was really well worth the visit (not to mention the whiskey tasting or the visit to murrayfield....)

Cadence Encounter SEGV on start faults cured III

2008-09-18T17:34:00.000+01:00

It is the fonts. I had similar segv crashes using X on windows without the fixed and misc fonts installed. Seems Cadence likes its traditional X client setup. Now I just need to diagnose what font packages I haven't installed / installed in the wrong places.

Day 1 Done

2008-09-16T23:58:00.001+01:00

I particularly liked the plenary Technology Interfacing for Fabless Semiconductor Companies by
Vahid Manian. For those who don't know he works for Broadcom. It was really interesting hearing how they manage their relationships with the CMOS foundries and how much effort they put into owning their own cell libraries and techniques.

More to follow....

Catch up with me at ESSCIRC next week

2008-09-14T19:55:00.000+01:00

ESSCIRC 2008, Edinburgh. I am really looking forward to this conference, and I am meeting up with Cadence and NMI to discuss the Cadence Academic Network. Should be good.

Look out for me with a badge from Southampton University.

Are you and academic and thinking of buying a Xilinx development kit?

2008-09-12T08:54:00.000+01:00

Then I can't plug Digilent enough. They have two very large FPGA boards available for very keen prices. The first is the Xilinx XUP, which is a XC2VP30 Virtex 2 Pro with 2 405PPC cores. This board supports DDR and is a great way to get started with prototyping Gaisler SoC designs. The excellent academic price is only $299! One word of warning: this board doesn't have true SATA ports depite there being connectors and labels saying SATA. They are high speed digital data links that are SATA like but are SATA non-standard and cannot connect to a SATA HDD. No out of band signals.

The second is an uprated ML505. This is identical to the standard Xilinx ML505, but it has a much larger FPGA on it (XC5VLX110T) and comes with a JTAG programmer. The ML505 from Xilinx doesn't. Total price $750.

I have hunted about and the prices here end up hundreds of pounds less than full commercial prices. In the case of the ML505 it is about £300.

Why getting a linksys WRT54GL wireless router is a good idea...

2008-09-12T08:40:00.000+01:00

Basically, the WRT54G router is now on the 8th revision of the hardware and has had it's software updated since it was made. For example the current software set can have its web management software secured with SSL and supports WPA/WPA2, concepts that didn't exist when they started making the model.

Also if you need to do something really special you can remove the stock firmware and replace it with OpenWRT linux, almost limitlessly configurable. One point: the linux compatible version is sold separately these days as the WRT54GL

Just P&R'ed and unconstrained SoC using Cadence Encounter

2008-09-05T11:47:00.000+01:00

Excellent, a LEON3, DDR controller, misc peripherals using a ST Microelectronics 120nm process from CMP. It was badly done, unconstrained and in all likelihood completely non-functional but it is a real start.
Taking it forward:

Verifying the rc generated verilog netlist is functionally correct. Modelsim will work for us here.
Using rc to generate the netlist from two technology files: Low Leakage and High Speed to allow the critical path to run faster.
Generalizing the setup of Encounter such that it fully uses the whole designkit in an easy-to-use package.
P&R'ing a whole SoC.
Verifying the back-extracted layout is fully correct.

Cadence Encounter SEGV on start faults cured II

2008-09-04T15:05:00.000+01:00

New diagnosis: The problem occurs when it attempts to display the window on Fedora Core 8 with or without compiz. I wonder if it ever worked? New cure: SEE LATEST POST ON THIS


xorg-x11-server-Xorg-1.3.0.0-47.fc8
Linux **** 2.6.25.14-69.fc8 #1 SMP Mon Aug 4 14:00:45 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

Dump of problem:


encounter
This version requires license using cdslmd daemon.
Checking out Encounter license ...
SOC_Encounter_GXL 6.2 license checkout succeeded.
INFO: Current OA version selected: OA22
Starting console server on port esdcad4.ecs.soton.ac.uk:8888 ..
sourcing /home/esdcad/software/cadence/linux/soc62_USR4/tools/fe/etc/rdaDSL.tcl
*******************************************************************
*   Copyright (c)  Cadence Design Systems, Inc.  1996 - 2007.     *
*                     All rights reserved.                        *
*                                                                 *
*                                                                 *
*                                                                 *
* This program contains confidential and trade secret information *
* of Cadence Design Systems, Inc. and is protected by copyright   *
* law and international treaties.  Any reproduction, use,         *
* distribution or disclosure of this program or any portion of it,*
* or any attempt to obtain a human-readable version of this       *
* program, without the express, prior written consent of          *
* Cadence Design Systems, Inc., is strictly prohibited.           *
*                                                                 *
*                 Cadence Design Systems, Inc.                    *
*                    2655 Seely Avenue                            *
*                   San Jose, CA 95134,  USA                      *
*                                                                 *
*                                                                 *
*******************************************************************

@(#)CDS: First Encounter v06.20-s285_1 (32bit) 03/20/2008 18:59 (Linux 2.4)
@(#)CDS: NanoRoute v06.20-s222 NR080304-1637/USR54-UB (database version 2.30, 58.1.0) {superthreading v1.10}
@(#)CDS: CeltIC v06.20-s075_1 (32bit) 03/06/2008 22:51:18 (Linux 2.4.21-37.ELsmp)
@(#)CDS: CTE v06.20-s256_1 (32bit) Mar 20 2008 15:56:31 (Linux 2.4.21-37.ELsmp)
--- Starting "First Encounter v06.20-s285_1" on Thu Sep  4 15:05:31 (mem=62.9M) ---
--- Running on esdcad4.ecs.soton.ac.uk (x86_64 w/Linux 2.6.9-78.0.1.ELsmp) ---
This version was compiled on Thu Mar 20 18:59:03 PDT 2008.
Set DBUPerIGU to 1000.
Set Default Mode Capacitance Scale Factor to 1.00
Set Detail Mode Capacitance Scale Factor to 1.00
Set Coupling Capacitance Scale Factor to 1.00
Set Resistance Scale Factor to 1.00
Set net toggle Scale Factor to 1.00
Set Shrink Factor to 1.00000
Encounter terminated by internal (SEGV) error/signal...
*** Stack trace in log file.

Cadence Encounter SEGV on start faults cured

2008-09-04T13:43:00.000+01:00

Problem: On RHEL 4u7 encounter from soc52 and soc62 crashes with a SEGV on run. In the stacktrace are lots of Tcl type errors.

Solution: Install RHEL 3! Seriously, running the most supported OS, in this case RHEL 3, solved the problem.

Cadence rc LEON3 compilation success

2008-09-02T13:03:00.000+01:00

I have just used Cadence SoC's rc (RTL Compiler) to build a verilog netlist of a LEON3 SoC. The estimates are that it would run at 300MHz on a 120nm process.

Now I just need to progress getting it into encounter to start floorplanning. And a large amount of verification and checking that it is valid and correct.

Cadence Physically Knowledgeable Synthesis on solaris

2008-08-28T15:46:00.000+01:00

Running a very old version of cadence pks_shell I decided to play about a bit with the configuration of the two old sun E3500's. Basically the systems are old 6 processor UltraSPARC II's and I had split the memory between them evenly. This turned out to be a very silly thing to do! It meant I didn't take advantage of the fantastically wide interleave available: If I install 4 lots of 1GB then I get a 4 way interleave quadrupling the memory bandwidth. So I am timing the compile again. Unfortunately our Cadence licensing doesn't allow me to share benchmark information, but it is surprisingly quicker.

Final flow looking better already: Cadence rc

2008-08-21T11:58:00.000+01:00

After a lot of checking about it seems SoC Encounter comes with its own RTL compiler which is a lot more modern than our installed version of PKS. It also looks like a lot of the functionality of PKS was pushed into encounter which is the sensible place for it to be. When laying out a modern SoC with IP blocks, analogue and RTL it makes sense to do the floorplanning, clock tree balancing and reordering all in one tool.

Converting Libraries for use in Cadence PKS

2008-08-20T18:37:00.000+01:00

Our designkits (which shall remain unspecified except that you can get some of them from CMP) mainly support Synopsys tools. However we have limited licenses for Design Compiler so to use them in Cadence PKS you can use a nifty little program called syn2tlf. This converts .lib files to .tlf, used by Cadence PKS. What I don't yet know is how to check that the conversion is anywhere near sane.

STmicroelectronic 65nm, 65nm SOI and 45nm Design Kit NDA's Signed

2008-08-13T18:51:00.000+01:00

Never underestimate the time it takes to sign a legal commitment! Finally I found the right person who was able to sign for the University binding us to not revealing secrets and accepting liabilities such that I can now receive the STMicroelectronic Design Kits (Cadence calls them PDK's) from CMP for their 65nm, 65nm SOI and 45nm CMOS processes.

Now to develop several flows including various verification strategies and frontends (Synopsys' Designware, Cadence IC, PrimeTime, etc).

DATE09 TPC Meeting on Wednesday, November the 5th

2008-08-13T18:43:00.000+01:00

The DATE09 (Design, Automation and Test in Europe) TPC (Technical Program Committee) meeting is going to be held at the awesome IET building, Savoy Place, London this year. Wednesday the 5th of November to be precise. For full details refer to the DATE09 TPC website, http://date09-tpc.ecs.soton.ac.uk/.

Update to AHB Slave Shenanigans and Massive Modelsim Migranes

2008-08-12T18:38:00.000+01:00

AHB Slave Shenanigans: The HREADY signal is supposed to be an input from all the other AHB slaves such that they all can note that a slave is hanging the master.

Massive Modelsim Migranes: After a lot of messing about I found out the following solution (for 64 bit linux on amd64 and intel amd64 ext systems):

libhm = $MODEL_TECH/../linux_x86_64/libhm.sl

instead of the libhm.sl line in step 4 of this article from Xilinx. This applies to Modelsim SE 6.3f and the Rocket IO (or Rocket I/O?) module called MGT internally and the SmartModel SWIFT models included in Xilinx ISE9.2i.

UK DVB Channel Numbers for MythDora 5

2008-08-07T09:23:00.000+01:00

Mythtv, for those who don't know, is a very powerful, flexible, PVR tweakers paradise which can be run on top of an existing linux OS or from one of the customised distributions available. The new version of Mythdora, 5, has a really irritating problem: using UK freeview DVB-T it doesn't assign channel numbers as you would expect. So to the rescue is a small mysql script to do just that. The channel numbers come from the awesome DigitalSpy website, one of the best collections of information on transmitted media I have ever come across.

Script:


USE mythconverg;
UPDATE channel SET channum=1 WHERE name='BBC ONE';       
UPDATE channel SET channum=2 WHERE name='BBC TWO';      
UPDATE channel SET channum=3 WHERE name='ITV1';         
UPDATE channel SET channum=4 WHERE name='Channel 4';    
UPDATE channel SET channum=5 WHERE name='Five';         
UPDATE channel SET channum=6 WHERE name='ITV2';         
UPDATE channel SET channum=7 WHERE name='BBC THREE';    
UPDATE channel SET channum=9 WHERE name='BBC FOUR';     
UPDATE channel SET channum=10 WHERE name='ITV3';         
UPDATE channel SET channum=11 WHERE name='SKY THREE';    
UPDATE channel SET channum=12 WHERE name='UKTV History'; 
UPDATE channel SET channum=13 WHERE name='Channel 4+1';  
UPDATE channel SET channum=14 WHERE name='More 4';       
UPDATE channel SET channum=16 WHERE name='QVC';          
UPDATE channel SET channum=18 WHERE name='The HITS';     
UPDATE channel SET channum=19 WHERE name='Dave';         
UPDATE channel SET channum=20 WHERE name='Virgin1';      
UPDATE channel SET channum=21 WHERE name='TMF';          
UPDATE channel SET channum=22 WHERE name='Ideal World';  
UPDATE channel SET channum=23 WHERE name='bid tv';       
UPDATE channel SET channum=24 WHERE name='price-drop tv';
UPDATE channel SET channum=28 WHERE name='ITV4';         
UPDATE channel SET channum=29 WHERE name='E4';           
UPDATE channel SET channum=30 WHERE name='E4+1';         
UPDATE channel SET channum=31 WHERE name='ITV2 +1';      
UPDATE channel SET channum=32 WHERE name='Film4';        
UPDATE channel SET channum=34 WHERE name='SETANTA SPORTS';
UPDATE channel SET channum=35 WHERE name='Five US';      
UPDATE channel SET channum=36 WHERE name='FIVER';        
UPDATE channel SET channum=37 WHERE name='smileTV';      
UPDATE channel SET channum=42 WHERE name='Nuts TV';      
UPDATE channel SET channum=43 WHERE name='Gems TV';      
UPDATE channel SET channum=44 WHERE name='GEMSTV1';      
UPDATE channel SET channum=45 WHERE name='Lottery Xtra'; 
UPDATE channel SET channum=61 WHERE name='TVX / REDHOT'; 
UPDATE channel SET channum=70 WHERE name='CBBC Channel';
UPDATE channel SET channum=71 WHERE name='CBeebies';     
UPDATE channel SET channum=75 WHERE name='CITV';         
UPDATE channel SET channum=80 WHERE name='BBC NEWS';
UPDATE channel SET channum=81 WHERE name='BBC Parliament';
UPDATE channel SET channum=82 WHERE name='Sky News';     
UPDATE channel SET channum=83 WHERE name='Sky Spts News';
UPDATE channel SET channum=87 WHERE name='Community';    
UPDATE channel SET channum=88 WHERE name='Teachers TV';  
UPDATE channel SET channum=100 WHERE name='Teletext';     
UPDATE channel SET channum=101 WHERE name='Ttext Holidays';
UPDATE channel SET channum=102 WHERE name='Rabbit';       
UPDATE channel SET channum=103 WHERE name='TeletextCasino';
UPDATE channel SET channum=104 WHERE name='Teletext on 4';
UPDATE channel SET channum=105 WHERE name='BBCi';
UPDATE channel SET channum=108 WHERE name='Sky Text';     
UPDATE channel SET channum=300 WHERE name='4TVinteractive';
UPDATE channel SET channum=301 WHERE name='301';          
UPDATE channel SET channum=302 WHERE name='302';          
UPDATE channel SET channum=303 WHERE name='303';          
UPDATE channel SET channum=304 WHERE name='tvtv DIGITAL'; 
UPDATE channel SET channum=305 WHERE name='305';          
UPDATE channel SET channum=700 WHERE name='BBC Radio 1';  
UPDATE channel SET channum=701 WHERE name='1Xtra BBC';    
UPDATE channel SET channum=702 WHERE name='BBC Radio 2';  
UPDATE channel SET channum=703 WHERE name='BBC Radio 3';  
UPDATE channel SET channum=704 WHERE name='BBC Radio 4';  
UPDATE channel SET channum=705 WHERE name='BBC R5 Live';  
UPDATE channel SET channum=706 WHERE name='BBC 5L SportsX';
UPDATE channel SET channum=707 WHERE name='BBC 6 Music';  
UPDATE channel SET channum=708 WHERE name='BBC 7';        
UPDATE channel SET channum=709 WHERE name='BBC Asian Net.';
UPDATE channel SET channum=710 WHERE name='BBC World Sv.';
UPDATE channel SET channum=711 WHERE name='The Hits Radio';
UPDATE channel SET channum=712 WHERE name='Smash Hits\!';  
UPDATE channel SET channum=713 WHERE name='Kiss';         
UPDATE channel SET channum=714 WHERE name='heat';         
UPDATE channel SET channum=715 WHERE name='Magic';        
UPDATE channel SET channum=716 WHERE name='Q';            
UPDATE channel SET channum=718 WHERE name='SMOOTH RADIO'; 
UPDATE channel SET channum=721 WHERE name='MOJO';         
UPDATE channel SET channum=722 WHERE name='Kerrang\!';     
UPDATE channel SET channum=723 WHERE name='talkSPORT';    
UPDATE channel SET channum=724 WHERE name='Clyde 1';      
UPDATE channel SET channum=725 WHERE name='Premier Radio';
UPDATE channel SET channum=727 WHERE name='Virgin Radio'; 
UPDATE channel SET channum=728 WHERE name='Heart';

To use it cut and paste the SQL into a text file called channel_num_fix.sql. Then run as root:


/etc/init.d/mythbackend stop
mysql -u mythtv -p < channel_num_fix.sql
/etc/init.d/mythbackend start

2 Potential warnings here: Firstly I get you to stop the backend. I am uncertain that is necessary, however on your own head be it. Also if you have channels not listed I would ensure they are not assigned to a channel number that one of the above channel's want. I don't know what would happen, perhaps nothing bad as each channel has a unique ID as well as its number.

AHB Slave Shenanigans and Massive Modelsim Migranes

2008-08-06T18:41:00.000+01:00

Setting up and running an ARM AMBA bus is not too tricky, and it is quite a neat standard. However in this case my student seems to have copied a rather cunning implementation from Gaisler Research's GRLIB. However the AMBA standard document seems to be rather inconsistent one one point: The HREADY signal is defined to be an input and an output for all AHB slaves, but for the life of me I can't find another mention of it, nor does it seem sensible. I shall consult Prof Flynn who is working here, as he developed AMBA and has worked with it for many years. If you are thinking of making your own GPL'ed AHB slave look no further than the Gaisler Research ahbram.vhd.

Modelsim and smartmodels (specifically the Rocket IO, MGT smartmodel). Good grief, this is a non-trivial procedure. Compile the models, install the models then make lots of opaque changes to the modelsim.ini file and it still doesn't work! Don't know why yet, but will post when I do.

I'm getting a Virtex-5 ML505

2008-08-04T23:10:00.000+01:00

Which, to me is great news. Up till now I have been using the excellent Xilinx XUP board however it has one real failing: the ports labelled SATA on the XUP are not capable of talking to SATA devices. They don't support Out Of Band signalling.

The Virtex-5 LXT based ML505 however does support the full SATA specification, as well as a lot of others besides. The reason is more advanced Rocket IO ports.

Back from holiday....

2008-07-28T15:28:00.001+01:00

Spent a lovely week with my wife and other close family in the south west of England, all the way down to the Lizard Peninsula.

I get to attend the IDESA "Advanced Digital Physical Implementation flow" Course

2008-07-28T15:18:00.000+01:00

IDESA is intended to kickstart the production of both analog and digital <=90nm CMOS among academia. I have got a place on the Advanced Digital Physical Implementation flow course hosted by Rutherford Appleton Laboratories in Didcot, Oxfordshire (the courses are available from other host institutions as well). The week looks very interesting:

Day 1: Intro, design environment and toolchain + LAB
Day 2: Leakage aware design and prevention, floorplanning LAB, design planning and libraries (including IP, soft and hard).
Day 3: Low power flow including positioning to minimise dynamic and leakage power, physical synthesis placement and optimisation. Multiple Clock Tree Synthesis.
Day 4: Physical Synthesis, Design for Test, Multimode and Multicorner, Routing to GDSII and labs.
Day 5: IR drop analysys, dynamic power analysis, on chip validation and statistical static timing analysis. Lab on signoff, signoff and design finishing and layout verification. Tape-out.

Anyway I am keen to angle my way onto other courses of this quality that are on offer.

Need a SPARC version of "ARM System-on-chip Architecture"

2008-07-17T22:42:00.000+01:00

"ARM System-on-chip Architecture", by Steve Furber is an excellent book for anyone wanting to get an OS or other software running well on the ARM range of microprocessor cores. Now if there is an equivalent for SPARC architectures please let me know as that is the current problem I am facing!

Coursework for Academics....

2008-07-17T20:19:00.000+01:00

We are now discussing the changes to the courses for next academic year. The main push on at the moment is directed at enhancing our teaching of software to the electronics undergraduates.

COMP1010 Big changes here to alter how we teach this module. The previous course centered on teaching as much C as possible using Visual Studio, with a lab a week reinforcing the lecture topic. To improve things by engaging the students more we are moving a lot of the C syntax and content into the semester 2 course. This leaves room for the introduction of AVR microcontrollers along with a bit of computer architecture. Hopefully this will engage the students immediately. The programming will be done in AVRStudio with WinAVR as the compiler. The assessment will be significantly changed to favour two "Exam Labs" which will be open book individual assessments. The first will have a lot of direction and the second will be solving a problem. Appropriate assessment of any course is essential for its success, and I personally belive in problem based learning as one of the most enjoyable and effective techniques.

ELEC1013 The main change here is the labs have been shortened and there will be more of them. There is also an open question whether to include an AVR Microcontroller that can be used over USB or networked to encourage the Computer Science students who take this course to mess about with gadgets.

Do the multipathing first, and the mirroring afterwards!

2008-07-15T16:54:00.000+01:00

If you are using a mirrored root under Disksuite and wish to enable mpxio I wish you well. It is a devil of a job, mainly due to the fact that stmsboot won't recognise your metadevice as a STMS device and so won't enable it.

So to fix it here is the answer:

Back everything up. EVERYTHING
Follow the guide here to undo the mirrored root
Run stmsboot -e and reboot immediately
Everything should now be correctly multipathed using mpxio
Rebuild all the mirrored root and other devices

and next time, do the multipathing first and the mirroring afterwards!

Adding a package called "leon-bootloader" to Angstrom

2008-07-15T11:03:00.000+01:00

I wonder how to handle this. Typically Angstrom downloads source packages from the internet as needed, however in this case the bootloader is never supplied as a separate download. Downloading and extracting snapgear linux to get at it doesn't appeal, neither does distributing it by myself. I am also uncertain whether Angstrom would accept a complete source package in their download system for such a niche market.

Imagination Technologies Visit

2008-07-10T17:48:00.000+01:00

I have just had the pleasure of hosting some representatives of Imagination Technologies.

It was a productive day, and I am looking forward to some really interesting projects and cooperation coming our way.

Writing Referral Exam Questions

2008-07-08T10:01:00.000+01:00

Unfortunately not all students pass the exam, and this is their second chance. History suggests that some will work very hard and do well, and some will (despite hard work in some cases) not. In many ways this is quite a difficult part of being an academic - assessment.

The LEON3 sparc linux bootloader generation process is awful

2008-07-04T16:18:00.000+01:00

Uses a combination of make and perl scripts reading from a global config.
Includes including includes including includes.
Variables drawn directly from .config files and the aforementioned headers, some of which are written by perl scripts driven from variables as above.
Uses gcc to edit a text file and then calls the result a .o (it is plain ASCII) after hardcoding all of the paths.

I either choose to sanitise this system, or just package it and gingerly push options in its general direction. It is also unclear what license it is under, however as it is part of a linux distro build process I believe that puts it under the GPL whether it is explicit or not.

Broken DDR DIMM replaced, now to continue..

2008-07-04T16:17:00.001+01:00

Replaced the broken DDR DIMM (which has a lifetimes warranty) and now to get on with things.

Trouble! Things that were working just fine, now are not

2008-07-04T11:58:00.000+01:00

Basically the system now claims it cannot see the DDR! Which is a blow. I don't know why but I am getting the dreaded 'stack pointer not set' errors and the system doesn't seem to think it has any memory. I am wondering if I need to add in a bit more manual deskewing or whether I have actually broken something (I certainly hope not!).

More to follow....

Booted the Kernel built by Angstrom on LEON3

2008-07-03T22:32:00.001+01:00

... but not the ramdisk. I seem to be having trouble with it at the moment. I shall investigate it properly tomorrow. Perhaps I haven't got enough RAM enabled, which can be a real problem apparently. Kernel hangs if you run out without error messages.

Just to be clear: I took the kernel from snapgear linux. I just created a single large patch against vanilla 2.6.21.1. The patch is quite large and I didn't want to care about such things.

However the version of glibc and the compiler are completely different. I don't yet know if this is going to cause stability problems, but I can just constrain Angstrom to use the right versions from the snapgear toolchain. Such is the power of OpenEmbedded.

Angstrom building for SPARC

2008-07-03T20:59:00.001+01:00

By poaching files and diffs from snapgear, Angstrom is merrily building away.

Slowly debugging issues and learning more than I ever wanted to know about the linux boot process.
Issues:

Does it work? Angstrom at the moment is building with gcc4 not 3.
Are there necessary glibc patches? If so I haven't done anything to apply any.
I need to fix the ramdisk builds.
Will udev work?

Anyway, off home now!

Beginning work on modifying angstrom...

2008-07-03T17:08:00.000+01:00

Seems that point 1 from below is already taken care of! Angstrom is setup for a sun4cdm with a supersparc CPU. I am building it now and hope to take care of packaging it for use in TSIM and GRMON as an image etc. (not that I have TSIM unfortunately).

Snapgear Linux or Angstrom..

2008-07-03T09:13:00.000+01:00

I am currently building and deploying Snapgear linux onto a LEON3 system aboard a xilinx-xup board. However I have several issues with Snapgear:

Despite all the hard work that has gone into it, it feels poorly constructed. I think they are discovering just how hard it is to maintain and build embedded linux distros. I am thinking of the early days of OpenZaurus
Functionality that just doesn't work out of the box: dhclient, openssl, ssh and sshd. Pretty fundamental tools here. Not to complain about the good work of uCdot

I think I shall try to get Ångström up and running as it is much better at handling these things. The main effort will be:

Toolchain. Assembling the patches and CFLAGS etc for the toolchain (glibc in the first instance).
Backend: Packaging the system such that it will be able to build images for the various GR tools.

Further posts will follow as I address these issues. Overall I think it is more valuable than fixing problems in Snapgear.

A brand new XUP board is sitting on my desk...

2008-06-30T17:31:00.000+01:00

... and even better it doesn't have the old jtag programmer onboard so it works with GRMON! So much better than the serial debug system I was using before. It programs about 10 times faster for a start.

Where to go from here: System C + Hardware/Software Codesign?

2008-06-30T13:29:00.000+01:00

The GRLIB components and tools by being GPL'ed and available in VHDL form are a serious attraction for Hardware/Software Codesign.

It isn't quite clear yet how usable/possible this will be, but it would allow us access to real, selectable hardware examples. Quite a proposition.

MSc Projects offered...

2008-06-27T14:47:00.000+01:00

I have offered the following MSc projects:

Remove the LEON3 core and substitute an OpenSPARC (possibly the single core, wishbone compatible variant).
Build a SATA controller
Explore the LEON3 GRLIB design space on ASIC and FPGA (i.e. how fast, how big, etc)
Build an AHB parallel port (high speed, of course. Maybe a bit of a ram buffer?)
Enable the Xilinx-XUP board's CF card to program the FPGA, install a boot loader and boot linux.

They are all different vairants of tricky, with 5 probably a real problem in disguise. I think it would be best for the boot loader to be part of the FPGA (i.e. a 1k ROM or similar) to boot off the CF card.

Linux successfully executed!

2008-06-26T05:22:00.001+01:00

Here is the first console dump of my executing linux session (the image.dsu was borrowed from the theora project). I shall have to consider that a success. Now onto the stickier proposition of how to boot and execute from a flash card using the xilinx-xup board. I am thinking of using systemACE to package the kernel and bitfile, and then targetting a linux partition on the CF card. It all depends if system ACE can actually put things into RAM, but I believe it can look like FLASH to the FPGA so all should be alright.

M:\GRMON\win32>grmon-eval.exe -uart //./com8 -ibaud 250000 -u -nb

GRMON LEON debug monitor v1.1.29 (evaluation version)

Copyright (C) 2004,2005 Gaisler Research - all rights reserved.
For latest updates, go to http://www.gaisler.com/
Comments or bug-reports to support@gaisler.com

This evaluation version will expire on 15/10/2008
try open device //./com8
###opened device //./com8

GRLIB build version: 2950

initialising ..............
detected frequency: 80 MHz

Component Vendor
LEON3 SPARC V8 Processor Gaisler Research
AHB Debug UART Gaisler Research
AHB Debug JTAG TAP Gaisler Research
GR Ethernet MAC Gaisler Research
AHB ROM Gaisler Research
AHB/APB Bridge Gaisler Research
LEON3 Debug Support Unit Gaisler Research
DDR266 Controller Gaisler Research
Generic APB UART Gaisler Research
Multi-processor Interrupt Ctrl Gaisler Research
Modular Timer Unit Gaisler Research
Keyboard PS/2 interface Gaisler Research
Text-based VGA controller Gaisler Research
Keyboard PS/2 interface Gaisler Research

Use command 'info sys' to print a detailed report of attached cores

grlib> load M:\Downloads\image.dsu
section: .stage2 at 0x40000000, size 10180 bytes
section: .vmlinux at 0x40004000, size 1232960 bytes
section: .rdimage at 0x40148f94, size 1598828 bytes
total size: 2841968 bytes (88.3 kbit/s)
read 3706 symbols
entry point: 0x40000000
grlib> run
Booting Linux
Booting Linux...
PROMLIB: Sun Boot Prom Version 0 Revision 0
Linux version 2.6.21.1 (root@brazilip-tec) (gcc version 3.2.2) #16 Mon Aug 20 19
:32:42 BRT 2007
ARCH: LEON
Vendors Slaves
Ahb masters:
0( 1: 3| 0): VENDOR_GAISLER GAISLER_LEON3
1( 1: 7| 0): VENDOR_GAISLER GAISLER_AHBUART
2( 1: 1c| 0): VENDOR_GAISLER GAISLER_AHBJTAG
3( 1: 1d| 0): VENDOR_GAISLER GAISLER_ETHMAC
Ahb slaves:
0( 1: 1b| 0): VENDOR_GAISLER Unknown device 1b
+0: 0x0 (raw:0x3fff2)
1( 1: 6| 0): VENDOR_GAISLER GAISLER_APBMST
+0: 0x80000000 (raw:0x8000fff2)
2( 1: 4| 0): VENDOR_GAISLER GAISLER_LEON3DSU
+0: 0x90000000 (raw:0x9000f002)
3( 1: 25| 0): VENDOR_GAISLER Unknown device 25
+0: 0x40000000 (raw:0x4003c002)
+1: 0xfff00100 (raw:0x10fff3)
Apb slaves:
0( 1: c| 2): VENDOR_GAISLER GAISLER_APBUART
+ 0: 0x80000100 (raw:0x10fff1)
1( 1: d| 0): VENDOR_GAISLER GAISLER_IRQMP
+ 0: 0x80000200 (raw:0x20fff1)
2( 1: 11| 8): VENDOR_GAISLER GAISLER_GPTIMER
+ 0: 0x80000300 (raw:0x30fff1)
3( 1: 7| 0): VENDOR_GAISLER GAISLER_AHBUART
+ 0: 0x80000400 (raw:0x40fff1)
4( 1: 60| 5): VENDOR_GAISLER GAISLER_KBD
+ 0: 0x80000500 (raw:0x50fff1)
5( 1: 61| 0): VENDOR_GAISLER GAISLER_VGA
+ 0: 0x80000600 (raw:0x60fff1)
6( 1: 60| 4): VENDOR_GAISLER GAISLER_KBD
+ 0: 0x80000700 (raw:0x70fff1)
7( 1: 1d|12): VENDOR_GAISLER GAISLER_ETHMAC
+ 0: 0x80000b00 (raw:0xb0fff1)
TYPE: Leon2/3 System-on-a-Chip
Ethernet address: 0:0:0:0:0:0
CACHE: direct mapped cache, set size 8k
Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz). Patching kerne
l for srmmu[Leon2]/iommu
64MB HIGHMEM available.
node 2: /cpu00 (type:cpu) (props:.node device_type mid mmu-nctx clock-frequency
uart1_baud uart2_baud )
PROM: Built device tree from rootnode 1 with 918 bytes of memory.
DEBUG: psr.impl = 0xf fsr.vers = 0x7
Built 1 zonelists. Total pages: 64302
Kernel command line: console=ttyS0,38400 init=/sbin/init
PID hash table entries: 1024 (order: 10, 4096 bytes)
Todo: init master_l10_counter
Attaching grlib apbuart serial drivers (clk:80hz):
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 252736k/262144k available (968k kernel code, 9244k reserved, 112k data,
116k init, 65536k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1561k freed
highmem bounce pool size: 64 pages
io scheduler noop registered
io scheduler cfq registered (default)
grlib apbuart: 1 serial driver(s) at [0x80000100(irq 2)]
grlib apbuart: system frequency: 80000 khz, baud rates: 38400 38400
ttyS0 at MMIO 0x80000100 (irq = 2) is a Leon
Loading theora ...
LEON THEORA driver by Andre Costa (2007) - andre.lnc@gmail.com
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
RAMDISK: Compressed image found at block 0
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 116k freed
init started: BusyBox v0.60.5 (2007.08.04-05:15+0000) multi-call binary
Shell invoked to run file: /etc/init.d/rcS
Command: #!/bin/sh
Command: mount
Please press Enter to activate this console.
Interrupt!
stopped at 0xf00140d0
grlib>

Just benchmarked my first LEON3

2008-06-25T11:07:00.001+01:00

29.8 Dhrystones MIPS! This is an 80MHz LEON3 system with no FPU. Onwards, to linux!

Just connected to my first LEON3 SoC

2008-06-23T18:10:00.000+01:00

... via the JTAG debugger but I am still unable to drive the DDR due to the lack of DCM modules in this particular Xilinx. I am now turning my attention to the XUP board from Digilent as they are quite common around here.

Hopefully I shall get further down that road towards the goal of booting linux on the system....

Trouble with the ML403...

2008-06-20T21:03:00.001+01:00

Heh, should have realised it wouldn't be that easy...

Basically the ML403 differs from the ML401 & 2 by the fact that they both their Virtex-4's have 8 DCMs as opposed the 403's 4, and the LEON3 core with a DDR controller (necessary for the built in DDR memory) needs 5. It took a surprisingly long time for me to realise that's what the error message meant. Still today has been quite productive with a lot of lessons learnt.

Another lesson is that Xilinx ISE on windows will rebuild a Xilinx ISE on linux project, meaning the 20 minutes I took building and routing the first design came to nothing, as the windows machine proceeded to take about 60 minutes to perform the same task.

Linux Tomorrow

2008-06-18T23:38:00.001+01:00

I am borrowing a Xilinx ML403 board over breakfast (in exchange for some copper pipe) so I should be testing Linux on LEON3 tomorrow. I have also provided my MSc students a tutorial getting them off the ground in messing with GRLIB which I really need to write up in our knowledgebase.

grlib is proving quick to get off the ground, I just hope it proves easy to customize too.

GRLIB now compiling in ModelSim

2008-06-18T08:31:00.001+01:00

After some silliness with the configuration stages GRLIB is now up and running.

First thing to do is informal validation tests against the various FPGA compilation tools we have available to see what produces working code, smallest/fastest etc.

Secondly I need to download Snapgear's linux for LEON3 and examine it for correctness / niceness. I might even port the patches into Angstrom and use that as a base depending on what I find.

Final block of marking done....

2008-06-15T20:18:00.000+01:00

Phew, glad that is over. Just got to set my MSc's going on their dissertations and help my Part III students get into and motivated over their projects.

I have given this lot of students as much feedback as I can, in an effort to improve things. A mark without comments is pretty pointless.

Platform express flow problems..

2008-06-15T11:40:00.001+01:00

Interesting, we can get hold of Mentor's Platform Express from mentor, but not the seamless cve product that we need to simulate cores. That being said, GRLIB is looking like the only option at the moment.

Pity, however we may be able to extract a processor that we can trivially wrap for the Synopsys tool. ARMs have to be hardwired into IRQs and their bus selects however, which GRLIB seems to approach differently.

GRLIB on its own will probably be the best way, which is a pity as I think the Synopsys tools are great. Without a core and a bunch of licenses however we are not going to get very far.

Wanted: Alternatives to Design Compiler

2008-06-15T07:01:00.000+01:00

There are only two synopsys licenses, which is far too few to teach with. I shall talk to Synopsys to see if I can get some more from them for teaching purposes.

As we have lots of Mentor licenses I shall investigate their products more.

LEON3 as a core until we get an ARM

2008-06-14T17:08:00.000+01:00

The SPARC v8 LEON3 and the associated GRLIB should fit in the planned teaching I have in mind:

http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=13&Itemid=53

It is what we needed: A core! It is also GPL licensed so we are legally entitled to and might be able to crack it open to better teach cache controllers and DMA controllers.

esdsun4 now running

2008-06-12T22:24:00.000+01:00

We are still using two old solaris workhorses: esdsun3 and esdsun4. Both are Enterprise 3500's with 6x 400MHz USII with 8MB of cache and a bunch of FCAL HDDs. Just got the second one working. What it troubling is that they are not much slower (if at all) than the V210's we have. Contrasting enterprise kit (old) with new budget kit doesn't reveal that many differences.

I am now Master of Masters!

2008-06-12T22:01:00.001+01:00

Not as cool as it sounds, but I hope to do a good job. I now organize and manage the MSc summer projects.

Success targetting coreAssembler on FPGA

2008-06-12T03:57:00.000+01:00

Just instantiated an AMBA bus structure into a cyclone III FPGA from Altera. Toolchain was a bit of a pain but most of that now sorted out. Now in a position to make arbitrary bus and peripheral structures. Just need cores now. And some form of memory.

coreAssembler -> Designware Compiler -> Quartus II

What a productive night.

Designware Compiler being difficult...

2008-06-11T19:45:00.000+01:00

Trying to use Designware compiler to build for altera FPGAs.

Quartus II supplies the needed db files, however it doesn't seem to be consistent! I can't make any small designs, but I have successfully built a large AMBA structure for a cyclone II. Trouble is the libraries are rated as compatible with designware compiler 2004, not 2007.

The compiler dies with an internal error and a stack-dump. Will try driving design compiler by hand first to get more design information.

Sun saga continues

2008-06-10T17:55:00.001+01:00

Tried my cunning plan. Completely failed to work.

New plan:

Install Sol9 and StorageTek SAN from scratch: a
Now all I have to do is:

change vfstab
change boot in eeprom
boot to new disks
move fiber
setup mirrored root
.....
profit!!!!

Servicing Suns

2008-06-09T16:52:00.000+01:00

I am trying to boot one of our cad servers from half of a mirror pulled from the other half. Predicatably it is being difficult, however if I want to preserve the exact setup I am at a loss how else to do it.

Still I think I am a sucker for punishment. Installing from scratch may, eventually, be the way to go from here.

The first batch of real exam marking this year

2008-06-09T14:20:00.000+01:00

I have several thoughts for essential exam marking equipment:

A stamp with a large red `?'
Calming tablets

You need 1 when a student does a brain dump or creates an unconnected string of words. You need 2 when your paranoia increases as a student returns an answer that matches your perfect one. Luckily either extreme is rare, however they typically dominate the whole script.

First Post!

2008-06-09T14:11:00.000+01:00

Heh, be warned, the humour of the above post is what you are likely to encounter here....