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 135700

Article: 135700
Subject: Re: Complex Event Processing on FPGA
From: spam@oxfordbromley.plus.com
Date: Mon, 13 Oct 2008 01:03:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 13, 12:10 am, Brian Drummond <brian_drummond wrote:

> discovered a j in your pension fund?

The j is orthogonal to my problems; it's
the j^2 that worries me :-)
--
Jonathan Bromley

Article: 135701
Subject: Re: Lattice vs Altera (Mico32 / NIOS)....or?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 13 Oct 2008 22:27:50 +1300
Links: << >>  << T >>  << A >>
MMJ wrote:

>>Why does this need to be on the FPGA ?
>>SoftCPUs still need external memory, so are a 2-3 chip solution.
> 
> 
> Correct, but the FPGA is a "must have" in this project, so an embedded 
> softcore will give us allot of advantages:
> 
> *No extra BOM cost for MCU and needed extra components.

Here you need care:
Your SoftCPU needs external Code memory, so that adds to the BOM
(unless you just happen to be using large external memory anyway, with
unused space, that can fit the CODE, and also happen to have spare bus 
cycles to access it.
It also might need a larger Config memory, another BOM adder, and
you might also need a larger FPGA.
You also have higher EMC issues, and could even need more PCB layers....
If that external memory is ONLY for code, that is a LOT of pins
you have added to the design....

> *No additional use of "real estate" for the MCU subsystem.

Single chip MCUs are quite small, and the flash is all done.

Generally, if you can fit your code into a merchant uC, it
makes more sense to use one, along side your (now smaller?) FPGA

> *High data bandwidt between our custom hardware and CPU.

How high do you need ?

> *"Weird" hardware configurations are supported (e.g. we need 4+ i2c busses).

Nothing stops you adding 4 i2c in the FPGA


> 
> These pros has made us going for the softcore soloution.

-jg



Article: 135702
Subject: Re: More Actel 'Funnies'
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 13 Oct 2008 10:39:15 +0100
Links: << >>  << T >>  << A >>
>> That's the way I've been describing bus tri-states since I started
>> FPGA design 15 odd years ago. As far as I know it's a 'standard'
>> so the tools should be able to deal with it.
> So have I but I've sometimes seen it not to work
> Nicolas


Which doesn't fill me full of confidence in the Actel tools.


I tend to design at a very (too) low level and have been using 80MHz as
a 'standard' clock speed for about the last 10 years. My designs
tend to easily build & work with a simple clock constraint and
IO constraints. This has been the case with multiple designs in
Altera and Xilinx devices.

The design that ran at 66MHz in the Cyclone I (not a II) is struggling
to meet that in the Actel device, this is after removing some registers
to ease up the critical path.

I'm starting to look at Lattice devices, the first pass run in an
XP2 ran at 95MHz. This is without pin constraints, so it will be
slower then that but it looks much more like the performance I'm used to.



Nial 



Article: 135703
Subject: Re: XMOS XC-1 kits are shipping
From: Bob <bob9@mailinator.com>
Date: Mon, 13 Oct 2008 03:14:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 10, 2:01 pm, Leon <leon...@btinternet.com> wrote:
> I've just ordered my 1600 MIPS XMOS XC-1 design kit.
>
> The XMOS chips will replace DSPs and FPGAs in a lot of applications.
>
> I haven't been so excited about a new chip since the transputer came
> out. David May designed them both, of course.
>
> Leon
> leon...@btinternet.com

I briefly saw XMOS at a trade show in London.
They seem far too fixated on doing everything in software, things like
ethernet where there is no point shoveling bytes in software if
hardware can take care of it.

The quarter VGA touchscreen on the dev kit has novelty value.

I'm not sure the performance justifies the effort of using somthing
so unusual in most cases.

I'd want to make a single lifetime buy of processors if I used
these in a product. Far too likely to dissapear without trace.

Bob


Article: 135704
Subject: Re: XMOS XC-1 kits are shipping
From: Leon <leon355@btinternet.com>
Date: Mon, 13 Oct 2008 03:33:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Oct, 11:14, Bob <b...@mailinator.com> wrote:
> On Oct 10, 2:01 pm, Leon <leon...@btinternet.com> wrote:
>
> > I've just ordered my 1600 MIPS XMOS XC-1 design kit.
>
> > The XMOS chips will replace DSPs and FPGAs in a lot of applications.
>
> > I haven't been so excited about a new chip since the transputer came
> > out. David May designed them both, of course.
>
> > Leon
> > leon...@btinternet.com
>
> I briefly saw XMOS at a trade show in London.
> They seem far too fixated on doing everything in software, things like
> ethernet where there is no point shoveling bytes in software if
> hardware can take care of it.
>
> The quarter VGA touchscreen on the dev kit has novelty value.
>
> I'm not sure the performance justifies the effort of using somthing
> so unusual in most cases.
>
> I'd want to make a single lifetime buy of processors if I used
> these in a product. Far too likely to dissapear without trace.
>
> Bob

They are supplying free libraries for all the usual peripheral
functions. Doing stuff like that in software is much cheaper than
using hardware, and easier in many ways.

Leon

Article: 135705
Subject: Re: DDR FLOP?
From: Gabor <gabor@alacron.com>
Date: Mon, 13 Oct 2008 05:19:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 12, 8:04=A0am, FP <FPGA.unkn...@gmail.com> wrote:
> On Oct 12, 8:02=A0am, FP <FPGA.unkn...@gmail.com> wrote:
>
> > Hello,
>
> > I am a newbie and I would like your help. What is a DDR Flop? I found
> > IFDDR and OFDDR primitives from Xilinx. However, I cannot find more
> > information on this topic.
>
> > Your comments are appreciated.
>
> I would like to use this to genrate a 200MHz clock from a 100 MHz
> source.

The point of DDR is that you can get 200 megabits per second out a
single I/O clocked at 100 MHz.  That doesn't mean that you have 200
MHz anywhere in the system.  In fact the highest frequency you deal
with is 100 MHz.  The OFDDR has two D inputs, one sampled on
the rising clock edge (usually) and the other on the falling clock
edge (again usually).  In the Xilinx DDR flops you don't have to use
both edges of a single clock for this as the OFDDR also has two
independent clock inputs, but normally the two clocks would either
be an inversion or 50% of period delay of eachother.

I think there are some older Xilinx appnotes with reference designs
for DDR memory control that can illustrate how these DDR
flip-flops are used.

Regards,
Gabor

Article: 135706
Subject: Re: Lattice vs Altera (Mico32 / NIOS)....or?
From: "MMJ" <Spam@aldrig.com>
Date: Mon, 13 Oct 2008 14:21:47 +0200
Links: << >>  << T >>  << A >>
> If you say what the specific bugs are, maybe I can offer some help or
> advice.

One of the main problems are the poor performance of the debug interface in 
the Mico32. A download speed of 20-30 kbit/sec is just to slow when 
developing large applications. Is there any way to speed up this interface?

> MicroBlaze and NIOS II have been around for longer and no doubt have a
> larger user base, but they are not without their own problems. Don't
> forget that much of the toolchain is pretty much the same s/w.

Offcourse! But you mention a big reasson to try out Altera....the large user 
base. Lattice have < 100 topics in their forum compared to >8k in Alteras. 
The large user may help you to find/fight some of the problems.

Regards

--
MMJ



Article: 135707
Subject: Re: Lattice vs Altera (Mico32 / NIOS)....or?
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 13 Oct 2008 14:27:35 +0200
Links: << >>  << T >>  << A >>
MMJ wrote:

> Offcourse! But you mention a big reasson to try out Altera....the large user 
> base. Lattice have < 100 topics in their forum compared to >8k in Alteras. 
> The large user may help you to find/fight some of the problems.

Maybe there are less topics because there are less problems :-)

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

Article: 135708
Subject: Re: More Actel 'Funnies'
From: Gabor <gabor@alacron.com>
Date: Mon, 13 Oct 2008 05:40:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 13, 5:39=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> >> That's the way I've been describing bus tri-states since I started
> >> FPGA design 15 odd years ago. As far as I know it's a 'standard'
> >> so the tools should be able to deal with it.
> > So have I but I've sometimes seen it not to work
> > Nicolas
>
> Which doesn't fill me full of confidence in the Actel tools.
>
> I tend to design at a very (too) low level and have been using 80MHz as
> a 'standard' clock speed for about the last 10 years. My designs
> tend to easily build & work with a simple clock constraint and
> IO constraints. This has been the case with multiple designs in
> Altera and Xilinx devices.
>
> The design that ran at 66MHz in the Cyclone I (not a II) is struggling
> to meet that in the Actel device, this is after removing some registers
> to ease up the critical path.
>
> I'm starting to look at Lattice devices, the first pass run in an
> XP2 ran at 95MHz. This is without pin constraints, so it will be
> slower then that but it looks much more like the performance I'm used to.
>
> Nial

I have run into problems with IOB placement especially in older
versions of XST.  The newer versions seem to cope with more
issues, but often I still need to coerce them a bit.  Some points
that confused various versions of XST synthesis:

1) Describing registers in a different level of hierarchy than the
pin.  Usually this was register in a lower level and pin at the
top.

2) Defining active high enable for tristate control.  Newer
versions invert the function to the D flop but older ones
could not place register into IOB because of the inverter
after the flop.

3) Not explicitly replicating the tristate function.  Newer
versions would do this automatically, but I had to turn
off "equivalent register removal" as well as turn on
"register duplication" to make it work.  There may
be similar knobs on the Actel synthesis tools.

Regards,
Gabor

Article: 135709
Subject: Re: DDR FLOP?
From: FP <FPGA.unknown@gmail.com>
Date: Mon, 13 Oct 2008 05:43:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 13, 8:19=A0am, Gabor <ga...@alacron.com> wrote:
> On Oct 12, 8:04=A0am, FP <FPGA.unkn...@gmail.com> wrote:
>
> > On Oct 12, 8:02=A0am, FP <FPGA.unkn...@gmail.com> wrote:
>
> > > Hello,
>
> > > I am a newbie and I would like your help. What is a DDR Flop? I found
> > > IFDDR and OFDDR primitives from Xilinx. However, I cannot find more
> > > information on this topic.
>
> > > Your comments are appreciated.
>
> > I would like to use this to genrate a 200MHz clock from a 100 MHz
> > source.
>
> The point of DDR is that you can get 200 megabits per second out a
> single I/O clocked at 100 MHz. =A0That doesn't mean that you have 200
> MHz anywhere in the system. =A0In fact the highest frequency you deal
> with is 100 MHz. =A0The OFDDR has two D inputs, one sampled on
> the rising clock edge (usually) and the other on the falling clock
> edge (again usually). =A0In the Xilinx DDR flops you don't have to use
> both edges of a single clock for this as the OFDDR also has two
> independent clock inputs, but normally the two clocks would either
> be an inversion or 50% of period delay of eachother.
>
> I think there are some older Xilinx appnotes with reference designs
> for DDR memory control that can illustrate how these DDR
> flip-flops are used.
>
> Regards,
> Gabor

Thank you all for your valuable comments. I appreciate it.

Article: 135710
Subject: Re: Lattice vs Altera (Mico32 / NIOS)....or?
From: "MMJ" <Spam@aldrig.com>
Date: Mon, 13 Oct 2008 15:05:04 +0200
Links: << >>  << T >>  << A >>

> Here you need care:
> Your SoftCPU needs external Code memory, so that adds to the BOM
> (unless you just happen to be using large external memory anyway, with
> unused space, that can fit the CODE, and also happen to have spare bus 
> cycles to access it.
> It also might need a larger Config memory, another BOM adder, and
> you might also need a larger FPGA.
> You also have higher EMC issues, and could even need more PCB layers....
> If that external memory is ONLY for code, that is a LOT of pins
> you have added to the design....

External flash for code is needed yes - but is also used on most silicon 
MCU/MPUs. Config memeory for the FPGA will be selected to support a fully 
configured FPGA. Regarding EMC and PCB we acutally keep allot of signals 
within the FPGA by embedding the CPU, which eases routing and maybe 
decreasses layers.

> Single chip MCUs are quite small, and the flash is all done.

Correct....if the job can be done at the right price by an internal flash 
MCU.

> Generally, if you can fit your code into a merchant uC, it
> makes more sense to use one, along side your (now smaller?) FPGA

No the size of the CPU in the FPGA is very few percent relative to the 
custom hardware that needs to be implemented.

> How high do you need ?

Above 10Mbit on a buffered DMA interface. Internally in the FPGA I guess 
this can be done by DMA from FPGA RAM to DDR ram of the CPU. Complette 
control of interrupt loading etc.

--
MMJ



Article: 135711
Subject: Re: Lattice vs Altera (Mico32 / NIOS)....or?
From: =?ISO-8859-2?Q?Adam_G=F3rski?= <totutousungorskia@malpawp.pl>
Date: Mon, 13 Oct 2008 15:12:25 +0200
Links: << >>  << T >>  << A >>
MMJ pisze:
>> Here you need care:
>> Your SoftCPU needs external Code memory, so that adds to the BOM
>> (unless you just happen to be using large external memory anyway, with
>> unused space, that can fit the CODE, and also happen to have spare bus 
>> cycles to access it.
>> It also might need a larger Config memory, another BOM adder, and
>> you might also need a larger FPGA.
>> You also have higher EMC issues, and could even need more PCB layers....
>> If that external memory is ONLY for code, that is a LOT of pins
>> you have added to the design....
> 
> External flash for code is needed yes - but is also used on most silicon 
> MCU/MPUs. Config memeory for the FPGA will be selected to support a fully 
> configured FPGA. Regarding EMC and PCB we acutally keep allot of signals 
> within the FPGA by embedding the CPU, which eases routing and maybe 
> decreasses layers.
> 

If you have enough space inside configuration flash you can use it for 
both - for FPGA image and for softprocessor code.

I'm doing this way.

Adam

Article: 135712
Subject: Re: How to synthesize a delay of around 10 ns in FPGA?
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 13 Oct 2008 06:35:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Okt., 01:01, Selensky <selen...@gmail.com> wrote:
> Hi Peter,
> You said that Virtex-4 IDELAY element is stable over temperature,
> voltage and processing. Is it stable over continuous years of
> operation too?

While the IDELAY element itself is stable, IO routing inside the FPGA
is not.
Have a look at the tables at the end of XAPP856. They show that the
clock
vs. data routing show a relative drift of 1 delay tap with temperature
and 6
delay taps with supply voltage.
The data is for Virtex-5.

Kolja Sulimma


Article: 135713
Subject: Re: How to synthesize a delay of around 10 ns in FPGA?
From: General Schvantzkopf <schvantzkopf@yahoo.com>
Date: Mon, 13 Oct 2008 08:59:55 -0500
Links: << >>  << T >>  << A >>
On Wed, 08 Oct 2008 07:35:44 -0700, Pratap wrote:

> Hi,
> I want to synthesize a delay of around 10 ns in Xilinx Virtex2 Pro. So I
> put around 200 inverters in series and get the desired delay. So I did
> port map the BASIC cell "INV" according to the XST settings. But when i
> place and route I guess the optimizer removes all the intermediate
> buffers and I get very less delay when I do a post route simulation.
> How can I get rid of this problem?
> Thanks in advance.
> -Pratap

Do you need a delay or can you accomplish your task with a phase shifted 
clock? If you can use a phase shifted clock from the DCM that's a much 
better way of doing it because it's stable over temperature and process 
and because it won't change when the tools change.

If you must build a delay line from buffers you will have to directly 
place them because the routing delays are much more important then the LUT 
delays. Also you should use an XOR instead of an inverter. Tie one side of 
the XOR to a flop which presets to 1 on reset and then clocks a zero into 
the data input. This will be enough to fool XST and PAR into leaving the 
components alone.

Article: 135714
Subject: Re: More Actel 'Funnies'
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 13 Oct 2008 15:13:31 +0100
Links: << >>  << T >>  << A >>
> There may be similar knobs on the Actel synthesis tools.

Perhaps, but the guy who's been looking at this doesn't know what they
are.


Nial. 



Article: 135715
Subject: Re: Lattice vs Altera (Mico32 / NIOS)....or?
From: =?ISO-8859-2?Q?Adam_G=F3rski?= <totutousungorskia@malpawp.pl>
Date: Mon, 13 Oct 2008 16:20:48 +0200
Links: << >>  << T >>  << A >>
Adam Górski pisze:
> MMJ pisze:
>>> Here you need care:
>>> Your SoftCPU needs external Code memory, so that adds to the BOM
>>> (unless you just happen to be using large external memory anyway, with
>>> unused space, that can fit the CODE, and also happen to have spare 
>>> bus cycles to access it.
>>> It also might need a larger Config memory, another BOM adder, and
>>> you might also need a larger FPGA.
>>> You also have higher EMC issues, and could even need more PCB layers....
>>> If that external memory is ONLY for code, that is a LOT of pins
>>> you have added to the design....
>>
>> External flash for code is needed yes - but is also used on most 
>> silicon MCU/MPUs. Config memeory for the FPGA will be selected to 
>> support a fully configured FPGA. Regarding EMC and PCB we acutally 
>> keep allot of signals within the FPGA by embedding the CPU, which 
>> eases routing and maybe decreasses layers.
>>
> 
> If you have enough space inside configuration flash you can use it for 
> both - for FPGA image and for softprocessor code.
> 
> I'm doing this way.
> 
> Adam

If you have external SDR SDRAM or DDR SDRAM of course or big enough 
internal ram

Adam

Article: 135716
Subject: Re: More Actel 'Funnies'
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 13 Oct 2008 16:56:33 +0200
Links: << >>  << T >>  << A >>
Nial Stewart a écrit :
> 
> Which doesn't fill me full of confidence in the Actel tools.

As I said in my first post on this topic, I have no experience with Actel.

Nicolas

Article: 135717
Subject: writing files to micro-SD with spartan 3e
From: pfrinec@yahoo.co.uk
Date: Mon, 13 Oct 2008 08:06:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello!

I would like to write image files (*.bmp, ...) to micro-SD card.
I am using Spartan 3e starter kit with microblaze soft processor and a
micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/
Pmod-B.html).
The general idea is to write files in FAT16 file system to micro-SD
card and then later transfer them to PC.
Does anybody have an idea (or reference design) how to do this? Is it
possible to use DOSFS?

Thanks!

Article: 135718
Subject: Re: Looking for a soft core 32 bit processor in VHDL
From: "beky4kr@gmail.com" <beky4kr@gmail.com>
Date: Mon, 13 Oct 2008 08:26:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 11 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8, 12:00, "HT-Lab" <han...@h=
t-lab.com> wrote:
> "bzigon" <bob.zi...@gmail.com> wrote in message
>
> news:62c7a069-d995-415b-a77e-4e0c87cb7e2f@x41g2000hsb.googlegroups.com...
>
> > Gang
>
> > I'm looking for a simple 32bit softcore processor in VHDL. I dont need
> > a cache or
> > and MMU. I do need interrupts. I also need software tools for the
> > processors.
> > I am happy to program in assembler, a C compiler is a bonus.
>
> > Any ideas?
>
> > Bob
>
> Google?
> Why 32bits?
> Opencoreshttp://www.opencores.org/browse.cgi/filter/category_microprocess=
or
>
> Hanswww.ht-lab.com

I recommend too to use leon.
I used it for an I2C example (http://bknpk.no-ip.biz)

Article: 135719
Subject: Re: writing files to micro-SD with spartan 3e
From: John McCaskill <jhmccaskill@gmail.com>
Date: Mon, 13 Oct 2008 08:54:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 13, 10:06=A0am, pfri...@yahoo.co.uk wrote:
> Hello!
>
> I would like to write image files (*.bmp, ...) to micro-SD card.
> I am using Spartan 3e starter kit with microblaze soft processor and a
> micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/
> Pmod-B.html).
> The general idea is to write files in FAT16 file system to micro-SD
> card and then later transfer them to PC.
> Does anybody have an idea (or reference design) how to do this? Is it
> possible to use DOSFS?
>
> Thanks!

We use a PicoBlaze in a Spartan 3e to read a bit file from a mini-SD
card and program it into a Virtex-4FX, so a MicroBlaze should not have
any problems with being able to write to a microSD card. Being able to
fit reading from a FAT16 file system was a tight fit for the
PicoBlaze.

Once the PicoBlaze configures the Virtex on our card, it turns
ownership of the miniSD card over to the Virtex. The V4 then has a
simple boot loader that loads Linux from the miniSD card. Linux has
full read write access to the miniSD card.

We have the card formatted as FAT16.  The PicoBlaze accesses the card
in four bit mode, and has DMA assist so that it can program the V4
fast enough for it to be configured in time to respond to a PCI bus
probe.  The V4 just uses the miniSD in SPI mode. For SPI mode, we use
the SPI core that comes with EDK.  Linux has a FAT16 file system
driver, so that is one good place to start looking.  EDK also comes
with a FAT16 file system in the xilfatfs library. Xilfatfs requires
the system ace controller, but you have the source code to the library
so you could modify it to use microSD if you wish.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 135720
Subject: Testing Analog-to-Digital Converter, Spartan-3A, LTC1407-A
From: m m <msmeerkat@gmail.com>
Date: Mon, 13 Oct 2008 09:07:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi:

I need to test some VHDL codes, which are commanding the LTC1407-A
Analog-to-Digital converter of the Spartan-3A, to take a sample on its
voltage input pin. The results of the conversion will be displayed on
the LCD.

The problem is that my background is not in electrical engineering and
I would like to know of a way (online tutorial, etc) to test these
codes, by sending the voltage output of the digital-to-analog-
converter (LTC2624 model) to the input pin of the analog-to-digital
converter.
I already confirmed, through an oscilloscope, that the DAC is sending
the voltage as I need it. Basically the FPGA application sends a
voltage and immediately after that, commands the analog-to-digital
converter to take a sample.


I have a cable, which bought in the Digilent Web site for the pins of
both terminals. A "6 Pin MTE Cable" found at :
http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable

.. however I received the advise that I need to make by myself a
circuit to join the ground pin with another pin... and that for these
steps I need to work with a resistor... etc... [ honestly I didn't
understand much  ]


Is there a simpler way to successfully send the voltage output of the
Digital-to-Analog converter to the voltage input of the Analog-to-
Digital converter?



Thank you,
m __ m

__________________________
LTC1407-A :
http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1001,C1150,P2485


LTC2624 (DAC) :
http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1005,C1156,P2048

Article: 135721
Subject: Re: XMOS XC-1 kits are shipping
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Mon, 13 Oct 2008 10:31:06 -0700
Links: << >>  << T >>  << A >>
steveu@coppice.org wrote:
> On Oct 11, 1:43 am, Leon <leon...@btinternet.com> wrote:
>> On 10 Oct, 17:42, ste...@coppice.org wrote:
>>
>>
>>
>>> On Oct 10, 9:01 pm, Leon <leon...@btinternet.com> wrote:
>>>> I've just ordered my 1600 MIPS XMOS XC-1 design kit.
>>>> The XMOS chips will replace DSPs and FPGAs in a lot of applications.
>>>> I haven't been so excited about a new chip since the transputer came
>>>> out. David May designed them both, of course.
>>>> Leon
>>>> leon...@btinternet.com
>>> Is the comparison with the Transputer supposed to imply this is a half
>>> thought out design with brain dead execution? :-\
>>> Steve
>> The transputer was ahead of its time, and really pushed the technology
>> that was available. I sold a lot of systems using it, mostly to
>> universities and research establishments, because there was nothing
>> else around with that sort of performance then. Inmos even had their
>> own fab!
>>
>> Leon
> 
> The Transputer wasn't ahead of its time. It was brain dead. A chip
> only effective in substantial arrays selling for hundreds of pounds
> per device was a dead duck from the start. The only people who could
> seriously look at it for substantial arrays were military
> applications. However, when approached about military parts Transputer
> gave evasive answers.
> 
> There was nothing innovative about the design of the Transputer. The
> device as it was supposed to be (i.e. separate comms and execution
> planes), rather than the crippled one they shipped, was similar to
> designs several people in the UK (and presumably elsewhere) were
> toying with at that time. The others did not proceed because the
> economics looked so wrong.


Toying means nothing in our industry, it's all about rolling out actual 
product. That is what Inmos did. But:

The economics didn't have to look wrong. They were wrong because IMHO a 
cardinal mistake had been made: Entering the market with very high price 
tags. That was bound to fail and cause me to turn away. Same thing 
happened with S/C filter chips.

Next, they should have lined up an early licensing deal with a major 
semiconductor manufacturer, one that engineers trust. This is extremely 
important. Nobody in their right mind would design in a single-source 
part from a tiny manufacturer without a serious business track record. 
My guess is that a few more business-thinkers could have potentially 
saved the bacon at Inmos.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Article: 135722
Subject: Re: XMOS XC-1 kits are shipping
From: Eric Smith <eric@brouhaha.com>
Date: Mon, 13 Oct 2008 12:42:25 -0700
Links: << >>  << T >>  << A >>
Bob wrote about XMOS:
> They seem far too fixated on doing everything in software, things like
> ethernet where there is no point shoveling bytes in software if
> hardware can take care of it.

Leon wrote:
> They are supplying free libraries for all the usual peripheral
> functions. Doing stuff like that in software is much cheaper than
> using hardware, and easier in many ways.

Been there, done that, and it's not cheaper or easier when you
consider the overall system cost impact, not just the "benefit" of
leaving out the hardware block.  That was the path Scenix/Ubicom went
down, calling it "virtual peripherals", and it was not very
successful.  Ubicom has since added hardware for Ethernet, USB,
etc. to their most recent parts.  The reality is that a hardware
Ethernet MAC costs less than the total system cost impact of the
software alternative.

Eric

Article: 135723
Subject: Re: writing files to micro-SD with spartan 3e
From: Eric Smith <eric@brouhaha.com>
Date: Mon, 13 Oct 2008 12:47:22 -0700
Links: << >>  << T >>  << A >>
pfrinec@yahoo.co.uk writes:
> I am using Spartan 3e starter kit with microblaze soft processor and a
> micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/
> Pmod-B.html).

You mean there's actually a way to purchase those?

> Is it possible to use DOSFS?

I don't see why not.  I've used DOSFS to access flash cards on other
platforms.

Article: 135724
Subject: Re: writing files to micro-SD with spartan 3e
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 13 Oct 2008 13:58:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 13, 10:47=A0pm, Eric Smith <e...@brouhaha.com> wrote:
> pfri...@yahoo.co.uk writes:
> > I am using Spartan 3e starter kit with microblaze soft processor and a
> > micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/
> > Pmod-B.html).
>
> You mean there's actually a way to purchase those?
>
http://www.trenz-electronic.de/
Trenz electronic has them in stock and several Xilinx kits are
shipping with them as bundled package from Trenz webshop

> > Is it possible to use DOSFS?
>
> I don't see why not. =A0I've used DOSFS to access flash cards on other
> platforms.

I have ported and packaged DOSFS as EDK software library and it is
very easy to use
the low level driver required may use different type of peripherals
1) SPI core
2) software SPI over GPIO
3) SD 1-bit mode over GPIO
4) SD 1-bit mode over custom IP

http://code.google.com/p/dev-kit/downloads/list
is the EDK packaged DOSFS library

for the low level drivers i need to cleanup and upload them
what will happen shortly now

Antti





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