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 80575

Article: 80575
Subject: Re: Good, affordable verilog simulator
From: "Paul Taddonio" <paul.taddonio@futureplus.com>
Date: Tue, 8 Mar 2005 10:47:14 -0800
Links: << >>  << T >>  << A >>
Kevin, I wouldn't mind simulating in VHDL, but the Xilinx tool won't let me setup any of the "create simulation model" processes to output VHDL. I only get a variety of verilog flavors to choose from. (My source files are verilog.) Do you know a different way?

Article: 80576
Subject: Re: Hierarchical Synchronous Design
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 08 Mar 2005 10:47:57 -0800
Links: << >>  << T >>  << A >>
valentin tihomirov wrote:
> I wonder how you can so easily speak about adding regisers somewhere in the
> circuit.

It's more a question of where do you
want to draw the boxes for a multi-module
design. With no rules at all you will have
a random collection of interfaces at
the ports:
<><>out]--[in<><>
1.  reg to  reg
2. flop to flop
3.  reg to flop
4. flop to  reg

1. Complicates timing.
2. Wastes flops
3. Is backwards from hdl synthesis
which assumes but does not enforce
synchronous inputs and creates registered
outputs.

So I say type 4 only:
All modules have plain inputs
and registered outs.

> Wouldn't it change the functionality of the circuit (missing
> cycles)? Consider a MUX(S, A, B): you cannot just FF the outputs as this
> will break the contract inferring a cycle delay.

Yes. Registering an output involves a one tick delay.
Consider simulation to get each module lined up right.

       -- Mike Treseler

Article: 80577
Subject: Re: state encoding in FSM for simple cases ?
From: Jason Zheng <xin.zheng@jpl.nasa.gov>
Date: Tue, 08 Mar 2005 10:51:17 -0800
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Jason Zheng wrote:
> 
>> 3%? I wonder how you implemented your 1-hot state machine.
> 
> 
> By changing a synthesis option setting.
> The state type is just an enumeration. See:
> http://home.comcast.net/~mike_treseler/uart.vhd
>     -- Mike Treseler
I'm not a VHDL coder but I read your code and have a feeling that your 
VHDL code did not synthesize to an optimal one-hot state machine. In 
verilog, there's a synthesis directive called "full-case" which tells 
the synthesizer that all the cases are covered and it doesn't need to 
generate the default case, which can kill 1-hot performance.

Article: 80578
Subject: Re: Asynchronous processor !?!
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 09 Mar 2005 07:51:40 +1300
Links: << >>  << T >>  << A >>
Peter Sommerfeld wrote:
> Great, thanks for the link. They're results are that the sync and async
> versions of the same processor have the same area, speed, and power
> consumption except that the async version apparently has less EMI. I
> was hoping the async design would have advantages in other areas, but I
> guess not.

  This was done using FPGA tool flows, designed for Sync use, and also
speed files done the same way - So I would not read too much into
the area and speed comparisons.
  I'm impressed they got it to go thru the tools at all :)

  Keeping the async handshakes safe is likely to consume area, but you 
could expect to save on less beefy global glock trees and drivers.

  The benefits I expect Epson see from Async, are more in deployment than
area or speed - if they can save hot spots, eliminate regulators, and
spread the EMI, as well as extend battery life, those are all important
gains to make in portable consumer equipment.

-jg


Article: 80579
Subject: Re: Hierarchical Synchronous Design (corrected)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 08 Mar 2005 10:57:43 -0800
Links: << >>  << T >>  << A >>
valentin tihomirov wrote:
> I wonder how you can so easily speak about adding regisers somewhere in the
> circuit. 
(corrected reply)
It's more a question of where do you
want to draw the boxes for a multi-module
design. With no rules at all you will have
a random collection of interfaces at
the ports:
<><>out]--[in<><>
1. gate to gate
2.  reg to reg
3. gate to reg
4.  reg to gate

1. Complicates timing.
2. Wastes  regs
3. Is backwards from hdl synthesis
which assumes but does not enforce
synchronous inputs and creates registered
outputs.

So I like type 4 only:
All modules have plain inputs
and registered outs.

 > Wouldn't it change the functionality of the circuit (missing
 > cycles)? Consider a MUX(S, A, B): you cannot
 > just FF the outputs as this
 > will break the contract inferring a cycle delay.

Yes. Registering an output involves a one tick delay.
Consider simulation to get each module lined up right.

       -- Mike Treseler

Article: 80580
Subject: Re: Good, affordable verilog simulator
From: "Paul Taddonio" <paul.taddonio@futureplus.com>
Date: Tue, 8 Mar 2005 10:59:17 -0800
Links: << >>  << T >>  << A >>
OK, I found the documentation on NetGen. I'll give it a try. Thanks everyone for responding.

Article: 80581
Subject: Async FIFO problem...
From: Paul Davis <rft56@dsl.nospam.pipex.com>
Date: Tue, 08 Mar 2005 19:04:09 +0000
Links: << >>  << T >>  << A >>
Yet another async FIFO question... :(

I've inherited an async FIFO that doesn't work. This is, I think, a
fairly standard implementation. On the write port, a clock and a write
enable increment a write pointer, and write the write data into a RAM.

The read pointer is Gray-coded, clocked into a reg on the write clock,
inverse coded, and then compared with the write pointer, to give a
write-side full flag.

The read side is simply the inverse of the write side.

So far, so good. The problem is that this design assumes a
free-running write clock, and my write clock is not free-running; I
simply generate a clock when the (unpredicatable) write data appears.
The write enable is therefore effectively redundant.

The problem arises because the 'fifo full' flag is generated by the
*write* clock. If, on write X, the comparator determines that the FIFO
is full, then the full flag is generated, and I don't create any more
write clocks. The read side might empty the FIFO, but this information
never gets back to the write port, because the register that samples
the Gray-coded read pointer is clocked by the write clock.

Any ideas on how I re-design this to cope with a write clock which
isn't free-running?

TIA -

Paul

Article: 80582
Subject: Basic cheap fpga configuration
From: Andy Main <a.s.main@gmail.com>
Date: Tue, 08 Mar 2005 19:07:15 +0000
Links: << >>  << T >>  << A >>
Hi there,

Please excuse my quite probably lame, simple question but I've been 
searching on the net for a while and haven't really answered myself yet!

I'm not at all used to programming fpga's, as my work has only ever been 
with ASICs, and on a customer level.  Now I've aquired some small 15k 
fpga's (XC2S15's) to put small state machines in, however I'm not 
entirely sure how to hold my bitstream.  Now the official flash prom's 
seem very expensive to me (at least at my supplier).  I read the xapp079 
app note and realise I could use a parallel eeprom.  Now, could I use 
something like the AT29 flash PEROM from Atmel for this?  Can I program 
it using the download cable - it doesn't seem to have a JTAG, so I don't 
get how to do this without a seperate programmer for the device.

Would someone mind just walking me through my options like I'm a baby!? 
I'm a hobbiest, so I really want to do it on the cheap and don't want to 
buy any tools etc.

Many thanks,

Andy Main.

Article: 80583
Subject: Re: Surge in S2? ~3 amperes at cold for a millisecond
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 08 Mar 2005 19:09:08 GMT
Links: << >>  << T >>  << A >>
"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message
news:1110304872.233206.130150@z14g2000cwz.googlegroups.com...
<snip>
> how hard is it to put a 2A supply on the board?
>
> Regards,
>
> Paul


The issue of startup current surge problems has been addressed on this
newsgroup before with battery-operated designs stresing seriously to supply
the startup surge.  Chips without inrush are so much nicer to work with.

If it's a non-problem, why would Altera bother to state on

http://www.altera.com/products/devices/stratix2/features/st2-competitive.html

that "Because Virtex-4 power-up specifications are higher than its static
current, it draws in-rush current spike during power-up" and show an inrush
spike in the graph if there is no inrush in Virtex-4 devices just as there
is no inrush in the other Stratix-II devices?  Scope traces sure would be
nice for *that* graph.

There are designers that need well behaved chips because they don't have the
luxury of wired supplies and those engineers that have been bitten by the
problems in past designs will look for the issue even if it doesn't matter
as much to their current designs.



Article: 80584
Subject: dsbram memory addressing
From: "Mindroad" <mindroad@hotmail.com>
Date: Tue, 8 Mar 2005 20:16:29 +0100
Links: << >>  << T >>  << A >>
Hi,

After I builded my design in EDK and made a toplevel VHDL in ISE, I started
writing code for both PPC on my V2P20 ... the first PPC serves as an
Communication unit which transfers data in between memories, accessible by
external device ... I have no problem whatsoever accessing these memories,
either on opb or plb busses
When I started the part of interconnecting the two PPC with a BRAM memory
using DSOCM I encountered the following problem, which up to know I cannot
solve (this is the first time I design on FPGA) ...

To access the BRAM from the first PPC serving as Comm Unit I used the code
which worked for accessing memories on the PLB since I suppose the
addressing of memories is always in the same way, as if we address one big
memory

code :
Xuint32 * bram_Ptr = XPAR_BRAM_BASE_ADDR;
Xuint32 value = *bream_Ptr;

When I download the bit file on the FPGA, the system hangs, when executing
these commands

can someone help me with this problem, I spend some time looking for the
solution and I found some macros in xio.h, but I have no clue how to use
them, and when I look into application notes, it appears nothing is ever
said about how accessing BRAM, so it must be straightforward

thx in advance

could be I miss some parameters or connections in the MHS file, but I doubt
it since all should almost be set by default

BEGIN dsocm_v10
<--- connected to the PPC405 through bus interface
 PARAMETER INSTANCE = dsocm_v10_0
 PARAMETER HW_VER = 2.00.a
 PARAMETER C_DSCNTLVALUE = 0x85
 PORT DSOCM_Clk = sys_clk
 PORT sys_rst = sys_rst_l
END

BEGIN dsbram_if_cntlr
 PARAMETER INSTANCE = dsbram_if_cntlr_0
 PARAMETER HW_VER = 3.00.a
 PARAMETER C_BASEADDR = 0xF0000000
 PARAMETER C_HIGHADDR = 0xF0001fff
 BUS_INTERFACE DSOCM = dsocm_v10_0
 BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
END

BEGIN bram_block
 PARAMETER INSTANCE = bram_block_0
 PARAMETER HW_VER = 1.00.a
 BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
 BUS_INTERFACE PORTB = dsbram_if_cntlr_1_porta
END




could be I made some mistake in my linker script :

_STACK_SIZE     = 1k;
_DOCM_SIZE = 8k;

MEMORY
{
  plb_bram_if_cntlr_1_bram : ORIGIN = 0xFFFF0000, LENGTH = 16K
  plb_bram_if_cntlr_2_bram : ORIGIN = 0xFFFF8000, LENGTH = 32K
  dsbram_if_cntlr_0_porta : ORIGIN = 0xF0000000, LENGTH = 8K
}
...



Article: 80585
Subject: Re: Surge in S2? ~3 amperes at cold for a millisecond
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: 8 Mar 2005 12:02:47 -0800
Links: << >>  << T >>  << A >>
Hi John,

> The issue of startup current surge problems has been addressed on
this
> newsgroup before with battery-operated designs stresing seriously to
supply
> the startup surge.  Chips without inrush are so much nicer to work
with.

I agree -- better not to have in-rush.  But for most applications of
high-end FPGAs (few of which are battery operated), working around an
in-rush spike is not a big deal.  And I should point out that if you
are using a 2S60ES to actually do something, you're likely using
something 2A+ for static + dynamic anyway.

> If it's a non-problem, why would Altera bother to state on
>
>
http://www.altera.com/products/devices/stratix2/features/st2-competitive.html
>
> that "Because Virtex-4 power-up specifications are higher than its
static
> current, it draws in-rush current spike during power-up" and show an
inrush
> spike in the graph if there is no inrush in Virtex-4 devices just as
there
> is no inrush in the other Stratix-II devices?  Scope traces sure
would be
> nice for *that* graph.

The V-4 plot is based on Xilinx's spec.  See "Virtex-4 Data Sheet:  DC
and Switching Characteristics" Table 5 and compare to Table 4.  For the
LX60, "Typical" (nominal Si, 25C) leakage is 167 mA on IccInt while
"typical" power-on current is 303 mA for IccInt.  For IccAux, the
numbers are 74 mA and 222 mA respectively.

I do not have a scope shot, but I trust they had good reason to publish
their specs.  Even if I measured a chip, there is no guarentee that
unit I measured would be at the "typical" point as far as start-up vs.
leakage is concerned.  Whenever Xilinx gets around to publishing
worst-case specs, it would be even more meaningless for me (or you) to
try to capture the spec'ed behaviour on a scope, given that you are
very unlikely to have a worst-case unit in your hands.

So V4 has a power-up surge.  Does this mean V4 is a bad or "broken"
chip?  No -- at least, as far as I can tell without a published
worst-case spec.  Oh yeah, and the spec given is only valid if VccAux
ramps before VccO (paragraph 2, page 5 of datasheet)... so I don't know
what happens in arbitrary ordering, for example when you want to be
hot-socket compliant.

Our point in showing this graph is that the power-on surge really
doesn't matter much anyway since operating power requirements dominate.
 This was in response to some Xilinx FUD where they treated our
previously published instantaneous current spec as if it was a "power"
consumption (only valid for a constant current draw), whereas for most
applications you really only care about operating power.  All that
graph is meant to show is that (a) Stratix II has no power-on surge and
(b) even for a chip (V4) that has one, it probably isn't a dominant
effect.
 
Regards,

Paul Leventis
Altera Corp.


Article: 80586
Subject: Re: What's the Altera Equivalent of a Xilinx .rbt file?
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Tue, 08 Mar 2005 20:38:14 GMT
Links: << >>  << T >>  << A >>
Hi Jock,

> For the Xilinx we used the .rbt file which is an ASCII version of the .bit
> file.
> 
> Does anyone know what the Altera equivalent of the .rbt file is?

That would be the .ttf file. You can find it under
Assignments->Device->Device and pin options->Programming files.

Best regards,


Ben


Article: 80587
Subject: Re: Async FIFO problem...
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 08 Mar 2005 20:47:29 GMT
Links: << >>  << T >>  << A >>
Hi - 

What's clocking the logic that's looking at the full flag?  Is it by
any chance an ungated version of the write clock?

Bob Perlman
Cambrian Design Works

On Tue, 08 Mar 2005 19:04:09 +0000, Paul Davis
<rft56@dsl.nospam.pipex.com> wrote:

>Yet another async FIFO question... :(
>
>I've inherited an async FIFO that doesn't work. This is, I think, a
>fairly standard implementation. On the write port, a clock and a write
>enable increment a write pointer, and write the write data into a RAM.
>
>The read pointer is Gray-coded, clocked into a reg on the write clock,
>inverse coded, and then compared with the write pointer, to give a
>write-side full flag.
>
>The read side is simply the inverse of the write side.
>
>So far, so good. The problem is that this design assumes a
>free-running write clock, and my write clock is not free-running; I
>simply generate a clock when the (unpredicatable) write data appears.
>The write enable is therefore effectively redundant.
>
>The problem arises because the 'fifo full' flag is generated by the
>*write* clock. If, on write X, the comparator determines that the FIFO
>is full, then the full flag is generated, and I don't create any more
>write clocks. The read side might empty the FIFO, but this information
>never gets back to the write port, because the register that samples
>the Gray-coded read pointer is clocked by the write clock.
>
>Any ideas on how I re-design this to cope with a write clock which
>isn't free-running?
>
>TIA -
>
>Paul


Article: 80588
Subject: Re: Async FIFO problem...
From: "Peter Alfke" <peter@xilinx.com>
Date: 8 Mar 2005 13:36:30 -0800
Links: << >>  << T >>  << A >>
This might be very tricky. That's why I always demand free-running
clocks.
FULL gets set by the write clock, which is ideal, since only the write
side is interested in FULL.
But FULL gets reset by a write clock, and that is inherently
asynchronous to any write operation. So one has to do some trickery to
move the falling edge of FULL back to the write clock domain. That's
where metastability can bite you.
And the same is also true for EMPTY ( with the clock names reversed).
The extra delay encountered at the trailing edge of FULL ( or EMPTY)
really does not matter, as long as it's just a few clock ticks. It just
means the FIFO pretends to be FULL (or EMPTY) a few cycles longer than
necessary. No big deal.

Maybe this helps to get your creative juices flowing. Your challenge is
non-trivial.
Peter Alfke, Xilinx Applications ("FIFO is my middle name")


Article: 80589
Subject: Re: Async FIFO problem...
From: Paul Davis <rft56@dsl.nospam.pipex.com>
Date: Tue, 08 Mar 2005 21:42:22 +0000
Links: << >>  << T >>  << A >>
On Tue, 08 Mar 2005 20:47:29 GMT, Bob Perlman
<bobsrefusebin@hotmail.com> wrote:

>Hi - 
>
>What's clocking the logic that's looking at the full flag?  Is it by
>any chance an ungated version of the write clock?

No - it's just the write clock that gets supplied to the FIFO. I do
create the clock myself, though - it's a combination of various
signals from two other clock domains. There isn't a free-running
precursor to this signal in one of the two domains (presumably that's
what you meant?)

- Paul

Article: 80590
Subject: Re: Async FIFO problem...
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Tue, 08 Mar 2005 14:44:05 -0700
Links: << >>  << T >>  << A >>
Paul Davis wrote:
> Yet another async FIFO question... :(
> 
> I've inherited an async FIFO that doesn't work. This is, I think, a
> fairly standard implementation. On the write port, a clock and a write
> enable increment a write pointer, and write the write data into a RAM.
> 
> The read pointer is Gray-coded, clocked into a reg on the write clock,
> inverse coded, and then compared with the write pointer, to give a
> write-side full flag.
> 
> The read side is simply the inverse of the write side.
> 
> So far, so good. The problem is that this design assumes a
> free-running write clock, and my write clock is not free-running; I
> simply generate a clock when the (unpredicatable) write data appears.
> The write enable is therefore effectively redundant.
> 
> The problem arises because the 'fifo full' flag is generated by the
> *write* clock. If, on write X, the comparator determines that the FIFO
> is full, then the full flag is generated, and I don't create any more
> write clocks. The read side might empty the FIFO, but this information
> never gets back to the write port, because the register that samples
> the Gray-coded read pointer is clocked by the write clock.
> 
> Any ideas on how I re-design this to cope with a write clock which
> isn't free-running?
> 
> TIA -
> 
> Paul
I think it was common back in the day to have FIFOs without free-running 
clocks but these have mostly disappeared.  What you really want to do, 
if at all possible, is to make the write clock free-running and gate it 
with the write enable.  If you have a gated write clock, you introduce a 
lot of timing issues, and the whole point of the asynchronous FIFO is to 
encapsulate the domain-crossings and abstract those problems away from 
you.  You can change the full flag so that it is clocked by the read 
domain, but then, again, you are reading it in a different domain and 
have domain-crossing issues.  You want all of the domain crossings to be 
between the gray-coded pointers inside the FIFO.
-Kevin

Article: 80591
Subject: Re: Basic cheap fpga configuration
From: "Gabor" <gabor@alacron.com>
Date: 8 Mar 2005 14:01:20 -0800
Links: << >>  << T >>  << A >>

Andy Main wrote:
> Hi there,
>
> Please excuse my quite probably lame, simple question but I've been
> searching on the net for a while and haven't really answered myself
yet!
>
> I'm not at all used to programming fpga's, as my work has only ever
been
> with ASICs, and on a customer level.  Now I've aquired some small 15k

> fpga's (XC2S15's) to put small state machines in, however I'm not
> entirely sure how to hold my bitstream.  Now the official flash
prom's
> seem very expensive to me (at least at my supplier).  I read the
xapp079
> app note and realise I could use a parallel eeprom.  Now, could I use

> something like the AT29 flash PEROM from Atmel for this?  Can I
program
> it using the download cable - it doesn't seem to have a JTAG, so I
don't
> get how to do this without a seperate programmer for the device.

I looked on the web for XCF01SVO20C and got a web price of $3.15
If this is expensive to you, I don't see what you're going to do with
the AT29 flash.  This is a 1Mbit part big enough to program about 5
of your XC2S15's if you chain them.  It has JTAG and works with the
Xilinx iMPACT software.  Good luck doing better with less effort.

>
> Would someone mind just walking me through my options like I'm a
baby!?
> I'm a hobbiest, so I really want to do it on the cheap and don't want
to 
> buy any tools etc.
> 
> Many thanks,
> 
> Andy Main.


Article: 80592
Subject: Re: Async FIFO problem...
From: Paul Davis <rft56@dsl.nospam.pipex.com>
Date: Tue, 08 Mar 2005 22:12:15 +0000
Links: << >>  << T >>  << A >>
On 8 Mar 2005 13:36:30 -0800, "Peter Alfke" <peter@xilinx.com> wrote:

>Maybe this helps to get your creative juices flowing. Your challenge is
>non-trivial.

No kidding... :)
Luckily, I'm on an hourly rate. Just checking that there weren't any
simple answers.

I recall using small discrete FIFOs about 10 or 15 years ago that
bubbled through read and write ops, and that only required a single
write strobe. I may try to look it up (a 7400 device?), but I remember
being surprised that they worked at all.

- Paul

Article: 80593
Subject: Using BUFG with internally generated clocks
From: Di Pascale <dipascale@aliceposta.it>
Date: Tue, 08 Mar 2005 22:22:49 GMT
Links: << >>  << T >>  << A >>
I'm trying to use a Xilinx XC2VP20 (Virtex II Pro family) to prototype 
an ASIC device but I'm experiencing a lot of trouble cause i'm new to FPGA.
The problem is that my project has various asyncronous clocks generated 
internally by means of dividers and NCOs. I would like to route these 
clocks through low skew lines by instantiating BUFG blocks (I've read on 
the Virtex II Pro user guide that it is possible) but even if XST 
compiles without errors ISE is not able to translate the design.
Does anyone knows if I'm trying the impossible or has any suggestion?
Any help will be strongly appreciated...

Article: 80594
Subject: Re: Good, affordable verilog simulator
From: aa55 <aa55@nospam.invalid>
Date: Wed, 09 Mar 2005 09:41:27 +1100
Links: << >>  << T >>  << A >>
Paul Taddonio wrote:
>We have a tight schedule so I will stick with the familiar language. 
>Any suggestions would be appreciated.

Going from Verilog to VHDL isn't as big a headache as you think.
Go to http://www.confluent.org/wiki/doku.php and click on HDL comparison 
to get a quick guide on the differences in Confluence, Verilog and VHDL.

Article: 80595
Subject: SPROM for Spartan II
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 08 Mar 2005 17:01:22 -0600
Links: << >>  << T >>  << A >>
Hello, all,

I am working on an update for a board that now uses an original 5-V Spartan
(XCS30) part.  To reduce cost, I'm looking at using the Spartan II XC2S30
part, which is less than half the price.  (I'd go with the Spartan IIE, 
but the smallest
is 50K gates, and config bitstream is about double the 2S30's 
requirement, which
negates the price advantage.)  Anyway, there are some 512KBit serial PROMs
available from some other makers that are 1/10th the cost of the Xilinx 
parts.
But, they max out at 400 Kbits/second, and the SpartanII starts 
configuring at
2.5 MBits /second in master serial mode.  I think I have come up with a very
simple circuit to divide my system clock down and sync INIT/  to it, so 
that I can
run the SpartanII in slave serial mode with a clock rate appropriate for 
the slow
SPROM.  I think I can do it in 2 74HCxx packages.  Does anyone have any 
comments
on this?  Have you done something similar?

(This particular product has no CPU onboard.  I suppose I could come up 
with a way
to configure the FPGA from a host CPU, but there are a few reasons I 
might want
to avoid that.)

Thanks,

Jon


Article: 80596
Subject: Re: Using BUFG with internally generated clocks
From: "pablo" <raonpc@gmail.com>
Date: 8 Mar 2005 15:07:25 -0800
Links: << >>  << T >>  << A >>
Hi,
  Check the availability of BUFG's in your device(do you exceed?).
There are some other options like taking the clk to I/O pin and
bringing
back the clk and using a DLL to adjust the skew as required(which is
best
option i think, with assumption that you have spare I/O pins and DLL's
available in your device). 

Thanks
rao


Article: 80597
Subject: Re: Basic cheap fpga configuration
From: Andy Main <a.s.main@gmail.com>
Date: Tue, 08 Mar 2005 23:11:38 +0000
Links: << >>  << T >>  << A >>
  > I looked on the web for XCF01SVO20C and got a web price of $3.15
> If this is expensive to you, I don't see what you're going to do with
> the AT29 flash.  This is a 1Mbit part big enough to program about 5
> of your XC2S15's if you chain them.  It has JTAG and works with the
> Xilinx iMPACT software.  Good luck doing better with less effort.

Much better, though I can't find any in the UK (RS/Farnell) - only the 
huge Virtex proms that made me think all this in the fist place.  If 
anybody  knows a suitable supplier for low quantity purchases please let 
me know.  I'd be very grateful.

Andy.

Article: 80598
Subject: Re: Good, affordable verilog simulator
From: "pablo" <raonpc@gmail.com>
Date: 8 Mar 2005 15:20:29 -0800
Links: << >>  << T >>  << A >>
Hi,
  I was able to make Xilinx Edition ModelSim(free) work both for
verilog and vhdl. Follow the below procedure.

 What you can do is first install
vhdl version, then copy vhdl folder  from
C:\Modeltech_xe_starter\xilinx\vhdl
to different location. Then uninstall the modelsim and again install
this time for verilog, this time you have
C:\Modeltech_xe_starter\xilinx\verilog
Now copy the vhdl from previous location to this location
C:\Modeltech_xe_starter\xilinx\
If you now open the modelsim you have both libraries.

Thanks
rao


Article: 80599
Subject: Call for Papers: 2005 MAPLD International Conference
From: "Richard B. Katz" <richard.b.katz@nospamplease.nasa.gov>
Date: Tue, 08 Mar 2005 17:34:05 -0600
Links: << >>  << T >>  << A >>


                            Call for Papers

                   2005 MAPLD International Conference

         Ronald Reagan Building and International Trade Center
                           Washington, D.C.

                          September 7-9, 2005



   The 8th annual MAPLD International Conference will present papers on
   programmable logic devices and technologies, digital engineering, and
   related fields, for military and aerospace applications.   Devices,
   technologies, logic design, verification, flight applications, fault
   tolerance, reliability, radiation susceptibility, and encryption
   applications of programmable devices, processors, and adaptive
   computing systems in military and aerospace systems are topics for
   papers.  

   For 2005, MAPLD will be expanded to 3 full days and will feature
   expanded "Birds of a Feather" Workshop Sessions.  Full-day seminars
   will be offered on September 6, 2005.

   We are planning an exciting program with presentations by Government,
   industry, academia, and consultants, including talks by distinguished
   Invited Speakers.   This conference is open to US and foreign
   participation and is unclassified.  For related information, please
   see the NASA Office of Logic Design Web Site (http://klabs.org). 

   Abstract submittal info: http://klabs.org/mapld05/
   Abstract deadline:       April 25, 2005


   Special Talks Include (developing):

      * Welcome and Opening Address
        Ralph Roe, NASA Engineering and Safety Center
      * Invited Mishap Talk (new for 2005)
        "Computer Overload and The  Apollo 11 Lunar Landing"
        Jack Garman (formerly NASA JSC) 
      * Panel Session: "Why Are Space Stations So Hard?" 
        Roger Launius, National Air and Space Museum
        Keith Cowing,  Editor, NASA Watch
        and more ....
      * Invited History Talk
      * The Application Engineers' View


   Four Seminars Are Being Planned:

      * Design Integrity
      * Device Failure Modes and Reliability 
      * Reconfigurable High-Performance Computing 
      * Real-Time, Hi-Rel Software Issues for Computer Designers 


   Planned Technical Sessions

      * Applications: Military & Aerospace
      * Verification of High Reliability Designs
      * Radiation Effects and Mitigation Techniques 
      * Logic Design and Processors 
      * Reconfigurable Computing, Evolvable Hardware, and Security 
      * Poster Session 
      * BOF-L: Mitigation Methods for Reprogrammable Logic in the Space
               Radiation Environment 
      * BOF-F: Reconfigurable Computing 
      * BOF-J: PLD Failures, Analyses, and the Impact on Systems 
      * BOF-S: NESC and Software 
      * BOF-G: Digital Engineering and Computer Design - A Retrospective
               and Lessons Learned for Today's Engineers 
      * BOF-W: Verification of Large Designs and Related Design
               Methodologies



   Reservations are being accepts for the Industrial & Gov't Exhibits:
      http://klabs.org/mapld05/exhibits/reservation_request_form.htm

   Early Industrial and Governemnt participants include:

      NASA Office of Logic Design      Synthworks 
      Space Micro                      SRC Computers 
      BAE Systems: Information and     Aldec 
         Electronic Warfare Systems  
      Actel Corporation                ATK Mission Research Corporation 
      Aeroflex Colorado Springs        Xilinx, Inc. 
      Sigrity                          Mentor Graphics Corporation 
      IEEE Aerospace and Electronics   NASA Engineering and Safety Center
      Systems Society   
      Nallatech                        Celoxica 
      Northrop Grumman Corporation     SEAKR Engineering 


   For additional information:

      Conference home page: http://klabs.org/mapld05

      Richard B. Katz
      NASA Office of Logic Design
      mapld2005@klabs.org



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