[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tr:Rep:Re: [f-cpu] "Tree"

On Thu, 10 Jan 2002, Kim Enkovaara wrote:
> I think biggest problem with SystemC style approach is that it is quite
> different compared to the real design process of many products. It's quite
> academic thinking that the product is first defined with some system
> language and only after that the implementation starts. 

Yes, up to now you are right. But does it need to be like this?

> For example if the product has an ASIC the ASIC design starts quite much
> before other designers even know about the product. ASIC design usually
> takes that 1.5-2 years. USW/higher level SW guys are still in their old
> projects during the start of ASIC phase. And ASIC is the critical path
> usually in products. If you design the system at system SW level before
> ASIC project it usually means substantial amount of system level code.
> Even if that code is directly usable in the end product the TTM is longer.
> ASIC project can be started later because the system description takes so
> long time. On the other hand if the ASIC is specified in done
> with traditional means and system SW design for example starts at the same
> time, time is saved.

I rather have the opinion that after the chip is ready and the
software starts to use it the problems show up - 2 years lost.
And imagine - who can spend more than 2 years time to market?
After 2 years time the premiss may have changed completely.
Some ASICs were cancelled right when they were finished and

> I think the real question is can the time used in system interface
> optimization saved in later stages of design. Usually competent designers
> can do quite good HW/SW interface (fortunately this list has HW guys :)).
> Can you really save the time needed to fix some HW quirks in SW by using
> much more time to design the interface.

Why use more time? If one has HW quirks either the definition
was sh.. or one has overlooked something fundamental or one
tried to save time from simulation (pressing schedule).
And - and that is my biggest concern - one didn't know how
the software will use the interface later.

If you look at e.g. IDTs 79RC32355 or NECs uPD98501 they both
have the errata that you can't use transmit queues for ethernet.
You have to individually setup every frame for transmission.
This one can only happen if the simulation does not have a real
driver for the device and/or few simulation time.


To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/