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 34400

Article: 34400
Subject: Testbench book
From: yangpece@yahoo.com (Diedricher)
Date: 23 Aug 2001 10:43:02 -0700
Links: << >>  << T >>  << A >>
Any one know good book teaches how to write testbench in VHDL and/or Verilog?

Article: 34401
Subject: Re: FPGA MP3 decoder
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 23 Aug 2001 20:38:27 +0200
Links: << >>  << T >>  << A >>
Andy Peters
> 
> Mark wrote:
> >
> > Hi there!
> >
> > I'm pretty new at FPGAs, and what I'm trying to do is
> > program an MP3 decoder into an FPGA..
> > Does anyone have experience at this?
> > Are there VHDL or Handel-C mp3 decoder sources around?
> > Or anyone wants to discuss this subject with me? :-))
> 
> Seems to me that you're better off implementing the decoder in a DSP.

Or even better, use a ASSP

have a look at 

www.vlsi.fi

their decoder is just 20$ and has an integrated DAC.


-- 
MFG
Falk


Article: 34402
Subject: Re: Testbench book
From: vhdlcohen@aol.com (VhdlCohen)
Date: 23 Aug 2001 18:39:37 GMT
Links: << >>  << T >>  << A >>
MY book Component Design by Example . provides a complete example in VHDL for
the application of transaction based TB designs, along with a reusable textio
parser for commands defined in files. 

At my site there is also a SNUG paper (under papers link) that demonstrates the
TB concepts along with a verilog example. 
Ben

---------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830
http://www.vhdlcohen.com/                 vhdlcohen@aol.com  
Author of following textbooks: 
* Component Design by Example ... a Step-by-Step Process Using 
  VHDL with UART as Vehicle",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
--------------------------------------------------------------------------
------------------

Article: 34403
Subject: Re: DRAM burst mode
From: "Jan Pech" <j.pech@sh.cvut.cz>
Date: Thu, 23 Aug 2001 20:49:40 +0200
Links: << >>  << T >>  << A >>
Very good description of DRAM modes, access etc. can be found in Micron's
datasheets (http://www.micron.com).

Jan

> Hi All,
>
> I can read and write data using a fpga and dram but have no information on
> how to use the burst mode.
> Has anyone got any information that could help me?
>
> I know that I need to change the mode and then assert the burst command
but
> do not have any of the mode information.
>
> Intel used to have a good page but it has since been removed and I never
> downloaded the pdf (DOH)
>
>
> Cheers in advance
> Dave
>
>
>
>



Article: 34404
Subject: Re: Testbench book
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Thu, 23 Aug 2001 20:14:23 +0100
Links: << >>  << T >>  << A >>
Janick Bergeron's book

"Diedricher" <yangpece@yahoo.com> wrote in message
news:f418afeb.0108230943.206f0d6d@posting.google.com...
> Any one know good book teaches how to write testbench in VHDL and/or Verilog?



Article: 34405
Subject: Re: Optical Bay Area Start-up! SW/HW Engs needed
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 23 Aug 2001 20:26:49 +0100
Links: << >>  << T >>  << A >>


"Andy Peters

> Hey, Mr. Headhunter:
>
> 1) Stop posting off-topic ads in this newsgroup -- nowhere in your ad
> did you mention the four magic letters "F-P-G-A"
>
> 2) Stop posting HTML-formatted crap.  Figure out how to properly
> configure your news-posting software.
>
> 3) Go away.
>

Methinks #3 is quite sufficient and basically way too polite.


Article: 34406
Subject: Testing ... please ignore
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 23 Aug 2001 21:03:08 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------9DA19003B9976025BA3CF1D9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------9DA19003B9976025BA3CF1D9
Content-Type: text/plain; charset=us-ascii;
 name="foo"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="foo"

Ignore - testing attach.

--------------9DA19003B9976025BA3CF1D9--


Article: 34407
Subject: Re: Slowing PCI for FPGA
From: Ken McElvain <ken@synplicity.com>
Date: Thu, 23 Aug 2001 13:17:56 -0700
Links: << >>  << T >>  << A >>
Amplify does much more than just better timing estimates based on your floorplan.

1) It makes it very easy to reorganize your logical hierarchy into 
an appropriate physical hierarchy for optimization.  The reorganization
can include replication of larger structures like state machines/counters
or whole RTL paths.  This can make it much easier for Amplify to optimize
the logic and timing along the paths.

2) RTL floorplan assignments are done on the names of the RTL components
(modules, adders, state machines, rams, logic ...) before they go through the complete
optimization and mapping flow.  This reduces the complexity of building the
floorplan.  Another benefit is that the HDL compilers in Amplify are pretty 
good at preserving names even when changes to the HDL are made, so your
floorplans can survive design changes.

3) Timing estimates are better during optimization.

4) The floorplan you enter is optimized concurrently with timing optimization.
At a detail level, logic and flip-flops are moved from region to region as
part of timing optimizations like replication or restructuring of long paths.  
This is the reason we call it a physical synthesis tool instead of just an 
RTL floorplanner and is responsible for a lot of the performance gains.
Essentially, your RTL floorplan is just a starting point for the construction
of a gate level floorplan.

5) I should also mention the TOPS technology announcement we made at DAC time (June)
about mixing of detailed placement and optimization.

Ken McElvain, CTO
Synplicity Inc.


Joey Oravec wrote:
> 
> hamish@cloud.net.au wrote in message news:<ZvNg7.21651$A5.65678@news1.eburwd1.vic.optushome.com.au>...
> > Do you see much advantage with Amplify? Do you see it doing anything
> > which you couldn't do yourself with Synplify Pro and the Xilinx floorplanner?
> >
> > I have access to an Amplify license at work and in my brief experience
> > with it, it just seems to be a way to enter your floorplan and have
> > it appear in an NCF. So I just enter it into the UCF myself, with
> > floorplanner or by hand.
> >
> > I'd like to be proven wrong though. What does the tool itself actually
> > do with the floorplanning information? What optimisations can
> > it make at synthesis time given the floorplan?
> 
> Well, amplify feels superior to synplify pro in synthesis. It's kind
> of comparing apples to oranges between versions of the software
> because I used synpro 7.0b2 and amplify 2.2.4. For me, Amplify's
> timing report was far more conservative which was great. Some designs
> failed by just a 4-5 ns during PAR (level2) with SynPro that succeeded
> under the same conditions with Amplify. Could have just been
> dumb-luck, but synthesis time I had those more accurate timing
> predictions with Amplify.
> 
> As for floorplanning effect on synthesis, I have no idea offhand. You
> make a good point that everything could probably be done by hand or
> with the floorplanner tool. This tool's strength lies more in its ease
> of use. In about an hour using the Amplify floorplanner with little
> knowledge of the RTL, I lowered cycle time from 47ns to 37ns post-PAR
> meeting the 25mhz constraint with under an hours work. The paths were
> 25% logic 75% route.
> 
> There's not a lot of choice for improving a design besides modifying
> the RTL code and improving placement/routing. Since modifying the RTL
> is a non-option in an ASIC prototype, Amplify was really the only
> route for improvement.
> 
> I was very skeptical of the tool, especially because the thought of
> rearranging a million gates on a large Virtex is absurd. However it
> really was pretty easy working with the RTL structures instead of
> gates. My design had a lot of block repetition and wide structures, so
> that really helps. Your mileage may vary.
> 
> -joey

--

Article: 34408
Subject: Re: Logic Emulation
From: Ken McElvain <ken@synplicity.com>
Date: Thu, 23 Aug 2001 13:23:42 -0700
Links: << >>  << T >>  << A >>
There is nothing wrong with gating clocks if you have the
timing analysis tools to check/optimize for them in all points in your
tool flow.  If you don't, then you are taking a big risk.

Gating of clocks is very important in power reduction for ASICs.

Falk Brunner wrote:
> 
> Tim schrieb:
> >
> >    Gated clocks in ASICs, less common in FPGAs
> 
> AHHHHH, there it is again, the ugly word.
> 
> GATED CLOCKS!!!
> 
> Jehova, Jehova, Jehova. ;-))
> 
> Can someone tell, how common they truely are? Are there special tecnics
> that simpifies verification of gated clocks?
> 
> --
> MFG
> Falk

-- 
Ken McElvain, CTO
Synplicity Inc.
(408)215-6060

Article: 34409
Subject: Carry chain warnings from Xilinx MAP
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 23 Aug 2001 21:44:21 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F211BF12E2A1203EA81F14C0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------F211BF12E2A1203EA81F14C0
Content-Type: text/plain; charset=us-ascii;
 name="syn-map.error"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="syn-map.error"

I'm getting some warnings from MAP that I think are being caused by a
bum synthesis [Synplify] but I'm not sure, it might be a MAP
problem. 

The warning message is:


WARNING:Pack:249 - The following adjacent carry multiplexers occupy different
   slice components.  The resulting carry chain will have suboptimal timing.
   	cpu/data/cpubuff/un1_fifo_level_1_cry_0
   	cpu/data/cpubuff/un1_fifo_level_1_cry_1_0

Looking into the code I can see this relates to this fragment [from
the post-synth .vm file]. I can't see anything wrong but (i) I'm
probably missing something, (ii) it maybe a more global problem of
resource conflicts elsewhere. All the other instances of this problem
occur in the same place i.e. at the beginning of a sort-of up/down
counter.

// @6:112
  LUT4_007F N_1551_i_Z (
	.I0(fifo_level_0[0]),
	.I1(fifo_almost_empty78),
	.I2(o1),
	.I3(G_50),
	.O(N_1551_i)
);

...

// @6:112
  LUT3_78 un1_fifo_level_1_axb_1_Z (
	.I0(fifo_almost_empty78),
	.I1(o1),
	.I2(fifo_level_0[1]),
	.O(un1_fifo_level_1_axb_1)
);
// @6:112
  LUT3_78 un1_fifo_level_1_axb_2_Z (
	.I0(fifo_almost_empty78),
	.I1(o1),
	.I2(fifo_level_0[2]),
	.O(un1_fifo_level_1_axb_2)
);
// @6:112
  LUT3_6A un1_fifo_level_1_axb_3_Z (
	.I0(fifo_level_0[3]),
	.I1(o1),
	.I2(fifo_almost_empty78),
	.O(un1_fifo_level_1_axb_3)

// @14:55
  MUXCY_L un1_fifo_level_1_cry_0_Z (
	.DI(fifo_level_0[0]),
	.CI(GND),
	.S(N_1551_i),
	.LO(un1_fifo_level_1_cry_0)
);
// @14:55
  MULT_AND un1_fifo_level_1_cry_1_Z (
	.I0(fifo_almost_empty78),
	.I1(o1),
	.LO(un1_fifo_level_1_cry_1_0)
);
// @14:55
  MUXCY_L un1_fifo_level_1_cry_1_0_Z (
	.DI(un1_fifo_level_1_cry_1_0),
	.CI(un1_fifo_level_1_cry_0),
	.S(un1_fifo_level_1_axb_1),
	.LO(un1_fifo_level_1_cry_1)
);
// @14:55
  MULT_AND un1_fifo_level_1_cry_2_Z (
	.I0(fifo_almost_empty78),
	.I1(o1),
	.LO(un1_fifo_level_1_cry_2_0)
);
// @14:55
  XORCY un1_fifo_level_1_s_1 (
	.LI(un1_fifo_level_1_axb_1),
	.CI(un1_fifo_level_1_cry_0),
	.O(un1_fifo_level_1_s_1_0)
);
// @14:55
  XORCY un1_fifo_level_1_s_2 (
	.LI(un1_fifo_level_1_axb_2),
	.CI(un1_fifo_level_1_cry_1),
	.O(un1_fifo_level_1_s_2_0)
);
// @14:55
  XORCY un1_fifo_level_1_s_3 (
	.LI(un1_fifo_level_1_axb_3),
	.CI(un1_fifo_level_1_cry_2),
	.O(un1_fifo_level_1_s_3_0)
);

--------------F211BF12E2A1203EA81F14C0--


Article: 34410
Subject: Re: Slowing PCI for FPGA
From: Richard Iachetta <iachetta@us.ibm.com>
Date: Thu, 23 Aug 2001 15:58:33 -0500
Links: << >>  << T >>  << A >>
In article <9m1vnt$e6d$1@slb7.atl.mindspring.net>, austin@87darkroom.com 
says...
> I'd suggest before telling people that they are "missing the point", you
> might want to take a look at exactly what "point" prople were answering.

Austin, good "point".  Very sorry.  In fairness the post I replied to was 
recommendations including how to design the state machines when "The goal 
is to prototype an ASIC in an FPGA." was part of the quoted text.  
Anyway, I should have noticed that that info was not in the original 
post.

-- 
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.

Article: 34411
Subject: Re: DRAM Burst Mode
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 23 Aug 2001 22:01:03 +0100
Links: << >>  << T >>  << A >>


Speedy Zero Two wrote:

> Hi All,
>
> I can read and write data using a fpga and dram but have no information on
> how to use the burst mode.
> Has anyone got any information that could help me?
>
> I know that I need to change the mode and then assert the burst command but
> do not have any of the mode information.
>

I find its a lot easier (?) to set the mode register once at the beginning of
time and then to truncate bursts shorter than the mode register setting using
some combination of the byte masks (DQMB) and early pre-charge. Which one
depends on whether or not you are using auto-precharge bursts.

Another thing to watch out for is the burst order in a system where you might
have a CPU using sub-block and some DMA (e.g. PCI) that needs linear. Even here
its possible to set sub-block and arrange that other bursts are always a power
of 2 and start at offset 0 modulo their size.



Article: 34412
Subject: Re: Principles of Verifiable RTL Design (2nd ed)
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Thu, 23 Aug 2001 15:12:55 -0600
Links: << >>  << T >>  << A >>
> It's not hidden, Ben, it's just in a different form. The way you know it's
> the same is twofold: first, you have a testbench you can run on the
> synthesized result, which should produce the same results as your original
> code. Second, you have formal verification tools, that can compare the
> synthesizer output (gate level verilog, in the case I'm familiar with) with
> your original VHDL or verilog code.

Since I use free tools I don't have access to the fancy tools. Secondly I use
paper and pencil most of my small design work. Since I use schematics, the old
eyeball
and a logic probe for testing none of the above will work for me. None the less
I need to know what logic I enter for FPGA does generate correct and efficient
nets for the FPGA.
Ben.
-- 
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.

Article: 34413
Subject: Re: DRAM Burst Mode
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Thu, 23 Aug 2001 22:16:15 +0100
Links: << >>  << T >>  << A >>

"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3B856F0F.71DE9A7B@algor.co.uk...
>
>
> Speedy Zero Two wrote:
>
> > Hi All,
> >
> > I can read and write data using a fpga and dram but have no information
on
> > how to use the burst mode.
> > Has anyone got any information that could help me?
> >
> > I know that I need to change the mode and then assert the burst command
but
> > do not have any of the mode information.
> >
>
> I find its a lot easier (?) to set the mode register once at the beginning
of
> time and then to truncate bursts shorter than the mode register setting
using
> some combination of the byte masks (DQMB) and early pre-charge. Which one
> depends on whether or not you are using auto-precharge bursts.
>
> Another thing to watch out for is the burst order in a system where you
might
> have a CPU using sub-block and some DMA (e.g. PCI) that needs linear. Even
here
> its possible to set sub-block and arrange that other bursts are always a
power
> of 2 and start at offset 0 modulo their size.
>


So how do I set the mode to "say4 or 8" ?

Dave







Article: 34414
Subject: Re: Principles of Verifiable RTL Design (2nd ed)
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Thu, 23 Aug 2001 16:05:42 -0600
Links: << >>  << T >>  << A >>
"Andy Peters
> 
> Ben Franchuk wrote:
> >
> > > It's not hidden, Ben, it's just in a different form. The way you know it's
> > > the same is twofold: first, you have a testbench you can run on the
> > > synthesized result, which should produce the same results as your original
> > > code. Second, you have formal verification tools, that can compare the
> > > synthesizer output (gate level verilog, in the case I'm familiar with) with
> > > your original VHDL or verilog code.
> >
> > Since I use free tools I don't have access to the fancy tools.
> 
> Further proof of the old adage, "you get what you pay for."

That must mean all the tools are JUNK. You don't buy the tools you RENT them!
Ben.
-- 
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.

Article: 34415
Subject: Re: DRAM Burst Mode
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 23 Aug 2001 23:19:00 +0100
Links: << >>  << T >>  << A >>


Speedy Zero Two wrote:

> "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
> news:3B856F0F.71DE9A7B@algor.co.uk...
> >
> >
> > Speedy Zero Two wrote:
> >
> > > Hi All,
> > >
> > > I can read and write data using a fpga and dram but have no information
> on
> > > how to use the burst mode.
> > > Has anyone got any information that could help me?
> > >
> > > I know that I need to change the mode and then assert the burst command
> but
> > > do not have any of the mode information.
> > >
> >
> > I find its a lot easier (?) to set the mode register once at the beginning
> of
> > time and then to truncate bursts shorter than the mode register setting
> using
> > some combination of the byte masks (DQMB) and early pre-charge. Which one
> > depends on whether or not you are using auto-precharge bursts.
> >
> > Another thing to watch out for is the burst order in a system where you
> might
> > have a CPU using sub-block and some DMA (e.g. PCI) that needs linear. Even
> here
> > its possible to set sub-block and arrange that other bursts are always a
> power
> > of 2 and start at offset 0 modulo their size.
> >
>
> So how do I set the mode to "say4 or 8" ?
>
> Dave

I could describe this & all the others but I think the advice to download a
Micron SDRAM data sheet is correct. They are well written & their web site has a
very good DRAM FAQ section.

The other source is the Intel site. Search for PC100 or PC133 and then grovel
through all the screeds of stuff about motherboards & chip sets.



Article: 34416
Subject: Re: Optical Bay Area Start-up! SW/HW Engs needed
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 23 Aug 2001 15:30:07 -0700
Links: << >>  << T >>  << A >>
Every time this happens I have been sending a standard complaint
email to the perpetrator. This seems to have worked most times.

I would recomend that others also send private email to the headhunters.
Sending it to the group really serves no purpose.

By the way Andy, did we really need for you to include his whole post ? :-)

Philip Freidin

On Thu, 23 Aug 2001 17:25:34 GMT, "Andy Peters <andy [@]
   exponentmedia" <".> com"> wrote:
>Hey, Mr. Headhunter:
>
>1) Stop posting off-topic ads in this newsgroup -- nowhere in your ad
>did you mention the four magic letters "F-P-G-A"
>
>2) Stop posting HTML-formatted crap.  Figure out how to properly
>configure your news-posting software.
>
>3) Go away.
>

Philip Freidin
Fliptronics

Article: 34417
Subject: Xilinx FPGA Editor - how to route to an internal macro net?
From: arast@inficom.com (Alex Rast)
Date: Fri, 24 Aug 2001 00:19:48 GMT
Links: << >>  << T >>  << A >>
This is one I think I've done before, so I probably just need my memory 
jogged. I'm sure it's something that happens, and that you need, all the time.

I've defined a hard macro, call it custommacro.nmc. This macro will have 
internal routes and external macro pins (not the pins/I/O pads of the device, 
the logical pins of the macro). Now, at least one of the nets connects to an 
external pin and an internal route. One common example, for instance, is CLK. 
You want the signal to be common to the internal CLB's of the macro and to 
connect to external routes (in the case of CLK, to the global clock net). 

Now, within the macro I define a proper external pin for the clock net, 
attaching it to one of the CLK pins for a slice. Then I instantiate the macro 
in the design within FPGA editor. So now I go to route a net, for instance the 
global clock net, to the appropriate external pin on the macro, thus 
connecting the external signal to the internal macro net. What I do is 
highlight the macro pin I want, and all segments of the external net I want to 
route. Then I click the route button.

No success. FPGA Editor complains "WARNING:FPGAEditor: 145 - Cannot add to net 
"Macro1CLK" -- it is an internal macro net."

What am I doing wrong? Is it an error in how I've defined the external pins in 
the macro? Using the wrong procedure to route the external nets? Or something 
else? This situation must surely be pretty common (clock signals, in 
particular, are almost always going to have to be common to internal routes in 
a macro and external routes) so I think I'm missing something. As I say, I 
think I've solved this problem before. But in any event, can someone give me 
the basic idea of what to do?

Thanks.

Alex Rast
arast@inficom.com
arast@qwest.net

Article: 34418
Subject: Re: Latest Maxim bit serializer-deserializer chip announcements
From: John Larkin <jjlarkin@highlandSNIP_THIStechnology.com>
Date: Thu, 23 Aug 2001 17:33:02 -0700
Links: << >>  << T >>  << A >>
On Thu, 23 Aug 2001 15:01:22 GMT, "Dave Feustel" <dfeustel1@home.com>
wrote:


Dave,

please don't spam us again, or I'll tell the story of how Maxim
screwed a lot of people with the MAX9690.

John




Article: 34419
Subject: Reading Text in Verilog
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Fri, 24 Aug 2001 00:33:18 GMT
Links: << >>  << T >>  << A >>
For testbenches, is there a method to read in a text file in Verilog?  The
$fdisplay function is great for writing to files, but the functions for
reading in files are limited; the only method I know of to read in a file is
to dump it into a register using the $readmemh command.  However, that only
works with files formatted in ascii-hex, e.g. "41 42 43", not files
formatted in text, e.g. "ABC".  I wrote a Perl script to convert text files
to ascii-hex but that seems a lame workaround.

-Kevin



Article: 34420
(removed)


Article: 34421
Subject: Re: Can't Install Modelsim - Alternatives for Verilog Simulation???
From: Stephen Williams <steve@icarus.com>
Date: 24 Aug 2001 01:27:17 GMT
Links: << >>  << T >>  << A >>

> I'd rather have a version
> I can compile with Visual Studio 6 (either as a project or with a make
> file) and run Icarus natively on Windows  than use Cygwin

Icarus Verilog 0.5 runs natively under Windows, complete with a working
installer. It is a mingw port rather then a Cygwin port. (Cygwin
compiled
binaries are just too much of a pain to work with, as you seem to know.)

Compiling Icarus Verilog from source still requires a Cygwin
installation,
but that is only for the tools other then the compiler -- gperf, make,
bison, flex, and a shell to run the configure script. There is a text
file in the source tarball that explains the mingw build process that
works.

And 0.5 also supports some minimal synthesis for 4000 series Xilinx
parts.
I have a new xnf code generator in the works that will support Virtex
series as well.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Article: 34422
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: Dave Vanden Bout <devb@xess.com>
Date: Thu, 23 Aug 2001 23:49:22 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> John,
>
> Make, model number, and where to buy the IR temp sensor?
>
> I get sooo many questions, and it would be worth its weight in gold to publicize this
> info!

You can buy an Extech infrared thermometer from Techni-tool for $99.00.  Measures 0 - 600
degrees F with a 6:1 field view.




>
>
> Austin
>
> John Larkin wrote:
>
> > On Mon, 20 Aug 2001 19:10:26 +0100, Rick Filipkiewicz
> > <rick@algor.co.uk> wrote:
> >
> > >Peter,
> > >
> > >On top of all the other useful stuff you contribute to CAF you have just answered a
> > >long-standing (or burning ?) question of mine regarding the calibration of heat
> > >sensing fingertips.
> >
> > Peter,
> >
> > my right forefinger is calibrated as follows:
> >
> > 50C - ok for infinite duration contact
> >
> > 52C - 10 seconds to pullaway
> >
> > 60C - 1 second to pullaway
> >
> > Interpolate linearly between points. Your digits may vary.
> >
> > We just got a cheap ($79) infrared temp sensor, which is cool (no pun,
> > really) for scanning FPGAs on a board.
> >
> > John
> >
> > >
> > >To go further and get another data point: Last summer I was wondering why our new
> > >board wasn't doing anything from power-on. I, very briefly, put my finger on it &
> > >came away with a large &  painful blister that was still very sore 2 days later.
> > >
> > >Cause = BGA chip pinout mirrored (not by me I hasten to add).
> > >
> > >What temp do you think the package would have reached ?




--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 34423
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@dark55room.com>
Date: Fri, 24 Aug 2001 00:07:51 -0400
Links: << >>  << T >>  << A >>

> Amplify does much more than just better timing estimates based on your
floorplan.
>
> 1) It makes it very easy to reorganize your logical hierarchy into
> an appropriate physical hierarchy for optimization.  The reorganization
> can include replication of larger structures like state machines/counters
> or whole RTL paths.  This can make it much easier for Amplify to optimize
> the logic and timing along the paths.
>
> 2) RTL floorplan assignments are done on the names of the RTL components
> (modules, adders, state machines, rams, logic ...) before they go through
the complete
> optimization and mapping flow.  This reduces the complexity of building
the
> floorplan.  Another benefit is that the HDL compilers in Amplify are
pretty
> good at preserving names even when changes to the HDL are made, so your
> floorplans can survive design changes.
>
> 3) Timing estimates are better during optimization.
>
> 4) The floorplan you enter is optimized concurrently with timing
optimization.
> At a detail level, logic and flip-flops are moved from region to region as
> part of timing optimizations like replication or restructuring of long
paths.
> This is the reason we call it a physical synthesis tool instead of just an
> RTL floorplanner and is responsible for a lot of the performance gains.
> Essentially, your RTL floorplan is just a starting point for the
construction
> of a gate level floorplan.

You know, all this fancy (and expensive) "stuff" that you have to do to get
synthesized code to work "fast" is absolutely no effort to do with the
design correctly done using schematics as the entry methodology.  Sigh.




Article: 34424
Subject: Re: Latest Maxim bit serializer-deserializer chip announcements
From: "Dave Feustel" <dfeustel1@home.com>
Date: Fri, 24 Aug 2001 04:50:01 GMT
Links: << >>  << T >>  << A >>
Why is this spam?

What's the story with the Max9690?


"John Larkin" <jjlarkin@highlandSNIP_THIStechnology.com> wrote in message
news:YqCFO=k8XHLXXAnBopne+EW6S45p@4ax.com...
> On Thu, 23 Aug 2001 15:01:22 GMT, "Dave Feustel" <dfeustel1@home.com>
> wrote:
>
>
> Dave,
>
> please don't spam us again, or I'll tell the story of how Maxim
> screwed a lot of people with the MAX9690.
>
> 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