CPLD/FPGA, software and 10 years support

On Wednesday, in article
     <4B82h.22186$j4.16516@newsfe1-win.ntli.net>
     hans64@ht-lab.com "Hans" wrote:

>Hi Paul,
>
>Not sure if anybody mentioned it but I would also have a look Actel (e.g. 
>APA/A3E devices). Because they support military/avionics their devices are 
>not EOL'd so quickly, also some of their largest devices are available in 
>PQ240.

Well it looks like some of the devices could do the job, but my quick look
and the software seems a minefield of different applications and no real
software overview (or even where it get device specific). Seeing thrid
party support tools with Cadence and Mentor, gets scary on a very low
production run ...

>Just a thought,

Appreciated and looking at everyone's suggestions as a broad search helps
especially when I might not have experience of some vendors' tools, or best
ways to obtain them.

>Hans.
>www.ht-lab.com
>
>
>"Paul Carpenter" <paul$@pcserviceselectronics.co.uk> wrote in message 
>news:20061101.1341.321856snz@pcserviceselectronics.co.uk...
>>I know others here have to deal with long life time support of designs, and 
>>I
>> have one where I ahev to also supply the tools (free or paid) so that 
>> customer
>> can support in at least 10 years time. The trouble is the design 
>> necessitates
>> a PLD/CPLD/FPGA, so the requirements get quite onerous....
>>
>> Device
..

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

On 1 Nov, in article
     <1162419522.633119.300890@e3g2000cwe.googlegroups.com>
     me@linnix.info-for.us "linnix" wrote:

>> >Win 98/2000
>>
>> Wonder what issues with XP and Vista will be, as unfortunately the host is
>> not being tied down.
>
>Have not try this on XP.  No need or desire to do so.

I wish I could lock down the OS as well. That is beyond my scope on this
job.

>I always keep old copies of OS and tools anyway.
>Ten years from now.   I don't need to run the latest OS
>with 15 years old tools and 20 years old chips (XC95XX).

Sometimes gets to be a pain when you have to replace system hardware and
revert to some VGA mode display due to lack of drivers..

I would rather have locked down systems.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

On Wed, 01 Nov 2006 23:07:28 +0000 (GMT),
paul$@pcserviceselectronics.co.uk (Paul Carpenter) wrote:


>I wish I could lock down the OS as well. That is beyond my scope on this
>job.

If you expect to be able to use something after 10 years or more, you
really have to archive also the whole toolchain, including the OS.
Anything requiring activation would be out of the question. WinXP
would be out of the question due to this, I don't know about WinXP
embedded. Win2000 does not need activation, neither does Linux. Thus
you should make a bootable CD containing the OS, toolchain and
application data. 

Then there is a question how long the CD-R/RW is readable, it might be
a good idea to also store the disk image on some other media, such as
some common type of flash.

>I would rather have locked down systems.

If only one copy is needed, archiving the hardware would not be that
bad idea. A small size PC with Ethernet interface should do. The
problem is how long the components will remain intact (especially
electrolytic capacitors). 

Also the display, keyboard or mouse availability in the future might
be an issue, so storing these might be an option. If these are not
stored, some telnet+VNC system should be set up to be used remotely
through Ethernet. 

If the hardware can not be archived, then there is the problem of
guessing what hardware is available in the future. It might be quite
safe to guess that x86 machines would be available in the future, at
least as old systems stored in a cupboard. 

For new hardware the problem is the availability of interface cards
and what buses are available. At least some well known PCI/PCI-E
Ethernet card should be available, but the system should boot without
display card or keyboard/mouse.

If the frozen system is built around Virtual86/386 mode, it should
also be checked that it will work under AMD 64 bit machines, which
might be common in the future.

Paul
 

Paul Keinanen wrote:
> On Wed, 01 Nov 2006 23:07:28 +0000 (GMT),
> paul$@pcserviceselectronics.co.uk (Paul Carpenter) wrote:
> 
> 
>> I wish I could lock down the OS as well. That is beyond my scope on this
>> job.
> 
> If you expect to be able to use something after 10 years or more, you
> really have to archive also the whole toolchain, including the OS.
> Anything requiring activation would be out of the question. WinXP
> would be out of the question due to this, I don't know about WinXP
> embedded. Win2000 does not need activation, neither does Linux. Thus
> you should make a bootable CD containing the OS, toolchain and
> application data. 
> 
> Then there is a question how long the CD-R/RW is readable, it might be
> a good idea to also store the disk image on some other media, such as
> some common type of flash.
> 
>> I would rather have locked down systems.
> 
> If only one copy is needed, archiving the hardware would not be that
> bad idea. A small size PC with Ethernet interface should do. The
> problem is how long the components will remain intact (especially
> electrolytic capacitors). 
> 
> Also the display, keyboard or mouse availability in the future might
> be an issue, so storing these might be an option. If these are not
> stored, some telnet+VNC system should be set up to be used remotely
> through Ethernet. 
> 
> If the hardware can not be archived, then there is the problem of
> guessing what hardware is available in the future. It might be quite
> safe to guess that x86 machines would be available in the future, at
> least as old systems stored in a cupboard. 
> 
> For new hardware the problem is the availability of interface cards
> and what buses are available. At least some well known PCI/PCI-E
> Ethernet card should be available, but the system should boot without
> display card or keyboard/mouse.
> 
> If the frozen system is built around Virtual86/386 mode, it should
> also be checked that it will work under AMD 64 bit machines, which
> might be common in the future.
> 
> Paul
>  

Another idea is to check if the toolkit and OS can work under 
virtualising software like VMWare.  Then you could archive the entire OS 
+ software image, and re-use it on other PC's later.  It doesn't matter 
if the software is locked to a specific MAC address, since the 
"ethernet" card is virtual, and the MAC address (I expect) follows the 
image.  Even better, if you can get it working under bochs or qemu, then 
you don't even need to have a x86 compatible machine in the future to 
run it.

Jim Granville wrote:
> Aside: Your spec does not call for _operate_ from flash drive, but that
> should be possible.
>  I have not tested WinCUPL (command Line) running from a FlashDrive yet, 
> but size will not be a problem, and I know Text Editors can run from 
> Flash Drives. When I get my flash drive back from the borrower, I'll
> try it sometime. Might slow the 1-2 second compile times, to 5-10 
> seconds... ?

I've tried an Atmel  WinCUPL Flash drive install/Run, with these results:

Yes, it all works fine.

Compile times: Slightly slower. Takes appx 2 seconds for Compile/Sim/JED 
create, from Flash drive. ~266K project directory

ZIPed sized :
  Functional Editor : 533K
  Functional WinCUPL\Shared : 3.17MB ( under 1% of OP's 400MB target )

Unzipped sizes:
  Text Editor: 1.4MB
  WinCupl : 8.21MB

So, a target of _operate_ from FLASH drive looks quite do-able and that
has to give more design-longevity, as then you only have to find a 
machine with a USB port to quickly try it. So your pool of candidates is
suddenly much larger.
Probably be good for 20+ years of design life ?

-jg

On Wed, 01 Nov 2006 07:56:32 -0800, linnix wrote:

>> Device
>>         100 registers min
>>         50 I/O min
>>         Surface mount as TQFP/PQFP/PLCC
>>                 (i.e. NOT BGA etc..)
>>         5V I/O or tolerant I/O
>>         Fastest clock is currently 25MHz
>>         Less than 80mA total Icc
>>                 (not all sections operating at same time)
>>         Flash or EEPROM programming (no RAM devices)
> 
> XC95108 should cover all.
> 

The XC95108 looks like it will exceed the 80mA spec. CoolRunner XPLA3
has 5V tolerant IO and is lower current. I had a brief look at coolrunner
II, but it doesn't look like it had the 5V tolerant I/O.

> 
> As stated from another post, wrong decision.
> 

Although quite a lot of hardware engineers don't know vhdl, or use it so
infrequently it's more productive to use schematic capture, with logic
symbols that all hardware engineers understand. 

Of course there are disadvantages, one that I have come across more than
once is that a hardware engineer may consider all nets on the schematic to
have propagation delays similar to wired board, when in fact they don't.
Some attention needs to be paid to synchronous design issues. A recent
thread on comp.arch.fpga, titled along the lines of 'spectre of
metastability', touched on this.

Regards,

Paul.

>>The restriction on size is silly - just get a 2 GB flash drive.
>
>Consider the market the customer is in respecifying that part which has
>been agreed upon is going to be a costly exercise adding at least 3 months
>to project.

How exactly does "Buy a bigger flash drive for anouther $20 or so" add 3 months to a project?

On 1 Nov 2006 14:18:42 -0800, "linnix" <me@linnix.info-for.us> wrote:

>> >Win 98/2000
>>
>> Wonder what issues with XP and Vista will be, as unfortunately the host is
>> not being tied down.
>
>Have not try this on XP.  No need or desire to do so.
>I always keep old copies of OS and tools anyway.
>Ten years from now.   I don't need to run the latest OS
>with 15 years old tools and 20 years old chips (XC95XX).

2000 would be a better archived OS than XP due to lack of the product activation nonsense.

Paul Taylor wrote:
> On Wed, 01 Nov 2006 07:56:32 -0800, linnix wrote:
> 
> 
>>>Device
>>>        100 registers min
>>>        50 I/O min
>>>        Surface mount as TQFP/PQFP/PLCC
>>>                (i.e. NOT BGA etc..)
>>>        5V I/O or tolerant I/O
>>>        Fastest clock is currently 25MHz
>>>        Less than 80mA total Icc
>>>                (not all sections operating at same time)
>>>        Flash or EEPROM programming (no RAM devices)
>>
>>XC95108 should cover all.
>>
> 
> 
> The XC95108 looks like it will exceed the 80mA spec. CoolRunner XPLA3
> has 5V tolerant IO and is lower current. I had a brief look at coolrunner
> II, but it doesn't look like it had the 5V tolerant I/O.

Atmel's ATF1508ASL ?

> 
> 
>>As stated from another post, wrong decision.
>>
> 
> 
> Although quite a lot of hardware engineers don't know vhdl, or use it so
> infrequently it's more productive to use schematic capture, with logic
> symbols that all hardware engineers understand.

IF they can load it ! - given the OPs desire for a long design-life, one
simple litmus test, is to look back ten+ years, and try and find
both a Trained Engineer and Design that can load any of those 10 year 
old SCH designs into todays tools, or find a 10 year old SCH+license 
that works on todays PCs.

Ask a sample of HW Engineers if they can understand this code snippet :

PIN   38   = RegQ0;
PIN   34   = RegQ1;

     RegQ0.ck = OscBN;
     RegQ1.ck = OscBN;

     RegQ0.t  = 'b'1;
     RegQ1.t  = RegQ0;

No, it is not VHDL - for CPLDs that's not really required.

> 
> Of course there are disadvantages, one that I have come across more than
> once is that a hardware engineer may consider all nets on the schematic to
> have propagation delays similar to wired board, when in fact they don't.

In modern FPGAs, routing delays now dominate, so there is a grain of 
truth in this.

-jg

On Thursday, in article <4549b1aa$1@clear.net.nz>
     no.spam@designtools.maps.co.nz "Jim Granville" wrote:

>Jim Granville wrote:
>> Aside: Your spec does not call for _operate_ from flash drive, but that
>> should be possible.
>>  I have not tested WinCUPL (command Line) running from a FlashDrive yet, 
>> but size will not be a problem, and I know Text Editors can run from 
>> Flash Drives. When I get my flash drive back from the borrower, I'll
>> try it sometime. Might slow the 1-2 second compile times, to 5-10 
>> seconds... ?
>
>I've tried an Atmel  WinCUPL Flash drive install/Run, with these results:
>
>Yes, it all works fine.
>
>Compile times: Slightly slower. Takes appx 2 seconds for Compile/Sim/JED 
>create, from Flash drive. ~266K project directory
>
>ZIPed sized :
>  Functional Editor : 533K
>  Functional WinCUPL\Shared : 3.17MB ( under 1% of OP's 400MB target )
>
>Unzipped sizes:
>  Text Editor: 1.4MB
>  WinCupl : 8.21MB
>
>So, a target of _operate_ from FLASH drive looks quite do-able and that
>has to give more design-longevity, as then you only have to find a 
>machine with a USB port to quickly try it. So your pool of candidates is
>suddenly much larger.
>Probably be good for 20+ years of design life ?

Thanks for the information, keeping options open, is what I am trying to
do with so many other constraints.

>-jg
>
>

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate