Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 80700

Article: 80700
Subject: Re: Spontaneous Board Reset
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 10 Mar 2005 02:38:14 -0800
Links: << >>  << T >>  << A >>
Ulf Ochsenfahrt wrote:

> I've been having a really weird problem with a Xilinx Virtex-E XCV1000E
> development board from AVNET. I've got a VHDL design that I've been
> working on since october last year. When I upload the compiled design into
> the FPGA, everything works fine except after a couple of seconds (10s or
> so), the board resets itself and the FPGA is reprogrammed with the onboard
> design.

Get a schematic and see what can drive the reset line.
Reset should only occur at power-up or power overload.
Good luck.

         -- Mike Treseler


Article: 80701
Subject: Re: State Machine Coding?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 10 Mar 2005 02:43:25 -0800
Links: << >>  << T >>  << A >>
Johnson Lee wrote:

>  I am writing a character controller using Altera MAXII device.
>  This controller will monitor the input signals from lpt port. I make
> a simulation and download to real chip to verify function, but
> unfortunately it won't work as I designed.

It won't work as you *expected*.

>  The simulation show that the state translate signals was initiated
> abnormal..

If the simulation doesn't work, there is a design error.
Debug it.

           -- Mike Treseler

Article: 80702
Subject: Altera Stratix kit PCI to DDR reference design
From: xvp@xs4all.nl (E. van Putten)
Date: 10 Mar 2005 03:40:48 -0800
Links: << >>  << T >>  << A >>
Hi everbody,

The Stratix PCI kit is a 32/64-bits PCI board from Altera with 256 MB
of DDR SDRAM (SO-DIMM). This kit includes a nice reference design that
has a PCI to DDR bridge. We would like to use this design as a
starting point for our own designs.

Unfortunately this design only works with the old Quartus II v2.1 and
the v1.2.1 SDRAM IP Megacore from Altera.

Importing the older project in the newer Quartus 4.2 does not work. We
tried creating a new project with the cores, pin settings, constraints
etc. But the only thing that can be read from the DDR memory is
garbage. Worse, it even gives this garbage when the SO-DIMM module
isn't even inserted (it reads out: 9d66001b .... 9d22001b,  while the
working design gives something like ffff00 in that case (which is far
more logical for disconnected hardware IMHO).

We tested this with both the old and the new SDRAM Megacore. Could
this be some project setting we overlooked? Byte lanes? Assignments?
LogicLock settings?

I tried asking Altera for help, they suggested downloading a newer PCI
core because it included a newer reference design. Unfortunately that
one doesn't use DDR but SDR instead. Then I asked if they could send
me a reference design from one the newer kits (hoping to extract some
useful information from it), and they said they can't (???).

It probably has something to do with the datapath, because the system
reads out garbage from the 'memory' even when the module isn't
psysically present in the system. Though, I don't understand why...

Anybody had any luck converting the (kit included) PCI 2 DDR reference
design (Quartus II 2.1) to the new Quartus 4.2?

Have a nice day!

Article: 80703
Subject: Re: Spontaneous Board Reset
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Thu, 10 Mar 2005 11:46:36 -0000
Links: << >>  << T >>  << A >>
Check the power rails are not dipping. If they do you could get a
re-configure and subsequent reset. Also check there are no glitches on the
PROG line.

-- 
John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk


"Ulf Ochsenfahrt" <ulfjack@gmx.de> wrote in message
news:pan.2005.03.10.09.47.50.817957@gmx.de...
> Hi!
>
> I've been having a really weird problem with a Xilinx Virtex-E XCV1000E
> development board from AVNET. I've got a VHDL design that I've been
> working on since october last year. When I upload the compiled design into
> the FPGA, everything works fine except after a couple of seconds (10s or
> so), the board resets itself and the FPGA is reprogrammed with the onboard
> design.
>
> (There is a sample design in an onboard ROM chip. I download my design via
> the JTAG interface.)
>
> When I take an old design (Tuesdays' in fact), everything runs fine and
> stable. The only change is that I make two instances of a module instead
> of one. The module is a self-written serial multiplier with RAM and ROM.
> The only difference between the two instances is a different ROM
> configuration (ROM data). The input lines (20-30 lines) are identical and
> the output lines (three of them) are treated very similar.
>
> I have already consulted my University colleagues, but so far without
> results. I already checked temperature, the clock/reset nets and I/O pin
> assignment. Everything looks fine to me, but I'm certainly not an FPGA
> wizard...
>
> Any ideas? Any recommended course of action?
>
> Thanks for your help!
>
> Cheers,
>
> -- Ulf



Article: 80704
Subject: Re: Spontaneous Board Reset
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Thu, 10 Mar 2005 12:21:46 GMT
Links: << >>  << T >>  << A >>
"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote in 
message news:1110455200.12605.0@echo.uk.clara.net...
> Check the power rails are not dipping. If they do you could get a
> re-configure and subsequent reset.

I second that.

I once had an embedded system that reset when using the FDD.

Turned out my PSU wasn't quite beefy enough, hence when the motor turned on, 
Vcc dipped, casing a reset.



Article: 80705
Subject: looking for PCI board with fpga and 1394 interface
From: Nicolas Schwarzentrub <schwn@hta-bi.bfh.ch>
Date: Thu, 10 Mar 2005 13:58:06 +0100
Links: << >>  << T >>  << A >>
Hi everybody,

we're two students looking for a low cost developer board for our 
diploma work. we intend to plug a camera to the pci board via 1394 and 
process the images throug the fpga and get the processed images from 
fpga via pci. The camera we will use, uses DCAM /IICD
Now we have several problems:
-we don't have a high budget, so it should be a low cost solution.

-we have not jet found a board that fits our need, does anybody know 
something cheep that could fit our needs?

-there would be several possibility to solve the connectivity problems:

* best would be to find a board that fits our need, means have at least 
pci, fpga and 1394 on it? any suggestions ont htat?

* if the above point can't be reached we could probably solder our 1394 
interface ourself on a board. What would then be best for our purpose? 
We could probably use a TSB12LV32 chip from ti if we don't find a board 
with firewire. 
(http://focus.ti.com/docs/prod/folders/print/tsb12lv32.html)? does 
anybody know this? would it then be possible to implement the dcam in 
the fpga?

Thanks to everbody

Article: 80706
Subject: Re: Global Reset paths
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Thu, 10 Mar 2005 08:07:30 -0500
Links: << >>  << T >>  << A >>
Hi Andres,

> What about Altera and Xilinx FPGAs ?  Do they have more than one
> global reset path ?

In Stratix/Stratix II/Cyclone/Cyclone II/Max II I believe that you can route 
an async reset using any global clock or local routing.  For example, 
Stratix II has 16 global clocks plus a bunch of quadrant-wide clocks.  These 
clock networks can be used to route non-clock signals -- they are very good 
for distributing high-fanout signals.  The clock networks can be driven 
directly by clock pins and by PLLs, or they can be fed from any other 
resource in the chip by routing a signal to an internal access port.

The Quartus II software will automaticaly promote high-fanout and 
asynchronous signals onto the clock network (which are thus called "globals" 
in Quartus).

Regards,

Paul Leventis
Altera Corp. 



Article: 80707
Subject: Re: Surge in S2? ~3 amperes at cold for a millisecond-- on ES material, fix available end of month for 2S60 ....
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Thu, 10 Mar 2005 08:16:26 -0500
Links: << >>  << T >>  << A >>
Austin,

> Are you done changing the worst case numbers?

No.  If after further process monitoring and characterization we find that 
we can safely reduce our spec, we will be happy to do so.  Just like our 
performance specs, which we have previously increased and will likely do 
again in the near future.

What's your point?  Are you suggesting that you are better off keeping your 
worst-case numbers to yourself, let users design using the typical numbers, 
and then unleash your worst-case numbers once you are 100% certain they 
won't change?  I wouldn't want to be the guy with the chip on my board with 
a 2W thermal budget when I finally find out that V4 actually could burn 2.5X 
the static power I'd been told.

Regards,

Paul Leventis
Altera Corp.



Article: 80708
Subject: Re: looking for PCI board with fpga and 1394 interface
From: "xman" <nospam@xxx.com>
Date: Thu, 10 Mar 2005 14:59:36 +0100
Links: << >>  << T >>  << A >>
you can find it here: http://www.plsgoogleit.com/


"Nicolas Schwarzentrub" <schwn@hta-bi.bfh.ch> wrote in message 
news:d0pg8u$nco$1@news.hispeed.ch...
> Hi everybody,
>
> we're two students looking for a low cost developer board for our diploma 
> work. we intend to plug a camera to the pci board via 1394 and process the 
> images throug the fpga and get the processed images from fpga via pci. The 
> camera we will use, uses DCAM /IICD
> Now we have several problems:
> -we don't have a high budget, so it should be a low cost solution.
>
> -we have not jet found a board that fits our need, does anybody know 
> something cheep that could fit our needs?
>
> -there would be several possibility to solve the connectivity problems:
>
> * best would be to find a board that fits our need, means have at least 
> pci, fpga and 1394 on it? any suggestions ont htat?
>
> * if the above point can't be reached we could probably solder our 1394 
> interface ourself on a board. What would then be best for our purpose? We 
> could probably use a TSB12LV32 chip from ti if we don't find a board with 
> firewire. (http://focus.ti.com/docs/prod/folders/print/tsb12lv32.html)? 
> does anybody know this? would it then be possible to implement the dcam in 
> the fpga?
>
> Thanks to everbody 



Article: 80709
Subject: Re: Spontaneous Board Reset
From: "Ulf Ochsenfahrt" <ulfjack@gmx.de>
Date: Thu, 10 Mar 2005 06:18:42 -0800
Links: << >>  << T >>  << A >>
Thanks for your replies, however, the problem is still unsolved:

I looked through the schematics and it shows the board reset button with a pull-up resistor (I read that as low-active reset). This net is connected to an IC (the onboard ROM I guess) and to a certain pin on the FPGA.

My thought then was that maybe the FPGA pulls down that pin for whatever reason. So I specified a pull-up in the constraints file. This helps. But not much. The board still resets itself, just after a slightly longer amount of time.

Then, a colleague also said that it's most likely a problem with the power supply. So I got a fancy electronic power supply, where you can set the voltage to a certain level and it shows the current.

The current tops at 1300 mA, which is more than the previous power supply could handle (it says 1200 mA max). The improved power supply helps. But, the board _still_ resets itself.

Now here's something interesting: My old (working) design only draws 1000 mA.

I am still investigating this.

Thanks for your help.

Cheers,

-- Ulf

Article: 80710
Subject: Re: Spontaneous Board Reset
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Thu, 10 Mar 2005 15:34:26 +0100
Links: << >>  << T >>  << A >>

> Then, a colleague also said that it's most likely a problem withthe power supply. So I got a fancy electronic power supply, where you can set the voltage to a certain level and it shows the current.
> 
> The current tops at 1300 mA, which is more than the previous power supply could handle (it says 1200 mA max). The improved power supply helps. But, the board _still_ resets itself.
> 
> Now here's something interesting: My old (working) design only draws 1000 mA.
> 

What about the powersupply on the board ?
I'd guess you have an external power supply providing a
single voltage and then on board several regulators to generate
the voltages required by the FPGA ? Can theses handle the bigger current ?
Maybe one of them is just heating, triggering thermal protection or ...



	Sylvain

Article: 80711
Subject: Re: Spontaneous Board Reset
From: "Ulf Ochsenfahrt" <ulfjack@gmx.de>
Date: Thu, 10 Mar 2005 06:54:53 -0800
Links: << >>  << T >>  << A >>


      What about the powersupply on the board ? I'd guess you have an external
      power supply providing a single voltage and then on board several regulators
      to generate the voltages required by the FPGA ? Can theses handle the
      bigger current ? Maybe one of them is just heating, triggering thermal
      protection or ...




Good point. The voltage regulators do get hot when I load my design. Fortunately, we got an office fan here, which we now installed above the board (looks pretty funny, if I had a camera, I'd take a picture). And now the board has been running fine for the last 5 minutes (wouldn't run longer than 30s before).

Seems odd though. The sample design (delivered with the board) is said to use ~600 mA and that is pretty small. Not to say tiny. Shouldn't the board have power regulators that can handle more than that? Or maybe they forgot to attach the heat sinks?

Thanks for pointing that out.

Cheers,

-- Ulf

Article: 80712
Subject: Re: Xilinx vs Altera high-end solutions
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 10 Mar 2005 07:56:04 -0800
Links: << >>  << T >>  << A >>
Jason,

All very good points.

My point was simply that a power user trying to get the last 2 ps out of 
their design usually ends up using the features specific to that part, A 
or X.

By doing so they often can use a lower speed grade part, or a smaller 
part, and save a lot of money.

(No offense intended to anyone).

Austin

Jason Zheng wrote:
> Austin Lesea wrote:
> 
>> Mike,
>>
>> You know your business, that is for sure.  And based on that, you make 
>> decisions.  We have a number of customers who treat FPGAs as a commodity.
>>
>> Use no special features.  Generic HDL only.
>>
>> Not my favorite model, but I know some folks use it.
>>
>> Austin
> 
> I'm a big supporter of using generic HDL, because it makes your design 
> portable. It's portable not just in a sense that you can synthesize the 
> design on different platforms TODAY, but also that you can easily apply 
> it to TOMORROR's hardware. Portability is one of the big philosophies 
> behind the UNIX movement (and yes that is software, but the idea is the 
> same). Without it, UNIX wouldn't have survived past PDP-11.
> 
> My point is, utilizing some special features may get you 20% more 
> performance today. But next year, some other vendor might come up with a 
> good platform that runs 50% faster than your current vendor's platform. 
> If you use generic HDL, very little, if any, efforts are needed to move 
> on to the better technology or platform. Whereas specialized HDL designs 
> will soon require too much effort to keep up with the new technology.
> 
> Finally, the less technology-dependent your design is, the easier for 
> you to leverage the advancement of the synthesizers. Maybe the 
> synthesizers today cannot imply some of the logics to optimal 
> components, but tomorrow they will be able to.
> 
> Having said so much about generic HDL, I also insist that HDL designers 
> should know what exactly they are designing. Sometimes what the 
> synthesizers generate is not what you really want, in which case you 
> have to step in.
> 
> -jz

Article: 80713
Subject: Re: Xilinx vs Altera high-end solutions
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 10 Mar 2005 07:59:09 -0800
Links: << >>  << T >>  << A >>
Marc,

See my other postings.  Only trying to make one simple point here.

As Paul points out (correctly), the tools try to fit generic HDL into 
the special structures (or else why would we even try to put them in).

Often the tools can't make the best, and most clever use of the device 
specific features, until a number of years have gone by, and the tools 
have been improved to that point.

After a number of years, we (as FPGA IC designers) are onto the 
generation after the next generation ....

Austin

Marc Randolph wrote:

> Austin Lesea wrote:
> 
>>Mike Treseler wrote:
>>
>>>Austin Lesea wrote:
>>>
>>>>If you know you are going to use part A, or part X, you will then
> 
> use
> 
>>>>the powerful built in features that each vendor offers.
>>>
>>>Many do, but I don't.
>>>If the feature can't be inferred from code
>>>for both vendors, I'd rather not use it.
>>
>>Mike,
>>
>>Then you are not a high end user.
> 
> 
> How silly.
> 
> You can infer DDR registers, shift-registers (which map flawlessly to
> SRLs), and even a number of math functions (which map to the latest V4
> DSP48 blocks).  What else does it take to meet your criteria of being
> be a high-end user?
> 
> Have fun,
> 
>    Marc
> 

Article: 80714
Subject: Iccint(max)
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 10 Mar 2005 08:07:21 -0800
Links: << >>  << T >>  << A >>
Paul,

I posted what the worst case was (more than a week ago).

If you are using our parts, and you want to know, your FAE can tell you 
everything, including plots from thousands of parts, over all the corners.

In other news --

"Virtex-4 FPGA Availability:

Virtex-4 LX25, LX60, LX100, SX35, SX55, and FX12 are shipping today. 
Xilinx now has a total of 14 FPGAs in production at 90nm, more than 
three times the number of its nearest competitor."


Austin


Article: 80715
Subject: Re: ML310 + Linux (elf file ) + bit file
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 10 Mar 2005 08:26:06 -0800
Links: << >>  << T >>  << A >>
Parag,

I think that you took a giant leap in your learning process and
it didn't quite work right.  Trying to debug the problem from
this point would be a very lengthy process.  I would suggest that
you start out with the shipped design files first and go through
the "Creating a Linux BSP and System Image" tutorial first.

http://www.xilinx.com/products/boards/ml310/current/reference_designs/base/linux/ml310_base_linux_bsp_proj_creation.pdf

After you have this flow understood and working, then go ahead
and build your new system.

Ed

beeraka@gmail.com wrote:
> Hi..
>      Has anyone been able to download their own bitfile (other than
> ..ml310_pci_bootloop.bit) and run linux (by downloading the elf file )
> using xmd...
> 
> 
>      What I did in generating my bit file is opened up EDK and then
> added up my own core (an OPB core indeed ) changed the settings in
> Software Platform to include linux_mvl31 for ppc405_0 and set the
> parameters in Library / OS parameters ..Then I generated the
> libraries...Then I obtained the download.bit file (which includes a
> bootloop indeed )..I downloaded the bit file using iMPACT on to the ML
> 310 and then downloaded the linux kernel Image elf file using XMD ..but
> I dont find any change on the serial port terminal.....
> 
>     So If anyone had success in doing this stuff then please help me
> out guys.....
> 
> Thanks in advance........
> --
> Parag Beeraka
> 

Article: 80716
Subject: Re: dsbram memory addressing
From: "Mindroad" <mindroad@hotmail.com>
Date: Thu, 10 Mar 2005 18:38:22 +0100
Links: << >>  << T >>  << A >>
So defenately no SW error,
after 3 days of searching, it appears i had overlooked a dcm parameter,
now i feel kind a stupid, but anyway, it is solved

for future references,
make sure ocm and ppc clock is an integer multiple of 4 and it works,

don't confuse the following like I did .. I didn't noticed it until now
PARAMETER C_CLKFX_DIVIDE
PARAMETER C_CLKDV_DIVIDE

2 letters diff is something you can miss easely , but can mean 3 days of
being an ass to the whole world, ah well


"Mindroad" <mindroad@hotmail.com> schreef in bericht
news:422f0b10$0$10333$ba620e4c@news.skynet.be...
> Well yesterday I tried something like :
>
> const XIo_Address sflag_PORT   = XPAR_DSBRAM_IF_CNTLR_0_BASEADDR + 0;
> Xuint32 sflag;
>
> sflag = XIo_In32( (XIo_Address)sflag_PORT);
>
> putnum(sflag);
>
>
> //////////////////////////////////////
> it still hangs :(
>
> is there someone that encountered this problem .. because the above I
almost
> copy pasted out of an example code
> thx in advance !
>
>
> "Mindroad" <mindroad@hotmail.com> schreef in bericht
> news:422dfa37$0$20677$ba620e4c@news.skynet.be...
> > Hi,
> >
> > After I builded my design in EDK and made a toplevel VHDL in ISE, I
> started
> > writing code for both PPC on my V2P20 ... the first PPC serves as an
> > Communication unit which transfers data in between memories, accessible
by
> > external device ... I have no problem whatsoever accessing these
memories,
> > either on opb or plb busses
> > When I started the part of interconnecting the two PPC with a BRAM
memory
> > using DSOCM I encountered the following problem, which up to know I
cannot
> > solve (this is the first time I design on FPGA) ...
> >
> > To access the BRAM from the first PPC serving as Comm Unit I used the
code
> > which worked for accessing memories on the PLB since I suppose the
> > addressing of memories is always in the same way, as if we address one
big
> > memory
> >
> > code :
> > Xuint32 * bram_Ptr = XPAR_BRAM_BASE_ADDR;
> > Xuint32 value = *bream_Ptr;
> >
> > When I download the bit file on the FPGA, the system hangs, when
executing
> > these commands
> >
> > can someone help me with this problem, I spend some time looking for the
> > solution and I found some macros in xio.h, but I have no clue how to use
> > them, and when I look into application notes, it appears nothing is ever
> > said about how accessing BRAM, so it must be straightforward
> >
> > thx in advance
> >
> > could be I miss some parameters or connections in the MHS file, but I
> doubt
> > it since all should almost be set by default
> >
> > BEGIN dsocm_v10
> > <--- connected to the PPC405 through bus interface
> >  PARAMETER INSTANCE = dsocm_v10_0
> >  PARAMETER HW_VER = 2.00.a
> >  PARAMETER C_DSCNTLVALUE = 0x85
> >  PORT DSOCM_Clk = sys_clk
> >  PORT sys_rst = sys_rst_l
> > END
> >
> > BEGIN dsbram_if_cntlr
> >  PARAMETER INSTANCE = dsbram_if_cntlr_0
> >  PARAMETER HW_VER = 3.00.a
> >  PARAMETER C_BASEADDR = 0xF0000000
> >  PARAMETER C_HIGHADDR = 0xF0001fff
> >  BUS_INTERFACE DSOCM = dsocm_v10_0
> >  BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
> > END
> >
> > BEGIN bram_block
> >  PARAMETER INSTANCE = bram_block_0
> >  PARAMETER HW_VER = 1.00.a
> >  BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
> >  BUS_INTERFACE PORTB = dsbram_if_cntlr_1_porta
> > END
> >
> >
> >
> >
> > could be I made some mistake in my linker script :
> >
> > _STACK_SIZE     = 1k;
> > _DOCM_SIZE = 8k;
> >
> > MEMORY
> > {
> >   plb_bram_if_cntlr_1_bram : ORIGIN = 0xFFFF0000, LENGTH = 16K
> >   plb_bram_if_cntlr_2_bram : ORIGIN = 0xFFFF8000, LENGTH = 32K
> >   dsbram_if_cntlr_0_porta : ORIGIN = 0xF0000000, LENGTH = 8K
> > }
> > ...
> >
> >
>
>



Article: 80717
Subject: Re: Xilinx vs Altera high-end solutions
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 10 Mar 2005 10:13:57 -0800
Links: << >>  << T >>  << A >>
Jason Zheng wrote:
(snip)

> I'm a big supporter of using generic HDL, because it makes your design 
> portable. It's portable not just in a sense that you can synthesize the 
> design on different platforms TODAY, but also that you can easily apply 
> it to TOMORROR's hardware. Portability is one of the big philosophies 
> behind the UNIX movement (and yes that is software, but the idea is the 
> same). Without it, UNIX wouldn't have survived past PDP-11.

> My point is, utilizing some special features may get you 20% more 
> performance today. But next year, some other vendor might come up with a 
> good platform that runs 50% faster than your current vendor's platform. 
> If you use generic HDL, very little, if any, efforts are needed to move 
> on to the better technology or platform. Whereas specialized HDL designs 
> will soon require too much effort to keep up with the new technology.

Following the unix analogy, where some low level parts might be 
written in assembly, write the generic HDL, and then replace 
specific modules with custom versions to get the extra 
performance.

-- glen


Article: 80718
Subject: Re: Xilinx vs Altera high-end solutions
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 10 Mar 2005 10:40:40 -0800
Links: << >>  << T >>  << A >>
Glen,

Good idea.  Don't work too hard.  Let the synthesis tools to their best, 
and then see where they did not do what they "could" have to get the 
best performance.

This is something that our FAE's help our customers with all the time: 
getting that last little bit out of the design (so that they may buy a 
smaller part, or a slower part, and save $$).

Austin

glen herrmannsfeldt wrote:
> Jason Zheng wrote:
> (snip)
> 
>> I'm a big supporter of using generic HDL, because it makes your design 
>> portable. It's portable not just in a sense that you can synthesize 
>> the design on different platforms TODAY, but also that you can easily 
>> apply it to TOMORROR's hardware. Portability is one of the big 
>> philosophies behind the UNIX movement (and yes that is software, but 
>> the idea is the same). Without it, UNIX wouldn't have survived past 
>> PDP-11.
> 
> 
>> My point is, utilizing some special features may get you 20% more 
>> performance today. But next year, some other vendor might come up with 
>> a good platform that runs 50% faster than your current vendor's 
>> platform. If you use generic HDL, very little, if any, efforts are 
>> needed to move on to the better technology or platform. Whereas 
>> specialized HDL designs will soon require too much effort to keep up 
>> with the new technology.
> 
> 
> Following the unix analogy, where some low level parts might be written 
> in assembly, write the generic HDL, and then replace specific modules 
> with custom versions to get the extra performance.
> 
> -- glen
> 

Article: 80719
Subject: Re: ethernet core on a xc3s200
From: adrian <adrian.mora@terra.es>
Date: Thu, 10 Mar 2005 19:01:32 GMT
Links: << >>  << T >>  << A >>
backhus escribió:
> 
> 
> Hi Adrian
> 
>>   Number of occupied Slices:                        2,625 out of 
>> 1,920  136%
>> (OVERMAPPED)
> 
> 
> This part of your design report shows that the core does not fit into 
> the X3S200 device.
> With some luck you can use different synthesis constraints and higher 
> efforts for the mapping and PAR to reduce the number of occupied Slices.
> 
> Have a nice synthesis
>   Eilert
> 

Hi Eilert,

Tnankyou for your reply.
How can I configure EDK for using other/better synthesis constraints and 
higher efforts?

Thankyou.

Article: 80720
Subject: RocketIO and Gigabit Ethernet
From: v_mirgorodsky@yahoo.com
Date: 10 Mar 2005 11:20:40 -0800
Links: << >>  << T >>  << A >>
Hello ALL,

I am designing device, based on Virtex-4 FX20 chip. This device is
going to produce lots of data and I would like to send it to processing
computer using Gigabit Ethernet interface. I am lucky to have two
Ethernet MAC's built-in in the FPGA. Also we would like to use
RocketIO transceivers to connect our Ethernet MAC's to physical
media. Here is my problem begins. I need to connect magnetic to
RocketIO differential outputs. I have searched Xilinx web-site, but
found nothing about this issue. There are two user guides, one about
Tri-mode Ethernet MAC and another about RocketIO MGT. Both guides full
of useful information, but none of them highlights this issue. They
just cross-reference each other on this matter :)

So, does any one has any experience in putting Ethernet MAC (hardware
or IP Core) and RocketIO transceiver to  work together in Gigabit
Ethernet configuration (without using external PHY)? Xilinx web-site
has an Answer Record 13928, stating full compliance Virtex-2 Pro
RocketIO MGT to all Gigabit Ethernet standards, so I assume Virtex-4
MGT is compliant to all Gigabit Ethernet standards as well.

With best regards,
Vladimir S. Mirgorodsky


Article: 80721
Subject: Re: Xilinx vs Altera high-end solutions
From: Jason Zheng <xin.zheng@jpl.nasa.gov>
Date: Thu, 10 Mar 2005 11:35:03 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Jason,
> 
> All very good points.
> 
> My point was simply that a power user trying to get the last 2 ps out of 
> their design usually ends up using the features specific to that part, A 
> or X.
> 
> By doing so they often can use a lower speed grade part, or a smaller 
> part, and save a lot of money.
> 
> (No offense intended to anyone).
> 
> Austin
> 

Austin,

No offense, but would you please stop top-posting on news groups? 
Bottom-posting is easier to read, especially when quoting several 
responses. This website has more explanations on why: 
http://www.caliburn.nl/topposting.html

Jason

Article: 80722
Subject: Re: RocketIO and Gigabit Ethernet
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 10 Mar 2005 11:46:48 -0800
Links: << >>  << T >>  << A >>
Vladimir,

I apologize, but this answer record is misleading.  There
are two different physical types of Gigabit Ethernet, the
Base-T versions and the Base-X versions.  What you are
describing is that you want to implement a 1000-Base-T
which is a RJ45 connector and CAT5/5e/6 cable and you can not
do this directly from a RocketIO MGT.

The RocketIO MGTs are electrically and physically compliant
to the Base-X versions (SX/LX), but not the Base-T version.
If you want to drive Base-T and you want to drive it with
a RocketIO MGT, then you need to use it configured as a SGMII
interface either to a discrete 1000-Base-T Phy (less expensive),
or to a SFP cage with a 1000-Base-T module (more expensive)
instead of the normal SFP optical module.

I will get this answer record updated to clarify the supported
modes.

Ed



v_mirgorodsky@yahoo.com wrote:
> Hello ALL,
> 
> I am designing device, based on Virtex-4 FX20 chip. This device is
> going to produce lots of data and I would like to send it to processing
> computer using Gigabit Ethernet interface. I am lucky to have two
> Ethernet MAC's built-in in the FPGA. Also we would like to use
> RocketIO transceivers to connect our Ethernet MAC's to physical
> media. Here is my problem begins. I need to connect magnetic to
> RocketIO differential outputs. I have searched Xilinx web-site, but
> found nothing about this issue. There are two user guides, one about
> Tri-mode Ethernet MAC and another about RocketIO MGT. Both guides full
> of useful information, but none of them highlights this issue. They
> just cross-reference each other on this matter :)
> 
> So, does any one has any experience in putting Ethernet MAC (hardware
> or IP Core) and RocketIO transceiver to  work together in Gigabit
> Ethernet configuration (without using external PHY)? Xilinx web-site
> has an Answer Record 13928, stating full compliance Virtex-2 Pro
> RocketIO MGT to all Gigabit Ethernet standards, so I assume Virtex-4
> MGT is compliant to all Gigabit Ethernet standards as well.
> 
> With best regards,
> Vladimir S. Mirgorodsky
> 

Article: 80723
Subject: Re: Xilinx vs Altera high-end solutions
From: Jason Zheng <xin.zheng@jpl.nasa.gov>
Date: Thu, 10 Mar 2005 11:50:25 -0800
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> Jason Zheng wrote:
> (snip)
> 
>> I'm a big supporter of using generic HDL, because it makes your design 
>> portable. It's portable not just in a sense that you can synthesize 
>> the design on different platforms TODAY, but also that you can easily 
>> apply it to TOMORROR's hardware. Portability is one of the big 
>> philosophies behind the UNIX movement (and yes that is software, but 
>> the idea is the same). Without it, UNIX wouldn't have survived past 
>> PDP-11.
> 
> <snip>
> 
> Following the unix analogy, where some low level parts might be written 
> in assembly, write the generic HDL, and then replace specific modules 
> with custom versions to get the extra performance.
> 
> -- glen
> 

True about the low-level assembly part, but you missed the point. 
Minimizing, not celebrating, such low-level components is the reason for 
Unix's succsess. On a side note, one of the trends in OS development is 
to shrink the kernel and to standardize the kernel interface. All of 
that makes it easier to port application programs from one unix system 
to another.

It is true that you cannot avoid doing low-level stuff in either 
software or hardware design. But the less you have to think in the 
lower-level abstraction layer, the more time you can spend in improving 
the high-level architecture.

-jz

Article: 80724
Subject: Re: Xilinx vs Altera high-end solutions
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 10 Mar 2005 13:02:32 -0800
Links: << >>  << T >>  << A >>
Paul Leventis wrote:

> The synthesis tools are pretty good at inferring multipliers/MACs from
> HDL, as well as other higher-level primitives.

Don't tell anyone, but the generic synthesis templates
born in Leo and Synplicity are getting covered
by XST and Quartus as well.
The multiplier/accumulator templates work. Block RAM/ROM
and the FIFO style dual-port RAM has worked for
years. Carry-chain counters, shifters, state sequencers, etc
work for just about any reasonable description.

The black box list is getting quite small.
PLLs and full dual-port rams are all that
come to mind.

> So your "vanilla"
> approach to design may still take advantage of some of the hard blocks
> available.

Yes, I would say most. I am a bit baffled to
find a use for multipliers in non-dsp applications.
Maybe I should be calculating Pi as a background process :)

> I should point out that you should see very good performance in
> Stratix-II without any architecture-specific coding.  Quartus will
> automatically balance multipliers between LEs and DSP blocks, and also
> automatically handles the mapping of generic RAMs into the three
> available RAM types in the device.  We like to make things as easy as
> we can on our users, otherwise these features would go unused in many
> designs!

Quartus synthesis wins my most-improved award.
It was once the worst vhdl synthesis on the planet.
Now it handles all my code just fine.
I use leo mainly because it is faster, covers
all the devices and has a better rtl viewer.

            -- Mike Treseler



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search