Hello all,
I'm a PhD student and I'm focusing on HW/SW co-design.
First of all, a brief introduction to problem:
Nowadays, we can use C++ libraries, called SystemC, to describe HW
behavior, and synthesize with commercial tools.
A SystemC description can be simulated using its own simulator kernel,
and we can indeed wrap a module with its simulator kernel into a C++
class, so we can use it as a 'normal' C++ code...
Our main problem now appears: if we develop a PCI device using SystemC
we cannot start to develop and test the device driver until we have a
real prototype,
and hence, we cannot test our HW with SW.
Our proposal is to develop a set of tools (kernel module, daemon, ...) in
order to use a SystemC model of HW as a virtual device.
With this set of code, when we have SystemC description finished (and
only SystemC code, nor prototype, nor real HW), we will able to start
developing driver, and testing our "virtual HW" with complete SW suite.
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.
Thanks,
M?rius
http://mariusmonton.name
http://cephis.uab.es
M?rius Mont?n wrote:
> Hello all,
>
> I'm a PhD student and I'm focusing on HW/SW co-design.
>
> First of all, a brief introduction to problem:
> Nowadays, we can use C++ libraries, called SystemC, to describe HW
> behavior, and synthesize with commercial tools.
>
> A SystemC description can be simulated using its own simulator kernel,
> and we can indeed wrap a module with its simulator kernel into a C++
> class, so we can use it as a 'normal' C++ code...
>
> Our main problem now appears: if we develop a PCI device using SystemC
> we cannot start to develop and test the device driver until we have a
> real prototype,
> and hence, we cannot test our HW with SW.
>
> Our proposal is to develop a set of tools (kernel module, daemon, ...) in
> order to use a SystemC model of HW as a virtual device.
>
> With this set of code, when we have SystemC description finished (and
> only SystemC code, nor prototype, nor real HW), we will able to start
> developing driver, and testing our "virtual HW" with complete SW suite.
>
> 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).
No need for a set of tools. As long as your SystemC simulator simulates
an entire platform -- CPU, DRAM, etc. -- then you can boot Linux on the
simulated platform.
If you can boot Linux on the simulated platform, then you can easily
develop a Linux driver long before real HW is available.
Jeff
On Wed, Sep 07, 2005 at 07:40:41AM -0400, Jeff Garzik wrote:
> No need for a set of tools. As long as your SystemC simulator simulates
> an entire platform -- CPU, DRAM, etc. -- then you can boot Linux on the
> simulated platform.
Even if it doesn't, hooking SystemC into something that does boot
Linux such as qemu strikes me as a much easier approach than modifying
a kernel running on bare metal to also use "virtual" hardware.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
09/07/2005 01:40 PM, Jeff Garzik wrote/a écrit:
> 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).
>
>
> No need for a set of tools. As long as your SystemC simulator simulates
> an entire platform -- CPU, DRAM, etc. -- then you can boot Linux on the
> simulated platform.
>
> If you can boot Linux on the simulated platform, then you can easily
> develop a Linux driver long before real HW is available.
No, this approach is not feasible because it would be require to
describe the entire computer in SystemC: it's extremly complex to do and
the simulation will be very slow.
From what I understand Màrius tries to only simulate one component
(like a PCI card). As suggested Muli, a plugin to something like quemu
sounds like a good idea?
Eric
Eric Piel wrote:
> 09/07/2005 01:40 PM, Jeff Garzik wrote/a écrit:
>> No need for a set of tools. As long as your SystemC simulator
>> simulates an entire platform -- CPU, DRAM, etc. -- then you can boot
>> Linux on the simulated platform.
>>
>> If you can boot Linux on the simulated platform, then you can easily
>> develop a Linux driver long before real HW is available.
>
>
> No, this approach is not feasible because it would be require to
> describe the entire computer in SystemC:
Correct.
> it's extremly complex to do
Not if you can reuse pre-existing parts from http://www.opencores.org/
and similar places.
> the simulation will be very slow.
Depends on your simulator ;-)
> From what I understand Màrius tries to only simulate one component
> (like a PCI card). As suggested Muli, a plugin to something like quemu
> sounds like a good idea?
A plugin to qemu or Bochs should work, in theory. In practice, neither
are great for PCI MMIO or PCI DMA.
Jeff
All suggestions are good, but from my point of view, both solutions
(entire simulated system, or using an emulator) could be too slow and
too much artificial, so in translation to 'real world' can be a lot of
problems.
I think our approach is the most real environment for our SystemC module.
We will try to implement in this way, so any hints here will be appreciated.
Thanks
Màrius
Jeff Garzik wrote:
> Eric Piel wrote:
>
>> 09/07/2005 01:40 PM, Jeff Garzik wrote/a écrit:
>>
>>> No need for a set of tools. As long as your SystemC simulator
>>> simulates an entire platform -- CPU, DRAM, etc. -- then you can boot
>>> Linux on the simulated platform.
>>>
>>> If you can boot Linux on the simulated platform, then you can easily
>>> develop a Linux driver long before real HW is available.
>>
>>
>>
>> No, this approach is not feasible because it would be require to
>> describe the entire computer in SystemC:
>
>
> Correct.
>
>> it's extremly complex to do
>
>
> Not if you can reuse pre-existing parts from http://www.opencores.org/
> and similar places.
>
>
>> the simulation will be very slow.
>
>
> Depends on your simulator ;-)
>
>
>> From what I understand Màrius tries to only simulate one component
>> (like a PCI card). As suggested Muli, a plugin to something like
>> quemu sounds like a good idea?
>
>
> A plugin to qemu or Bochs should work, in theory. In practice,
> neither are great for PCI MMIO or PCI DMA.
>
> Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Màrius Montón i Macián [email protected]
<mailto:[email protected]> http://microelec.uab.es/~marius
<http://microelec.uab.es/%7Emarius>
Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534
Fax: +34 935 813 033
QC2088. ETSE. Campus UAB.
080193 Bellaterra
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
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,
Dick 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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
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.
>
True, but our plan is to develop a module to wrap PCI comunication,
bypassing northbridge driver and PCI IP-core:
Application <-> our driver <-> kernel PCI-subsystem <-> our link <->
daemon <-> SystemC simulator.
Our link and our daemon get all PCI communication, and interface to
SystemC simulator.
Is that so complex to develop?
Also, we want to validate functional behavior, not timming. But we need
to validate entire funcionality, so we think an emulator won't be
accurate enough.
> 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,
>
>
We are using Cynthesizer by ForteDS with a educational license. This
tool generates Verilog from SystemC. we are in troubles mapping this
verilog to FPGAs, due to libraries problems (a fix for that is using
ASIC libraries and then remap them to FPGA), but they said us new
version (3Q2005) will support FPGAs.
> -ben
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
--
M?rius Mont?n i Maci?n [email protected]
<mailto:[email protected]> http://microelec.uab.es/~marius
<http://microelec.uab.es/%7Emarius>
Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectr?nica i Sistemes Electr?nics
ETSE - Universitat Aut?noma de Barcelona (UAB) Phone: +34 935 813 534
Fax: +34 935 813 033
QC2088. ETSE. Campus UAB.
080193 Bellaterra
On Mer, 2005-09-07 at 12:31 +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).
The first thing that would worry me about such an architecture would be
deadlocks between user space and kernel PCI accesses trapped under
simulation.
If you take a look at Xen or qemu both would give you a way to run the
virtualised simulated device in Linux user space on a sane complete
Linux environment while running a seperate copy of Linux experiencing
the simulated device.
Xen is fast - very fast, qemu is somewhat slower but because it is a JIT
can do accurate tracing and has a lovely well designed API for adding
virtualised drivers, plus nice examples like video cards and a virtual
NE2000.
Alan
Mikael Starvik wrote:
>>Application <-> our driver <-> kernel PCI-subsystem <-> our link <->
>>daemon <-> SystemC simulator.
>>
>>
>
>
>
>>Our link and our daemon get all PCI communication, and interface to
>>SystemC simulator.
>>Is that so complex to develop?
>>
>>
>
>No, not really. I've implemented a link like this
>
>Application<->driver<->our link<->daemon<-TCP/IP->glue<->Verilog simulator
>
>In your case I would probably implement a "fake" PCI bridge that forwards any PCI access to you daemon and puts the requesting process to sleep until the request has been processed. Some drivers may of course break due to the latency.
>
>Our link is a kernel module that queues up requests from the driver and deliver them to the daemon through a poll/read interface. Each process that make a request is put to sleep until the request has been answered by the dameon. A couple of days of development. A bit more in your case due to the fake PCI bridge (yes, I have implemented one of those as well for cardbus).
>
>Regards
>/Mikael
>
>
>
Can you send me or post your code?
This code can be a good starting point for us.
Thanks
Màrius
>
>
>
>