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 138950

Article: 138950
Subject: Re: inout pins use in fpga
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Mon, 16 Mar 2009 09:54:56 -0700
Links: << >>  << T >>  << A >>
On Sun, 15 Mar 2009 05:42:11 -0700 (PDT)
denish <dinesh.twanabasu@gmail.com> wrote:

> Hi,
>  I am using "inout" signal for the first time in designing I2C
> communication with cmos sensor module.I have completed the design. The
> post map simulation worked fine and  synthesized without warnings and
> errors. But when I implemented the design in Spartan 3A DSP by using
> pull up resistors for the pins I couldnot get the output.Suggest me
> about using the "inout" pins.
> Regards
> Dinesh.

I believe that you want to assign, at any given time, the values '0' or
'Z' to the pin.  Then, if you want to use the pullups in the Spartan,
you need to place a PULLUP on those pins in the UCF constraint file.
Or, if you're talking about real people resistors, you don't.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 138951
Subject: Re: Getting started with FPGA
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 16 Mar 2009 09:58:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Don't worry Plod is on the beat.

On 16 Mar, 15:53, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 16, 5:20=A0pm, John Adair <g...@enterpoint.co.uk> wrote:
>
>
>
>
>
> > Some useful things linked on our websitehttp://www.enterpoint.co.uk/tec=
hitips/techitips.html.
>
> > As to boards we have lots but maybe Drigmorn1http://www.enterpoint.co.u=
k/component_replacements/drigmorn1.html
> > would be a good starting place.
>
> > John Adair
> > Enterpoint Ltd.
>
> > On 14 Mar, 19:41, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote:
>
> > > I'd like to design a custom microprocessor (just for learning purpose=
s). I
> > > used Lattice's GAL chips with ABEL before, but quickly ran out of spa=
ce.
> > > As such, I'd like to move over to an FPGA platform.
>
> > > However, I've never used FPGAs, VHDL, or Verilog before.
>
> > > I was wondering if someone could point me in the right direction? As =
far a
> > > development board to start with or a book on a programming language, =
or
> > > both?
>
> > > Thanks!
>
> I was so curious...
>
> ....to checkout if John's post has some info besides advertizement
> inside.
>
> Antti- Hide quoted text -
>
> - Show quoted text -


Article: 138952
Subject: Re: I2C EEPROM
From: gabor <gabor@alacron.com>
Date: Mon, 16 Mar 2009 12:49:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 13, 6:55=A0am, David Fejes <fej...@gmail.com> wrote:
> Hello,
>
> Maybe this is a bit offtopic but may I ask you what kind of I2C ipcore
> do you use? I have to implement some i2c slave logic with some
> readable and writable registers in my next design and I'm curious
> about that..
>
> thank you in advance

I wrote my own for a simple slave interface.  Look at this
thread on the Xilinx forums:

http://forums.xilinx.com/xlnx/board/message?board.id=3DSpartan&message.id=
=3D268&query.id=3D674829#M268

Article: 138953
Subject: Re: SPI controller for FPGA
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 16 Mar 2009 22:35:52 +0100
Links: << >>  << T >>  << A >>
Vesh a écrit :
> Hi,
> I am using the Xilinx Spartan 3E starter kit for driving the RFM12B RF
> transceiver module. I need to have an SPI controller core that can
> drive this module in SPI mode. The VHDL code that I wrote is totally
> okay in simulations but its not working through the FPGA board. Can
> anyone help me with it? I am not being able to debug this thing. The
> simulation's all well but the RF module is not transmitting any data
> and I have no idea how to debug it in FPGA hardware.

Hello
Have you checked your pinout constraint ?
Have you tried to look at your SPI lines with an oscilloscope ?

Nicolas

Article: 138954
Subject: Re: SPI controller for FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 16 Mar 2009 22:53:09 GMT
Links: << >>  << T >>  << A >>
Vesh <veshrajsharma@gmail.com> wrote:

>Hi,
>I am using the Xilinx Spartan 3E starter kit for driving the RFM12B RF
>transceiver module. I need to have an SPI controller core that can
>drive this module in SPI mode. The VHDL code that I wrote is totally
>okay in simulations but its not working through the FPGA board. Can
>anyone help me with it? I am not being able to debug this thing. The
>simulation's all well but the RF module is not transmitting any data
>and I have no idea how to debug it in FPGA hardware.

A simple logic analyzer will be handy. Perhaps there is just a bit
missing or the frequency is too high.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 138955
Subject: Re: SPI controller for FPGA
From: Kolja <ksulimma@googlemail.com>
Date: Mon, 16 Mar 2009 16:18:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 16 Mrz., 16:32, Vesh <veshrajsha...@gmail.com> wrote:
> I have no idea how to debug it in FPGA hardware.

Use this:
http://www.xilinx.com/ise/optional_prod/cspro.htm

Kolja Sulimma


Article: 138956
Subject: Zero operand CPUs
From: rickman <gnuarm@gmail.com>
Date: Mon, 16 Mar 2009 19:10:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have been following the development of the ZPU, a zero operand
processor for FPGAs.  The primary intent is to design a CPU that can
span a range of sizes from very space efficient to high speed while
being efficient at running C code.  The original author has an open
source compiler producing code for it which seems to be the part he is
good at.

However, it has been running rather slow in the benchmark they have
been running, Dhrystone.  I think I figured out why.  The ISA is zero
operand, but the stack in maintained in memory.  There is no stack
register architecture.  So every stack operation consists of reading
the operands, performing the operation and writing back the result.  I
can see why it is giving slow performance, even when pipelined.

I believe the real issue is that the focus is on building a complex
machine and trying "techniques" to make it simple and fast.  The more
I look at things like this, the more I am convinced that the Moore
philosophy is right.  You can achieve performance by adding more and
more complexity, or you can simplify to the point of inherent speed.

But then my thinking is biased.  I am a hardware guy and my
programming has always been the sort of stuff that can fit in a .com
file, you know, the ones with the 64 kbyte limit.  I still think Bill
Gates was right when he said that no one would ever need more than 640
kbytes ;^)  I just know that my current multi-GHz machine is not
really any faster than my old 12 MHz 286 in many respects... It
certainly does not boot any faster and is *much* slower to turn off.

Rick

Article: 138957
Subject: Re: Zero operand CPUs
From: Muzaffer Kal <kal@dspia.com>
Date: Mon, 16 Mar 2009 19:41:10 -0700
Links: << >>  << T >>  << A >>
On Mon, 16 Mar 2009 19:10:56 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

>I have been following the development of the ZPU, a zero operand
>processor for FPGAs.  The primary intent is to design a CPU that can
>span a range of sizes from very space efficient to high speed while
>being efficient at running C code.  The original author has an open
>source compiler producing code for it which seems to be the part he is
>good at.
>
>However, it has been running rather slow in the benchmark they have
>been running, Dhrystone.  I think I figured out why.  The ISA is zero
>operand, but the stack in maintained in memory.  There is no stack
>register architecture.  So every stack operation consists of reading
>the operands, performing the operation and writing back the result.  I
>can see why it is giving slow performance, even when pipelined.

Even a stack based ISA can be implemented to be fast. You can
certainly make an out of order, multi-issue stack machine as long as
you make the memory image consistent with an in-order cpu. In fact
even this may not be a requirement if you're not interested in
multi-core implementations. You can merge multiple instructions (micro
and macro operator fusion) and retire instructions out of order etc by
keeping an internal virtual register file which implements register
renaming for various stack locations.
Whether it's easier or more difficult to extract instruction level
parallelism from a stack based ISA is not very clear to me but it
certainly is possible.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 138958
Subject: Re: Send data from FPGA to PC via USB
From: mng <michael.jh.ng@gmail.com>
Date: Mon, 16 Mar 2009 21:20:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 8:14=A0am, nntpman68 <news1...@free.fr> wrote:
> Hi Mng,
>
> Could you please elaborate on this one?
> What kit are you exactly talking about?
> Is there any documentation.
> I'd be quite interested in this info.
>
> bye
>
> N
>
> mng wrote:
> > The Avnet Spartan-3A kit has the USB chip set up by default to provide
> > a 115.2 kbaud virtual serial port to the FPGA. If that's all you need,
> > then it could be a quick way to get started with your project.

http://www.google.com/search?q=3DAvnet+Spartan-3A+kit

Article: 138959
Subject: Re: MIG 2.0 for DDR - Spartan3E
From: =?ISO-8859-1?Q?Jaime_Andr=E9s_Aranguren_Cardona?= <jaime.aranguren@gmail.com>
Date: Tue, 17 Mar 2009 00:58:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 16 Mrz., 17:18, Jaime Andr=E9s Aranguren Cardona
<jaime.arangu...@gmail.com> wrote:
> On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>
>
> > gabor wrote:
>
> > (snip)
>
> > > For Spartan 3 MIG, which is primitive compared to the Virtex 5
> > > MIG, the order of row vs. bank addressing is not important.
> > > This is due to the fact that the MIG code only leaves one
> > > row of one bank active at any time. =A0The column address should
> > > be your low order address bits for linear addressing. =A0This
> > > will prevent unnecessary row precharge / activate sequences
> > > when performing linear access to memory.
>
> > One that I might try is a video display that also refreshes
> > the RAM. =A0That is an old trick that might still work.
>
> > > Also note that
> > > the least significant bits of the column address are
> > > incremented inside the memory chip during a burst operation.
> > > There is no carry out to the upper address bits, so when
> > > starting a burst you should normally begin at a burst
> > > boundary to avoid rapping back to previous addresses.
>
> > I don't expect any burst operations. =A0My first system will
> > be 8080 based, and I don't believe that the 8080 does bursts.
>
> > > Be careful when using the MIG top level interface with
> > > "linear" address. =A0It may be using the least significant
> > > bits for the bank address (depends on which interface
> > > typeDDR, DDR2, etc.).
>
> > -- glen
>
> Hi guys,
>
> Going further with the thread, I want to "report" that it seems to be
> working, but partially. In simulation everything goes fine, both for
> writing and reading data. I generate a sequence of numbers, fill the
> memory with it, and then read all the positions back, comparing with
> the sequence of numbers written. If an error is found, a counter is
> incremented. At the end of the read sequence, if everything goes fine,
> one led should glow, if not (even a single mismatch was found, which
> means the error counter is different to zero) then 6 leds glow.
>
> I am testing my stuff on an S3E Kit. If I just run the test for a very
> few rows (say 3), then most of the times the test passes, others it
> does not. If I run for higher number of rows, then at all times it
> fails. So, it seems to me that I am getting timing problems. Besides,
> I have to add that I am not using an external 133 MHz clock to SMA
> connector, I am using the onboard 50Mhz clock instead and a couple
> DCMs, one for generating a 100 MHz clock and another one to generate
> the 90 degree phase shifted clock.
>
> Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see
> that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps).
> Looking into the details of the UCF, I see that this signal, which for
> the S3E Starter kit is implemented as a loopback, has an assigment to
> pin P13. I suppose that that is needed because of packaging to IOBs,
> which is one of the project options for the MIG generated project. Is
> there a way to make the signal always internal and not look for a
> physical pin?
>
> The only way I have found to meet timing constraints was to remove
> that constraint in the UCF (the one that assigns rst_dqs_div signal to
> pin P13), but now another problem arises: when generating the
> bitstream, it fails because DRC is not passed, saying that the signal
> rst_dqs_div was assigned to bank3 which uses impedance controlled
> buffers or has Vref requeriments, which rst_dqs_div does not meet.
>
> How can it be got to work reliably? Even the original project
> generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without
> modifications, fails to meet the timing constraints for signal
> rst_dqs_div, which is supposed to be a critical timing signal
> necessary to get the controller working correctly.
>
> All your comments and suggestion are very welcome.
>
> Kind regards.

Hi,

I bypassed the DRC test for bitstream generation, but results are even
worse: now, most of the times it fails.... very seldom passes, even
for just 3 rows.

Any hint?

Kind regards.

Article: 138960
Subject: Re: Send data from FPGA to PC via USB
From: nntpman68 <news1234@free.fr>
Date: Tue, 17 Mar 2009 08:59:57 +0100
Links: << >>  << T >>  << A >>
Hi Mng,

Sorry my fault.


I ordered my Spartan 3A kit from Avnet and I did not find any 
documentation about the initial serial mode of the USB chip.
That's why I got curious when I rad your post.


However I overlooked the obvious:

I ordered from Avnet, but bought the Digilent kit,
which unfortunately has no Cypris chip and no uart via USB


bye


N



mng wrote:
> On Mar 14, 8:14 am, nntpman68 <news1...@free.fr> wrote:
>> Hi Mng,
>>
>> Could you please elaborate on this one?
>> What kit are you exactly talking about?
>> Is there any documentation.
>> I'd be quite interested in this info.
>>
>> bye
>>
>> N
>>
>> mng wrote:
>>> The Avnet Spartan-3A kit has the USB chip set up by default to provide
>>> a 115.2 kbaud virtual serial port to the FPGA. If that's all you need,
>>> then it could be a quick way to get started with your project.
> 
> http://www.google.com/search?q=Avnet+Spartan-3A+kit

Article: 138961
Subject: Re: libxdh_PartAnno.dll
From: =?ISO-8859-1?Q?Jaime_Andr=E9s_Aranguren_Cardona?= <jaime.aranguren@gmail.com>
Date: Tue, 17 Mar 2009 01:19:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mrz., 07:16, StYm <satyam.dwiv...@gmail.com> wrote:
> My Xilinx EDk (XPS) is not starting. It is giving error:
>
> "This application has failed to start because libXdh_Part_Anno.dll was
> not found. Re-installing the application may fix this problem."
>
> I reinstalled, but of no use.
>
> Can anyone help ??
>
> Thanks,
>
> Satyam

Hi,

Check that ..\EDK\lib\nt is in your global PATH environmental
variable. I had a similar issue with libPortability.dll, and this
solved it.

In this case ".." means the folder where you installed the Xilinx
software, for instance C:\Xilinx\10.1\

Regards.

Article: 138962
Subject: Re: Zero operand CPUs
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 17 Mar 2009 08:24:19 +0000
Links: << >>  << T >>  << A >>
On Mon, 16 Mar 2009 19:10:56 -0700 (PDT), rickman wrote:

>[ZPU's] stack is maintained in memory.  There is no stack
>register architecture.  So every stack operation consists of reading
>the operands, performing the operation and writing back the result.  I
>can see why it is giving slow performance, even when pipelined.

Strange.  I'm sure you too can see what to do about this - 
same as you had to do on the AMD29K which used some of its
huge register set to cache the top of the stack.  Implement
the stack in on-chip RAM, using circular addressing.  When
the on-chip stack threatens to overflow, "spill" some of
the oldest part of it to main memory, using a fast block
write operation.  CPU operations then continue to use the
on-chip stack but the circular addressing no longer overflows.
Similarly, when the stack threatens to underflow, "fill"
from main memory.  Way back then, you could get quite good
performance if you were careful to align the spill/fill 
operations with a DRAM page.  The 29K used software trap
routines to do the spill/fill, but I'm sure you could
do it at least partly in hardware without too much trouble.
Spill/fill can then be done speculatively, in the background, 
when there is spare bandwidth on the memory interface. 

Unfortunately the stack cache trashes multi-threading 
performance, because there is so much context to swap.  
I guess the correct compromise these days would be very 
different, with the stack cache probably about 16 words.  
With only a small stack cache you can keep several process's
stacks in the on-chip memory (that's harder to plan,
of course, but may still be helpful particularly in 
a small system).

>I believe the real issue is that the focus is on building a complex
>machine and trying "techniques" to make it simple and fast.  The more
>I look at things like this, the more I am convinced that the Moore
>philosophy is right.  You can achieve performance by adding more and
>more complexity, or you can simplify to the point of inherent speed.

Always provided you have sufficiently smart compilers to 
convert complicated real-world code into a suitable stream of 
your simple instructions.  But in general I think I agree.
Compilers _are_ pretty smart these days.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138963
Subject: Re: Zero operand CPUs
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 17 Mar 2009 03:46:55 -0500
Links: << >>  << T >>  << A >>

>Strange.  I'm sure you too can see what to do about this - 
>same as you had to do on the AMD29K which used some of its
>huge register set to cache the top of the stack.  Implement
>the stack in on-chip RAM, using circular addressing.  When
>the on-chip stack threatens to overflow, "spill" some of
>the oldest part of it to main memory, using a fast block
>write operation.  CPU operations then continue to use the
>on-chip stack but the circular addressing no longer overflows.
>Similarly, when the stack threatens to underflow, "fill"
>from main memory.  Way back then, you could get quite good
>performance if you were careful to align the spill/fill 
>operations with a DRAM page.  The 29K used software trap
>routines to do the spill/fill, but I'm sure you could
>do it at least partly in hardware without too much trouble.
>Spill/fill can then be done speculatively, in the background, 
>when there is spare bandwidth on the memory interface. 

You can simplify the hardware a lot by pushing
the stack overflow problem back to the compiler.
That is, the stack has a fixed size.  The compiler
can't generate code that overflows that limit.




>Unfortunately the stack cache trashes multi-threading 
>performance, because there is so much context to swap.  
>I guess the correct compromise these days would be very 
>different, with the stack cache probably about 16 words.  
>With only a small stack cache you can keep several process's
>stacks in the on-chip memory (that's harder to plan,
>of course, but may still be helpful particularly in 
>a small system).

I don't understand that comment.  Multi-threading requires
separate stacks.  That's just more RAM in the CPU, perhaps
the virtual CPU number is part of the RAM address if that's
what you mean by multi-threading.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138964
Subject: Re: Zero operand CPUs
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 17 Mar 2009 09:04:12 +0000
Links: << >>  << T >>  << A >>
On Tue, 17 Mar 2009 03:46:55 -0500, Hal Murray wrote:

>You can simplify the hardware a lot by pushing
>the stack overflow problem back to the compiler.
>That is, the stack has a fixed size.  The compiler
>can't generate code that overflows that limit.

OK.

Getting the compiler to limit the stack size is
clearly possible (Transputer, anyone? it had a
3-register stack).  But this is certain to 
cause more memory references to escape to 
memory.  It's a compromise, like everything else.

>>Unfortunately the stack cache trashes multi-threading 
>>performance, because there is so much context to swap.  
[...]
>I don't understand that comment.  Multi-threading requires
>separate stacks.  That's just more RAM in the CPU

Yes, but if a large swath of CPU register space is used
to cache the top-of-stack, then that cache must be 
saved and restored on a context switch.  You can only
provide a finite number of stack spaces in the CPU's
on-chip RAM, so at some point a context switch is
sure to entail a large penalty as some other thread's
stack cache must be evicted to main memory.

Shallower on-chip stack cache means slower single-
thread performance, but faster context switch and
the opportunity to keep more threads' stacks
on-chip.  Compromises again.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138965
Subject: How to load an image onto system ace compact flash embedded on virtex
From: mopra <mohitprakas@gmail.com>
Date: Tue, 17 Mar 2009 03:58:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
Can anyone tell me how I can load an image file like .jpeg or .bmp on
to the system ace compact flash embedded on virtex 2 Pro device?

I need to store image onto the compact flash and then do some
processing on it. I tried using the different functions in
sysace_stdio.h header file like sysace_fopen  etc but couldn't find a
way to load an image file onto the compact flash, so please help me in
this regard

Article: 138966
Subject: Re: How to load an image onto system ace compact flash embedded on
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 17 Mar 2009 04:02:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 12:58=A0pm, mopra <mohitpra...@gmail.com> wrote:
> Can anyone tell me how I can load an image file like .jpeg or .bmp on
> to the system ace compact flash embedded on virtex 2 Pro device?
>
> I need to store image onto the compact flash and then do some
> processing on it. I tried using the different functions in
> sysace_stdio.h header file like sysace_fopen =A0etc but couldn't find a
> way to load an image file onto the compact flash, so please help me in
> this regard

copy myimage.jpg f:\

where f: is the compact flash drive

later just use file functions from your code, they do work !

Antti

Article: 138967
Subject: Re: How to load an image onto system ace compact flash embedded on
From: mopra <mohitprakas@gmail.com>
Date: Tue, 17 Mar 2009 04:51:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey thanks for your help but can you explain it a little more
elaborately.

where should i use " copy myimage.jpg f:\  "?  How to embed that in
the C code?

Please help me in this regard.

Regards,
Mohit

Article: 138968
Subject: Re: Zero operand CPUs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 17 Mar 2009 13:13:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
 
> You can simplify the hardware a lot by pushing
> the stack overflow problem back to the compiler.
> That is, the stack has a fixed size.  The compiler
> can't generate code that overflows that limit.

As is usually done for x87 floating point.

The story is that the 8087 was designed such that software
could detect the stack over/underflow and swap to/from
memory.  No-one tried writing the software until the
hardware was done, and then it was found that it wasn't
possible.  

Presumably it could have been fixed in later processors,
but as far as I know, it wasn't changed.  

-- glen

Article: 138969
Subject: Re: Zero operand CPUs
From: Jacko <jackokring@gmail.com>
Date: Tue, 17 Mar 2009 06:24:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)

Another zero operand CPU http://nibz.googlecode.com

cheers jacko

Now available in free licence of one core per ASIC/FPGA/CPLD, with two
conditions.
1. A K Ring Technologies Logo must be printed atop the chip or close
by on the PCB at any resolution.
2. Any documentation produced must acknowledge copyright and provide
the URL.

This licence is for those folks who do not like the BSD derived work
restrictions.


Article: 138970
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 17 Mar 2009 06:58:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote:
> Hi
>
> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>
> Another zero operand CPUhttp://nibz.googlecode.com
>
> cheers jacko
>
> Now available in free licence of one core per ASIC/FPGA/CPLD, with two
> conditions.
> 1. A K Ring Technologies Logo must be printed atop the chip or close
> by on the PCB at any resolution.
> 2. Any documentation produced must acknowledge copyright and provide
> the URL.
>
> This licence is for those folks who do not like the BSD derived work
> restrictions.

the difference between zpu and nibz is that ZPU is supported
by GCC toolchain, while there are no tools to generate any
meaningful code for nibz

correct me if i am wrong

Antti

Article: 138971
Subject: Re: Zero operand CPUs
From: rickman <gnuarm@gmail.com>
Date: Tue, 17 Mar 2009 08:09:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 9:58=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote:
>
>
>
> > Hi
>
> > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>
> > Another zero operand CPUhttp://nibz.googlecode.com
>
> > cheers jacko
>
> > Now available in free licence of one core per ASIC/FPGA/CPLD, with two
> > conditions.
> > 1. A K Ring Technologies Logo must be printed atop the chip or close
> > by on the PCB at any resolution.
> > 2. Any documentation produced must acknowledge copyright and provide
> > the URL.
>
> > This licence is for those folks who do not like the BSD derived work
> > restrictions.
>
> the difference between zpu and nibz is that ZPU is supported
> by GCC toolchain, while there are no tools to generate any
> meaningful code for nibz
>
> correct me if i am wrong
>
> Antti

Is that really the primary critera?  I think you are right.  But I
have a similar CPU design that I expect to use on a project shortly
and it will be programmed in assembly, but it will look a lot like
Forth.  I consider that to be close enough to a high level language.

BTW, ZPU may have a GCC compiler, but without a debugger, is that
really useful?  There aren't many projects done in C that are debugged
without an emulator.

Rick

Article: 138972
Subject: Re: Zero operand CPUs
From: David Brown <david@westcontrol.removethisbit.com>
Date: Tue, 17 Mar 2009 16:22:42 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com"
> <Antti.Luk...@googlemail.com> wrote:
>> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote:
>>
>>
>>
>>> Hi
>>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>>> Another zero operand CPUhttp://nibz.googlecode.com
>>> cheers jacko
>>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two
>>> conditions.
>>> 1. A K Ring Technologies Logo must be printed atop the chip or close
>>> by on the PCB at any resolution.
>>> 2. Any documentation produced must acknowledge copyright and provide
>>> the URL.
>>> This licence is for those folks who do not like the BSD derived work
>>> restrictions.
>> the difference between zpu and nibz is that ZPU is supported
>> by GCC toolchain, while there are no tools to generate any
>> meaningful code for nibz
>>
>> correct me if i am wrong
>>
>> Antti
> 
> Is that really the primary critera?  I think you are right.  But I
> have a similar CPU design that I expect to use on a project shortly
> and it will be programmed in assembly, but it will look a lot like
> Forth.  I consider that to be close enough to a high level language.
> 
> BTW, ZPU may have a GCC compiler, but without a debugger, is that
> really useful?  There aren't many projects done in C that are debugged
> without an emulator.
> 
> Rick

It's possible to do a lot of development without a debugger.  I often do 
embedded development without one (though I prefer to have one available 
if possible).  Until you've done debugging with only a single LED for 
signalling, you haven't really done embedded development.  Bonus points 
if the microcontroller you're using only comes in OTP version.

Even big projects can be done without a debugger:
<http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html>

So a compiler without a debugger is somewhat limited but still useful, 
but a debugger without a compiler is rather less useful!


Article: 138973
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 17 Mar 2009 08:27:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 5:09=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 17, 9:58=A0am, "Antti.Luk...@googlemail.com"
>
>
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote:
>
> > > Hi
>
> > > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>
> > > Another zero operand CPUhttp://nibz.googlecode.com
>
> > > cheers jacko
>
> > > Now available in free licence of one core per ASIC/FPGA/CPLD, with tw=
o
> > > conditions.
> > > 1. A K Ring Technologies Logo must be printed atop the chip or close
> > > by on the PCB at any resolution.
> > > 2. Any documentation produced must acknowledge copyright and provide
> > > the URL.
>
> > > This licence is for those folks who do not like the BSD derived work
> > > restrictions.
>
> > the difference between zpu and nibz is that ZPU is supported
> > by GCC toolchain, while there are no tools to generate any
> > meaningful code for nibz
>
> > correct me if i am wrong
>
> > Antti
>
> Is that really the primary critera? =A0I think you are right. =A0But I
> have a similar CPU design that I expect to use on a project shortly
> and it will be programmed in assembly, but it will look a lot like
> Forth. =A0I consider that to be close enough to a high level language.
>
> BTW, ZPU may have a GCC compiler, but without a debugger, is that
> really useful? =A0There aren't many projects done in C that are debugged
> without an emulator.
>
> Rick- Hide quoted text -
>
> - Show quoted text -

well assembler is GOOD if it exist :)

so any soft-core with assembler is ok
but there is no assembler for nibz? so =3D=3D useless.
no C, no assembler, =3D=3D not possible to use :(

a non working somesort of forht partially adopted
but not really tested does not count as development tool.

a simple assembler would.

I personally dont like C, but unfortunatly can not fully avoid it
either

Antti

Article: 138974
Subject: Re: Zero operand CPUs
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Tue, 17 Mar 2009 11:40:04 -0400
Links: << >>  << T >>  << A >>
On Tue, 17 Mar 2009 16:22:42 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:

>rickman wrote:
>> On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com"
>> <Antti.Luk...@googlemail.com> wrote:
>>> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote:
>>>
>>>
>>>
>>>> Hi
>>>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>>>> Another zero operand CPUhttp://nibz.googlecode.com
>>>> cheers jacko
>>>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two
>>>> conditions.
>>>> 1. A K Ring Technologies Logo must be printed atop the chip or close
>>>> by on the PCB at any resolution.
>>>> 2. Any documentation produced must acknowledge copyright and provide
>>>> the URL.
>>>> This licence is for those folks who do not like the BSD derived work
>>>> restrictions.
>>> the difference between zpu and nibz is that ZPU is supported
>>> by GCC toolchain, while there are no tools to generate any
>>> meaningful code for nibz
>>>
>>> correct me if i am wrong
>>>
>>> Antti
>> 
>> Is that really the primary critera?  I think you are right.  But I
>> have a similar CPU design that I expect to use on a project shortly
>> and it will be programmed in assembly, but it will look a lot like
>> Forth.  I consider that to be close enough to a high level language.
>> 
>> BTW, ZPU may have a GCC compiler, but without a debugger, is that
>> really useful?  There aren't many projects done in C that are debugged
>> without an emulator.
>> 
>> Rick
>
>It's possible to do a lot of development without a debugger.  I often do 
>embedded development without one (though I prefer to have one available 
>if possible).  Until you've done debugging with only a single LED for 
>signalling, you haven't really done embedded development.  Bonus points 
>if the microcontroller you're using only comes in OTP version.

Hear, hear! You can dump an awful lot of information out of a single
pin, even floating point numbers (don't ask).

Emulators are slightly useful to check on whether one's understanding of
the datasheet is correct but, unless they're a cycle-by-cycle exact
replica of the microcontroller core *and* all of its peripherals then
it's not really emulating, more like approximating -- and that path can
lead to trouble.

-- 
Rich Webb     Norfolk, VA



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