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
2017JanFebMarApr2017

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 33700

Article: 33700
Subject: Re: Spartan II and asynchronous memory interface
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 02 Aug 2001 10:47:21 -0700
Links: << >>  << T >>  << A >>
One suggestion ( for cases of blind desperation ) is to cool the FPGA ( and
perhaps also the RAM) down , well below freezing.
This makes the chips much faster, and might make the error occur more often, and
thus more easy to analyze. Higher Vcc has the same effect.
A very fast 'scope ( and scope probe ) might also show potential clock ringing,
reflections, Vcc dips etc.
"A 1 MHz clock does not a slow chip make"  :-(

Peter Alfke, Xilinx Applications

======================================

david garnett wrote:

> The BurchED Spartan board is only two layer, and has what seems to me is a
> fairly poor power/ground layout - I would be much happier to see a real
> ground 'plane' at least under the chip. Perhaps your problems are related -
> things happen really fast inside something like a Spartan II and if your
> decoupling is not perfect  ...
> Dave
>
> [ In other respects I think that the board is useful and very good value for
> money - but if I were laying it out I'd have a solid ground under the chip
> proper, with all chip grounds connected directly to it, and then place
> decoupling caps round the edge of the chip on the underside, preferably
> connecting to a VCC power 'plane' directly under the ground 'plane', giving
> very short decoupling track lengths.]
>
> Dave
>
> "Steven Derrien" <sderrien@irisa.fr> wrote in message
> news:3B697EF9.E5BDF155@irisa.fr...
> > Hi,
> >
> > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org)
> > to a VHDL targeted to the BurchEd Spartan II board
> > (http://www.burched.com)
> >
> > We plan to make our work freely available, but are currently stuck on
> > a problem. The design is a 16 CPU-SOC which interfaced to a parallel
> > port.
> >
> > We have somes on-chip blockrams which serves as ROM, and off-chip
> > asynchronous
> > SRAM whiwh serves as main memory. Our problem is that we get frequent
> > errors when accessing the off-chip SRAM banks. Generally a single bit
> > wrong in a 16 bit data word every 200-300 access.
> >
> > All simulation (RTL,gate-level,post place and route) went fine.
> > Right now, our system is clocked at 1Mhz far below its maximum
> > frequency.
> > Besides, the SRAM Write Enable command output signal is registered
> > (although not in a IOB register) to avoid glitches which could cause
> > wrong write operations.
> >
> > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB
> > config)
> >
> > We have been beating our heads on this problem for almost a week now,
> > are there any experts around there to offer some tips/ideas/advices ?
> >
> > Thanks,
> >
> > Steven


Article: 33701
Subject: Re: Spartan II and asynchronous memory interface
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 02 Aug 2001 17:54:11 GMT
Links: << >>  << T >>  << A >>
david garnett wrote:
> 
> The BurchED Spartan board is only two layer,

That's good to know.

If it were me, I'd do at least four layers - top and bottom for signal,
middle two for VCC and GND.

-andy

Article: 33702
Subject: Re: Spartan II and asynchronous memory interface
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 02 Aug 2001 18:05:30 GMT
Links: << >>  << T >>  << A >>
Steven Derrien wrote:

> We have somes on-chip blockrams which serves as ROM, and off-chip
> asynchronous
> SRAM whiwh serves as main memory. Our problem is that we get frequent
> errors when accessing the off-chip SRAM banks. Generally a single bit
> wrong in a 16 bit data word every 200-300 access.
> 
> All simulation (RTL,gate-level,post place and route) went fine.
> Right now, our system is clocked at 1Mhz far below its maximum
> frequency.
> Besides, the SRAM Write Enable command output signal is registered
> (although not in a IOB register) to avoid glitches which could cause
> wrong write operations.
> 
> All IOB are configured with SLOW slew-rate and drive 12mA (default IOB
> config)
> 
> We have been beating our heads on this problem for almost a week now,
> are there any experts around there to offer some tips/ideas/advices ?

In addition to registering the write enable, I'd register the SRAM data
and address busses, too. Many years ago, as a "green" engineer, I was
bitten by an extremely weird problem similar to yours: I was writing to
a Xicor NovRAM from an 8051 via an Altera EPLD.  The EPLD (among other
things) had a mux that drove the RAM address lines (one source was the
8051, the other was "something else").  Initially, I did not register
the address outputs, and the thing would not work -- corrupted data. 
Looking at it on a logic analyzer, and a fast digitizing 'scope, showed
me that I was meeting setup requirements by a WEEK (well, you know what
I mean).  After about a week of flattening my forehead against various
hard structural objects, I asked another engineer what I was doing
wrong.  The first question he asked: "Are your outputs synchronous?" 
The answer, of course, was no.  He said, "Register the address outputs."
 I did so, and everything was hunky AND dory.

I would also use the IOB registers.  You'll get "highly-similar"
clock-to-out times for all of your signals.

Why aren't you putting the write enable register in an IOB?  They're
free, ya know.

The other obvious thing is to make sure that you're meeting setup and
hold requirements around the SRAM write enable.  Check your simulation model.

-andy

Article: 33703
Subject: Re: RAM - VHDL - Altera,...
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 02 Aug 2001 11:06:17 -0700
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
> 
> > Interesting. I thought LPM was just an altera thing for AHDL. Are
> > all device and tools vendors supporting LPM libraries?
> >
> > I guess its ok to use LPM functions in brand-neutral code then?
> 
> I also thought that's good news. But I tried today to use LPMs
> in Xilinx WebPack but it's not supported:
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
> 1&getPagePath=5163
> 
> So again two versions for A and X.

That depends.

A vendor-independent design flow requires a 
vendor-independent synthesis tool. 

Software vendors make money by fitting generic
code into as many devices as they can.

Device vendors make money by keeping customers
using their devices.

Xilinx WebPack is fine for certain Xilinx
devices, but it's unreasonable to expect much 
support for device independence from that tool. 

If all the vendors provided full 
support for a standard like LPM, the designer's
lives would be simpler, and FPGAs would become
even more of a commodity

       --Mike Treseler

Article: 33704
Subject: Re: Duty cycle problem with Virtex-II
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 02 Aug 2001 18:07:33 GMT
Links: << >>  << T >>  << A >>
"Sune G. Krohn" wrote:
> 
> I can't get a signal out of Xilinx Virtex-II 2V100 and 2V40 with a correct
> duty cycle.
> 
> I only see this problem in 1.5 and 2.5 voltages mode.
> 
> I also see the problem on Xilinx Virtex-II Evaluation Kit with a 2V40.
> 
> As output I use OBUF_LVCMOS15_F_16 for 1.5 V and OBUF_LVCMOS33_F_16.
> 
> With a frequency about 100MHz is the duty cycle about 35/65. In the test I
> run the clock through a FF to make a 50/50 duty cycle and with no luck.
> 
> It is always the high pulse that a shorter than the low, even if I invert
> the signal.
> 
> We have asked Xilinx's Technical Support Office United Kingdom every day for
> two weeks and they can't answer the question they just ask irrelevant
> questions. For instance, they ask my to do an IBIS simulation on their
> Evaluation Kit with their chip.

What's the signal's load?  That's why they want you to do an IBIS sim...

-andy

Article: 33705
Subject: Re: Building ROM and RAM blocks - Xilinx Foundation Series 3.1i
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 02 Aug 2001 18:08:53 GMT
Links: << >>  << T >>  << A >>
Manoj K Krishnan wrote:
> 
>         Iam trying to build a ROM and RAM module using Xilinx Foundation
> series 3.1i (VHDL coding) I tried using Core Generator to generate a
> Distributed Memory block. But unfortunately the memory was not properly
> generated. It works sometimes but fails sometimes. I tried calling Xilinx
> custommer support. I came to know that they have some problem with the
> core generator software.
> 
> Can anyone suggest me a way to build a ROM and RAM using VHDL coding. Iam
> not very particular about using core generator. All I need is to build a
> ROM and a RAM which is generic in nature.

Get a Real synthesis tool (Synplify or Leonardo) and infer the RAMs. 
The Core Generator simulation models are broken.

-andy

Article: 33706
Subject: Re: spartan & atmel eeproms
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 02 Aug 2001 18:11:20 GMT
Links: << >>  << T >>  << A >>
emanuel stiebler wrote:
> 
> Hi,
> 
> Anybody here uses an ATMEL serial EEPROm as a configuration
> PROM for a SPARTAN XC40 device ?
> 
> Which one ?
> Problems ?
> Hints ?

I used one: the 1 Mb part. Works fine.  I'm not sure if they're any
cheaper than the Brand X parts. MAKE SURE YOU DO NOT ORDER THE "A" PART!
(And don't let your purchasing department helpfully substitute it,
either).  In this case,"A" == "Altera," not "better/faster."

As Felix says, watch out for reset/OE polarity, since by default it's
the "wrong way" for the Xilinx FPGAs.

-andy

Article: 33707
Subject: Re: a few xilinx fpga and hdl questions
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 02 Aug 2001 18:17:29 GMT
Links: << >>  << T >>  << A >>
atif wrote:
> 
> Hi ppl,
> 
> I am trying to build a parallel port to PC card interface for a
> student project. I have a few problems and I will appreciate any help
> about them.
> 
> 1) When reading data from the memory card, I have to make the OE
> (output enable) signal low a setup time after I make the read address
> valid. How can I get this delay using HDL code? I don't have a clock
> that I can use for this purpose.

You're hosed.  Go back to your schoolbooks and read up on "Synchronous
design."  You'll want a clock.  Trust me.
 
> 2) Some of the pins connected with the PC card control signals have to
> be open drain with pullup resistor (>10 k). I am not sure how get that
> in a Xilinx 4000 series FPGA. The data sheet says I can get an open
> drain output by using a tri state ouput buffer(OBUFT), with its input
> connected to ground and enable pin to the output signal. Seems to me
> that in this case, I will have to use external pull up resistors (not
> really interested in doing this). Or can I connect PULLUP at the
> output of the buffer? Can I use the BUFOD (open drain buffer) with a
> PULLUP as output buffer? Any other ways of doing this?

Use the OBUFT as they describe, and use external resistors.  The PULLUP
isn't strong enough.  Resistors are cheap.  Many large FPGA designs have
to have external passives.  That's the way it is.

> 3) For Global Set/Reset, the manuals say I have to use the INIT
> attribute to specify the locat set/reset state of each ff. Where do I
> set this INIT attribute....in the schematic or in the code? How? for
> example, following is the general structure of my code
>    process(clk, reset)
>    begin
>       if reset='1' then
>           x<='0';
>           y<='1';
>       elsif rising_edge(clk) then
>       -- stuff
>       end if;
>    end process;
> What do I have to do so that x and y are reset and set
> respectively(using GSR).
> Note that the 4000E series that I am using does not seem to have a
> STARTBUF module. In has a STARTUP module, which has GSR input, but no
> GSR output (as in STARTBUF). Thus using this module will set/reset the
> flip flops according to the INIT attribute.

I'm not sure which version of Xilinx' tools you're using, but if you
code each and every flip-flop in your design with the same exact reset
signal, you don't have to do anything to init the flops. GSR will be
inferred by the synthesis tool, and your registers will be set or
cleared as indicated by your "if reset = '1' then ..." statement.  So,
don't worry about INIT, don't worry about STARTUP, just make sure you
reset all of your flops.

Yes, it would be nice if Xilinx updated their docs once in a while.

-andy

Article: 33708
Subject: Re: Spartan II and asynchronous memory interface
From: Steven Derrien <sderrien@irisa.fr>
Date: Thu, 02 Aug 2001 20:22:09 +0200
Links: << >>  << T >>  << A >>


"Andy Peters
> 
> Steven Derrien wrote:
> 
> > We have somes on-chip blockrams which serves as ROM, and off-chip
> > asynchronous
> > SRAM whiwh serves as main memory. Our problem is that we get frequent
> > errors when accessing the off-chip SRAM banks. Generally a single bit
> > wrong in a 16 bit data word every 200-300 access.
> >
> > All simulation (RTL,gate-level,post place and route) went fine.
> > Right now, our system is clocked at 1Mhz far below its maximum
> > frequency.
> > Besides, the SRAM Write Enable command output signal is registered
> > (although not in a IOB register) to avoid glitches which could cause
> > wrong write operations.
> >
> > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB
> > config)
> >
> > We have been beating our heads on this problem for almost a week now,
> > are there any experts around there to offer some tips/ideas/advices ?
> 
> In addition to registering the write enable, I'd register the SRAM data
> and address busses, too. Many years ago, as a "green" engineer, I was
> bitten by an extremely weird problem similar to yours: I was writing to
> a Xicor NovRAM from an 8051 via an Altera EPLD.  The EPLD (among other
> things) had a mux that drove the RAM address lines (one source was the
> 8051, the other was "something else").  Initially, I did not register
> the address outputs, and the thing would not work -- corrupted data.
> Looking at it on a logic analyzer, and a fast digitizing 'scope, showed
> me that I was meeting setup requirements by a WEEK (well, you know what
> I mean).  After about a week of flattening my forehead against various
> hard structural objects, I asked another engineer what I was doing
> wrong.  The first question he asked: "Are your outputs synchronous?"
> The answer, of course, was no.  He said, "Register the address outputs."
>  I did so, and everything was hunky AND dory.

I'll try to do that, thanks.

> I would also use the IOB registers.  You'll get "highly-similar"
> clock-to-out times for all of your signals.
> 
> Why aren't you putting the write enable register in an IOB?  They're
> free, ya know.

yep, this is just because the register is in a inner edif module and 
apparently the map -b does not manage to put it it in the IOB, but 
that's to check again.

> 
> The other obvious thing is to make sure that you're meeting setup and
> hold requirements around the SRAM write enable.  Check your simulation model.

Setup and hold should be OK (WE is active for a clock cycle aka for 1000
ns)

> 
> -andy

Thanks again

steven

Article: 33709
Subject: newbie
From: szekit <szekit.chan@osram-os.com>
Date: Thu, 2 Aug 2001 11:25:54 -0700
Links: << >>  << T >>  << A >>
What is the CAE library used for?  I generated an EDIF file on my sun workstation from cadence and then put it through the Xilinx's design manager (alliance) on my PC but it generates errors stating some components are not expanded.  Do I have to install the CAE library on the sun's machine and reference to this library when I try to generate the EDIF with cadence or synopsys?  What kind of setup and environment (libraries) do I need to install to have a design flow such that I can generate an EDIF from cadence or synopsys on sun's machine and then pass the EDIF to xilinx's design manager on a PC?  Your help is much appreciated!!!!

Article: 33710
Subject: Re: Spartan II and asynchronous memory interface
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 02 Aug 2001 11:50:45 -0700
Links: << >>  << T >>  << A >>

Steven Derrien wrote:

> Is this also a strong issue when the system is clocked below 1MHz ?
> (sorry I have very little knowledge of PCB layout issues)
>

Yes, unfortunately it is.
Signal integrity problems are instigated by a signal edge, often a clock edge,
and the time distance until the following edge is usually of no consequence.
Therefore, signal integrity problems are as bad and devious at 1 MHz, as they are
at 100 MHz.
It's the inherent speed of the device that matters, not the clock rate of the
application.

This bites the designer of slow systems so badly, when he uses simple
instruments, limited board-layout skills etc, but then inserts these very fast
modern chips that can react to a 1-ns blip.
A 250-MHz scope does not even show this blip...

Peter Alfke, Xilinx Applications



Article: 33711
Subject: Re: finite defect statistics
From: Ray Andraka <ray@andraka.com>
Date: Thu, 02 Aug 2001 18:57:57 GMT
Links: << >>  << T >>  << A >>
Yep, that's what I do.  For high clock rates, you may find that you need to locate the registers at the point of
crossing in the same CLB (opposite slices), as you reduce the allowed prop times.

Falk wrote:

> Ok, I think the easiest and safest solution is a synchronizing FF working on the other (here the falling) edge.
> Thanks a lot for the warning and advice.
>
> Regards
> Falk

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 33712
Subject: Re: Spartan II and asynchronous memory interface
From: Ray Andraka <ray@andraka.com>
Date: Thu, 02 Aug 2001 19:05:54 GMT
Links: << >>  << T >>  << A >>
Yes.  The problem is in the di/dt caused by very fast edges on the signals.  You
can help it out some be selecting the low slew rate drive and setting the output
currents at the lowest possible values consistent with what you are driving.  You
can also intentionally skew outputs if you have a higher clock available to
minimize the number of outputs changing at once.

Steven Derrien wrote:

> Is this also a strong issue when the system is clocked below 1MHz ?
> (sorry I have very little knowledge of PCB layout issues)
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 33713
Subject: Simple Division by Shift/Add (2nd try)
From: jdiaz_pr@excite.com (jdiaz_pr)
Date: 2 Aug 2001 12:25:12 -0700
Links: << >>  << T >>  << A >>
May be it is an off topic post, but I liked to have some feedback
about that. I posted it on comp.arch.arithmetic, so far I have not see
much action there.

Well, in any case I am intended to implement it on a FPGA. :-)

----------------------------
Hi again guys!

I have N1=1/25 that can be aproximated by 41/1024 where the  error is
around .000039 then we do:

If x is w=8 bits wide (unsigned)and its maximum accumulated error is
.00996

N1approx: x*N1 ~ x(<<5 + <<3 + 1)>>10 needing only one(1) w+5(because
higher hardwired SLL)+ 1 (to account the 1 for the Carry-in) bits
ADDER, then we apply a the 10-SRL(harwired). NOTE that dividing x(max)
by 25 will require at least 4 bits; and another 5 bits after the
radix-point to account for the accuracy of 41/1024.

Do anyone has a more creative way to implement that?

NOW I have another similar case: N2=1/24 ~ 85/2048
I have been trying to develop a similar method but it will require
more H/W, wider ADDERs and  having a bigger accumulated error.

Thinking again, here is were I need the creative solution. ;-)

Article: 33714
Subject: Re: Spartan II and asynchronous memory interface
From: "david garnett" <dave.garnett@metapurple.co.uk>
Date: Thu, 2 Aug 2001 20:27:03 +0100
Links: << >>  << T >>  << A >>

"Steven Derrien" <sderrien@irisa.fr> wrote in message
news:3B698F7B.73A2211A@irisa.fr...

> ground 'plane' at least under the chip. Perhaps your problems are
related -
> > things happen really fast inside something like a Spartan II and if your
> > decoupling is not perfect  ...
>
> Is this also a strong issue when the system is clocked below 1MHz ?
> (sorry I have very little knowledge of PCB layout issues)

Absolutely ! - what matters is that lots of things change state on the clock
edge, and for these changes to take place currents must flow - possibly
quite a lot of current, although for a very short time. If the ground/vcc
connections present any significant impedance, then different parts of the
chip will find themselves with different ground/vcc levels during the
changes, and just about anything could happen !

Depending on what you are doing in the fpga, everything will settle in a few
tens of nanoseconds  - so, providing your clock is slow enough to let this
happen plus a bit, the clock speed will not have a great effect - except to
make the fault occur more often, which is often a help in tracking it down !

My experience is that, even with a very fast scope, it is very difficult to
observe ground bounce type faults directly - you certainly see all sorts of
bouncing and glitches, but they are often caused by probing problems ...

>
>
> Thank you,
> Steven
>




Article: 33715
Subject: Re: Spartan II and asynchronous memory interface
From: "Shane Tow" <shane_tow@yahoo.com>
Date: Thu, 2 Aug 2001 15:32:13 -0400
Links: << >>  << T >>  << A >>

> Setup and hold should be OK (WE is active for a clock cycle aka for 1000
> ns)


Registering the WE, Data Bus, and Address Bus is a very good idea.  Also
make sure that you send the Address Bus and Data Bus out to the SRAM at
least one clock cycle before you assert the WE.  Also, hold the Address Bus
and Data Bus at least one clock cycle after clearing WE.  You don't want to
send the Address, Data, and WE on the same clock edge or clear them on the
same clock edge.

Good Luck,

Shane



Article: 33716
Subject: Re: Simple Division by Shift/Add (2nd try)
From: John_H <johnhandwork@mail.com>
Date: Thu, 02 Aug 2001 20:12:46 GMT
Links: << >>  << T >>  << A >>
If you have plenty of time you can do a real "shift and subtract" divider
or the approximated "shift and add" multiplier with the 1/n multiplicand
using a serial shifter for an arbitrary value.  If you need the value in
one clock cycle you can use discreete adders.  In the case of 85/2048
(55/800 hex)you can add x+4x(=5x) then add the result 5x+16*5x(=85x) to
get your raw result.  The last adder is larger than the 1/25 example but
you need it for the accuracy.

Does a true divider just not work for you because of the delay?



jdiaz_pr wrote:

> May be it is an off topic post, but I liked to have some feedback
> about that. I posted it on comp.arch.arithmetic, so far I have not see
> much action there.
>
> Well, in any case I am intended to implement it on a FPGA. :-)
>
> ----------------------------
> Hi again guys!
>
> I have N1=1/25 that can be aproximated by 41/1024 where the  error is
> around .000039 then we do:
>
> If x is w=8 bits wide (unsigned)and its maximum accumulated error is
> .00996
>
> N1approx: x*N1 ~ x(<<5 + <<3 + 1)>>10 needing only one(1) w+5(because
> higher hardwired SLL)+ 1 (to account the 1 for the Carry-in) bits
> ADDER, then we apply a the 10-SRL(harwired). NOTE that dividing x(max)
> by 25 will require at least 4 bits; and another 5 bits after the
> radix-point to account for the accuracy of 41/1024.
>
> Do anyone has a more creative way to implement that?
>
> NOW I have another similar case: N2=1/24 ~ 85/2048
> I have been trying to develop a similar method but it will require
> more H/W, wider ADDERs and  having a bigger accumulated error.
>
> Thinking again, here is were I need the creative solution. ;-)


Article: 33717
Subject: Re: Err with this AHDL code
From: John_H <johnhandwork@mail.com>
Date: Thu, 02 Aug 2001 20:24:20 GMT
Links: << >>  << T >>  << A >>
"it sumulates it with no err"...  The simulator simulates your design with
results you anticipate but...

"it doesn't give me the right value for ma[]"... the simulator or the resulting
design?  If it's the simulator, this is where you start "drilling down" into the
design to look at the signals that go to the ma[] registers - the d input, the
clock, the reset.

If your simulator says your results are not as expected, start looking at the
individual nodes that aren't behaving correctly and eventually you'll find the
trouble.


Abhimanyu Rastogi wrote:

> Yes i did....and it simulates it with no err or warnings.....
> but....it doesn't give me the right values for ma[] ....  which should be
> the same as upad[].... that i'm feeding in thru the simulator.....   instead
> it gives me some odd values for ma[] ...
>
> Could that be due to the clk....  or some delay...   cuz...  upad[] is an
> INPUT and ma[] is a dffe variable...   so does that matter??
>
> Abhimanyu Rastogi
> Russell Shaw <rjshaw@iprimus.com.au> wrote in message
> news:3B68A427.47ED3915@iprimus.com.au...
> > I can't see a problem. Have you fed it thru the maxplus2 simulator?
> >
> > Abhimanyu Rastogi wrote:
> > >
> > > Hi all,
> > > I haveing some trouble with this code I wrote...
> >
> > --
> >    ___                                           ___
> >   /  /\                                         /  /\
> >  /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
> > /__/   / Victoria, Australia, Down-Under      /__/\/\/
> > \  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
> >  \__\/                                         \__\/


Article: 33718
Subject: Re: Does Flexlm Licensing Work on Windows 2000 Pro?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 02 Aug 2001 13:28:50 -0700
Links: << >>  << T >>  << A >>
Dave Feustel wrote:

 
> Does the Flexlm licensing and license validation procedure actually
> *work* on Windows 2000?

I can testify that validation works on win2k.
My license server is elsewhere on the network.
I assume you have set a path for
LM_LICENSE_FILE or MGLS_LICENSE_FILE 

(Start, Settings, ControlPanel, 
System, Advanced, Environment . . .)


 --Mike Treseler

Article: 33719
Subject: Clock skew with Xilinx DLLs...
From: "Cary McCormick" <jcmccorm@hiwaay.net>
Date: Thu, 2 Aug 2001 16:47:27 -0500
Links: << >>  << T >>  << A >>

Hi folks,
    I'm using a DLL in a SpartanII design and have discovered with lab
experimentation that lo and behold, the /4 output lags the edge of the x1
output by about 1ns. I'm certain that I'm using the DLL correctly (BUFGs on
both outputs, feedback comes from BUFG'd x1 output) and I imagine that the
phase difference is due entirely to loading differences since the /4 clock
is *much* more heavily loaded than the x1 clock.
    So, given that we're kind of stuck with this (what's the point of BUFG's
anyway if this happens?) how can I design with this? Will the Design Manager
(using 3.1) check for setup problems? Any design tricks that the gurus can
share on this matter?? Safety precautions I can add to the UCF file??
Thanks!!

Cary McCormick





Article: 33720
Subject: Re: Too low output voltage on Altera 7000S??
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 02 Aug 2001 14:55:13 -0700
Links: << >>  << T >>  << A >>
Here is the simple rule for 5-V parts:

If Voh min is specified as 2.4 V, then it is a TTL-like "totem-pole" structure
with an n-channel pull-up transistor, and the real Voh will be one threshold
below Vcc, i.e. around 3.7 V.
To get a higher Voh, use an external pull-up resistor.

If Voh min is specified as 3.5 to 4.0 V, then it really is a true CMOS output
with a p-channel pull-up, and the unloaded Voh is identical with Vcc.

Lower-Vcc standards ( 3.3, 2.5, 1.8, 1.5 V)  have always true CMOS outputs (
unless they are open-"collector", like GTL.)  PECL and differential standards
like LVDS are a different matter.

Peter Alfke, Xilinx Applications

====================================================
Victor Schutte wrote:

> TTL compatible outputs. You might even go as high as 3.7V. Open drain should
> even be worse.  Try pull-up resistors (e.g. 4k7 to VCC), especially when
> your pin fans out to active high inputs. Remember that the TTL high level is
> about 2.4V  and that it should work in most cases.

Article: 33721
Subject: Re: Can't Install Modelsim - Alternatives for Verilog Simulation???
From: "Dan Notestein" <dan@syncad.com>
Date: Thu, 2 Aug 2001 17:58:24 -0400
Links: << >>  << T >>  << A >>
VeriLogger Pro is available on PC for $3000. You can download an eval
copy from the location below:

--
For a FREE evaluation of Timing Diagrammer, WaveFormer, VeriLogger, or
TestBencher Pro, visit our web site: http://www.syncad.com
******************************************************************
   SynaptiCAD, Inc.                    Sales:   (800) 804-7073
   P.O. Box 10608                      Support: (540) 953-3390
   Blacksburg, VA  24062-0608          Fax:     (540) 953-3078
   ftp: www.syncad.com                 email: sales@syncad.com

"Dave Feustel" <dfeustel@mindspring.com> wrote in message
news:9jugr9$5vr$1@slb4.atl.mindspring.net...
> Modelsim licensing refuses to work on my computer.
>
> What alternatives to Modelsim are there for Verilog simulation
> on Windows 2000?
>
> Thanks.
>
>



Article: 33722
Subject: Re: May I connect two pins to the same net?
From: "Peter Ormsby" <faepetedeletethis@mediaone.net>
Date: Thu, 02 Aug 2001 23:31:50 GMT
Links: << >>  << T >>  << A >>
Wow.  Bite my head off.

I think there's some confusion on the tools.  I'm sorry I didn't specify I
waas speaking of Quartus.  Unless you're designing MAX3000 or MAX7000,
there's no reason to be using MAX+PLUS II anymore.

In any case, the default behaviour "out-of-the-box" for Quartus is to have
the unused pins configured as inputs (tristated).  You don't need to delve
into the menus if you don't want to.  Is that nice enough default behaviour?

I was just trying to show you how to change the default settings if you
wanted to.  Too much information, I guess.

-Pete-


<martin.j.thompson@trw.com> wrote in message news:u7kwmft3s.fsf@trw.com...
> Falk <> writes:
>
> > So what the hell means
> >
> > - as output, driving an unspecified signal????
> >
>
> I've also seen the same behaviour that Nial describes elsewhere in
> this thread... threw us off track for a *long* while.  We now make a
> point of explicitly defining the state of all pins, used or unused.
>
> > Is there any use for that??  My opinion is, that the software has to
> > keep its hands of the pins, unless I tell them to do other. So unused
> > pins should be tristated by default (not after you set a tiny switch
> > hidden deep down in the 10th option menu :-(
> >
>
> Not nice default behaviour IMHO!
>
> Cheers,
> Martin



Article: 33723
Subject: Re: Clock skew with Xilinx DLLs...
From: John_H <johnhandwork@mail.com>
Date: Fri, 03 Aug 2001 00:41:14 GMT
Links: << >>  << T >>  << A >>
I don't know DLL and BUFG count around where you're working, but how about
slaving the 1x clock to the /4 ?  It'll take some rethinking to get the whole
system to come back and align, but if your feedbacks are what give you the edge
matching, you need the heavily loaded net in the feedback path.  Good luck!

Cary McCormick wrote:

> Hi folks,
>     I'm using a DLL in a SpartanII design and have discovered with lab
> experimentation that lo and behold, the /4 output lags the edge of the x1
> output by about 1ns. I'm certain that I'm using the DLL correctly (BUFGs on
> both outputs, feedback comes from BUFG'd x1 output) and I imagine that the
> phase difference is due entirely to loading differences since the /4 clock
> is *much* more heavily loaded than the x1 clock.
>     So, given that we're kind of stuck with this (what's the point of BUFG's
> anyway if this happens?) how can I design with this? Will the Design Manager
> (using 3.1) check for setup problems? Any design tricks that the gurus can
> share on this matter?? Safety precautions I can add to the UCF file??
> Thanks!!
>
> Cary McCormick


Article: 33724
Subject: Re: Spartan II and asynchronous memory interface
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 03 Aug 2001 11:29:20 +1000
Links: << >>  << T >>  << A >>


david garnett wrote:
> 
> "Steven Derrien" <sderrien@irisa.fr> wrote in message
> news:3B698F7B.73A2211A@irisa.fr...
> 
> > ground 'plane' at least under the chip. Perhaps your problems are
> related -
> > > things happen really fast inside something like a Spartan II and if your
> > > decoupling is not perfect  ...
> >
> > Is this also a strong issue when the system is clocked below 1MHz ?
> > (sorry I have very little knowledge of PCB layout issues)
> 
> Absolutely ! - what matters is that lots of things change state on the clock
> edge, and for these changes to take place currents must flow - possibly
> quite a lot of current, although for a very short time. If the ground/vcc
> connections present any significant impedance, then different parts of the
> chip will find themselves with different ground/vcc levels during the
> changes, and just about anything could happen !
> 
> Depending on what you are doing in the fpga, everything will settle in a few
> tens of nanoseconds  - so, providing your clock is slow enough to let this
> happen plus a bit, the clock speed will not have a great effect - except to
> make the fault occur more often, which is often a help in tracking it down !
> 
> My experience is that, even with a very fast scope, it is very difficult to
> observe ground bounce type faults directly - you certainly see all sorts of
> bouncing and glitches, but they are often caused by probing problems ...

It would be interesting to know what the inductance is of the chip
bond wires. That way, the layout person could determine how long
they could leave pwr/gnd tracks without much effect relative to
the bond-wires.



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
2017JanFebMarApr2017

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