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 77275

Article: 77275
Subject: Re: Free IP-Core for FPGA Config from MMC-Cards
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 3 Jan 2005 02:46:24 -0800
Links: << >>  << T >>  << A >>
Hi and thanks for the pointers.

well the SD Card support is not that easy a combined MMC-SD card IP-Core would be at least 50 PLD Cells (MMC only is 21 Macrocells). I know all the spec and differencies, I just never got enough time to add SD support.

One option could of course be using SPI mode, but thats not so nice.

When MMC-SD Card is left in MMC mode then the FPGA can after config use its own MMC Core to communicate with the Card, if the config core initializes SPI mode then FPGA should also access the card in SPI mode.

Antti

Article: 77276
Subject: Re: USB JTAG programmers?
From: "Peter Seng" <NOSPAM@seng.de>
Date: Mon, 3 Jan 2005 15:16:31 +0100
Links: << >>  << T >>  << A >>
There is a PCMCIA to Parallel-Port adapter available:
QUATECH SPP-100,
Single parallel port PCMCIA card for about 160,00 Euro, it worked well on
several PCs...

And for just configuring - have a look at the FTDI chips and bit-bang
app-notes:
http://www.ftdichip.com


with best regards,

Peter Seng


#############################
SENG digitale Systeme GmbH
Im Bruckwasen 35
D 73037 Goeppingen
Germany
tel  +49 7161 75245
fax  +49 7161 72965
eMail  p.seng@seng.de
net  http://www.seng.de
#############################





"Alan Randomdude" <randomdude@gmail.com> schrieb im Newsbeitrag
news:d2b05bc6.0412261533.58ba2077@posting.google.com...
> Hi there.
>
> I've been programming using a parallel byteBlaster-type lead,
> attatched to an old 486, via a network connection to my laptop. This
> is because my laptop is devoid of parallel or serial ports (oh, the
> foresight). I hear I can't use USB to Parallel adaptors (arse!) and I
> can't imagine me finding a pcmcia parallel adaptor (though I could
> make one..?) and looking on alteras site reveals they want about
> 150/$300usd for their USB baster. Nads to that - Anyone know of
> anywhere selling a usb programmer for sensible (hobbyist) amounts? Or
> a way out of my situation? Thanks.
>
> -Alan / randomdude



Article: 77277
Subject: Re: USB JTAG programmers?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 3 Jan 2005 14:22:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter Seng <NOSPAM@seng.de> wrote:
> There is a PCMCIA to Parallel-Port adapter available:
> QUATECH SPP-100,
> Single parallel port PCMCIA card for about 160,00 Euro, it worked well on
> several PC?s...

> And for just configuring - have a look at the FTDI chips and bit-bang
> app-notes:
> http://www.ftdichip.com


The FT2232 has a dedicated serial engine to generate JTAG/SPI/I2C. However I
have not seen an open project for JTASG interface to use this chip.

Bye

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 77278
Subject: Re: VHDL implementation of merge-sort
From: "Swapnajit Mittra" <mittra@juno.com>
Date: 3 Jan 2005 06:40:42 -0800
Links: << >>  << T >>  << A >>
What you want is only the last step of a merge sort.
You still need to need to implement it in VHDL (or
whatever HDL you choose), but here is a pointer
that may help you.

http://www-unix.mcs.anl.gov/dbpp/text/node127.html

--
SystemVerilog DPI tutorial on Project VeriPage:
http://www.project-veripage.com/dpi_tutorial_1.php
For subscribing to Project VeriPage mailing list:
<URL: http://www.project-veripage.com/list/?p=subscribe&id=1>


Article: 77279
Subject: Re: Free IP-Core for FPGA Config from MMC-Cards
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Mon, 03 Jan 2005 15:00:40 GMT
Links: << >>  << T >>  << A >>
I was under the impression that SD was designed to be a superset of MMC, 
e.g. that if you plugged one into an MMC socket the equipment would read it 
in that mode.

That sounds sensible but the SD designers may not have been.

Is it that SD equipment can read both cards but MMC equipment can only read 
MMC?


Your project is very welcome, those configuration memories are way too 
expensive.


I wonder how hard it would be to have a small micro (e.g. AVR 2313?) reading 
a FAT-formatted SD card to get a fixed named file (e.g. FPGA_CFG.ROM) to 
load the FPGA?

That would allow ordinary PC software to just copy the file across, rather 
than have to write to a linear sequence of blocks.

As a useful bonus, the SD card after FPGA-loading might be handed over to 
the target micro for normal memory card duties. So long as it doesn't mess 
around with the FPGA_CFG.ROM file of course!

The target micro may even be the same as the loader micro.

I hear FAT handling is non-trivial, so perhaps having written it for the 
loader micro the loader could also be useful as an I/O slave. Might save a 
lot of porting work.





Article: 77280
Subject: Re: Recover FPGA Verilog or VHDL source from .SOF file
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 03 Jan 2005 07:02:13 -0800
Links: << >>  << T >>  << A >>
highwayismyway wrote:

> Some of the my companies IP cores source has
> disappeared and thought maybe someone here could help me out at
> recovering the missing source.  Does anyone know of any altera
> dissassembler or decompiler for the SOF file?  I'm not particularly
> concerned if the the output is VHDL, verilog, or even AHDL.

It is possible to recover a primitive netlist
of the entire design. However, picking out IP
cores for reuse is not possible.

This situation illustrates the downside of keeping
source code on a single machine.

A disk drive drive can die or take to the highway
at any time without advance notice.

        -- Mike Treseler

Article: 77281
Subject: Re: Free IP-Core for FPGA Config from MMC-Cards
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 03 Jan 2005 07:19:04 -0800
Links: << >>  << T >>  << A >>
Kryten wrote:

> I wonder how hard it would be to have a small micro (e.g. AVR 2313?) reading 
> a FAT-formatted SD card to get a fixed named file (e.g. FPGA_CFG.ROM) to 
> load the FPGA?

Flash file systems are available to do this
if your micro can compile C code.

Vendor-specific versions are sometimes free.

       -- Mike Treseler

Article: 77282
Subject: problem with edk
From: "R!SC" <opb@xilinx.com>
Date: Mon, 03 Jan 2005 15:57:46 GMT
Links: << >>  << T >>  << A >>
Hi all,

i'm first time approch with fpga, i have xilinx ise and edk 6.3i version. 
With XPS I have create a new project with project builder on spartan 3 
starter development kit. When i go to compile the project the programm given 
back   this error:


Performing System level DRCs on properties...
INFO:MDT - List of peripherals addressable from processor instance 
microblaze_0
:
- dlmb_cntlr
- ilmb_cntlr
- debug_module
- Generic_GPIO

Building Directory Structure for microblaze_0
cd: Too many arguments.
ERROR:MDT - Failed to remove G:\Documents and
Settings\risc\microblaze_0\libsrc\.
LibGen Done.
make: *** [microblaze_0/lib/libxil.a] Error 2
Done.


Have you an idea to resolve this problem?

thanks
Regards
R!SC 



Article: 77283
Subject: Re: Recover FPGA Verilog or VHDL source from .SOF file
From: Jim Lewis <Jim@SynthWorks.com>
Date: Mon, 03 Jan 2005 08:28:35 -0800
Links: << >>  << T >>  << A >>
Mark,
If you still have a simulation library for it,
you might find it in one form or another in
there.  For modelsim, these are typically
a directory named work.

Cheers,
Jim

> I realize that this might not be appropriate question for this group,
> but considering the level of knowledge I thought I would see if anyone
> knows much about recovering lost verilog code from a .sof altera
> Quartus FPGA binary?  Some of the my companies IP cores source has
> disappeared and thought maybe someone here could help me out at
> recovering the missing source.  Does anyone know of any altera
> dissassembler or decompiler for the SOF file?  I'm not particularly
> concerned if the the output is VHDL, verilog, or even AHDL.  Because of
> the ethics of reverse engineering I would be willing to present anyone
> with the evidence they might need to verify that my company has all
> copyrights and ownership of the .sof Im asking to derive the source
> code.  Any thoughts how I can do this?
> 
> Mark S.
> 


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 77284
Subject: Re: PCBs for modern FPGAs.
From: "Joanne Moores" <jo@lidwell.wanadoo.co.uk>
Date: Mon, 3 Jan 2005 16:54:24 -0000
Links: << >>  << T >>  << A >>
Hi Sylvain,
Just saw your message; Hotmail relegated your email to my Spam folder!
Anyway, I'm working away in the UK presently, I'll be back at my desk later
this week, when I can give you more detail. I can say that the spacing
between layers 1 and 2 is small. It has to be for the laser drill to work.
IIRC, it's only 2 mil / 2 thousands of an inch. This means that layer 1's
'reference plane' is of course layer 3, but it's not much further away from
layer 1 than layer 2. The consequences are, I suppose, that, for controlled
impedance traces, layer 1 tracks have to be a little thicker. I generally
keep my controlled impedance traces on layer2. Or very short so it doesn't
matter; remember the laser vias enable you to get ICs a lot closer together
than you would otherwise be able to do! Of course, if you're trying to build
accurate controlled impedance traces on layer 1, you don't want to be
putting a lot of layer 2 traces underneath these layer 1 traces. On the
other hand, occasional 90 degree crossings aren't gonna be a problem.
Mentor's Hyperlynx is a great tool for checking this sort of stuff out.
Cheers, Syms.
"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> wrote in message
news:41D6B1AF.2010705@reducespam.com...
> Hello Symon,
>
>
> I'd like more informations about the stackup you use, what are the
thickness of the layers/prepreg ?
> What are the consequences of not having the top layer referenced to a
'near' plane ?
>
>
> Thanks,
>
> Sylvain
>
>
> PS: Note I wrote both to the news group and bcc to you to make sure you
see this answer,
> as the topic is not recent.
>
>
> Symon wrote:
> > All,
> >
> > After reading and contributing to a few interesting threads recently
about
> > PCBs for FPGA designs, I thought I'd post about the technology I've been
> > using for the past 3-4 years. My job involves getting a lot of high
density
> > circuitry into a small space, and so awhile back I decided to use
microvias
> > (laser drilled vias) to pack more stuff onto my boards. The surprising
thing
> > was that the boards worked out cheaper for my application than if I
hadn't
> > used this method.
> >
> > I'll explain why, but you might first want to download the picture at
> >
> > http://www.fpga-faq.org/caf_pics/layer_1_2.gif
> >
> > My stackup is ten layers, like this:-
> >
> >  1) signal
> >
> >  2) signal
> >
> >  3) ground
> >
> >  4) signal
> >
> >  5) signal
> >
> >  6) ground
> >
> >  7) signal
> >
> >  8) signal
> >
> >  9) ground
> >
> > 10) signal
> >
> >
> >
> > There are laser drilled microvias between layers 1 and 2. The only other
> > vias are through vias, i.e. from layer 1 through all layers to layer 10.
> > This means there's still only one mechanical drilling process during
> > manufacture. What you can see in the picture you downloaded is how to
route
> > out all but four of the signal pins on banks 2 and 3 of a V2PRO in a
FG676
> > package without using any through vias, just microvias between the two
> > layers, blue and light green. The track and gap distance is 4mils or
100um.
> > With this technology you can go 8 rows deep on a 1mm pitch BGA without
using
> > through vias.
> >
> > In no particular order, here are the advantages.
> >
> > It's no problem at all to put microvias in a pad. The microvia is just a
> > 2mil deep pit that fills with solder, unlike a through via which must be
> > plugged to stop the solder wicking away.
> >
> > You can use fewer signal layers because the signal paths out from the
FPGA
> > aren't baulked by through vias.
> >
> > You can use fewer (or no) power layers because it's possible to fit a
lot of
> > bypass caps on the back side of the board from the FPGA, with through
vias
> > direct from these to the FPGA power balls. (In the picture you can see
the
> > ground (green) balls and Vcco (yellow) balls. By the time this board
went
> > out, there were two through vias for each power ball.) With a
conventional
> > board, the through vias don't leave space on the backside to fit (m)any
> > caps.
> >
> > You get to have a decent ground plane(s) for your BGA devices, not one
> > turned into Swiss cheese by a myriad through vias. Bye-bye ground
bounce.
> >
> > You gain board area all over the back side of the board simply because
> > there's less space used by the vias from the topside.
> >
> > Compared to a through via, the SI of a microvia is much better. After
all,
> > it's only 1/30th the length of a through via.
> >
> > The components can be closer together, reducing SI issues.
> >
> >
> >
> > I always follow some rules when routing FPGAs this way. Like these:-
> >
> > Draw lines from the four corner balls to the very centre of the part.
Don't
> > let any layer 1 or 2 traces cross these lines, it always seems to screw
> > things up.
> >
> > Be prepared to put much more effort into the PCB. This doesn't work well
> > unless you're prepared to sit down with the layout person and swap pins
on
> > the FPGA as you route things up to align with other components on the
board.
> > For diff pairs be prepared to swap Ps and Ns. You can fix up the
inversion
> > inside the FPGA.



Article: 77285
Subject: Nios II & obj copy this Unknown!!!!!
From: "Jjletodoc" <jimboa@tiscali.it>
Date: Mon, 03 Jan 2005 17:28:12 GMT
Links: << >>  << T >>  << A >>
Hi There,

I am an Nios developer , i build toons of project for this excellent
soft-core, now i migrate to Nios II, nothing problem except one!
i need to convert an .out file to binary using nios2-elf-objcopy ...

the line is : nios2-elf-objcopy -O binary xxxx.out xxxxx.bin

well the binary come is bigger than the .out ,, normally is the
contrary!!!!!

i've used every parameter to resize the bin but they don't work..

An Exemples...
Nios 1 : .out = 500k .bin = ~200k
Nios 2 : .out = 500k . bin = ~ 1200k !!!!!! why?

please help me

Best Regards
Jjleto!



Article: 77286
Subject: Re: Recover FPGA Verilog or VHDL source from .SOF file
From: "rcarlson" <rcarlson@skytekinc.com>
Date: 3 Jan 2005 10:29:02 -0800
Links: << >>  << T >>  << A >>
I have done this many times as a contract for other companies that have
lost Verilog, VHDL, or AHDL source code.  Its quite common to have a
.sof in control from manufacturing and missing the source code.  For
example, if the designer leaves a company and his desktop is lost or
changed by IT or if the designer's hard drive has a sudden death and is
not under control or backed up.  The end result of my disassembling /
decompiling the FPGA binary will be much better than a netlist as it
will be readable (.v), (.vhdl) .  I usually charge anywhere from $3,000
to $7,000 US dollars for the time required in reobtaining the source
code depending on the type of FPGA and the amount of LUTS used.  I can
usually have the source within a time frame of 2 weeks to a month
depending on my schedule at the time.

If you would like me to give you a quote on recovering your source code
you can send me an email at:

rcarlson "|AT|" @ skytekinc. "|DOT| " com  <=====My correct email is
without the spaces and "|AT|" and "|DOT|" quotes above.  This is to
prevent the spammers from getting my correct email by parsing the
messages on this board.

Rod Carlson
Senior Hardware Engineer
Sky Tek Inc.

> I realize that this might not be appropriate question for this group,
> but considering the level of knowledge I thought I would see if
anyone
> knows much about recovering lost verilog code from a .sof altera
> Quartus FPGA binary? Some of the my companies IP cores source has
> disappeared and thought maybe someone here could help me out at
> recovering the missing source. Does anyone know of any altera
> dissassembler or decompiler for the SOF file? I'm not particularly
> concerned if the the output is VHDL, verilog, or even AHDL. Because
of
> the ethics of reverse engineering I would be willing to present
anyone
> with the evidence they might need to verify that my company has all
> copyrights and ownership of the .sof Im asking to derive the source
> code. Any thoughts how I can do this?

> Mark S.


Article: 77287
Subject: Re: Multipliers implementation (xilinx)
From: Sam <totalsam-n.o-s.p.a.m@hotmail.com>
Date: Mon, 03 Jan 2005 19:34:35 +0100
Links: << >>  << T >>  << A >>
Ok, thank you for these answers !

Sam

Article: 77288
Subject: Re: Free IP-Core for FPGA Config from MMC-Cards
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Mon, 03 Jan 2005 19:40:03 GMT
Links: << >>  << T >>  << A >>

"Mike Treseler" <mike_treseler@comcast.net> wrote in message 
news:qZWdnYYDOKj0_0TcRVn-gQ@comcast.com...
> Kryten wrote:
>
>> I wonder how hard it would be to have a small micro (e.g. AVR 2313?) 
>> reading a FAT-formatted SD card to get a fixed named file (e.g. 
>> FPGA_CFG.ROM) to load the FPGA?
>
> Flash file systems are available to do this
> if your micro can compile C code.
>
> Vendor-specific versions are sometimes free.

If/when I have time I will look around for code.

There are some amateur MP3 player projects on the web, using FAT but they 
tend to use IDE drives or CF cards. Oh well, they might be a fair starting 
point...



Article: 77289
Subject: Skew between signals
From: aktaeon@gmail.com (Michel Bieleveld)
Date: 3 Jan 2005 12:55:45 -0800
Links: << >>  << T >>  << A >>
The problem is that i have two output signals, CE and WE, now i want
to "schedule" the rising of WE just after the rising of CE.

I tried it by putting the rising statement of CE earlier in the
process than the rising of WE, unfortunately, but expectly, without
any succes.

So how can i "schedule" the rising of the signal after the other. I
don`t want to do doubling of the clock, using both clock edges, etc. I
hope to do it with just constraints in Xilinx ISE.

So can anyone tell me how to fix this problem, any info would be
appreciated !

Michel Bieleveld.

Article: 77290
Subject: Large open source FPGAs?
From: "David Kanter" <dkanter@gmail.com>
Date: 3 Jan 2005 13:00:51 -0800
Links: << >>  << T >>  << A >>
Hi,

I am interested in doing some performance profiling and benchmarking
using FPGA software.  Right now, I am looking for a large open source
FPGA to play around with.  Unfortunately, I don't have a good sense of
what constitutes a 'large' FPGA.  Right now, I am working with a 35k
gate USB controller that was suggested to me (I believe it's available
through opencores.org).  Does anyone have some other suggestions?

Thanks in advance, I would really appreciate some advice and guidance
on the matter.


David Kanter


Article: 77291
Subject: Re: Skew between signals
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 3 Jan 2005 22:02:31 +0100
Links: << >>  << T >>  << A >>

"Michel Bieleveld" <aktaeon@gmail.com> schrieb im Newsbeitrag
news:47fe273e.0501031255.4e19d7fc@posting.google.com...

> The problem is that i have two output signals, CE and WE, now i want
> to "schedule" the rising of WE just after the rising of CE.
>
> I tried it by putting the rising statement of CE earlier in the
> process than the rising of WE, unfortunately, but expectly, without
> any succes.

Sure, we are talking about real world, synthesizable HDL. The delay
statements in VHDL are for simulation only.
VHDL is concurrent, statements are processed in parallel as fast as possible
(given by the target technology).

> So how can i "schedule" the rising of the signal after the other. I
> don`t want to do doubling of the clock, using both clock edges, etc. I
> hope to do it with just constraints in Xilinx ISE.

Hope is good, but basic understading of things is better.
So how do you think such a thing might be possible.?? Adding a RC-Filter to
an IO?
There are serval tricks to get a more or less usefull workaround, but a
reliable and safe way is to use a clock (and maybe the inverted edge).
Nothing wrong with this.
You can "adjust" the phase relation also by setting the IO driver to
different driving strength and slew rates, but this is IMHO not a clean way
(phase will vary with VCC and temperature)

Regrads
Falk




Article: 77292
Subject: Re: Large open source FPGAs?
From: Marius Vollmer <mvo@zagadka.de>
Date: Mon, 03 Jan 2005 22:41:30 +0100
Links: << >>  << T >>  << A >>
"David Kanter" <dkanter@gmail.com> writes:

> Does anyone have some other suggestions?

You could try LEON, a Sparc processor with AMBA and peripherals:

    http://www.gaisler.com,

Direkt link to LEON, but a frame:

    http://www.gaisler.com/products/leon2/leon_down.html

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

Article: 77293
Subject: Re: Large open source FPGAs?
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Mon, 03 Jan 2005 22:42:44 +0100
Links: << >>  << T >>  << A >>
Hi

> I am interested in doing some performance profiling and benchmarking
> using FPGA software.  Right now, I am looking for a large open source
> FPGA to play around with.  Unfortunately, I don't have a good sense of
> what constitutes a 'large' FPGA.  Right now, I am working with a 35k
> gate USB controller that was suggested to me (I believe it's available
> through opencores.org).  Does anyone have some other suggestions?

Well, "open source FPGA" is an abuse of language, a fpga is a hardware piece.
The "cores" or "IP blocks" you program/load in them are open sources.

If you're just looking for a "big" thing. Look at gaisler leon 3. It's a
complete SoC solution with differents cores in it, you can surely configure
it to become pretty large. And it's also more "polyvalent" since you have
cpu core, memory controller, pci , ...


Sylvain

Article: 77294
Subject: Re: Skew between signals
From: "Eric" <ericjohnholland@hotmail.com>
Date: 3 Jan 2005 14:53:09 -0800
Links: << >>  << T >>  << A >>
if you want WE to toggle after CE you have two states not one (If you
think of your design as a state machine). So doubling the clk is the
best solution. That way you'll have WE toggle on one clk edge and CE
toggle on the next.

It's not the answer you wanted to hear, but i think it is the way that
will get you the most consistant results.

Eric


Article: 77295
Subject: Re: Large open source FPGAs?
From: "David Kanter" <dkanter@gmail.com>
Date: 3 Jan 2005 15:06:28 -0800
Links: << >>  << T >>  << A >>

Sylvain Munaut wrote:
> Hi
>
> > I am interested in doing some performance profiling and
benchmarking
> > using FPGA software.  Right now, I am looking for a large open
source
> > FPGA to play around with.  Unfortunately, I don't have a good sense
of
> > what constitutes a 'large' FPGA.  Right now, I am working with a
35k
> > gate USB controller that was suggested to me (I believe it's
available
> > through opencores.org).  Does anyone have some other suggestions?
>
> Well, "open source FPGA" is an abuse of language, a fpga is a
hardware piece.
> The "cores" or "IP blocks" you program/load in them are open sources.

I should have known that; thanks for the pointer.  Nothing beats
looking like a n00b...

> If you're just looking for a "big" thing. Look at gaisler leon 3.
It's a
> complete SoC solution with differents cores in it, you can surely
configure
> it to become pretty large. And it's also more "polyvalent" since you
have
> cpu core, memory controller, pci , ...

That might be interesting.  My rationale for looking for something
"big" is that I would like to have reasonably long run times.  The USB2
controller I was working with took under a minute to synthesize.  One
of the problems is that I would like my workload to be as 'real world'
as possible, and testing EDA tools with tiny chips isn't very
interesting for those who really are using them for work.

I don't really know enough FPGA's to explain, but for an ASIC, I am
pretty sure that the time to do an extraction for a 1mm^2 chip will be
almost entirely uncorrelated to the time for an extraction of similar
quality on a 370mm^2 behemoth.  The real issue is trying to get a
realistic workload and my feelings are that most of what I have seen at
opencores.org are 'small'.
Thanks for your help everyone I appreciate the comments!


David Kanter


Article: 77296
Subject: Re: USB JTAG programmers?
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Tue, 4 Jan 2005 00:34:46 +0100
Links: << >>  << T >>  << A >>
> > And for just configuring - have a look at the FTDI chips and bit-bang
> > app-notes:
> > http://www.ftdichip.com
>
>
> The FT2232 has a dedicated serial engine to generate JTAG/SPI/I2C. However
I
> have not seen an open project for JTASG interface to use this chip.
>
If someone cares to do something...

The AT91SAM7S64 is nice for the job.
* USB Client
* ARM7 running at 48 MHz (will not handle 70'C at this temp though)
* Built in Flash and SRAM
* High speed synch interface for JTAG Master

This should be MUCH MUCH fatser than bitbanging.
There is of course the small matter of programming...

The AT91SAM7A3 is even better, but availability of production part is later.

Couped with a dataflash on the SPI bus you coul dbuild a device which
looks like a USB Mass Storage Device so you could easily download
the bitstream, and at powerup the ARM would configure the FPGA(s)

Too lazy to do it myself, but I am sure it would be sellable.

Best Regards
ulf at a-t-m-e-l.doth com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB




Article: 77297
Subject: Re: Skew between signals
From: "Purvesh" <purveshkhona@yahoo.com>
Date: 3 Jan 2005 16:51:47 -0800
Links: << >>  << T >>  << A >>
What Eric is suggesting is the cleanest way to do things.

Another alternative without going thru re designing logic too much is
to use DCM to generate half frequency clk phase shifted by what ever
delay you want. Use that clock as a gate to your WE. This will cause
bad output times on you WE and could be a concern if you are planning
to run at very high speeds and there is no margin to play with (if
board delay plus set up times plus clk to q are barely meeting).

Else if you are generating WE thru a flop, things are still easier. Use
DCM to generate same frequency clk as your core clk, delay phase shift
by whatever amount you want and use that to clock your WE.

Hope all these help,

Regards,

Purvesh

Eric wrote:
> if you want WE to toggle after CE you have two states not one (If you
> think of your design as a state machine). So doubling the clk is the
> best solution. That way you'll have WE toggle on one clk edge and CE
> toggle on the next.
>
> It's not the answer you wanted to hear, but i think it is the way
that
> will get you the most consistant results.
> 
> Eric


Article: 77298
Subject: Re: problem with edk
From: "newman5382" <newman5382@yahoo.com>
Date: Tue, 04 Jan 2005 01:32:28 GMT
Links: << >>  << T >>  << A >>
Last time I checked with EDK6.2i, it did not like embedded spaces in the 
path name.  IIRC, one could either put the files in a path without embedded 
spaces, or use the subst command.

- Newman

"R!SC" <opb@xilinx.com> wrote in message 
news:_XdCd.622615$35.25734702@news4.tin.it...
> Hi all,
>
> i'm first time approch with fpga, i have xilinx ise and edk 6.3i version. 
> With XPS I have create a new project with project builder on spartan 3 
> starter development kit. When i go to compile the project the programm 
> given back   this error:
>
>
> Performing System level DRCs on properties...
> INFO:MDT - List of peripherals addressable from processor instance 
> microblaze_0
> :
> - dlmb_cntlr
> - ilmb_cntlr
> - debug_module
> - Generic_GPIO
>
> Building Directory Structure for microblaze_0
> cd: Too many arguments.
> ERROR:MDT - Failed to remove G:\Documents and
> Settings\risc\microblaze_0\libsrc\.
> LibGen Done.
> make: *** [microblaze_0/lib/libxil.a] Error 2
> Done.
>
>
> Have you an idea to resolve this problem?
>
> thanks
> Regards
> R!SC
> 



Article: 77299
Subject: Using LM317S adjustable linear regulator for Spartan 3?
From: Eric Smith <eric@brouhaha.com>
Date: 03 Jan 2005 19:49:41 -0800
Links: << >>  << T >>  << A >>
Is there any reason why using an LM317S adjustable linear regulator with
1% resistors wouldn't be satisfactory for the Spartan 3 power supplies,
particularly Vccint and Vccaux?

I have a cost-sensitive application for which the LM317S looks to be
much less expensive than using fixed-output LDO regulators, e.g.,
$0.58 for the LM317S vs. $4.45 for an LP3881ES-1.2 for Vccint.

Thanks for any advice!
Eric



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