Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 130300

Article: 130300
Subject: Linux 2.6 PCI Device Driver on Virtex 4
From: bin.arthur@gmail.com
Date: Wed, 19 Mar 2008 15:20:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have spent the past few months slowly trying to get a PCI design
with Linux 2.6 on the Virtex 4. I have been able to overcome some of
the hurdles; however, I am still unable to boot up a working system.
If anyone has tried to do this (or has already done this) I would
apprecaite any help or suggestions.  I can go into more detail as to
what I have done and where I am stuck if there is anyone who would be
willing to guide me!

Thanks,
Bin

Article: 130301
Subject: Re: FSL or DMA w/ FIFO?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 19 Mar 2008 16:31:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Mark,

markmcma...@hotmail.com wrote:

> My project has several ADC channels with 16bit data up to 24kSPS.
>
> There is no need for each ADC sample to be sent ASAP to the
> microblaze, as the data is processed in chunks of 200 samples.  A
> previous (non-xilinx) version of this project used a FIFO and a burst
> read over a PCI bus to a pentium processor.
>
> Now, reading about FSL it seems that the microblaze has to execute an
> instruction to get every sample of data?
> What I want is the lowest overhead - given that I can use a FIFO,
> would the FIFO with DMA route be better suited to my needs than FSL?

As of EDK9.2, there is an plb2fsl_bridge, basically a single channel
bridge between the PLB and FSL.  So,. combine that with an
xps_central_dma and you can DMA directly to an FSL-based peripheral.

I really like FSL but the requirement for all data to pass through the
CPU is a performance problem, particularly in OS environments such as
Linux.  Standalone dedicated apps maybe not so bad.  If the data is
truly sourcing or  sinking in the CPU, then direct FSL is OK.  But, if
memory is your source or sink, DMA is necessary.

Regards,

John

Article: 130302
Subject: Re: A Challenge for serialized processor design and implementation
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 20 Mar 2008 12:36:31 +1200
Links: << >>  << T >>  << A >>
Walter Banks wrote:
> 
> Jim Granville wrote:
>>With the COP800 well past it's commercial life, what
>>is the status of 'abandonware' C Compilers for it ?
> 
> We have a COP8 compiler. The COP8 certainly fits the description
> because it original implementation was almost identical.

Do you still sell any ?

> 
> 8051, Z8 and 6804 would also be on my historical short list.

The target has to be smaller than PicoBlaze/Mico8
- otherwise, why bother ?

So, 8051 are too large for this project, and I thought of the Modern RS08
(as that does have C compilers ;), but I get the feeling
all the multi-byte opcodes, and address variants would
not map well onto a FPGA. (so it would fail size) )

Z8 - Nice Reg-Reg scheme, but likely to be close to 8051
in FPGA resource usage.

8048 ? maybe, but no compilers for this ?

The best-mapped FPGA small CPUs use 18 bit opcodes,
so that makes finding some old chip, with a C-Compiler,
unlikely!

There is CoolRisc 816, which uses a 22 bit opcode,
and does have a GNU C compiler, and some infrastructure ?
Again, could be too large...

A 24 bit opcode is also possible. It WOULD give faster operation,
and more opcodes/KB, than 32 bit opcodes.
Not sure how many C compilers, for 24 Bit opcodes ?

-jg


Article: 130303
Subject: Re: dual clock fifo
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 19 Mar 2008 17:46:42 -0700
Links: << >>  << T >>  << A >>
Patrick Dubois wrote:

> I found the source code that was available at edif.org through
> archive.org:
> http://web.archive.org/web/20031204114425/http://www.edif.org/lpmweb/more/vhdl.htm

The internet never forgets ;)

> It looks like complete source code, I'm not sure what additional
> support I would need from vendors. It seems to me that I could just
> use lpm_fifo_dc from 220model.vhd. Am I missing something?

The code is synthesizable as is,
but I would at least clean up the
non-standard libraries and the
odd-ball string generics.

    -- Mike Treseler

ps: here's a first cut:
http://home.comcast.net/~mike_treseler/sync_fifo.vhd



Article: 130304
Subject: Re: A Challenge for serialized processor design and implementation
From: rickman <gnuarm@gmail.com>
Date: Wed, 19 Mar 2008 21:07:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 19, 8:36 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Walter Banks wrote:
>
> > Jim Granville wrote:
> >>With the COP800 well past it's commercial life, what
> >>is the status of 'abandonware' C Compilers for it ?
>
> > We have a COP8 compiler. The COP8 certainly fits the description
> > because it original implementation was almost identical.
>
> Do you still sell any ?
>
>
>
> > 8051, Z8 and 6804 would also be on my historical short list.
>
> The target has to be smaller than PicoBlaze/Mico8
> - otherwise, why bother ?
>
> So, 8051 are too large for this project, and I thought of the Modern RS08
> (as that does have C compilers ;), but I get the feeling
> all the multi-byte opcodes, and address variants would
> not map well onto a FPGA. (so it would fail size) )
>
> Z8 - Nice Reg-Reg scheme, but likely to be close to 8051
> in FPGA resource usage.
>
> 8048 ? maybe, but no compilers for this ?
>
> The best-mapped FPGA small CPUs use 18 bit opcodes,
> so that makes finding some old chip, with a C-Compiler,
> unlikely!
>
> There is CoolRisc 816, which uses a 22 bit opcode,
> and does have a GNU C compiler, and some infrastructure ?
> Again, could be too large...
>
> A 24 bit opcode is also possible. It WOULD give faster operation,
> and more opcodes/KB, than 32 bit opcodes.
> Not sure how many C compilers, for 24 Bit opcodes ?

Maybe I am missing something, but I have seen CPUs in FPGAs as small
as 600 LUTs.  I am pretty sure the picoBlaze is about that size.
Isn't there a C compiler for that?

The OP asked for something that would use no more than 25% of the
smallest FPGA in a given family.  That is still nearly 1000 LUTs.  So
why go with anything else?

A bit serial CPU might be smaller than an 8 bit CPU, but what is the
driving need for something that small?  600 LUTs is not much in a 3000
LUT FPGA!



Article: 130305
Subject: Re: A Challenge for serialized processor design and implementation
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 20 Mar 2008 05:29:21 +0100
Links: << >>  << T >>  << A >>
rickman wrote:

> Maybe I am missing something, but I have seen CPUs in FPGAs as small
> as 600 LUTs.  I am pretty sure the picoBlaze is about that size.

I think it is smaller, about 200 LUTs:

http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php

> A bit serial CPU might be smaller than an 8 bit CPU, but what is the
> driving need for something that small?  600 LUTs is not much in a 3000
> LUT FPGA!

Could be interesting to pack it in a Max II, where the smallest device has
240 LEs. Sometimes you need some high speed logic and some more complex
tasks, but which can be low speed (keyboard sampling, output to LCD text
display). If you can get an additional low speed CPU for free, you could
save an external microcontroller.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 130306
Subject: Re: A Challenge for serialized processor design and implementation
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 20 Mar 2008 17:55:23 +1200
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> rickman wrote:
> 
> 
>>Maybe I am missing something, but I have seen CPUs in FPGAs as small
>>as 600 LUTs.  I am pretty sure the picoBlaze is about that size.
> 
> 
> I think it is smaller, about 200 LUTs:
> 
> http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php

And also the similar Mico8  ~240-323 LUT
http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm

> 
>>A bit serial CPU might be smaller than an 8 bit CPU, but what is the
>>driving need for something that small?  600 LUTs is not much in a 3000
>>LUT FPGA!
> 
> 
> Could be interesting to pack it in a Max II, where the smallest device has
> 240 LEs. Sometimes you need some high speed logic and some more complex
> tasks, but which can be low speed (keyboard sampling, output to LCD text
> display). If you can get an additional low speed CPU for free, you could
> save an external microcontroller.

The serial code memory is part of the appeal.
FPGA cores are easy enough, but they are like stone soup,
and you need to add code execution storage, = many pins, and EMC and PCB
area issues.
Single chip uC are a tough nut to crack, as they have FLASH+Analog,
and higher volumes and growths than the FPGA sector.

-jg




Article: 130307
Subject: Re: A Challenge for serialized processor design and implementation
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 20 Mar 2008 00:19:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mrz., 06:55, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Frank Buss wrote:
> > rickman wrote:
>
> >>Maybe I am missing something, but I have seen CPUs in FPGAs as small
> >>as 600 LUTs.  I am pretty sure the picoBlaze is about that size.
>
> > I think it is smaller, about 200 LUTs:
>
> >http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php
>
> And also the similar Mico8  ~240-323 LUThttp://www.latticesemi.com/products/intellectualproperty/referencedes...
>
>
>
> >>A bit serial CPU might be smaller than an 8 bit CPU, but what is the
> >>driving need for something that small?  600 LUTs is not much in a 3000
> >>LUT FPGA!
>
> > Could be interesting to pack it in a Max II, where the smallest device has
> > 240 LEs. Sometimes you need some high speed logic and some more complex
> > tasks, but which can be low speed (keyboard sampling, output to LCD text
> > display). If you can get an additional low speed CPU for free, you could
> > save an external microcontroller.
>
> The serial code memory is part of the appeal.
> FPGA cores are easy enough, but they are like stone soup,
> and you need to add code execution storage, = many pins, and EMC and PCB
> area issues.
> Single chip uC are a tough nut to crack, as they have FLASH+Analog,
> and higher volumes and growths than the FPGA sector.
>
> -jg

Hi all

I wasnt online yesterday (was in Tirol/Austri-not for fun) so I answer
all in one


"serial implementations of the past" - have worked with COP800 and I
had hard days optimizing DES for ST62T10
- none of those is suitable directly, maybe there is something to look
and learn, but not much to direct use

small FPGA soft-cores (existing ones)
- too large
- not flexible in configuration options
- no real C compilers exist
- can not address "flat word" 32bit addressing

now some additional considerations:

32 bit ALU for serial implementation cost the same as 1 bit ALU
32 bit registers if implemented in BRAM or data buffer of Atmel
Dataflash cost very little (0 FPGA fabric resource)
code data memory space cost very little, so opcode density is almost
least priority
number of cycles per instruction is also very low priority (at least
for some optimization options)

lets look sone special targets

1) device S3AN-50
=============

if we use picoblaze, we use 30% of BRAM and some small % of FPGA, but
we only get 1KW of code and 8 bit processor/ALU

a S3/Dataflash optimized SPU could use Dataflash dual ram buffers for
registers,ram,stack those not use BRAM at all. Say it would run at 512
clock per instruction, so what? It would be 32 bit processor with 0.1
MIPS leaving ALL BRAMs to the user and almost all of the fabric as
well. And it would not cost anything extra as it the Dataflash is
already present in the S3AN

2) Actel A3P060/IGLOO60+SD card
==========================
SPU should be configured to use half-BRAM for registes, ram,stack and
could be executing either from SD-card, again this would be 32 bit
processor with c compiler. Actel has no LUT ram option and any known
small 8 but softcore would already too be too large also. the code
memory price on SD card is virtually 0

3) XXX + Winbond Quad SPI
====================
here we could also achieve some not so bad performance despite the
serialized code memory

if all of the above special cases would be support by the same C
compiler (with settings to adapt to config differences) ?

single chip MCU's are hard to crack, but that isnt the goal, in many
cases there are "unused" resources present, so the SPU could really
come virtually free, besides an extra IC + extra 0.80 USD is still
extra cost for additional MCU in the system


Antti

































Article: 130308
Subject: Re: A Challenge for serialized processor design and implementation
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Thu, 20 Mar 2008 00:53:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 11:28 pm, Antti <Antti.Luk...@googlemail.com> wrote:
> 1) VERY small when implemented in any modern FPGA (less 25% of
> smallest device, 1 BRAM)
> 2) be supported by high level compiler (C ?)
> 3) execute code in-place from either serial flash (Winbond quad speed
> SPI memory delivers 320 mbit/s!) or from file on sd-card

I can see cases where this could be useful, where there's a need for a
complex
state machine, but not necessarily super fast processing.

IMO, the most critical aspect of such a core is that it's easy to
target a real C compiler,
like LLVM, for it. Thus I strongly suggest a plain-jane orthogonal *32-
bit* RISC,
ideally without delay slots or special purpose registers, etc.

Maybe one of the existing ones (MIPS, MB, Nios II, Mico32, etc) is
already suitable enough,
which would save the effort of building a new tool chain, but they may
be too big.

AVR is an interesting example as it was explicitly designed to support
C compilation
(and it does, far better than PIC). However, 32-bit code ends up
suffering badly from having
to do everything in 8-bit steps and there aren't really enough
registers.

Finally, the most impressive little core I've seen is Bernd Paysan's
b16: http://www.jwdt.com/~paysan/b16.html

It appears there was some effort to port GCC to it, but I don't know
the status.


Good luck,
Tommy

Article: 130309
Subject: Re: A Challenge for serialized processor design and implementation
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 20 Mar 2008 02:45:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 Mrz., 22:29, Jecel <je...@merlintec.com> wrote:
> Antti,
>
> my impression is that a subset of the 32 bit Transputers with a serial
> implementation would be the best tradeoff in terms of complexity and
> performance.

Or something similar, more modern:
http://www.intellasys.net/index.php?option=com_content&task=view&id=35&Itemid=63
9mW per core at 1GHz.

Kolja Sulimma

Article: 130310
Subject: Re: A Challenge for serialized processor design and implementation
From: sky465nm@trline4.org
Date: Thu, 20 Mar 2008 10:55:46 +0100 (CET)
Links: << >>  << T >>  << A >>
>single chip MCU's are hard to crack, but that isnt the goal, in many
>cases there are "unused" resources present, so the SPU could really
>come virtually free, besides an extra IC + extra 0.80 USD is still
>extra cost for additional MCU in the system

I don't think the 0.80 USD is so bothersome. As having to make space on a
already tight pcb for another chip. Arranging powersupply, decouple, route
properly without crosstalk etc.., find a reliable component source etc.. are
the factors that makes it attractive to use the least number of components
as possible.


Article: 130311
Subject: Re: A Challenge for serialized processor design and implementation
From: Steve Goodwin <ng@p2cl.co.uk>
Date: Thu, 20 Mar 2008 10:23:53 +0000
Links: << >>  << T >>  << A >>
In article <47e1a2f1$1@clear.net.nz>, Jim Granville <no.spam@designtools
.maps.co.nz> writes

>8048 ? maybe, but no compilers for this ?

Nooooo... please, please noooo... I still have nightmares....

-- 
Steve Goodwin...  www.p2cl.co.uk (includes contact details)

Article: 130312
Subject: Re: Altera EPM7032S reading checksum
From: SKatsyuba@gmail.com
Date: Thu, 20 Mar 2008 04:16:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
You may read the device idcode. If received idcode equals to EPM7032S
idcode then JTAG is OK.

On Mar 19, 10:15 pm, "maxi" <maxit...@virgilio.it> wrote:
> Hi,
>
> is it possible to read a checksum of a
> EPM7032S with Byteblaster an Max Plus II without having any information of
> how and what can be inside only for test the Jtag is ok?
>
> If yes how can i do?
>
> Thanks for any help
>
> MAX
>
> EPM7032SEPM7032S

Article: 130313
Subject: SD-Card SDHC artificial 32GB limit
From: sky465nm@trline4.org
Date: Thu, 20 Mar 2008 12:21:16 +0100 (CET)
Links: << >>  << T >>  << A >>
I just noticed one can get SDHC (SD-card 2.0) with 16 GB capacity for 89 EUR.
The limit according to the v2.0 standard for SD-Card is 32 GB. But the layout
of the configuration memory (CSD) allows representation of 2048 GB. Guess
they have to remove that limit soon..


Article: 130314
Subject: Re: Optimizing an inferred counter
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 20 Mar 2008 11:25:03 +0000
Links: << >>  << T >>  << A >>
kennheinrich@sympatico.ca writes:

> - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their
> LOCK output can assert even though the output clock is completely
> unstable, or possibly just running at a harmonic, like half-rate. 

Really!? What's the point of the LOCKED output then?  Do that flaw not
make them a bit useless?

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 130315
Subject: Configure Spartan-3E w SD-Card?
From: sky465nm@trline4.org
Date: Thu, 20 Mar 2008 13:07:48 +0100 (CET)
Links: << >>  << T >>  << A >>
I think someone here mentioned the possibility to configure an Xilinx
Spartan-3E fpga with an SD-Card (MMC) in SPI mode. However when checking on
this by chance today I found that it seems to not work because:

Read commands are defined as:
http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer_Spec.pdf
  READ_SINGLE_BLOCK  0x51
  READ_MULTI..       0x52

But Spartan-3E SPI uses the commands:
http://direct.xilinx.com/bvdocs/publications/ds312.pdf  Page79
  Fast read   0x0B
  Read        0x03
  Read array  0xE8

Or did I miss something?

Article: 130316
Subject: Re: Configure Spartan-3E w SD-Card?
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 20 Mar 2008 05:26:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mrz., 13:07, sky46...@trline4.org wrote:
> I think someone here mentioned the possibility to configure an Xilinx
> Spartan-3E fpga with an SD-Card (MMC) in SPI mode. However when checking on
> this by chance today I found that it seems to not work because:
>
> Read commands are defined as:http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer...
>   READ_SINGLE_BLOCK  0x51
>   READ_MULTI..       0x52
>
> But Spartan-3E SPI uses the commands:http://direct.xilinx.com/bvdocs/publications/ds312.pdf Page79
>   Fast read   0x0B
>   Read        0x03
>   Read array  0xE8
>
> Or did I miss something?

think you missed something.

FPGA's can get configured from DATAFLASH mounted in SDCARD plastic
(atmel sells those!)
and sure mmc-sd can be used in spi or sd mode, but there is extra
circuitry required, either mcu or cpld

Antti







Article: 130317
Subject: Re: Configure Spartan-3E w SD-Card?
From: sky465nm@trline4.org
Date: Thu, 20 Mar 2008 13:48:39 +0100 (CET)
Links: << >>  << T >>  << A >>
>think you missed something.

>FPGA's can get configured from DATAFLASH mounted in SDCARD plastic
>(atmel sells those!)
>and sure mmc-sd can be used in spi or sd mode, but there is extra
>circuitry required, either mcu or cpld

I think my point was to accomplish this without adding an extra chip..
Using a MCU/CPLD it would ofcourse work.


Article: 130318
Subject: Re: Optimizing an inferred counter
From: Andy <jonesandy@comcast.net>
Date: Thu, 20 Mar 2008 05:53:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 20, 6:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> kennheinr...@sympatico.ca writes:
> > - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their
> > LOCK output can assert even though the output clock is completely
> > unstable, or possibly just running at a harmonic, like half-rate.
>
> Really!? What's the point of the LOCKED output then?  Do that flaw not
> make them a bit useless?
>
> Cheers,
> Martin
>
> --
> martin.j.thomp...@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

There are input clock specifications for which the the DCM operation
is guaranteed, including the operation of the locked signal. Violate
those specs, and the DCM is no longer guaranteed to function
"properly". This is no different than any other clocked electronic
device, and is far from rendering the device/function "a bit useless".

Andy

Article: 130319
Subject: Re: Configure Spartan-3E w SD-Card?
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 20 Mar 2008 05:59:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mrz., 13:48, sky46...@trline4.org wrote:
> >think you missed something.
> >FPGA's can get configured from DATAFLASH mounted in SDCARD plastic
> >(atmel sells those!)
> >and sure mmc-sd can be used in spi or sd mode, but there is extra
> >circuitry required, either mcu or cpld
>
> I think my point was to accomplish this without adding an extra chip..
> Using a MCU/CPLD it would ofcourse work.

well dont think it can be done, would be too good to be true ;)

Antti

Article: 130320
Subject: Re: A Challenge for serialized processor design and implementation
From: Walter Banks <walter@bytecraft.com>
Date: Thu, 20 Mar 2008 08:20:06 -0500
Links: << >>  << T >>  << A >>


Jim Granville wrote:

> Walter Banks wrote:
> >
> > Jim Granville wrote:
> >>With the COP800 well past it's commercial life, what
> >>is the status of 'abandonware' C Compilers for it ?
> >
> > We have a COP8 compiler. The COP8 certainly fits the description
> > because it original implementation was almost identical.
>
> Do you still sell any ?

Actually yes, the COP8 is still being used as the core of some
special purpose self contained devices. The COP8 has low
analog noise and works well hybrid systems.

A main stream part as Ulf said it is now rarely used.

Walter..




Article: 130321
Subject: Re: Configure Spartan-3E w SD-Card?
From: job@amontec.com
Date: Thu, 20 Mar 2008 06:22:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 20, 1:07 pm, sky46...@trline4.org wrote:
> I think someone here mentioned the possibility to configure an Xilinx
> Spartan-3E fpga with an SD-Card (MMC) in SPI mode. However when checking on
> this by chance today I found that it seems to not work because:
>
> Read commands are defined as:http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer...
>   READ_SINGLE_BLOCK  0x51
>   READ_MULTI..       0x52
>
> But Spartan-3E SPI uses the commands:http://direct.xilinx.com/bvdocs/publications/ds312.pdf Page79
>   Fast read   0x0B
>   Read        0x03
>   Read array  0xE8
>
> Or did I miss something?

SPI bus means to have one Master and one Slave.

SD card cannot be master, you need to have a Master to get the data
from!
FPGA CONFIG RAM cannot be master, you need to have a master to write
the data to the FPGA RAM !

For programming FPGA, you need a master getting the data from SD and
writing to FPGA RAM.

Larry,
http://www.amontec.com

Article: 130322
Subject: Re: A Challenge for serialized processor design and implementation
From: Walter Banks <walter@bytecraft.com>
Date: Thu, 20 Mar 2008 08:31:56 -0500
Links: << >>  << T >>  << A >>


Jim Granville wrote:

> So, 8051 are too large for this project, and I thought of the Modern RS08
> (as that does have C compilers ;), but I get the feeling
> all the multi-byte opcodes, and address variants would
> not map well onto a FPGA. (so it would fail size) )

Might want to look at 6804. Jack Ganssle's newsletter was recently
talking about bit serial processors and I dug out the documentation
for the 6804 and was surprised just how similar it was to RS08.

The interesting thing about multibyte opcodes is they are generally
either address or data fields that get routed to some register or alu
and I don't think would be all that complex to implement.

Walter..



Article: 130323
Subject: Re: Optimizing an inferred counter
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 20 Mar 2008 13:43:55 +0000
Links: << >>  << T >>  << A >>
Andy <jonesandy@comcast.net> writes:

> On Mar 20, 6:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>> kennheinr...@sympatico.ca writes:
>> > - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their
>> > LOCK output can assert even though the output clock is completely
>> > unstable, or possibly just running at a harmonic, like half-rate.
>>
>> Really!? What's the point of the LOCKED output then?  Do that flaw not
>> make them a bit useless?
>>
>> Cheers,
>> Martin
>>
>> --
>> martin.j.thomp...@trw.com
>> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html
>
> There are input clock specifications for which the the DCM operation
> is guaranteed, including the operation of the locked signal. Violate
> those specs, and the DCM is no longer guaranteed to function
> "properly". This is no different than any other clocked electronic
> device, and is far from rendering the device/function "a bit
> useless".

Ahh, that makes more sense.  I misunderstood the original statement to
be a bit wider than that!

Thanks,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 130324
Subject: Re: A Challenge for serialized processor design and implementation
From: John Devereux <jdREMOVE@THISdevereux.me.uk>
Date: Thu, 20 Mar 2008 13:44:27 +0000
Links: << >>  << T >>  << A >>
Steve Goodwin <ng@p2cl.co.uk> writes:

> In article <47e1a2f1$1@clear.net.nz>, Jim Granville <no.spam@designtools
> .maps.co.nz> writes
>
>>8048 ? maybe, but no compilers for this ?
>
> Nooooo... please, please noooo... I still have nightmares....

You too? Perhaps we should start a support & recovery group.

Didn't you just *love* how you could insert a line of assembler, and
trigger half a dozen errors elsewhere due to code crossing the page
boundaries?

-- 

John Devereux



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search