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 96900

Article: 96900
Subject: How to decode FAR register in Virtex-4?
From: "Bertrand Rousseau" <bertrand.rousseau@gmail.com>
Date: 13 Feb 2006 05:20:37 -0800
Links: << >>  << T >>  << A >>
Hi everyone,

I'm trying to understand how the frame addresses have to be decoded for
a Virtex-4 FPGA from Xilinx. So far I could find documentation about
the configuration for VI and VII FPGAs, but there seem to be small
modifications between these models frame addresses and the new
Virtex-4.

Has anyone already tried to understand frame addresses in Virtex-4?

Thanks

Bertrand


Article: 96901
Subject: Re: spartan3 starter kit.
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 13 Feb 2006 13:42:08 GMT
Links: << >>  << T >>  << A >>
On Mon, 13 Feb 2006 10:52:11 -0000, "Symon" <symon_brewer@hotmail.com> wrote:

>"Mike Harrison" <mike@whitewing.co.uk> wrote in message 
>news:tin0v1hh1b8c01eoi9tif20elqsh3treio@4ax.com...
>>
>> Here's another way :
>> The ground is the nearest to the solder side of the inner planes so it's 
>> possible to dremel down to
>> it & add more grounds..
>> http://www.redremote.co.uk/electricstuff/ektapr61.jpg
>>
>Mike,
>You butcher! VG!
>I wonder if there's a lesson here for the prototype board product guys. 
>After all, these boards are often bodged up for proof-of-concept projects. 
>Put a ring of exposed ground all the way around the edge of the board to 
>help SI design. Carefully stiched to the gnd plane, of course. What about 
>it, Mr. Adair?

One neat feature of his Raggedstone 1 board is the provision of solder-bridges to reassign IOs to
ground.

Article: 96902
Subject: Re: spartan3 starter kit.
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Mon, 13 Feb 2006 14:43:00 -0000
Links: << >>  << T >>  << A >>
Oh we have done better than that on some of the RF boards we have done for 
customers. How about exposed earth bond(0V) both side and mounting screw 
holes every 20mm.

On a simpler note you might what we have done on Hollybush1 but you will 
have to wait until DATE to see it.

John Adair
Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan-3 Development 
Board.
http://www.enterpoint.co.uk


"Symon" <symon_brewer@hotmail.com> wrote in message 
news:43f06463$0$15791$14726298@news.sunsite.dk...
> "Mike Harrison" <mike@whitewing.co.uk> wrote in message 
> news:tin0v1hh1b8c01eoi9tif20elqsh3treio@4ax.com...
>>
>> Here's another way :
>> The ground is the nearest to the solder side of the inner planes so it's 
>> possible to dremel down to
>> it & add more grounds..
>> http://www.redremote.co.uk/electricstuff/ektapr61.jpg
>>
> Mike,
> You butcher! VG!
> I wonder if there's a lesson here for the prototype board product guys. 
> After all, these boards are often bodged up for proof-of-concept projects. 
> Put a ring of exposed ground all the way around the edge of the board to 
> help SI design. Carefully stiched to the gnd plane, of course. What about 
> it, Mr. Adair?
> Cheers, Syms.
> 



Article: 96903
Subject: [ANN] MicroBlaze uClinux FPGA module (with microwindows) at Embedded
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Feb 2006 06:43:58 -0800
Links: << >>  << T >>  << A >>
this week Embedded in Nurnberg, Halle 12, Standnummer: 12-338 (TQC):

FPGA module with MicroBlaze uClinux on display, not much to see but
 it has some MicroWindows demos loaded

Antti
PS I will be around that stand, hm 1500 on tuesday if someone wants to
say hello


Article: 96904
Subject: Re: [ANN] MicroBlaze uClinux FPGA module (with microwindows) at Embedded
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 13 Feb 2006 14:53:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@xilant.com> wrote:
> this week Embedded in Nurnberg, Halle 12, Standnummer: 12-338 (TQC):

> FPGA module with MicroBlaze uClinux on display, not much to see but
>  it has some MicroWindows demos loaded

> Antti
> PS I will be around that stand, hm 1500 on tuesday if someone wants to
> say hello

What a pitty. I will be there wednesday...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 96905
Subject: Re: MicroBlaze uClinux FPGA module (with microwindows) at Embedded
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Feb 2006 06:57:50 -0800
Links: << >>  << T >>  << A >>
I *might* be around on wednesday too, so just drop by at the same time,
if I am there Im there

Antti


Article: 96906
Subject: Re: spartan3 starter kit.
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 13 Feb 2006 15:15:37 -0000
Links: << >>  << T >>  << A >>
"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote in 
message news:1139841784.24768.0@doris.uk.clara.net...
> Oh we have done better than that on some of the RF boards we have done for 
> customers. How about exposed earth bond(0V) both side and mounting screw 
> holes every 20mm.
>
Hi John,
Trouble is, _every_ board with a modern FPGA on it is an 'RF' board these 
days!!
Cheers, Syms. 



Article: 96907
Subject: Re: cheap USB analyzer based on FPGA
From: cs_posting@hotmail.com
Date: 13 Feb 2006 07:18:08 -0800
Links: << >>  << T >>  << A >>
Jerome wrote:
> NO NO , i'm NOT trying to crack anything
> I just want to make USB  devpt (using libusb) and i need an usb analyzer
> I'm sure it is feasible with a $200 FPGA which is 1/3 price of the cheapest
> USB analyser

Have you ruled out software analyzers?  There's something that plugs in
partway through the windows USB stuff and monitors traffic between the
driver and the device...


Article: 96908
Subject: Re: Async Processors
From: Martin Ellis <me_ncl@hotmail.com>
Date: Mon, 13 Feb 2006 15:38:29 +0000
Links: << >>  << T >>  << A >>
Allan Herriman wrote:
> Please bear in mind that most comms interfaces (e.g. Ethernet) are
> synchronous in nature (at least at the physical layer).  One has real
> time requirements to meet.
> Synchronous design makes a lot of sense for a hardware router or
> switch, etc.  (As it does for the products we design here, but I won't
> bore you with the details.)

Hmm.  Wasn't the whole point of the DRACO microprocessor that it was
actually designed for, and used in, telecoms systems?  The whole idea being
that an asynchronous design was used because of the requirement for good
EMC.

Why would such a design not also "make a lot of sense"?

Martin

Article: 96909
Subject: Re: Async Processors
From: fpga_toys@yahoo.com
Date: 13 Feb 2006 09:07:14 -0800
Links: << >>  << T >>  << A >>

rickman wrote:
> Likewise, I don't see any reason to belive that async clocked logic
> design has significant advantages over standard sync clocked logic
> design for most applications.

Proponents of async state that async designs automatically adjust
performance and power consumption across the entire range of
environmentals (temp, voltage, thermal gradients, etc) as long as the
underlying hardware is still performing correctly. They state that this
reduces hardware costs by allowing higher variances in temp, voltage,
thermal gradient, etc while extending the operating range past what is
achievable with traditional sync design at lower costs. This is clearly
useful in a wide range of applications from hand held battery operated
devices, to harsh industrial/automotive environments. By removing the
global clock, they also obtain EMC benifits that are critical to many
applications, which also lower shielding, packaging, filtering and
other EMC mitigation costs. That tools like the Phased Logic conversion
utilities, semiautomatically take existing designs, convert them to
async, and achieve part or all of these benifits.

You state that YOU can do better (IE lower costs and improve
performance for the same applications) by adding hardware and extensive
testing to determine the correct margins so that the system can
automatically adjust clock speeds and other factors to obtain the same
extended operation ranges, at the same or better performance, and the
same or lower closts. You fail to explain just how you can do this --
at the same or better performance, at a lower cost. You fail to offer a
similar conversion tool which takes existing designs and lowers it's
power, while extending it's operating range and reducing EMC
requirements without additional hardware costs or allowing equivalent
lower cost components, packaging, and other environmental controls.

Until you can enlighten the world about your claims, you are just
insulting a lot of people which believe they are doing genuine state of
the art research and product development to better man kind and our
industry.


Article: 96910
Subject: xilinx ise 8.1 mig 1.4 /1.5
From: "guy" <MADORIG@gmail.com>
Date: 13 Feb 2006 09:36:04 -0800
Links: << >>  << T >>  << A >>
hello
the ise7.1 had the mig1.4 for memory interface generator
does it work on the ise 8.1?
if not is there any newer version for ise 8.1?

thanks
guy


Article: 96911
Subject: spartan-3e starter kit
From: Tom Dahlen <dahl0550@umn.edu>
Date: Mon, 13 Feb 2006 12:19:42 -0600
Links: << >>  << T >>  << A >>
I have been waiting to get the spartan 3e starter kit from xilinx for 
awhile now, but it doesn't seem to be out yet.  Does anyone know if they 
are still look at releasing it this month as they mention on their website?

Article: 96912
Subject: Rocketio, modelsim xe
From: ndt <info@ndt.ca>
Date: Mon, 13 Feb 2006 14:14:37 -0500
Links: << >>  << T >>  << A >>
Hi, I'm trying to implement rocketio on xilinx fpga. Is there a way to 
simulate it using modelsim XE. I know for the PE, SE version its using 
smartmodels or generating libraries.

Also is there any basic programs using rocketio, architect (wizard can't 
simulate, core generator can't compile libraries for modelsim, and the 
program that came with the eval board uses multiple buses, memory and 
the PPC).

Rob

Article: 96913
Subject: Re: Async Processors
From: Allan Herriman <allanherriman@hotmail.com>
Date: Tue, 14 Feb 2006 07:32:06 +1100
Links: << >>  << T >>  << A >>
On Mon, 13 Feb 2006 15:38:29 +0000, Martin Ellis <me_ncl@hotmail.com>
wrote:

>Allan Herriman wrote:
>> Please bear in mind that most comms interfaces (e.g. Ethernet) are
>> synchronous in nature (at least at the physical layer).  One has real
>> time requirements to meet.
>> Synchronous design makes a lot of sense for a hardware router or
>> switch, etc.  (As it does for the products we design here, but I won't
>> bore you with the details.)
>
>Hmm.  Wasn't the whole point of the DRACO microprocessor that it was
>actually designed for, and used in, telecoms systems?  The whole idea being
>that an asynchronous design was used because of the requirement for good
>EMC.

Is DRACO popular in commercial designs?  Google only seems to find
academic links.

There are better ways to "avoid" EMC, BTW, but they are off topic for
this thread.

>Why would such a design not also "make a lot of sense"?

The point I was making is that most comms interfaces are fundamentally
synchronous at their lowest levels.  Consider a popular interface like
100Base-Tx Ethernet.  This pushes out a byte of data every 80ns, and
this timing must come from an accurate clock.  Asynchronous logic has
no place here.

Some parts (e.g. control plane in a Ethernet switch) are "best effort"
rather than "exact timing" in nature, and asynchronous logic might be
feasible.  This type of function is often performed in a
microprocessor.

Regards,
Allan

Article: 96914
Subject: Question about using LMB to connect BRAM in MicroBlaze
From: "fpga" <hy34@njit.edu>
Date: 13 Feb 2006 12:34:28 -0800
Links: << >>  << T >>  << A >>
I am trying to create a MicroBlaze system with 8K instruction memory
and 16K data memory. So I use includes a 8K Bram in my system and
connected to the ilmb bus and a 16k Bram connected to the dlmb bus and
give them non-overlapped address range. When I tried to debug my
program by connecting it to the virtual system, it gives me the error
"
Vpconnect mb
i, dlmb address maps should match
VP target failed.

I understand that ilmb dlmb actually are using the same
lmb_bram_if_cntlr and LMB bus. Different address should be the only way
to tell the difference. But how can I tell where should the data be
stored in my high level C program. It seems that the MicroBlaze will
automatically store data after the instruction section.  Similarly, if
I want to use a shared memory place for two MicroBlaze, where can I
give the information in the high level C program where the shared
memory is. 

Thanks a lot for your reply.


Article: 96915
Subject: Re: PacoBlaze updated
From: Allan Herriman <allanherriman@hotmail.com>
Date: Tue, 14 Feb 2006 07:40:18 +1100
Links: << >>  << T >>  << A >>
On 12 Feb 2006 23:16:08 -0800, "Pablo Bleyer Kocik"
<pablobleyer@hotmail.com> wrote:

> Hello folks.
>
> I would like to let you know that I have made a new release of
>PacoBlaze (2.0b). Some bugs noticed by users were fixed and the modules
>were modified a bit to ease implementation, as suggested by a friend.
>As usual, you can find the files in the 'PacoBlaze' section of my web
>site, http://bleyer.org/.
>
> Wow, it is almost two years since I wrote the first version of
>PacoBlaze. Thanks for all the people who have found the module and the
>Java assembler useful (in ways that I never anticipated!) and have sent
>encouraging words despite the fact that my replies have been terribly
>slow ;o)

Thanks!

Do you have a detailed description of the actual bugs fixed?

Regards,
Allan

Article: 96916
Subject: Re: Question about using LMB to connect BRAM in MicroBlaze
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 13 Feb 2006 21:42:48 +0100
Links: << >>  << T >>  << A >>
"fpga" <hy34@njit.edu> schrieb im Newsbeitrag 
news:1139862868.498078.295090@f14g2000cwb.googlegroups.com...
>I am trying to create a MicroBlaze system with 8K instruction memory
> and 16K data memory. So I use includes a 8K Bram in my system and
> connected to the ilmb bus and a 16k Bram connected to the dlmb bus and
> give them non-overlapped address range. When I tried to debug my
> program by connecting it to the virtual system, it gives me the error
> "
> Vpconnect mb
> i, dlmb address maps should match
> VP target failed.
>
> I understand that ilmb dlmb actually are using the same
> lmb_bram_if_cntlr and LMB bus. Different address should be the only way
> to tell the difference. But how can I tell where should the data be
> stored in my high level C program. It seems that the MicroBlaze will
> automatically store data after the instruction section.  Similarly, if
> I want to use a shared memory place for two MicroBlaze, where can I
> give the information in the high level C program where the shared
> memory is.
>
> Thanks a lot for your reply.
>

you can place code and data in any place you want by writing proper linker 
scripts

the virtual platform possible isnt supporting the case where the ilmb and 
dlb addresses
don match as it is very seldom the case

Antti



Article: 96917
Subject: Re: Async Processors
From: fpga_toys@yahoo.com
Date: 13 Feb 2006 13:04:27 -0800
Links: << >>  << T >>  << A >>

Allan Herriman wrote:
> The point I was making is that most comms interfaces are fundamentally
> synchronous at their lowest levels.  Consider a popular interface like
> 100Base-Tx Ethernet.  This pushes out a byte of data every 80ns, and
> this timing must come from an accurate clock.  Asynchronous logic has
> no place here.

The external interface logic for comms, memory, and most things real
world are clearly not async. However,  placing an async to sync dual
ported fifo at the chip pads, allows all internal control and data path
logic to become async, with at most a small sync state machine for
control.


Article: 96918
Subject: Re: Question about using LMB to connect BRAM in MicroBlaze
From: "fpga" <hy34@njit.edu>
Date: 13 Feb 2006 13:37:59 -0800
Links: << >>  << T >>  << A >>
Thank you very much.


Article: 96919
Subject: Re: digital logic library by 74xxxx part number?
From: "richard" <richard@idcomm.com>
Date: 13 Feb 2006 13:38:00 -0800
Links: << >>  << T >>  << A >>
For the most part, I'm right with you on your comments.  However ...
<sigh> ... there's always a however ... sometimes someone hands you a
schematic and says, "THIS is what I want, and THIS is what I'll pay you
to recreate in programmable logic," and that's where the fun begins.
I've had little trouble getting "transcriptions" of SSI/MSI designs to
work in CPLD's, with the exception of one-shots, which can, but
shouldn't, be implemented in CPLD's with SCHMITT inputs.  However, some
"TTL" library parts didn't work quite right when taken directly from
the XILINX library, and some had extra or omitted signals, the
justification for which was seldom available.

If someone wants THIS generated in CPLD/FPGA hardware, you have to give
it your best effort, but if you do it in HDL, it's unlikely anybody
will be able to review it to their satisfaction.  If you present a 100
modules of VHDL to a group of guys my age, who went to college when
transistor radios were just becoming commonplace, all you'll get is
"what's this?" and maybe fired, unless, say, you can plug our device in
an application for what you've got to replace, and demonstrate it works
as well as the original.

Reviews are a problem.  If you have a well-designed, well-documented,
fully verified logic design implemented on a device that's working to
your satisfaction, you still have to go through the review process.  If
the senior engineers, and I don't mean those kids who don't even
remember back before there was a NASA, are presented with a single-page
schematic, they can grasp what's going on in the design, at least to
their own satisfaction, with the help of the documentation, in about a
half an hour.  If you hand them a stack of HDL listings, and especially
if you've presented them with a block diagram that represents a bunch
of HDL-implemented blocks, you're in for a rough ride, and a week of
being raked over the coals, at great expense to someone, since all that
engineering horsepower has to be paid, and the buy who signs their
checks probably signs yours, too.  If you show them a schematic, they
know what it means and can interpret it as well as they need.  If you
substitute synchronous for asynchronous logic, they'll understand why
you did that.  Support it with block schematics and simulations and
they'll bite.  If you support it with HDL blocks and simulations,
they'll fight.  You'll be accused of bait-and-switching on them.

That, BTW, is why I'm so upset over the fact that both XILINX and
ALTERA have made their schematic capture software a distant, neglected,
and indadequately documented stepchild.  

Richard


Article: 96920
Subject: Re: Async Processors
From: Allan Herriman <allanherriman@hotmail.com>
Date: Tue, 14 Feb 2006 08:43:11 +1100
Links: << >>  << T >>  << A >>
On 13 Feb 2006 13:04:27 -0800, fpga_toys@yahoo.com wrote:

>
>Allan Herriman wrote:
>> The point I was making is that most comms interfaces are fundamentally
>> synchronous at their lowest levels.  Consider a popular interface like
>> 100Base-Tx Ethernet.  This pushes out a byte of data every 80ns, and
>> this timing must come from an accurate clock.  Asynchronous logic has
>> no place here.
>
>The external interface logic for comms, memory, and most things real
>world are clearly not async. However,  placing an async to sync dual
>ported fifo at the chip pads, allows all internal control and data path
>logic to become async, with at most a small sync state machine for
>control.

Consider a store-and-forward Ethernet switch or router.  A packet
comes in on one synchronous interface, gets written to synchronous
ram, gets read out of synchronous ram and sent to another synchronous
interface.
One could put sync-to-async and async-to-sync fifos in between those
blocks, but why would you?  Where is the benefit for a data plane
application which requires accurate timing?

I can see that async logic might help in something like a
microprocessor (where you often don't care about exact execution
times), but the arguments don't seem compelling for any of the tasks I
meet in my work.

Regards,
Allan

Article: 96921
Subject: SCHEMATICS ... Is anybody as frustrated as I am with the software?
From: "richard" <richard@idcomm.com>
Date: 13 Feb 2006 13:53:53 -0800
Links: << >>  << T >>  << A >>
I've recently noticed that the schematic software that's included with
XILINX' ISE WebPack and with Altera's Quartus WebEdition software is
pretty lame.  It looks as though the folks who generate, maintain, and
repair this stuff have never had to make their living with it.

I recently abandoned the last two releases of XILINX' WebPack stuff
because there were problems making it nearly unuseable.  Release 7 was
apparently written in VB or JAVA, hence, was so slow I couldn't use it,
and release 8 was not only slow but "broken" in a number of ways that I
couldn't use it either.

Several bugs that I reported in 2002 still can be found, including a
problem aligning bus taps with nets drawn on the grid that aligns with
the symbol pins, translation/netlist errors, random breakdown in
sequential signal-numbering (tell it to increment, and it decrements,
and vice-versa, but not always) ... I could go on, and will in a note
to the local sales rep ...

The release 3 and 4 of Quartus wouldn't display whole text strings on
any of our HP desktops.  That meant that, for a year, no Altera
development could be done, except with MaxPlus-II.

The current Quartus doesn't associate net names between net segments,
i.e. if I put a right angle in a "wire," it loses its net-name
property.   There are cases wherein a net name can't be deleted from a
sheet, even if the net's gone, where a net name=>pin assignment won't
work because the assignment editor doesn't allow editing of the net
name, and busses ... well ...

So, are any of you guys seeing the same sorts of problems?  Doesn't it
make sense to have a half-hour review of a schematic rather than a
week-long review of a ream of HDL listings?

Richard


Article: 96922
Subject: Re: digital logic library by 74xxxx part number?
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 13 Feb 2006 14:02:22 -0800
Links: << >>  << T >>  << A >>
richard wrote:
> If
> the senior engineers, and I don't mean those kids who don't even
> remember back before there was a NASA, are presented with a single-page
> schematic, they can grasp what's going on in the design, at least to
> their own satisfaction, with the help of the documentation, in about a
> half an hour.

Good luck fitting a modern design on a single schematic sheet.  Unless,
of course, that sheet is Z size, or whatever.

> That, BTW, is why I'm so upset over the fact that both XILINX and
> ALTERA have made their schematic capture software a distant, neglected,
> and indadequately documented stepchild.

Seems to me that Altera and Xilinx (and Lattice, and Actel and
QuickLogic) are putting their efforts where it's needed (and wanted),
which is to say in better synthesis tools.

-a


Article: 96923
Subject: Re: SCHEMATICS ... Is anybody as frustrated as I am with the software?
From: "JJ" <johnjakson@gmail.com>
Date: 13 Feb 2006 14:31:39 -0800
Links: << >>  << T >>  << A >>


richard wrote:
> I've recently noticed that the schematic software that's included with
> XILINX' ISE WebPack and with Altera's Quartus WebEdition software is
> pretty lame.  It looks as though the folks who generate, maintain, and
> repair this stuff have never had to make their living with it.
>
> I recently abandoned the last two releases of XILINX' WebPack stuff
> because there were problems making it nearly unuseable.  Release 7 was
> apparently written in VB or JAVA, hence, was so slow I couldn't use it,
> and release 8 was not only slow but "broken" in a number of ways that I
> couldn't use it either.
>
> Several bugs that I reported in 2002 still can be found, including a
> problem aligning bus taps with nets drawn on the grid that aligns with
> the symbol pins, translation/netlist errors, random breakdown in
> sequential signal-numbering (tell it to increment, and it decrements,
> and vice-versa, but not always) ... I could go on, and will in a note
> to the local sales rep ...
>
> The release 3 and 4 of Quartus wouldn't display whole text strings on
> any of our HP desktops.  That meant that, for a year, no Altera
> development could be done, except with MaxPlus-II.
>
> The current Quartus doesn't associate net names between net segments,
> i.e. if I put a right angle in a "wire," it loses its net-name
> property.   There are cases wherein a net name can't be deleted from a
> sheet, even if the net's gone, where a net name=>pin assignment won't
> work because the assignment editor doesn't allow editing of the net
> name, and busses ... well ...
>
> So, are any of you guys seeing the same sorts of problems?  Doesn't it
> make sense to have a half-hour review of a schematic rather than a
> week-long review of a ream of HDL listings?
>
> Richard

For most of us, the days of schematics are long gone but they still
remain useful for high level views and for floorplanning. The best
schematic tool I ever used was VLSI/Compass for ASIC design, it got
most everything right and even allowed true edit in place of symbols
within a live schematic but VLSI Inc developed that for their ASIC biz
some 20yrs ago. When it garbage collected though it died for 20mins.
Once synthesis & HDLs took over, all these schematic tools went south,
there is no revenue model for them.

My big gripe has been the uselessness of the synthesized schematics
from code, if the code is trivial to understand, the schematics can be
passable but not of much real help. If the code is too complex to
understand, the software has no way to know how to reconstruct a decent
looking schematic. Since these are constructed each & every time from
synthesis, the slightest change to source code means a complete
regeneration of synthesized schematic. Much of the code wouldn't really
translate well to schematics as it looks more like C expression code
than object instances. I would like to see a mechanism where by the
synthesized schematic could be somewhat edited for good presentation
and that the result be reused for the next pass without the tool
getting confused by small changes. The biggest joke is when you build
datapaths n bits wide, and these tools usually just consider these bit
paths as just more soso giving mostly random placements that are easily
made non linear by smaller edge details. If a draftsman created these
machine like schematics, they be out the door pronto. In the ASIC world
they have $$$ software that can take flattened mass of logic with
regular hierarchy removed and refind the natural hierarchy and put it
back in for more regular layout, but that wouldn't work too well over
FPGA fabric. Don't expect too much from unpaid software.

end of rant, 

John Jakson


Article: 96924
Subject: Re: Rocketio, modelsim xe
From: Gerhard Hoffmann <dk4xp@freenet.de>
Date: Tue, 14 Feb 2006 00:05:58 +0100
Links: << >>  << T >>  << A >>
On Mon, 13 Feb 2006 14:14:37 -0500, ndt <info@ndt.ca> wrote:

>Hi, I'm trying to implement rocketio on xilinx fpga. Is there a way to 
>simulate it using modelsim XE. I know for the PE, SE version its using 
>smartmodels or generating libraries.

I don't think so. Even PE needs a $1K option to understand
the encrypted smartmodels. 
I'd be glad if I was wrong here :-)

regards, Gerhard





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