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 66725

Article: 66725
Subject: Re: ModelSim, Virtex DCM, and clk0 phase problem
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Wed, 25 Feb 2004 18:36:23 -0700
Links: << >>  << T >>  << A >>

Dan,

    Sounds like you might have run into this problem:

Answer Record # 16847 5.2isp1 Simulation - DCM outputs are 180 degrees 
out of phase (UniSim and SimPrim VHDL models) 
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=16847

Generally it is a good idea to search the Xilinx Support Site when you 
encounter issues such as these as if it has been perviously identified, 
it is generally documented there.

--  Brian



Dan Braunstein wrote:

> Has anyone experienced the clk0 being 180 deg out of phase with the
> DCM input clock during simulation (wave view) in ModelSim? I have clk0
> going to clkfb through a bufg, just like what is described in the V-II
> Platform Handbook (jellybean simple implementation), but after lock,
> clk0 is 180 out of phase, so I do not get the wave that is shown in
> the modelsim wave view in the Handbook.
> 
> My fix is to run clk180 to clkfb. Then clk0 is in phase with clkin.
> But this makes no sense to me. I have not implemented on chip to see
> what really happens.
> 
> As an aside, my input clock is 27MHz, but I need 13.5 MHz for my logic
> with various phase relationships. Any advice? What are the
> implications of running various phased 27MHz clocks into flops to get
> various phased 13.5 MHz clocks?
> 
> Thanks. I am new to all this, but have to say the DCM/simulation bit
> has been infinitely frustrating.
> 
> Danny


Article: 66726
Subject: Re: SmartMedia writer (implments using VHDL)....
From: "Kelvin" <kelvin8157@hotmail.com>
Date: Thu, 26 Feb 2004 09:37:13 +0800
Links: << >>  << T >>  << A >>
It is true that it is more difficult to write to FAT16. However, we can
simplify it.

Format the SM/MMC/SD with FAT16, and write an empty file to this card. Then,
with the same FAT16 reader to
get the addresses. Thirdly, write to this file...do I sound right?

Best Regards,
Kelvin




Amontec Team, Laurent Gauch <laurent.gauch@amontecDELETEALLCAPS.com> wrote
in message news:403c921a$1@news.vsnet.ch...
> Antti Lukats wrote:
> >>what I want to know is:
> >>1. has someone done something similar before. If so, does what I'm about
> >
> > to do sound feasible? Am I overlooking any issue?
> >
> >>2. if you know a better way to transfer data from a PCB to computer
using
> >
> > standard removable media(can be non-smartmedia), what is it?
> >
> >>3. tips?
> >
> >
> > smartmedia has to many wires.
> > reading FAT16 is real simple, connecting to MMC is real simple.
> > you can get some old PC monetherboard for 1 $ and cut the ISA socket, or
use
> > the old floppy cable if you have one there you MMC socket.
> > reading MMC required only 4 lines.
> >
> > xilinx.openchip.org
> >
> > there is source code in C for microblaze to read 1 file from FAT16 on
> > compact flash card, it can be modified to read from MMC. there is also
> > simple half made routine to talk to MMC card (connected to MicroBlaze
GPIO
> > pins).
> >
> > you can of course use smartmedia, but it way more wires!
> >
> > antti
> >
> >
> Yes, FAT16 reader is very simple to implement. But the original message
> is about writing in FAT16 format. FAT16 writer is much more complex. And
> you need to have a processor to do the JOB, an FPGA will be to expensive
> for this JOB, for this *sequential* JOB.
>
> Some month ago, we designed a datalogger with an FAT16 writer to a
> compactFlash. We did the JOB with a PIC up for the FAT16 format, and a
> small CPLD for the AD dialog and some pre-processing data JOB (some mA
> for all the JOB ...)
>
> Laurent
> www.amontec.com
>



Article: 66727
Subject: Re: Modular Design in WebPack
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 25 Feb 2004 20:50:15 -0500
Links: << >>  << T >>  << A >>
"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
message news:c1iqrh$1jah9r$1@ID-212430.news.uni-berlin.de...
> Design consists of two modules: VHDL top-module and EDIF-netlist instance.
> In other words, the design is broken down into two files and I need to
> assemble it. Usually, simulation tools allow for geterogeneous sources.
> Simulators comile source files to extract design units and put them into
> libraries. Do sinthesis tools favor this practice?
>
> EDIF-module's design is a cell named SCH1 located in SCH1_LIB library. It
> has two inputs I1, I2 and output O. How should parent VHDL module look
like?
>
> Development System Reference Guide at
> http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/devtoc.html states
> that Modular Design is an option of Xilinx Development System. Does
WebPack
> support it?
>
> Is Modular Design the only solution?
>

What you are trying to do as far as I can tell is not a modular design in
sense of Xilinx tools. You simply have mixed sources. There is more than one
way to do this under ISE (I believe Webpack is the same). I can't remember
the proper way off the top of my head, but one way is to create a normal
VHDL-flow design and then set Macro Search path in Translate options to
where you have your edif file.This assumes that the top level is VHDL.

/Mikhail
-- 
To reply directly:
matusov at square peg ca
(join the domain name in one word and add a dot before "ca")



Article: 66728
Subject: powerpc
From: "Terrence Mak" <stmak@se.cuhk.edu.hk>
Date: Thu, 26 Feb 2004 10:30:21 +0800
Links: << >>  << T >>  << A >>
Hi,

How to time jobs of powerpc in the EDK?

Do anyone have some examples?

Thanks,
Terrence



Article: 66729
Subject: Re: Stratix 2 ALUT architecture patented ?
From: mrather@altera.com (Michael)
Date: 25 Feb 2004 18:37:04 -0800
Links: << >>  << T >>  << A >>
Austin,

As a general rule, Altera likes to avoid using this site as a
marketing tool. Instead, we choose to focus just on relevant technical
questions. However, since you brought it up, the question at hand: is
the innovation in Stratix II just a renaming of the f5/f6/f7/f8 muxes
in Virtex products?

On the contrary, the Stratix II architecture represents a complete
redesign of a programmable logic fabric.

Recognizing the need for a more powerful and efficient approach than
the 4LUT + register fabric that all mainstream FPGAs have relied on
for years, Altera increased the capability and flexibility of the
Stratix II logic with a larger and truly adaptive logic module (ALM). 
An ALM can efficiently implement one to two 6LUTs, any 5LUT and 3LUT
combination, two 5LUTs (for almost any 2 functions), any two 4LUTs
etc...all in a single logic block.  (For more complete listing, look
here: http://www.altera.com/products/devices/stratix2/features/architecture/st2-lut.html)
Previous FPGA architectures have only had 4LUT capabilities without
routing between multiple logic blocks.

Virtex devices are really a 4LUT architecture with some MUXes (note
that "variable LUT terminology" was only recently mentioned in a white
paper but is not found in the data sheet). The f5/fX muxes are one way
to emulate larger LUT functions, but this approach comes at the cost
of multiple LC resources, routing structures between those LC's, and
requires that the synthesis tool (or the designer) intelligently map
to those muxes.  Analysis of synthesis and place and route results,
suggests the f5/fX resources are commonly used in large distributed
memory functions and wide muxes, but rarely benefit wide LUT
functions.

Comparing results of how real designs synthesize and map to Stratix II
ALMs vs. Virtex-II Pro slices (the most direct comparison since each
ALM/slice is capable of 2 4LUT functions)  shows a 54% efficiency
advantage for Stratix II.  This increased logic efficiency also
results in better performance and lower power, since with more logic
density inside each logic block, less routing circuitry is used which
tends to be slower and leakier by comparison.

For those of you curious to find out more details on this, the
following white paper and web seminar may interest you:.

Logic Structure Comparison Between Stratix & Virtex-Based
Architectures
http://www.altera.com/literature/wp/wpstxiixlnx.pdf

http://www.altera.com/education/net_seminars/current/stratix2/ns-stratix2.html?f=sx2hp&k=g2

Mike Rather
Altera Corp.

Austin Lesea <austin@xilinx.com> wrote in message news:<c1gfrh$l613@cliff.xsj.xilinx.com>...
> Lenz,
> 
> I am sure that they have filed for their patents.  Since it takes two or 
> more years, we will just have to wait and see what it is that gets patented.
> 
> How this is any different than f5/f6/f7/f8 muxes is also at issue:  have 
> they just "renamed" an already existing architecture?  Do they now 
> achieve the same packing that is already enjoyed by others?
> 
> Austin

Article: 66730
Subject: Re: Stratix 2 / MAX II
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 26 Feb 2004 15:52:28 +1300
Links: << >>  << T >>  << A >>
Michael,
  Since you popped your head over the parapet... :)

  What's the story on MAX II Devices ?. There was glossary, timing
and lib files gradually appearing, and suddenly the Altera
web is cleansed and it's like MAX II is now 'off the radar' ?.
  Would seem to indicate some problems.....

-jg


Article: 66731
Subject: Re: Xilinx webpack 6.1.03i error
From: Marc Guardiani <marc@guardiani.com>
Date: Thu, 26 Feb 2004 03:19:56 GMT
Links: << >>  << T >>  << A >>
Which OS are you using? NT is no longer supported.

Sumit Gupta wrote:
> I upgraded to webpack 6.1i from 4.2 and when I compile my design I get the
> following error.
> 
> Loading device for application Xst from file 'v100.nph' in environment
> C:/Xilinx.
> FATAL_ERROR:DeviceResourceModel:basnpdevice.c:620:1.23 - bad nph file
> Process will terminate.  To resolve this error, please consult the Answers
> Database and other online resources at http://support.xilinx.com. If you
> need further assistance, please open a Webcase by clicking on the "WebCase"
> link at http://support.xilinx.com
> 
> I searched through answer database but did not find anything. Does anybody
> has any ideas ?
> 
> Sumit
> --------------------
> http://www.c-nit.net
> 
> 

Article: 66732
Subject: Re: Stratix 2 ALUT architecture patented ?
From: austin <austin@xilinx.com>
Date: Wed, 25 Feb 2004 20:32:14 -0800
Links: << >>  << T >>  << A >>
Michael,

Thank you very much.  I have read all of the publicly available 
materials, and am still puzzled by the claims.

Any claims of remarkable efficiency, you may understand, I am quite 
leary of.  For example, if the claim of a St2 50% speed improvement is 
really true, then our demonstrated 40% speed improvement on average in 
the i6.2 release makes St2 only 10% faster than our 2 year old V2 
Pro.....lowest speed grade.  So leaving marketing to those who enjoy it, 
I will forego any claims of performance, and just ask about architecture.

I was unclear on just how a ALM is any different from drawing the box 
differently around the components.  I am still puzzled, but the block 
diagrams appears to have 3, 4, 5 and 6 LUTS with muxes, and maybe if it 
was actually designed this way then that is simply what it is.  A true 6 
LUT has 64 memory cells and the associated logic, and two of these seems
a bit excessive and would not require any other logic or muxes at all. 
  Combining existing 4 LUTs to deliver some of the possible terms of a 6 
LUT is a completely different matter.

Regardless, it is enjoyable to hear about any radical or innovative new 
architecture, as there are so many that now dot the landscape as dead 
skeletons of past FPGAs.

Austin

Article: 66733
Subject: Re: SmartMedia writer (implments using VHDL)....
From: hamilton <hamilton@deminsional.com>
Date: Wed, 25 Feb 2004 22:22:54 -0700
Links: << >>  << T >>  << A >>


Kelvin wrote:
> It is true that it is more difficult to write to FAT16. However, we can
> simplify it.
> 
> Format the SM/MMC/SD with FAT16, and write an empty file to this card. Then,
> with the same FAT16 reader to
> get the addresses. Thirdly, write to this file...do I sound right?
> 
> Best Regards,
> Kelvin

Yes, this sounds about right.

A few things to be aware of:

1) a newly formatted SM/MMC/SD or CF for that matter will not have a 
fragmented FAT table.

2) a new file written to the media should have the FAT table in 
sequencal order. ( this is a good thing )

3) Finding the start cluster and start sector will be different with 
different cluster sizes. ( I know you knew that )

So if the embedded code can find this information, over writting the 
clusters in order should take care of any problems.

But, if your going to ASSUME that much, why not write a real FAT file 
handler and assume nothing.

This trick is also useful to help preventing a corrupt FAT table.

hamilton


Article: 66734
Subject: Re: Dual-stack (Forth) processors
From: "Davka" <mygarbagepail@hotmail.com>
Date: Wed, 25 Feb 2004 23:10:47 -0700
Links: << >>  << T >>  << A >>

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:KX7%b.2619$6k.0@newssvr27.news.prodigy.com...
> Davka wrote:
>
> > I learned APL when I was a kid.  I love it too.  It taught me respect
for
> > languages that don't have an implicit order of operations.
>
> Small World, isn't it!
> The other thing that's nice about APL is the ability to abstract away from
> the mechanics of programming and live within the problem domain.

You're not the first fellow nerd that I've met who likes both Forth
and APL.  :-)

> > was prohibitive.  Now, I have a real chance to build some music
hardware.
>
> Have you consider just doing it the FPGA way?  I haven't stopped to think
> about what's required but you can certainly create building blocks in
> hardware (say, filters).  Also, with the Virtex 2 Pro family you have the
> ability to use the PowerPC processor/s as, well, processors and the rest
of
> the FPGA is available for custom peripherals (if you want to think of it
> that way).

That's the plan.  I've already put dozens of hours into learning the Altera
tool
and their chip families, so that's the way I will go initially.  They have
their
own tiny RISC implementation (called NIOS), so if I don't do my own
processor,
I'll use that one.

The idea for the system architecture is to have a bunch of DSP modules of
various flavors
in the hardware which can be dynamically allocated by the software system
that manages them.

> Of course, an optimized Forth machine would/could make it very interactive
> and fun to play with.  Is there an implementation of Forth for PowerPC?

:-)  I think it's called Open Firmware.

-Davka



Article: 66735
Subject: Re: Dual-stack (Forth) processors
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 26 Feb 2004 01:16:23 -0500
Links: << >>  << T >>  << A >>
Davka wrote:
> 
> "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
> news:KX7%b.2619$6k.0@newssvr27.news.prodigy.com...
> > Davka wrote:
> >
> > > I learned APL when I was a kid.  I love it too.  It taught me respect
> for
> > > languages that don't have an implicit order of operations.
> >
> > Small World, isn't it!
> > The other thing that's nice about APL is the ability to abstract away from
> > the mechanics of programming and live within the problem domain.
> 
> You're not the first fellow nerd that I've met who likes both Forth
> and APL.  :-)
> 
> > > was prohibitive.  Now, I have a real chance to build some music
> hardware.
> >
> > Have you consider just doing it the FPGA way?  I haven't stopped to think
> > about what's required but you can certainly create building blocks in
> > hardware (say, filters).  Also, with the Virtex 2 Pro family you have the
> > ability to use the PowerPC processor/s as, well, processors and the rest
> of
> > the FPGA is available for custom peripherals (if you want to think of it
> > that way).
> 
> That's the plan.  I've already put dozens of hours into learning the Altera
> tool
> and their chip families, so that's the way I will go initially.  They have
> their
> own tiny RISC implementation (called NIOS), so if I don't do my own
> processor,
> I'll use that one.
> 
> The idea for the system architecture is to have a bunch of DSP modules of
> various flavors
> in the hardware which can be dynamically allocated by the software system
> that manages them.

I found a mention of a Forth for DSP called FROTH.  I believe it is an
open source project, but the page does not seem to have been updated in
quite a while.  Some of the other posters here may know more about it.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 66736
Subject: Re: difference btw H/W & S/W implementations !!
From: "Mickey" <mickey@mickey.com>
Date: Thu, 26 Feb 2004 07:41:22 +0100
Links: << >>  << T >>  << A >>
> What is the difference between a hardware implementation of an
> algorithm and a software one.

Hardware implementation would be like floating point mathematics in
DSP microcontroller, so DSP has instructions which dirrectly execute
in processor in 1 cycle, and software implementation would take
50 or something like that instructions on processor that doesn't have
floating point math hardware.

> How do you say an algorithm is faster in one and slower in other.. if
> it's based on timing how do you do that?? What makes it faster in one
> and not in other??

It should be obvious from my answer to previous question.

You can look on hardware solution as a washing machine, you can wash
faster with it than by hands (software approach), to get the same quality.

Mickey



Article: 66737
Subject: FSM in fpga's
From: "Avinash Sharma" <asharma3@REMOVETHIS.uiuc.edu.NOSPAM>
Date: Thu, 26 Feb 2004 00:47:51 -0600
Links: << >>  << T >>  << A >>
is it true that one-hot encoding for FSM's is used in FPGA's? If so,
why? is it due to the large amount of registers available i.e: enough
registers to store all states? what kind of encoding is using in ASIC's?

thanks much
-- 
avi



Article: 66738
Subject: Re: difference btw H/W & S/W implementations !!
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 25 Feb 2004 23:51:47 -0800
Links: << >>  << T >>  << A >>
Hello OP,

hope you got an better name in your next life. 

omnipresent@hotmail.com (OP) wrote:
> Feeling really intelligent today.. I would like to know some basic
> stuff..
> 
> What is the difference between a hardware implementation of an
> algorithm and a software one.  

HW & SW are uncomparable in general because SW w/o HW makes no sence.

In some context you speak of HW or SW solution when you mean the
decission to use either
- a general purpose CPU (eg. micro controller) and write the
appropriate SW for this CPU
or
- build an ASIC (application specific IC, could of course be a fpga
too) that solves your problem.

In general is an ASIC faster and fits better in your special needs for
reliability, power consumption and size, but tends to be more
expensive (unless  huge quantities) and you have big trouble when you
find a better algorithm for your problem.
   
You would think twice before using an ASIC for data compression on the
other hand it's impossible to do very high speed realtime data
processing (eg. 10GB Switch) with a CPU.

bye Thomas

Article: 66739
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Kevin Brace <k0evinbr1ace@m2ail.c3om>
Date: Thu, 26 Feb 2004 02:45:03 -0600
Links: << >>  << T >>  << A >>
        The $100 license's US residency requirement is there because if
a licensee violates the license agreement of personal use, and uses the
PCI IP core in a commercial project in a foreign country, it is probably
going to be much harder to stop that than if it happened in this
country.
The no-academic research restriction is there because I want to charge
more than $100 for research-related academic use.
If you don't like that, talk to Xilinx, because I heard that they
sometimes donate their PCI IP core to universities.
        Regarding your "one-shot PCI cores" comment, no, mine will cost
$100 more than a free one, but as a product it will be identical to a
commercial version I am planning to charge much more than $100.
Plus, the licensee can receive technical support through a forum in
Yahoo! Groups I am planning to set up.


Kevin Brace



Sander Vesik wrote:
> 
> 
> Not the point. The heavy handed part is 'US only, no-research, pay
> money and return printed licence'.
> 
> You know, your licenceing is way more restrictive for which I can
> download the Oracle database and most of their products, and same
> applies to IBM and similar. Not only are your terms unreasonable,
> you aren't even really all that price competitive as far as one-shot
> PCI cores go.
> 
> 
> --
>         Sander
> 
> +++ Out of cheese error +++

Article: 66740
Subject: Re: $100 for Americans PCI-bridge in NGO netlist for Spartan-IIE (Was:
From: Kevin Brace <k0evinbr1ace@m2ail.c3om>
Date: Thu, 26 Feb 2004 02:52:42 -0600
Links: << >>  << T >>  << A >>
        I am trying to run a business (Sounds better than working at a
retailer.) licensing my PCI IP core to other firms or people, so the RTL
code will cost as much as a new car.
As far as I know, that's how much IP core firms charge for a PCI IP
core.
I probably shouldn't trash Opencores.org PCI IP core here, but I believe
my PCI IP core will be easier for beginners to use than Opencores.org
PCI IP core because it is structually simpler, will be supplied in
netlist format (As opposed to having to synthesize the PCI IP core.),
and comes with a constraint file to meet setup and hold time
requirements of PCI.


Kevin Brace



Roger Larsson wrote:
> 
> Kevin Brace wrote:
> 
> 
> So, what is wrong with the OpenCores PCI?
> 
> http://www.opencores.org/projects.cgi/web/pci/home
> 
> Especially when you concider that you also get the
> generic source, you have not indicated any price
> for that...
> 
> /RogerL
> 
> --
> Roger Larsson
> Skellefteċ
> Sweden

Article: 66741
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: buchty@atbode100.informatik.tu-muenchen.de (Rainer Buchty)
Date: Thu, 26 Feb 2004 09:21:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <c1kbg6$t67$3@newsreader.mailgate.org>,
 Kevin Brace <k0evinbr1ace@m2ail.c3om> writes:
|> The no-academic research restriction is there because I want to charge
|> more than $100 for research-related academic use.

Let me get this straight. The use should be

        - non-commercial
        - non-profit
        - non-academic research
        - strictly personal purposes

So who the hell should license that core? I can understand that you rule out
commercial use, I *could* understand if you ruled out industrial research.

But ruling out academic research because you want to charge *more* from
universities is reducing the number of potential customers pretty much to
zero.

Rainer

Article: 66742
Subject: Re: Modular Design in WebPack
From: "John Adair" <newsreply@loseinspace.co.uk>
Date: Thu, 26 Feb 2004 09:24:13 -0000
Links: << >>  << T >>  << A >>
Have a look at our current TechiTips
http://www.enterpoint.co.uk/techitips.html . Method2 is relevant to want you
want to do.

Modular design is an add-on to ISE have a look here
http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design . It
is aimed mainly at team design and may not be what you want.

John Adair
Enterpoint Ltd.

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.

"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
message news:c1iqrh$1jah9r$1@ID-212430.news.uni-berlin.de...
> Design consists of two modules: VHDL top-module and EDIF-netlist instance.
> In other words, the design is broken down into two files and I need to
> assemble it. Usually, simulation tools allow for geterogeneous sources.
> Simulators comile source files to extract design units and put them into
> libraries. Do sinthesis tools favor this practice?
>
> EDIF-module's design is a cell named SCH1 located in SCH1_LIB library. It
> has two inputs I1, I2 and output O. How should parent VHDL module look
like?
>
> Development System Reference Guide at
> http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/devtoc.html states
> that Modular Design is an option of Xilinx Development System. Does
WebPack
> support it?
>
> Is Modular Design the only solution?
>
> How to allocate floorplan area automatically?
>
> How do you simulate modular designs?
>
>
> Thanks.
>
>



Article: 66743
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: "Torsten Lauter" <torsten.lauter@opti-x-soft.de>
Date: Thu, 26 Feb 2004 10:32:22 +0100
Links: << >>  << T >>  << A >>
Our conditions:

Dear User,

thank you for your interest in our free VHDL PCI core.
The VHDL code is provided to you free of charge and we ask you not to pass
it on to any third parties.

The design has been tested and is expected to run smoothly.
However, no support or design guidance is guaranteed.
Its use is at your own risk and you take over full liability.

We reserve the right to name you/your company as reference user.
In turn, you ought to reference us as origin of the PCI core in the final
product description (e.g. manual, flyer etc.).

Code documentation is also at early stage, since the VHDL design is part of
a bigger project. Once there is time left in the project schedule, we will
round up the documentation.

To sum up the conditions:

- the code is provided free of charge
- no guarantee is given what so ever
- you agree to be named as reference user
- you must not pass the code on to third parties
- documentation is at early stage and support can not be guaranteed
- a reference (acknowledgement notice) to us as origin of the PCI core
  must be included in the final product description

Finally, we would appreciate your feedback about functionality, application
scenarios, documentation and code add ons.

We ask you to agree to the conditions given above by means of an appropriate
email answer.
The VHDL PCI core will be emailed to you as soon as your compliance email
arrives.

Regards,

Torsten Lauter & Thomas Knoll

http://www.infotech.tu-chemnitz.de/~knoll/vhdl_pci_bridge/

"Rainer Buchty" <buchty@atbode100.informatik.tu-muenchen.de> schrieb im
Newsbeitrag news:c1kdrj$2h1f3$1@sunsystem5.informatik.tu-muenchen.de...
> In article <c1kbg6$t67$3@newsreader.mailgate.org>,
>  Kevin Brace <k0evinbr1ace@m2ail.c3om> writes:
> |> The no-academic research restriction is there because I want to charge
> |> more than $100 for research-related academic use.
>
> Let me get this straight. The use should be
>
>         - non-commercial
>         - non-profit
>         - non-academic research
>         - strictly personal purposes
>
> So who the hell should license that core? I can understand that you rule
out
> commercial use, I *could* understand if you ruled out industrial research.
>
> But ruling out academic research because you want to charge *more* from
> universities is reducing the number of potential customers pretty much to
> zero.
>
> Rainer



Article: 66744
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Kevin Brace <k0evinbr1ace@m2ail.c3om>
Date: Thu, 26 Feb 2004 03:38:09 -0600
Links: << >>  << T >>  << A >>
        The $100 license for my PCI IP core is not intended for
prototyping of a commercial product.
Whoever wanting to use it in a commercial product should get a
commercial license which will cost several thousand dollars because
that's what other firms charge for a comparable PCI IP core, and that's
probably how much I need to get paid to run a business, and make a
living out of doing of it.
        My intention for the $100 PCI IP core license is that hobbyists,
FPGA enthusiasts, and students simply cannot afford commercial PCI IP
cores which cost several thousand dollars, but they probably want a
commercial quality PCI IP core for something they can afford to pay.
Realistically speaking, I don't believe they are willing to pay anything
more than $100 for such a PCI IP core, so that's how much I can probably
charge.
From a business perspective, if I can get 100 users to pay $100, I will
earn $10,000, which is comparable to several commercial design wins.
The only problem is, as the number of licensees grow, the quality of
technical support will probably degrade because I will be have to deal
with more licensees.


Kevin Brace 



Sander Vesik wrote:
> 
> Taavi Hein <hein@bps.co.ee> wrote:
> > On Tue, 24 Feb 2004 15:25:02 -0600, Kevin Brace <kev0inb1rac2e@m3ail.c4om>
> > wrote:
> >
> > >> * The licensee Will agree that the PCI IP core will be used only for
> > >> non-commercial, non-profit, non-academic research, and personal
> > >> purposes.
> >
> > I could live with that restriction.
> 
> Really? You do realise that should you prototype something in the FPGA
> that works with that core (whetveer directly or now) you are effectively
> forced to *ALWAYS* start over from scratch if you want to use it in
> some other project? This is the sucky part about such a core - you can't
> get a replacement one and continue developing in that, be cause the moment
> you try you may be suddenly retroactively screwed from start (notice the
> word continue).
> 
> --
>         Sander
> 
> +++ Out of cheese error +++

Article: 66745
Subject: Re: SmartMedia writer (implments using VHDL)....
From: "p" <chaosdynasty@hotmail.com>
Date: Thu, 26 Feb 2004 09:57:45 GMT
Links: << >>  << T >>  << A >>
Hi, sorry, I'm going to stick to external removable media.

serial port would make my life easier but it's too common.

One of the goal of this project is to test my endurance. The other one is to
make data transfering as painless as possible.

Thanks!


"Hal Murray" <hmurray@suespammers.org> wrote in message
news:103olioln4u5cd0@corp.supernews.com...
> >2. if you know a better way to transfer data from a PCB to computer
> > using standard removable media(can be non-smartmedia), what is it?
>
> The usual way to get data from a random project to a PC is over
> a serial port.  (RS-232)
>
> I haven't worked with Smart Media.  They are used in digital cameras.
> The usual way to get pictures from a camera is via USB where the
> storage device looks like a disk.  That means you (probably) have
> to write things in a file-system format.  Is your software going
> to support that?
>
> I don't know why you want to use Smart Media.  I'll assume you want
> to put it where a serial cable won't reach.
>
> If the file system software turns out to be too complicated, you might
> be able to build a chunk of hardware that reads the SM card and sends the
> bits out a serial port.  Mostly the reverse of writing it.  (Or you
> could add a serial port to your existing board and load new firmware.)
>
> --
> The suespammers.org mail server is located in California.  So are all my
> other mailboxes.  Please do not send unsolicited bulk e-mail or
unsolicited
> commercial e-mail to my suespammers.org address or any of my other
addresses.
> These are my opinions, not necessarily my employer's.  I hate spam.
>



Article: 66746
Subject: Re: SmartMedia writer (implments using VHDL)....
From: "p" <chaosdynasty@hotmail.com>
Date: Thu, 26 Feb 2004 09:59:07 GMT
Links: << >>  << T >>  << A >>
Hi guys,

thanks for your input

I did spend a lot of time studying the SM FAT12 implmentation (<8 mb = FAT
12). Theoretically, the sequentially step would be

1. set address to the 1st sector, the FAT area
2. write the filename, attribute, extension, etc. to FAT
3. set address to the root directory sector
4. write the filepath to the root directory
5. set address to the 2nd sector, the data area
6. stream the data, compute the total number of bytes written
7. jump back to the FAT area and add the length value

if a blank file is already created, then step1-5 can be skip, however, a new
step is needed
1. search the entire FAT for the file entry. I heard that the file entry in
FAT is random. 2. read the entry and set the pointer to that data area

so no matter what the design becomes too complicated. In the end I designed
it doesn't worth the trouble...

Good to know that I'm right about this issue.

So I guess I will stick with no file system, raw data, and use disk dump as
the bridge between the two. I will ask around and see if unix/linux can read
SM format (using those 9in1 card reader). Also, if the guy who ported dd to
windows did a good job, then a batch file is probably all I need to read
back the data.

Regarding to the numerous lines on SM chip, I agree they are a pain.
However, I have a bunch of SM specification (by Toshiba). There is a timing
diagram that has all the programmable lines for Serial Data input(data
streaming with auto address increment). So if I recreate that waveform in
VHDL, something will get into the chip right? Anyways, MMC seems to be a
pretty good alternative, I will probably dig into it a bit. But the SM
wiring is already completed, so without any documententation on MMC
programming, I can't justify the trouble of rewiring the chip and getting
new components.

By the way, if anyone wants the SM specifications, I can put them on my site
for download


Thanks guys!


"hamilton" <hamilton@deminsional.com> wrote in message
news:403d82ad$1_4@omega.dimensional.com...
>
>
> Kelvin wrote:
> > It is true that it is more difficult to write to FAT16. However, we can
> > simplify it.
> >
> > Format the SM/MMC/SD with FAT16, and write an empty file to this card.
Then,
> > with the same FAT16 reader to
> > get the addresses. Thirdly, write to this file...do I sound right?
> >
> > Best Regards,
> > Kelvin
>
> Yes, this sounds about right.
>
> A few things to be aware of:
>
> 1) a newly formatted SM/MMC/SD or CF for that matter will not have a
> fragmented FAT table.
>
> 2) a new file written to the media should have the FAT table in
> sequencal order. ( this is a good thing )
>
> 3) Finding the start cluster and start sector will be different with
> different cluster sizes. ( I know you knew that )
>
> So if the embedded code can find this information, over writting the
> clusters in order should take care of any problems.
>
> But, if your going to ASSUME that much, why not write a real FAT file
> handler and assume nothing.
>
> This trick is also useful to help preventing a corrupt FAT table.
>
> hamilton
>



Article: 66747
Subject: Re: FSM in fpga's
From: "p" <chaosdynasty@hotmail.com>
Date: Thu, 26 Feb 2004 09:59:39 GMT
Links: << >>  << T >>  << A >>
"is it true that one-hot encoding for FSM's is used in FPGA's? If so,
why? is it due to the large amount of registers available i.e: enough
registers to store all states? "

Yep!


"Avinash Sharma" <asharma3@REMOVETHIS.uiuc.edu.NOSPAM> wrote in message
news:c1k4qp$sq7$1@news.ks.uiuc.edu...
> is it true that one-hot encoding for FSM's is used in FPGA's? If so,
> why? is it due to the large amount of registers available i.e: enough
> registers to store all states? what kind of encoding is using in ASIC's?
>
> thanks much
> --
> avi
>
>



Article: 66748
Subject: Re: Altera ACEX chip wide reset
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 26 Feb 2004 10:01:19 +0000
Links: << >>  << T >>  << A >>
gregs@altera.com (Greg Steinke) writes:

> Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uishvxwee.fsf@trw.com>...
> > gregs@altera.com (Greg Steinke) writes:
> > <snip>
> > > Rick,
> > > 
> > > When the ACEX device is initialized after configuration, or when you
> > > assert the Chip Wide Reset, the FFs are all set to 0. There are two
> > > ways of achieving your goal of having an FF power up to 1.
> > > 
> > > 1. You can code the VHDL so that you end up with a NOT gate before the
> > > D of the FF, and another NOT gate after the Q of the FF. Any logic
> > > that the FF drives would actually be driven by the NOT gate in the
> > > HDL. When the FF powers up at 0, it will appear as 1 by the rest of
> > > the logic. But in normal operation, the double-negation will have no
> > > effect. You'll have to be careful with simulation however, since the
> > > FF's value will be the opposite of what you expect. This works in
> > > MAX+PLUS II or Quartus II as it's simply an HDL code.
> > > 
> > 
> > IIRC the 10K, on which the 1K is based, cannot do a preset without NOT
> > gates anyway, irrespective of whether it's a chip-side reset, or not.
> > If you write an aync reset clause that initialises something to a '1',
> > Synplify (at least) will put the appropriate NOT gates in for you.
> > Which will then hammer your tco for any pins you want to default to a
> > '1' - like ooh, maybe a chip-select....  Not that I bear the scars or
> > anything :-)
> 
<snip>
> Martin,
> The ACEX 1K (and FLEX 10K) LE has an async clear and an async load. An
> async preset could be implemented by the NOT technique or by using the
> async load. A design that uses just the preset will generally end up
> using the NOT technique, whereas a design that uses a preset and a
> clear will use the async load technique.
> 

True - my memory was only of the IOEs.  However, if you want a preset,
you have to sacrifice DATA3 in the LUT according to my datasheet (as
implicated by the use of the term "load" rather than "preset").  I
knew I'd recalled something about presets not being quite as "free" as
resets :-)

> The IO Element has a programmable inversion in it to accomodate the
> NOT technique. So for example if an LE register drives a pin, and the
> design calls for the register to be async preset, the compiler will
> use the NOT technique and implement the after-register NOT in the IOE.
> However, the best tCO is obtained by using the IOE register, and the
> programmable inversion is before the D of the IOE register. So there
> is no way to implement an async preset in the IOE, which is probably
> the reason for the tCO pushout that you saw - the register was moved
> into an LE which increases tCO.
> 
> If you see a design where an async-preset LE drives a pin, and there's
> an extra LE put into the path to implement the NOT gate, this is a bug
> and should be reported to Altera and/or Synplicity. But I'll bet that
> the tCO pushout is due to the register moving from the IOE to the LE.
> 

Yes, that is what was happening - it was a while ago, I remember now!
What happens to the power-up (not reset) behaviour?  Does it still
power up low until the reset occurs?

> You will be happy to know that we have enhanced the IOE registers of
> the Stratix and Cyclone FPGAs. In these devices, you can choose to
> have an async clear or async preset on an IOE. This is selectable per
> IOE. Furthermore, an IOE register that uses the async preset will
> power up high. Perfect for your active-low chip select.
> 

Good stuff!

> > 
> > > 2. Quartus II has an ACF setting called "POWER_UP_LEVEL". You can set
> > > this to HIGH or LOW for an individual register. You can apply this
> > > setting using the Assignment Editor or in the HDL using the
> > > "altera_attribute" syntax. Here's an example:
> > > 
> > > signal my_reg : std_logic
> > > attribute altera_attribute : string;
> > > attribute altera_attribute of my_reg : signal is
> > > "POWER_UP_LEVEL=HIGH";
> > > 
> > > Either approach works - just depends on whether you would rather
> > > modify the HDL or change assignments.
> > > 
> > 
> > 
> > I assume this only affects the configuration bitstream, not how the
> > chip-wide reset behaves?  Or have I misunderstood the chip-wide reset?
> > 
> > Cheers,
> > Martin
> For the second question -
> In ACEX 1K FPGAs, on the silicon level, the chip-wide reset sets all
> the registers to zero. The NOT technique that I proposed simply
> modifies the LUT that feeds the register, and the LUTs that the
> register feeds, to add the NOT gates. (Through the configuration
> bitstream as you suggest.) If you were to microprobe the register, you
> would see it go low when chip-wide reset is asserted. But every case
> where that register is used now would have a NOT gate, so it would
> seem to go high.
> 

OK, that's clear enough (although Figure 12 of the datasheet implies
that chip-wide reset *can* do a preset of the FF)

But does the POWER_UP_LEVEL technique infer NOT gates as in solution
1), or do you get a '1' on power up and then a '0' on chip-wide reset?

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 66749
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Kevin Brace <k0evinbr1ace@m2ail.c3om>
Date: Thu, 26 Feb 2004 04:04:13 -0600
Links: << >>  << T >>  << A >>
        The $100 PCI IP core license is intended for hobbyists, FPGA
enthusiasts, Verilog learners, and students who want to make their own
PCI device for personal use.
I believe there are potentially several hundred people in the US who are
willing to pay $100 for the license.
It is my perception that people who do research can probably pay more
than a personal user, so I feel like I should charge more for a license
than a personal user.
If cost is that much of an issue, ask Xilinx because I read in this
newsgroup while back that they do sometimes donate their PCI IP core to
educational institutions.
I just don't intend to compete with a free one.


Kevin Brace



Rainer Buchty wrote:
> 
> In article <c1kbg6$t67$3@newsreader.mailgate.org>,
> 
> Let me get this straight. The use should be
> 
>         - non-commercial
>         - non-profit
>         - non-academic research
>         - strictly personal purposes
> 
> So who the hell should license that core? I can understand that you rule out
> commercial use, I *could* understand if you ruled out industrial research.
> 
> But ruling out academic research because you want to charge *more* from
> universities is reducing the number of potential customers pretty much to
> zero.
> 
> Rainer



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