Re: 'virtual HW' into kernel (SystemC)

From: linux-os (*** Johnson) (linux-os_at_analogic.com)
Date: 09/07/05

  • Next message: Christoph Hellwig: "Re: [PATCH] add romfs_get_size()" 
    Date:	Wed, 7 Sep 2005 10:59:54 -0400
To: "Benjamin LaHaise" <bcrl@kvack.org>

    On Wed, 7 Sep 2005, Benjamin LaHaise wrote:

    > On Wed, Sep 07, 2005 at 12:31:07PM +0200, Màrius Montón wrote:
    >> At this point, we plan to develop a pci device driver to act as a bridge
    >> between kernel PCI subsystem and SystemC simulator (in user space).
    >>
    >> Do you think this implementation is fine? Maybe it's better to register
    >> a new bus
    >> subsystem and link to a daemon to user space to run SystemC simulations?
    >> We are open to any idea or suggestion about it.
    >
    > That's actually quite a difficult approach to take as you aren't able to
    > fully simulate how the hardware interacts with the system, making concerns
    > like timing very difficult to accurately model. A better approach is to
    > tie into a full system simulator -- qemu makes it very easy to add a new
    > pci device into the system. This way your hardware simulator doesn't have
    > to worry about the complexities of kernel programming, and the resulting
    > device drivers doesn't need hooks for the simulator as it would see the
    > pci device as if it were installed in a system.
    >
    > Btw, do you know of any inexpensive ways to be introduced SystemC
    > development on FPGAs? Cheers,
    >
    > -ben

    Writing drivers for an emulated hardware environment probably
    won't work because the eventual hardware won't match the
    emulation. If you are serious about concurrent development,
    i.e., writing software while a device is being designed, I
    have some free advice grabbed from a PPT presentation I
    made a few years ago.....

    The ten steps to writing software for hardware in the
    development phase.

    (1) Get the hardware people to define their interface chips.
    (2) Get the hardware people to define their register maps.
    (3) Get the hardware people to define the function of the entire board.
    (4) Get the hardware people to sign off on a written document.
    (5) Write an interface specification (API to driver).
    (6) Write some test-code to that API.
    (7) Write a driver that interfaces with the API and pretends to
          interface with the hardware. Make damn sure that runs first.
          The hardware is emulated with some address-space that your
          driver allocated.
    (8) Write some kind of "debugger/monitor" that allows a user,
          from a user program, to read and write hardware registers
          of the target device through your driver. If you do this
          for a living, use the same program you wrote years ago for
          your first driver (with any new functionality you might need
          for the present one). Leave that new functionality for the
          next project.
    (9) Replace stubs in the emulator code with real functioning
          code. In the absence of hardware, make sure that nothing
          ever "waits forever". Good drivers will work with bad and
          even non-existent hardware. To a driver, a hardware error
          is just an event, handled just like any other kind of event.
          There cannot be any "fatal" errors in drivers.
    (10) When the hardware arrives, help debug it with your ready-
          made debugger/monitor after you have gotten the interface
          code to work (PCI perhaps). You will have the opportunity to
          fix bugs in your driver while getting credit for fixing
          hardware, perhaps FPGA, bugs.

    The first 5 paragraphs are the hardest. Hardware Engineers often
    don't like to commit themselves to anything as specific as a
    register map. Sometimes you have to force them to do this work
    because certain hardware engineers are used to blaming a late
    or non-working project on "software". This gives them time
    to fix the broken hardware while pointing fingers at some other
    department.

    Cheers,
    *** Johnson
    Penguin : Linux version 2.6.13 on an i686 machine (5589.51 BogoMips).
    Warning : 98.36% of all statistics are fiction.

    ****************************************************************
    The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

    Thank you.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Christoph Hellwig: "Re: [PATCH] add romfs_get_size()"
    Loading