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 18225

Article: 18225
Subject: Re: Can't detect Flex 10K Altera device through JTAG port
From: Armin Mueller <armin.mueller@stud.uni-karlsruhe.de>
Date: Fri, 08 Oct 1999 16:06:25 +0200
Links: << >>  << T >>  << A >>
Mike wrote:
> 
> We are having troubles in programming Altera 10K30A device via JTAG port.
> Altera software does not detect the device at all. Everything is configured
> according to their datasheet for the case of JTAG only programming. There is
> only one device in the chain. We are using standard ByteBlaster.
> 

Ahhh??? I thought the Byteblaster was only for programming!
JTAG should be done via the TDI/TDO/TCK/TMS pins.

Armin
Article: 18226
Subject: Capacity metrics for Virtex
From: Stephen Charlwood <s.m.charlwood@bham.ac.uk>
Date: Fri, 08 Oct 1999 15:30:18 +0100
Links: << >>  << T >>  << A >>
Hi.

Could anyone possibly explain why a Xilinx Virtex-series CLB is
considered equiavlent to 4.5 logic cells? I understand why an
XC4000-series CLB is equivalent to 2.375 logic cells, but don't see the
Virtex translation.

Thanks,

Steve


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Digital Systems & Vision Processing Group 
School of Electronic & Electrical Engineering
University of Birmingham, Edgbaston, Birmingham, B15 2TT 
e-mail: s.m.charlwood@bham.ac.uk

Signal Processing & Imagery Department 
Defence Evaluation & Research Agency
DERA Malvern, St. Andrews Rd., Malvern, Worcs., WR14 3PS 
e-mail: steve.charlwood@acm.org

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Article: 18227
Subject: Re: Altera 10K50V in-rush/temp problem...
From: "Bob Weber" <rweber@txc.com>
Date: Fri, 8 Oct 1999 11:12:41 -0400
Links: << >>  << T >>  << A >>
This would be a killer problem in some applications. Is there a way to avoid
or prevent the problem other than having a big enough power supply to plow
its way through the problem?

Bob W.

Dave Krueger <dave@kruegerphoto.com> wrote in message
news:OlbL3.5686$eM4.452242@typ11.nn.bcandid.com...
> Thanks, guys.
>
> Allan, we have both the I/O and internal VCC supplies connected to the
same
> 3.3V supply, so it's not a sequencing problem.
>
> I had a reply in e-mail that I think explains what's going on.  If, at
power
> up, the internal latches come up in some random state, there will be
> contension on the INTERNAL busses that account for the excessive current
on
> the VCC.  The part apparently clears these latches, but only if the power
> supply is capable of producing enough current to operate the part.  With
> some lot codes and temperatures, it draws as much as 700 mA.  Our supply
was
> capable of about 500 mA.  After the latches are cleared, the current drops
> to about 20 mA (big difference!).
>
> Upon beefing up the supply, the parts still show the current spike, but
the
> device always comes out of it and the current drops to normal.
>
> If this were a latch-up issue, the part would not recover like that.
That's
> primarily why I referred to the problem as an "in-rush" problem rather
than
> a latch-up problem.
>
> I appreciate all the responses.
>
> -Dave
>
>


Article: 18228
Subject: Re: Can't detect Flex 10K Altera device through JTAG port
From: "Mike" <mmatusov@ics-ltd.com>
Date: Fri, 08 Oct 1999 15:24:24 GMT
Links: << >>  << T >>  << A >>

Armin Mueller wrote in message <37FDFA61.E389297F@stud.uni-karlsruhe.de>...
>Mike wrote:
>

>Ahhh??? I thought the Byteblaster was only for programming!
>JTAG should be done via the TDI/TDO/TCK/TMS pins.
>

Yes, Byteblaster is for programming and this is what we are trying to do.
And yes we are connecting it to the JTAG port, which is one of the possible
programming ports for the Altera devices. And this is something we have been
doing successfully with various Altera devices for long time.

We have just received a message from Altera saying that delay in applying
high level to the 2 pins mentioned in the original mail should not matter.
Now we are completely out of the ideas....


Mikhail Matusov


Article: 18229
Subject: Re: External Cloking of Altera MAX 7000S
From: "Mike" <mmatusov@ics-ltd.com>
Date: Fri, 08 Oct 1999 15:34:00 GMT
Links: << >>  << T >>  << A >>

Moussa Ba wrote in message <37FD1D45.848CC6A5@eng.umd.edu>...
>Thank you for your reply.  I forgot to mention in my email that I did use a
TTL
>crystal oscillator.  And I still get a messed up signal as soon as I
connect the
>
>clock to the clock input of the MAX chip.
>


Is it possible that you connect your clock to a wrong pin? Check how your
pins were routed in your .rpt file. It sounds like you are connecting your
clock to a pin configured as an output.

Mikhail Matusov


Article: 18230
Subject: Re: Announcement: VHDL/FPGA Development Boards (up to 400.000 Gates) (Corrected Links, More Boards)
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Fri, 8 Oct 1999 08:42:04 -0700
Links: << >>  << T >>  << A >>
I believe that the correct links are shown below.

http://www.tzkom.de/service/devboard.htm

http://www.tzkom.de/service/devboard_e.htm

There is another page for these boards on the related Alcatel site at
http://www.alcatel.de/telecom/asd/test_hw/devboards.htm.  You may also be
interested in the fairly comprehensive list of boards available at
http://www.optimagic.com/boards.html.


--
-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------



<lothar_brodbeck@my-deja.com> wrote in message
news:7tks00$il3$1@nnrp1.deja.com...
> Hello reader,
>
> I would announce two development boards. The two boards are useful for
> ASIC prototyping and simulation as well as for other purposes.
> We and some other companies (Alcatel, Rhode&Schwarz, Siemens,
> Wandel&Goltermann, ...) already used the boards to verify our
> designs.
>
> Examples:
>
> - DSP algorithms written in VHDL
> - behaviour of PLL circuits
> - building of complex test equipment
> - call simulator for 480 subscribers
> - etc.
>
>
> Short description of the boards:
>
> Altera FLEX10K development board:
>
> - up to 400.000 logical gates
> - 2 slots for external memory (standard SIMM modules)
> - PBA size 233mm*210mm
> - 5V or 3.3V operation voltage (depending on used FPGAs)
> - breadboard area for user applications
> - on board reset circuit
> - ...
>
>
> Altera FLEX8K development board:
>
> - up to 20.000 logical gates
> - PBA size 233mm*160mm
> - board splittable into 2 times 100mm*160mm
> - 5V operation voltage
> - breadboard area for user applications
> - on board reset circuit
> - ...
>
> For more information about the development boards use one of
> the possibilities listed below.
>
> Web-Site:   1st page:
> http://www.tzkom.de
>
>                      development boards page:
> http://www.tzkom.de/kompetenz/nt/devboard.htm
>
>                      (English: sorry not the final version
> http://www.tzkom.de/kompetenz/nt/devboard_e.htm)
>
> Email:        Lothar.Brodbeck@tzkom.de .
>
>
> Kind Regards
>
> Lothar Brodbeck
>
>
> p.s.:
>
> An user wrote:    ... we successfully used the Altera FLEX10K board to
>                          verify our complex signal processing algorithm.
> ... The
>                          programming and the handling of the evaluation
> board
>                          stands out. ...
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 18231
Subject: DLL and programmable delay in Xilinx FPGA
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Fri, 08 Oct 1999 10:43:20 -0500
Links: << >>  << T >>  << A >>
All,
I've read all the docs I can get my hands on, but still don't understand
something (or maybe a few things).  We want to use the DLL on the clock
input on our Virtex design to get zero skew between the external and
internal clock.  As I understand it, the DLL takes the external clock,
feeds it through the DLL which delays it (up to 360 degrees) based on a
feedback path which is the longest onchip clock delay.  Thus, the
internal clock is delayed (again, up to 360 degrees) until it is in
phase with the external clock.....fine....

Now the part I don't understand.  The IOB description in the data sheet
shows a "programmable delay element".  For signal inputs, this element
can be used or not used.  If I use the DLL, is the delay element in the
signal input paths used?  It is used to "get zero hold times" between
the pads.  Is this delay element related to the DLL implimentation or
are they exclusive.  How do I know if I am using the delay element on
the signal input paths or not.  Why would you need to delay the signals?

The main reason we ask is that the setup times for "using delay element"
and "not using delay element" are different.  The hold times are always
listed at zero.  How can that be????????  If not using the delay
element, the input has a lower setup time, should there not be a hold
time.  According to the datasheet, if you use the delay element, you
basically have 2.3ns more setup time and if you don't you still don't
have a hold time.

Confused.
Tom


Article: 18232
Subject: Xchecker cable
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Fri, 08 Oct 1999 10:45:18 -0500
Links: << >>  << T >>  << A >>
All,
We want to drive 7 Virtex parts from one Xchecker cable.  Is this
possible?  The docs limit the load to 4 for older technologies.  Any
advice would be appreciated.

Tom


Article: 18233
Subject: Re: UK or Europe Des. Engs for California jobs
From: Jonathan Bromley <jonathan@oxfordbromley.u-net.com>
Date: Fri, 08 Oct 1999 17:35:55 +0000
Links: << >>  << T >>  << A >>
Anthony Quigley wrote:
> 
> Are you looking for a job in the sunshine?

Can you spell "cost of living in the Valley"?

Ask again when you have a decent ratio of salary
to job spec.

Jonathan Bromley
Article: 18234
Subject: GSR on ORCA FPGAs
From: mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas)
Date: 8 Oct 1999 17:56:05 GMT
Links: << >>  << T >>  << A >>
Hello,

I wonder if someone has found how to make this works...

I am having trouble getting a reset input into my ORCA FPGA to route
properly (as viewed in the NCD file via Epic and as observed in the lab
on an actual device).  I am running Leonardo/Spectrum 1998.2f and have
run the example they provide for implementing GSR on an ORCA part, but
my NCD file seems to look similar (presumably wrong again?) to my
original design.  I have tried having Leonardo/Spectrum infer the GSR
signal and providing it manually.  According to the Exemplar
documentation, the VHDL reset signal should be assert high, by the way.

Does anyone have experience routing the GSR signal in an ORCA part,
preferrably (but not necessarily) using Leonardo/Spectrum as a front
end?

Any insights would be greatly appreciated.


-- 
M. H. Salinas (MSalinas@Virginia.EDU)
Senior Scientist
Department of Electrical Engineering
University of Virginia
Article: 18235
Subject: Re: Altera 10K50V in-rush/temp problem...
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Fri, 08 Oct 1999 11:19:16 -0700
Links: << >>  << T >>  << A >>
There was an old series of posts (April this year?) on a similar problem with Altera 8K.
One theory was that it might have been crowbar current on the TTL level compatible
input buffers, i.e. with an artificial threshold voltage of 1.2 or whatever
volts rather than VCC/2, the upper and lower transistors can turn on simultaneously as
the power supply voltage comes up for some combinations of upper and lower
threshold voltages which vary with voltage and temperature.
Try http://www.dejanews.com with query "Altera power".

regards, tom

Dave Krueger wrote:
> 
> Thanks, guys.
> 
> Allan, we have both the I/O and internal VCC supplies connected to the same
> 3.3V supply, so it's not a sequencing problem.
> 
> I had a reply in e-mail that I think explains what's going on.  If, at power
> up, the internal latches come up in some random state, there will be
> contension on the INTERNAL busses that account for the excessive current on
> the VCC.  The part apparently clears these latches, but only if the power
> supply is capable of producing enough current to operate the part.  With
> some lot codes and temperatures, it draws as much as 700 mA.  Our supply was
> capable of about 500 mA.  After the latches are cleared, the current drops
> to about 20 mA (big difference!).
> 
> Upon beefing up the supply, the parts still show the current spike, but the
> device always comes out of it and the current drops to normal.
> 
> If this were a latch-up issue, the part would not recover like that.  That's
> primarily why I referred to the problem as an "in-rush" problem rather than
> a latch-up problem.
> 
> I appreciate all the responses.
> 
> -Dave

-- 
Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767
Article: 18236
Subject: Re: UK or Europe Des. Engs for California jobs
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Fri, 08 Oct 1999 18:25:58 GMT
Links: << >>  << T >>  << A >>
*nods in agreement*

They still think they're selling glass beads to indians!

+0000, Jonathan Bromley <jonathan@oxfordbromley.u-net.com> wrote:

>Can you spell "cost of living in the Valley"?
>
>Ask again when you have a decent ratio of salary
>to job spec.
>
>Jonathan Bromley

For Email remove "NOSPAM" from the address
Article: 18237
Subject: Re: Capacity metrics for Virtex
From: muzo <muzok@nospam.pacbell.net>
Date: 08 Oct 1999 13:07:20 PDT
Links: << >>  << T >>  << A >>
from page 3-7 of Xilinx 1999 Data book, second paragraph of
"Configurable Logic Block" section:

"In addition to the four basic LCs, the Virtex CLB contains logic that
combines function generators to provide functions of five or six
inputs. Consequently, when estimating the number of system gates
provided by a given device, each CLB counts as 4.5 LCs."

Stephen Charlwood <s.m.charlwood@bham.ac.uk> wrote:

>Hi.
>
>Could anyone possibly explain why a Xilinx Virtex-series CLB is
>considered equiavlent to 4.5 logic cells? I understand why an
>XC4000-series CLB is equivalent to 2.375 logic cells, but don't see the
>Virtex translation.
>
>Thanks,
>
>Steve
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>Digital Systems & Vision Processing Group 
>School of Electronic & Electrical Engineering
>University of Birmingham, Edgbaston, Birmingham, B15 2TT 
>e-mail: s.m.charlwood@bham.ac.uk
>
>Signal Processing & Imagery Department 
>Defence Evaluation & Research Agency
>DERA Malvern, St. Andrews Rd., Malvern, Worcs., WR14 3PS 
>e-mail: steve.charlwood@acm.org
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

muzo

Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)
Article: 18238
Subject: Re: RAM in xilinx FPGAs.
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Sat, 09 Oct 1999 01:31:26 +0300
Links: << >>  << T >>  << A >>


> Rob,
>   Your best bet is to use the Core Generator tool that comes with both
> Foundation and Alliance software packages from Xilinx.
>
>   Using the Core Generator tool, you select your device family (4k) and any
> other options you desire.  CoreGen will output several files, the main one
> being a netlist to be used during Place and Route.  Also produced is a
> ".vhi" file that has the component declaration and instantiation template.
>
>   As far as inferring RAM, both Leonardo Spectrum (Exemplar) and Synplify
> (Synplicity) will infer memories.  You should check their web site(s) for
> examples if you are using those synthesis tools.
>
>   Good luck,
>
>   Jim

 until these mails, always manual inference is discussed. manual inference
 is actually not a design issue, I think. The point is, how the write and read
 decoders will be implemented. If the internal macro is big enough, then the
 relative placement of RAM16X1 etc. macros and their decoders will be getting
 important. And Xilinx' tools must be superior to designer-made architectures.
 Answer: Core Generator or LogiBlox. Use either of them.

 Utku

--
I feel better than James Brown.



Article: 18239
Subject: Re: RAM in xilinx FPGAs.
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Sat, 09 Oct 1999 01:46:24 +0300
Links: << >>  << T >>  << A >>
Robert Larkin wrote:

> Hello,
>
> I need to create a block of 3*64 memory in an 4005XLPC84. I have
> been informed that this has to be done via 12 lookup tables. Does
> any one know of an application note demonstrating how this can be
> implemented? Also does any one have an example VHDL model that
> either infers or instantiates RAM in this manner?
>
> Thanks
> Rob Larkin

 one more comment:

 In Xilinx databooks, it is told that the amount of CLB of your memory is

 (number_of_your_bits) / (16x1) [dual port ram]

 or

 (number_of_your_bits) / (32x1) [single port ram].

 So, I think you are talking about a dual-port RAM implementation of your
 3x64 memory, so

 3x64 / 16x1 = 3 x 4 = 12.

 But as I said, read and write decoders will consume additional area.
 The tools like LogiBlox or Core Generator can generate this amount of memory
 according to some styles (relative placement, small mode, fast mode etc...)

 Utku

--
I feel better than James Brown.



Article: 18240
Subject: Re: External Cloking of Altera MAX 7000S
From: Moussa Ba <babs@eng.umd.edu>
Date: Fri, 08 Oct 1999 19:18:20 -0400
Links: << >>  << T >>  << A >>
The board I am using is the University Program Altera board that features a
MAX7000S as well as a FLEX10K chip.  I did notice that on the pinout of the
MAX7000S it had a bunch of VCCIO, VCCINT and GND pins.  In my pin description
file it mentions that these pins have to be connected to 5.0,5.0 and GND
respectively.  I assumed that these pins were directly driven by the on-board
power supply.  Is my assumption wrong?  I did test out the pins and they provide
no Voltage.  Do I have to provide that voltage?

Moussa
Mike wrote:

> Moussa Ba wrote in message <37FD1D45.848CC6A5@eng.umd.edu>...
> >Thank you for your reply.  I forgot to mention in my email that I did use a
> TTL
> >crystal oscillator.  And I still get a messed up signal as soon as I
> connect the
> >
> >clock to the clock input of the MAX chip.
> >
>
> Is it possible that you connect your clock to a wrong pin? Check how your
> pins were routed in your .rpt file. It sounds like you are connecting your
> clock to a pin configured as an output.
>
> Mikhail Matusov

Article: 18241
Subject: Re: Capacity metrics for Virtex
From: gd@nospam.heliontech.com (Graeme Durant)
Date: Fri, 08 Oct 1999 23:37:55 GMT
Links: << >>  << T >>  << A >>
On Fri, 08 Oct 1999 15:30:18 +0100, Stephen Charlwood
<s.m.charlwood@bham.ac.uk> wrote:

>Hi.
>
>Could anyone possibly explain why a Xilinx Virtex-series CLB is
>considered equiavlent to 4.5 logic cells? I understand why an
>XC4000-series CLB is equivalent to 2.375 logic cells, but don't see the
>Virtex translation.
>
>Thanks,
>
>Steve
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>Digital Systems & Vision Processing Group 
>School of Electronic & Electrical Engineering
>University of Birmingham, Edgbaston, Birmingham, B15 2TT 
>e-mail: s.m.charlwood@bham.ac.uk
>
>Signal Processing & Imagery Department 
>Defence Evaluation & Research Agency
>DERA Malvern, St. Andrews Rd., Malvern, Worcs., WR14 3PS 
>e-mail: steve.charlwood@acm.org
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Xilinx have managed to confuse the issue by changing terminology for
Virtex.  The 'new' Virtex CLB is a bit like two old-style 4000 series
CLBs, in that it consists of four LUTs with a bit of jiggery-pokery
wrapped around them (for implementation of carry chains, fast
multiplication etc.).  They reckon that the bits around the LUTs add
up to the functionality of half a LUT, hence the total of 4.5 cells
per CLB.

I'm just in the process of converting a 4085 design into Virtex 300,
and the initial confusion in terms of cell counts was not useful!  In
fact the 4085XLA is broadly similar in capacity to a XCV300, less the
BlockRams...but you will find it much much faster and more synthesis
friendly.

Hope that answers your question.

Graeme Durant
HELION Technology Limited
Cambridge, UK.
~~~~~~~~~~~~~~~~~~~~
Xilinx 'Xpert' Consultancy
www.heliontech.com
Article: 18242
Subject: Re: Capacity metrics for Virtex
From: James Yeh <jiahau@uclink4.berkeley.edu>
Date: Fri, 08 Oct 1999 16:39:12 -0700
Links: << >>  << T >>  << A >>
So if you look in the Data sheet, there is a diagram of a CLB, there are
a couple muxes inside a clb slice that one can use.  So, these can be
thought of as adding another input.  Each of these muxes (which are
dependent on the LUTS) can add another degree of freedom in certain
cases.  

muzo wrote:
> 
> from page 3-7 of Xilinx 1999 Data book, second paragraph of
> "Configurable Logic Block" section:
> 
> "In addition to the four basic LCs, the Virtex CLB contains logic that
> combines function generators to provide functions of five or six
> inputs. Consequently, when estimating the number of system gates
> provided by a given device, each CLB counts as 4.5 LCs."
> 
> Stephen Charlwood <s.m.charlwood@bham.ac.uk> wrote:
> 
> >Hi.
> >
> >Could anyone possibly explain why a Xilinx Virtex-series CLB is
> >considered equiavlent to 4.5 logic cells? I understand why an
> >XC4000-series CLB is equivalent to 2.375 logic cells, but don't see the
> >Virtex translation.
> >
> >Thanks,
> >
> >Steve
> >
> >
> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> >
> >Digital Systems & Vision Processing Group
> >School of Electronic & Electrical Engineering
> >University of Birmingham, Edgbaston, Birmingham, B15 2TT
> >e-mail: s.m.charlwood@bham.ac.uk
> >
> >Signal Processing & Imagery Department
> >Defence Evaluation & Research Agency
> >DERA Malvern, St. Andrews Rd., Malvern, Worcs., WR14 3PS
> >e-mail: steve.charlwood@acm.org
> >
> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> muzo
> 
> Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)
Article: 18243
Subject: Re: Mentor on a Laptop
From: jcooley@world.std.com (John Cooley)
Date: Sat, 9 Oct 1999 00:08:12 GMT
Links: << >>  << T >>  << A >>
Kurt Caudle  <caudlek@igs.net> wrote:
>Anyone in this group have advice on running Mentor on a Laptop.
>
>Hardware minimum? Does it import/export to the Mentor Unix Version
>easily?

Kurt,

I'm not exactly sure what you mean by "Mentor".  I'm assuming
you're talking about the Mentor Windows-based tools from
its Model Tech and Exemplar divisions.  Yes, they're easily
run on PC's -- but if you're going to do any real FPGA
synthesis or Verilog/VHDL simulation, I recommend you get
the biggest, fastest, meanest, memmory-loaded laptop you
can.  EDA tools (not just Mentor's, but all EDA tool) can
seriously tax a workstation or a PC if you're doing real
design with them.  And the few dollars you spend on getting
the higher end PC with LOTS of memory is more than worth the
time you'd spend if your tool sparts going to disk for swap
space....

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

============================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 9,607 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."
 The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
Article: 18244
Subject: Re: RAM in xilinx FPGAs.
From: Ray Andraka <randraka@ids.net>
Date: Fri, 08 Oct 1999 22:15:37 -0400
Links: << >>  << T >>  << A >>
The Core generator tools do not always turn out better designs than what an
experienced FPGA designer can do.  Considering the ability of the average user
however, using the generator is usually a good idea.  Just be careful you know
what you are really getting in terms of speed, area and function.

Utku Ozcan wrote:

> > Rob,
> >   Your best bet is to use the Core Generator tool that comes with both
> > Foundation and Alliance software packages from Xilinx.
> >
> >   Using the Core Generator tool, you select your device family (4k) and any
> > other options you desire.  CoreGen will output several files, the main one
> > being a netlist to be used during Place and Route.  Also produced is a
> > ".vhi" file that has the component declaration and instantiation template.
> >
> >   As far as inferring RAM, both Leonardo Spectrum (Exemplar) and Synplify
> > (Synplicity) will infer memories.  You should check their web site(s) for
> > examples if you are using those synthesis tools.
> >
> >   Good luck,
> >
> >   Jim
>
>  until these mails, always manual inference is discussed. manual inference
>  is actually not a design issue, I think. The point is, how the write and read
>  decoders will be implemented. If the internal macro is big enough, then the
>  relative placement of RAM16X1 etc. macros and their decoders will be getting
>  important. And Xilinx' tools must be superior to designer-made architectures.
>  Answer: Core Generator or LogiBlox. Use either of them.
>
>  Utku
>
> --
> I feel better than James Brown.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18245
Subject: Re: RAM in xilinx FPGAs.
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Sat, 09 Oct 1999 10:16:07 +0100
Links: << >>  << T >>  << A >>

Robert Larkin wrote:
> 
> Hello,
> 
> I need to create a block of 3*64 memory in an 4005XLPC84. I have
> been informed that this has to be done via 12 lookup tables. Does
> any one know of an application note demonstrating how this can be
> implemented? Also does any one have an example VHDL model that
> either infers or instantiates RAM in this manner?
> 
> Thanks
> Rob Larkin

A simple example:

--
--  Project     : SVAL FPGA
--
--  File        : svalhf_ea.vhd (see Readme.txt file for additional
information)
--
--  Module      : RAM memory
--
--  Author      : Eduardo Bezerra <E.A.Bezerra@sussex.ac.uk>
--  Date        : 14/10/98
--  Last change : 08/04/99
--
--  Description:
--
--  64 x 8 bits synthesizable RAM memory. Synplify can infer RAM memory
from this description.
--
--  Change SIZE64_C, PTR64_C and BYTE_C in order to modify the memory
size/lenght.
--
--   constant SIZE64_C  : integer := 64;                   --  64
addresses
--   constant PTR64_C   : integer := 6;                    --  64
addresses
--   constant BYTE_C    : integer := 8;                    -- 8 bits


library IEEE;
   use IEEE.std_logic_1164.all;
   use IEEE.std_logic_unsigned.all;
   use work.SVAL_PKG.all;

entity RAM64_MEM is
  port ( CLK_IN       : in  std_logic;
         ADDR_IN      : in  std_logic_vector(PTR64_C - 1 downto 0);
         WR_IN        : in  std_logic;
         DATA_IN      : in  std_logic_vector(BYTE_C - 1 downto 0);
         DATA_OUT     : out std_logic_vector(BYTE_C - 1 downto 0)
        );
end RAM64_MEM;

architecture RAM64_MEM_BEH of RAM64_MEM is
   type RAM_TYP is array(SIZE64_C - 1 downto 0) of
std_logic_vector(BYTE_C - 1 downto 0);
   signal MEM         : RAM_TYP;
   signal ADDR_IDX    : std_logic_vector(PTR64_C - 1 downto 0);

begin
   DATA_OUT <= MEM(conv_integer(ADDR_IDX));
   MEMORY_PRO: process (CLK_IN)
   begin
      if CLK_IN'event and CLK_IN = '1' then
         if (WR_IN = '1') then
            MEM(conv_integer(ADDR_IN)) <= DATA_IN;
         end if;
         ADDR_IDX <= ADDR_IN;
      end if;
   end process MEMORY_PRO;
end RAM64_MEM_BEH;
Article: 18246
Subject: Re: Can't detect Flex 10K Altera device through JTAG port
From: Steve Rencontre <Steve@XXX_REMOVE_XXXrsn-tech.demon.co.uk>
Date: Sat, 09 Oct 1999 13:41:42 +0100
Links: << >>  << T >>  << A >>
It shouldn't matter if nCONFIG and nTRST are held low initially.
Sounds to me like your ByteBlaster may be faulty, or possibly you have
an incorrect driver setup.

You say "standard" ByteBlaster - do you mean the +5V version? That
might well be the problem if you have 3V3 logic. 

On Fri, 08 Oct 1999 13:27:24 GMT, in
<0jmL3.23007$m4.84753273@news.magma.ca> "Mike" <mmatusov@ics-ltd.com>
wrote:

>Hi all,
>
>We are having troubles in programming Altera 10K30A device via JTAG port.
>Altera software does not detect the device at all. Everything is configured
>according to their datasheet for the case of JTAG only programming. There is
>only one device in the chain. We are using standard ByteBlaster.
>
>Our only guess is that two pins nCONFG and nTRST of the device that should
>be tied high for this to work according to Altera, are connected in our case
>to 3.3v plane. 3.3v in its turn is generated on our board and there is about
>3ms delay on power-up before it goes up. In other words on power up these
>two pins are essentially tied low and if their condition is latched at that
>moment then that would explain weird behaviour we see. But is it actually
>being latched at all?
>
>Can anybody shed some light on this matter?
>
>Thank you in advance.
>
>
>Mikhail Matusov
>

--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk/  --  remember to despam return address
Article: 18247
Subject: Re: ATM srambler
From: "David Tang" <dtang@springtidenet.comNOSPAM>
Date: Sat, 9 Oct 1999 11:21:15 -0400
Links: << >>  << T >>  << A >>
Here is a proven working ATM scrambler:

reg  [42:0]  delay_tap;
assign delay_tap = {delay_tap[0] ^ serial_in, delay_tap[42:1]};
assign serial_out = scram_en ? delay_tap[0] ^ serial_in : serial_in;

Good Lucks!

David-

rseglie@my-deja.com wrote in message <7t9ufs$npk$1@nnrp1.deja.com>...
>In article <37F7BAF6.B3A3999C@ids.net>,
>  Ray Andraka <randraka@ids.net> wrote:
>> Who is Norm?
>>
>> I'm not sure if the polynomial is correct for ATM or not.  If the
>polynomial is
>> x^43 + 1 then you need 43 delays, not the 42 you have shown.  Think of
>1 as
>> x^0.  In your drawing d0 should be e+q43.  The '+' is the one bit sum,
>which is
>> the exclusive OR of the serial data input and the feedback data
>path(s).  The
>> output can be taken off anywhere along the delay queue.  You may want
>to take
>> it from immediately AFTER the first register if the design is highly
>pipelined
>> (as it would likely be for an FPGA implementation).  This of course is
>the
>> scrambler.  The descrambler has feed-forward instead of feedback, also
>by 43
>> delays.
>>
>> Note that this scrambler is for serialized data, and as such may have
>too high
>> a bit rate to be done in the FPGA.  My guess is that you are using an
>external
>> serializer, in which case you will need to transform this to the
>parallel form
>> for the scrambler rather than this serial one.   The translation to a
>parallel
>> design is not trivial, and will take some time to derive.
>>
>> Rémi SEGLIE wrote:
>>
>> > I have to do an ATM scrambler in a FPGA and I wonder some questions
>:
>> > Norm says that the polynome is x^43+1, it's enabled only during
>payload and
>> > that the basic diagram is :
>> >
>> >           -------------------------------
>> >           |         __     __               __   |
>> >          V       |    |    |    |             |    |   |
>> > Ei -->+-----|    |-- |    |--  ...  --|    |--|
>> >                |   |__|    |__|             |__|
>> >               V
>> >               Yi
>> >
>> > (sorry for this poor draw)
>> > In others words :
>> > d0 = e + q42
>> > d1 = q0
>> > d2 = q1
>> >  ...
>> >  d42 = q41
>> >
>> > Is it right ?
>> >
>> > Thank you for your help.
>> >
>> > Rémi SEGLIE
>> > Hardware Design Engineer
>> > company : CELOGIC
>> > www : http://www.celogic.com/
>>
>> --
>> -Ray Andraka, P.E.
>> President, the Andraka Consulting Group, Inc.
>> 401/884-7930     Fax 401/884-7950
>> email randraka@ids.net
>> http://users.ids.net/~randraka
>>
>>
>Tank you for your help
>
>Norm is for "standard" (sometimes I forget my basic english).
>
>I solve the problem on friday. The polynom is ok, I've done a mistake
>about where to get the output.
>
>A few answers to your email :
>About degree : I start from 0 (d0 for Q0) so there's, of course, 43
>registers.
>The + means xor.
>
>Standards always show serial scrambler so I thought that it's easier to
>talk about them.
>In my FPGA, I transform the "serie" version in 8 bits parallel "version"
>, looking the content of all registers after 8 clock cycles. Of course
>you can use this method for 16 bits version.
>
>My mistake was to take the output after the register but it must be
>taken before ! (when I wrote this message I have any idea and I thought
>the diagram was wrong).
>I test it and it's ok !!
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.


Article: 18248
Subject: FYI
From: "Shen Jiakan" <sjks@kali.com.cn>
Date: Sun, 10 Oct 1999 00:28:56 +0800
Links: << >>  << T >>  << A >>
To Whom It May Interest:
http://magsite.yeah.net



Article: 18249
Subject: test
From: jjlarkin@highlandSnipSniptechnology.com (John Larkin)
Date: Sat, 09 Oct 1999 21:13:25 GMT
Links: << >>  << T >>  << A >>


Do not be alarmed. This is a test - repeat - this is only a test.

If this were an actual newsgroup posting, I would possibly

have something useful to say.

John




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