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 66700

Article: 66700
Subject: Re: SRAM bidirectional bus
From: Bassman59a@yahoo.com (Andy Peters)
Date: 25 Feb 2004 09:33:18 -0800
Links: << >>  << T >>  << A >>
Michael Schöberl <MSchoeberl@ratnet.stw.uni-erlangen.de> wrote in message news:<c1g6sr$1imo9d$1@ID-40811.news.uni-berlin.de>...
> > How can I connect l_sram_data_out and l_sram_data_in 
> > in a appropriate way to the bidirectional bus? 
> 
> My goal was to make Xilinx ISE use all the FF in the io-blocks ... 
> one ff for data_in, for the tristate-buffer and for data_out
> 
> the following has to be placed in the toplevel and was the 
> only way to make ISE do what I wanted ... 
> 
> (Options: keep_hierarchy=true, use io-buffers=all/auto... can't 
> remember)
> 
> 
> 
> if clk'event and clk = 1 then
>     l_sram_data_in <= Sram_data;
> 
>     if OE_bar = '1' then
>         Sram_data <= l_sram_data_out;
>     else
>         Sram_data <= (OTHERS => 'Z');
>     end if;
> end if;
> 
> 
> yes ... this produces latency ... but its synchronous

That works?  The synthesis tool doesn't choke on the (others => 'Z')?

The usual way to do it is (sorry for Verilog here, also assume active
HIGH output enable):

    assign Sram_data = OE ? l_sram_data_out : 'hz;

-a

Article: 66701
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: "Jim" <jim@nospam.com>
Date: Wed, 25 Feb 2004 17:35:55 -0000
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> wrote in message
news:c1ik9m$72t1@cliff.xsj.xilinx.com...
> Jim,
>
> You are welcome.
>
> Audio is all snake oil, so I have to agree that you need to have a good
> story, backed up by some great data, or else the snake oil will taste
> all wrong....
>
> It is amazing how sensitive the ear-brain is.  Jitter on audio, delay of
> audio can easily be discerned.
>
> For example, if you play mp3 files on a computer, any time the song is
> affected by a more important interrupt (whoch may only cause a very tiny
> time delay of the program material) my brain screams: ARTIFACT!!!!
>
> Gallileo timed his experiments (like the dropping of objects from a
> building) by singing a song which had 32nd notes.  He was able to
> measure differences in arrival times of 1/64 seconds by ear, and time
> intervals of about 5 to 10 seconds to an accuracy of 1/32 of a second.
>
> Not bad for just some "wetware."
>
> Austin
>
<snip>

That's a great tale, Austin!

As an aside, in the UK/Europe a movie on a DVD plays at 4% over the speed it
was recorded (due to the 25 frames per second playback compared with the 24
fps film rate). The audio is therefore 4% sharper, I understand. Most people
(including myself) don't notice this, but for those who are tonally acute it
makes the listening experience less than ideal.

Jim



Article: 66702
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: "Jim" <jim@nospam.com>
Date: Wed, 25 Feb 2004 17:55:53 -0000
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message
news:403CD7E4.C2A23732@andraka.com...
> I suspect as long as you adhere to good design practices (proper
bypassing,
> good clock crystal, proper power supplies and distribution), that your
jitter
> is going to be well under what would affect audio.  How much jitter is too
> much?
>
<snip>

Hi Ray,

Thanks for the advice. We will try to follow good design practices as you
say.

From what I have gleaned from the web, 300ps or so of jitter will have no
effect on a SPDIF signal with a 48kHz sample rate (serial bit rate of
6.144MHz). However, there are "dejitter" boxes around that advertise 75ps or
better (and sell for $$$$!) To me this sounds OTT, since I understand that
the PLL in the receiver IC of the amplifier will change the jitter (for
better or worse) anyway, regardless of the jitter on the incoming signal.

FWIW our product is not being sold to reduce jitter but since it reclocks
the data we need some understanding of its effect on the bitstream. We were
hoping to quote 200ps, since that is the typical jitter from the clock we
are using, and it seems to be recognised as an acceptable level for most
applications. I can now see that to find out what it actual is would not be
so easy.

Jim



Article: 66703
Subject: Modular Design in WebPack
From: "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com>
Date: Wed, 25 Feb 2004 20:51:29 +0200
Links: << >>  << T >>  << A >>
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: 66704
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Taavi Hein <hein@bps.co.ee>
Date: Wed, 25 Feb 2004 21:26:36 +0200
Links: << >>  << T >>  << A >>
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.

>> * The licensee is will agree, sign, and mail back to a license agreement
>> form I will provide.

I could live with that restriction.

>> * The licensee will pay for the PCI IP core license through an online
>> payment source like PayPal.

I almost could live with that restriction as well, although would prefer 
direct credit card payment, as PayPal doesn't think my country worthy 
enough to be able to subscribe.

>> * The licensee resides within the United States (Don't have to be a US
>> citizen.).

That requirement I find offensive. There is life outside US as well. There 
might even be developers that don't reside in US.

>         That's because the licensee is paying only $100.
> If the licensee is willing to pay much more than that, that person can
> use my PCI IP core in a commercial project.

It's not the commercial project requirement that's unreasonable, as you 
can see from above.

PS. Sorry if I was too sarcastic, I couldn't help it.

-- 
Taavi Hein,
developer residing outside US.

Article: 66705
Subject: Re: SRAM bidirectional bus
From: =?iso-8859-1?Q?Michael_Sch=F6berl?= <MSchoeberl@ratnet.stw.uni-erlangen.de>
Date: Wed, 25 Feb 2004 20:33:39 +0100
Links: << >>  << T >>  << A >>
> That works?  The synthesis tool doesn't choke on the (others => 'Z')?

well - yes ... 
there are a few things I should have mentioned:
- Im using Xilinx fpgas with ISE and XST. 
- The signals are all std_logic_vector and Sram_data 
should be std_logic_vector with INOUT
- (others => 'Z') is only a vhdl shortcut for "ZZZZZZZZZZZZ"

> The usual way to do it is (sorry for Verilog here, also assume active
> HIGH output enable):
> 
>     assign Sram_data = OE ? l_sram_data_out : 'hz;

this looks similar to 
Sram_data <= l_sram_data_out WHEN OE_bar = '1' ELSE (OTHERS => 'Z');

if you allow FFs to be placed in io-blocks then XST puts the
data-FFs in the iob ...
but if you take a close look at xilinx fpgas then you can see 
another FF for controlling the Tristate-Buffer ... the only way 
(I know) to make XST use this FF was the above description ...


bye,
Michael


Article: 66706
Subject: Re: SmartMedia writer (implments using VHDL)....
From: "Antti Lukats" <antti@case2000.com>
Date: Wed, 25 Feb 2004 11:38:01 -0800
Links: << >>  << T >>  << A >>
> 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



Article: 66707
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 25 Feb 2004 19:44:50 GMT
Links: << >>  << T >>  << A >>
On Wed, 25 Feb 2004 13:06:30 -0000, "Jim" <jim@nospam.com> wrote:
>This is my first design using programmable logic, so apologies if this
>question can be found in the datasheet or timing report - I don't know quite
>what I'm looking for.
>
>We have a Xilinx XC9572XL (10ns) being driven by either a 12.288MHz or a
>6.144MHz clock on the GCK pin. The clock has max jitter 200ps. The CPLD
>output is a single flip-flop using this clock, driving a 74HC04 gate (for
>buffering).
>
>Is there a way of determining the maximum jitter of the output from the
>CPLD? It's for digital audio so this info would be very useful.
>
>Many thanks,
>
>Jim

As your signal moves through each stage of your design, each net and
gate can contribute some jitter. I suspect that the combined jitter
probably has a distribution related to the square root of the sum of
the squares of the separate jitter components. The peak may be as high
as the sum of the non mutually exclusive jitter components.

Since you are reclocking your data on the output of the CPLD, all the
stuff going on inside the CPLD is probably irrelevant, except for its
noise contribution to the Tco of the final flip flop. This is because
the clock has to come into the CPLD (input level sense is modified by
on chip noise), has to traverse the CPLD (unknown number of rebuffering
stages, each with level sense modified by the on-chip noise), and then
the output flip flop has to use this clock. Clearly the jitter can be
no less than the initial 200ps of your clock, but could be more. I have
no supportable idea of how much "more" means. If I was a guessing dude,
and rather pessimistic, maybe 200ps to 400ps of additional jitter?

Jitter can be attenuated by using a PLL on the clock, but it has to be
a PLL designed specifically for jitter attenuation.

If your goal was to have sub 200ps final jitter, I would suggest
researching a structure such as:

Take the output of the CPLD and run it through a single FF outside the
CPLD, such as a NL17SZ74US .

Use extraordinary efforts for isolation from noise, such as sepparate
local low noise LDO regulator with local bypassing for its power supply
and appropriate issolation from ground noise of the rest of the system.

Take your clock and pass it through a jitter attenuation PLL, with
similar care with power supply and grounds. Use this (improved) clock
for this external retiming flip flop.

Measuring actual jitter parameters is non-trivial. There are some
outrageously expensive scopes and analyzers available that are designed
specifically for these types of measurements. Normal (very fast) scopes
can be used, but they can contribute significantly to the measured
jitter because of their inherent jitter in their trigger circuit and
their horizontal time base oscillator. An alternative is to use a
spectrum analyzer. With enough math, you can turn the results into
jitter numbers, for some but not all jitter parameters.

Good luck,

Philip


Philip Freidin
Fliptronics

Article: 66708
Subject: Re: Altera ACEX chip wide reset
From: gregs@altera.com (Greg Steinke)
Date: 25 Feb 2004 11:45:43 -0800
Links: << >>  << T >>  << A >>
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 :-)
> 
> > 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

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.

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.

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.

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.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

Article: 66709
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: "Jim" <jim@nospam.com>
Date: Wed, 25 Feb 2004 20:52:12 -0000
Links: << >>  << T >>  << A >>
"Philip Freidin" <philip@fliptronics.com> wrote in message
news:10tp309nnr65be5n29ei4q30sdf7s93p84@4ax.com...
<snip>
> If your goal was to have sub 200ps final jitter, I would suggest
> researching a structure such as:
>
> Take the output of the CPLD and run it through a single FF outside the
> CPLD, such as a NL17SZ74US .
>
> Use extraordinary efforts for isolation from noise, such as sepparate
> local low noise LDO regulator with local bypassing for its power supply
> and appropriate issolation from ground noise of the rest of the system.
>
> Take your clock and pass it through a jitter attenuation PLL, with
> similar care with power supply and grounds. Use this (improved) clock
> for this external retiming flip flop.
>
> Measuring actual jitter parameters is non-trivial. There are some
> outrageously expensive scopes and analyzers available that are designed
> specifically for these types of measurements. Normal (very fast) scopes
> can be used, but they can contribute significantly to the measured
> jitter because of their inherent jitter in their trigger circuit and
> their horizontal time base oscillator. An alternative is to use a
> spectrum analyzer. With enough math, you can turn the results into
> jitter numbers, for some but not all jitter parameters.
>
> Good luck,
>
> Philip
>
>
> Philip Freidin
> Fliptronics

Thank you Philip for your very thorough reply. I can see that minimizing
jitter and measuring jitter are deep subjects in themselves. Your ideas seem
very sensible and I would love to try out that route. TBH, I don't have the
time or knowledge to pursue it as much as maybe it deserves. Since our
product is not being sold to reduce jitter, I am hoping that by keeping it
simple and using good design pratices the jitter will be within acceptable
limits - I've just seen some audio magazine "lab" reports on various DVD
players, and they seem to go up to 500ps (with an average of about 350ps).

FYI our clock is the PLL in a Cirrus Logic CS8416 digital audio receiver IC,
with a max jitter of 200ps. We use that as it needs to handle the various
frequencies associated with digital audio. I don't know if anyone uses it to
de-jitter audio signals.

As long as our product does not make the jitter unacceptable we are going to
probably have to go with that - it's a low price product. The prototype
"sounds" fine to me(!), i.e. it sounds no different to when the product is
not there. I haven't done any jitter measurements on it, and unfortunately I
don't think my scope, or I, are up to it.

Jim




Article: 66710
Subject: Re: Dual-stack (Forth) processors
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 25 Feb 2004 20:54:02 GMT
Links: << >>  << T >>  << A >>
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.


> My goals for asking about DSP and Forth processors:
>
> I'm teaching myself digital design and DSP.
<SNIP>
> My first substantial FPGA project was a minimal instruction set 16-bit
Forth
> processor.  It simulates at 90+ MIPS in a small Altera Cyclone part.  It
uses about 800 LEs.
<SNIP>
> state-of-the-art synthesis, using physical modeling of instruments.
<SNIP>
> liked to build/buy some hardware to experiment with at home, but the cost
> 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).

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?

Sounds like you are going to have some fun.



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 66711
Subject: difference btw H/W & S/W implementations !!
From: omnipresent@hotmail.com (OP)
Date: 25 Feb 2004 13:09:41 -0800
Links: << >>  << T >>  << A >>
Hi,

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.  

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??

all the help is appreciated.

OP.

Article: 66712
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 26 Feb 2004 10:16:19 +1300
Links: << >>  << T >>  << A >>
Jim wrote:
> This is my first design using programmable logic, so apologies if this
> question can be found in the datasheet or timing report - I don't know quite
> what I'm looking for.
> 
> We have a Xilinx XC9572XL (10ns) being driven by either a 12.288MHz or a
> 6.144MHz clock on the GCK pin. The clock has max jitter 200ps. The CPLD
> output is a single flip-flop using this clock, driving a 74HC04 gate (for
> buffering).
> 
> Is there a way of determining the maximum jitter of the output from the
> CPLD? It's for digital audio so this info would be very useful.

  You can get a feel for jitter, and what matters, by doing some 
slew/threshold calculations.
  eg consider a clock signal slewing at 1Volt/ns, and apply 10mv of 
threshold noise ( combined effects of Vcc noise ,Gnd bounce and 
crosstalk ) then purely the threshold modulation gives 10ps of jitter.
  So, in CMOS a clean (linear) low noise power supply will help,
as will short, shielded traces for Osc module -> PLD.
  Faster edges from the Osc module will help (if you get the choice),
and keeping any async, or random content signals 'away' from the clock
divider portion of the PLD.
  If you have a PLD+HC04, doing only /2, you could consider a HC1G79
which is a tiny logic FF, to do both jobs. With NO other signals,
and very low power, as well as a tiny package, this should have the
lowest possible jitter.

  In Audio, I believe jitter affects absolute noise floors, so you could
look for that effect.
  At 48KHz that's ~20us, so 20ns jitter is -60dB, and 20ps jitter
is -120dB (numeric ratio only) - so it's not entirely snake
oil, jitter numbers well under 1ns could have a measurable (if not 
audible:) impact.

  For some real values quoted by process, see OnSemi's TND301
http://www.onsemi.com/pub/Collateral/TND301-D.PDF

-jg


Article: 66713
Subject: How would you...
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 25 Feb 2004 22:28:57 +0100
Links: << >>  << T >>  << A >>
... solve the following?

A Xilinx DCM generates clk and clk2x For each coinciding edge there
should be generated a clock enable for the higher freq. clock (which
is a toggle FF with the right phase)

Which solution have you used?

Homann
-- 
Magnus Homann, M.Sc. CS & E
homann@homann_REM_.se


Article: 66714
Subject: Re: difference btw H/W & S/W implementations !!
From: Vadim Borshchev <vadim.borshchev@127.0.0.1>
Date: Wed, 25 Feb 2004 21:29:48 -0000
Links: << >>  << T >>  << A >>
On 25 Feb 2004 13:09:41 -0800, OP <omnipresent@hotmail.com> wrote:

> Hi,
>
> Feeling really intelligent today.. I would like to know some basic
> stuff..


> NNTP-Posting-Host: 128.193.4.98

~/cvs> whois 128.193.4.98

OrgName:    Oregon State University
OrgID:      OSU-3
Address:    Network Services
Address:    Milne Hall 217
City:       Corvallis
StateProv:  OR
PostalCode: 97331
Country:    US


Why not walk into the uni library and get yourself a book?  (Feeling 
really smart pants today ...)

Article: 66715
Subject: ARM+FPGA tiny board
From: pablobleyer@hotmail.com (Pablo Bleyer Kocik)
Date: 25 Feb 2004 13:32:40 -0800
Links: << >>  << T >>  << A >>
Well, thank you very much for all the people who shared their ideas
and suggestions about our board in our previous post. Production is on
its way now, development continues swiftly and, as many of you already
know, the site ARMoid (http://ARMoid.com) is being set up to
commercialize our new product line.

 Thanks again. Warmest regards!

--
PabloBleyerKocik /
 pbleyer        /"Simplicity is prerequisite for reliability."
  @embedded.cl / -- Edsger Wybe Dijkstra

Article: 66716
Subject: Re: How would you...
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Wed, 25 Feb 2004 22:09:34 GMT
Links: << >>  << T >>  << A >>
That is a great question.  It seems to me that the DCM really needs an
output, in the clk2x domain, that tells you which cycles are aligned with
the 1x clock.  It's very often that I have to transfer data from the 1x
domain to the 2x domain and then it's very useful to know this so I can
maximize setup time.

The way I do it is to have a 'T' flop (that toggles every cycle) in the 1x
clock domain.  This gets sampled in the 2x domain, and an edge detector in
the fast domain determines which 2x cycles are aligned with the 1x cycles.

-Kevin

"Magnus Homann" <d0asta@licia.dtek.chalmers.se> wrote in message
news:ltptc2svae.fsf@licia.dtek.chalmers.se...
> ... solve the following?
>
> A Xilinx DCM generates clk and clk2x For each coinciding edge there
> should be generated a clock enable for the higher freq. clock (which
> is a toggle FF with the right phase)
>
> Which solution have you used?
>
> Homann
> --
> Magnus Homann, M.Sc. CS & E
> homann@homann_REM_.se
>



Article: 66717
Subject: Re: difference btw H/W & S/W implementations !!
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Wed, 25 Feb 2004 22:13:26 GMT
Links: << >>  << T >>  << A >>
Everything is essentially done in hardware.  A processor is hardware.  I
guess the main difference is when you build the hardware for a less general
application.  Generally, the hardware implementation will be more parallel
to make it faster.  The more parallelism, the more hardware you need, and
the faster the operation.
-Kevin

"OP" <omnipresent@hotmail.com> wrote in message
news:a0539759.0402251309.55f0ebaa@posting.google.com...
> Hi,
>
> 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.
>
> 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??
>
> all the help is appreciated.
>
> OP.



Article: 66718
Subject: Re: difference btw H/W & S/W implementations !!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 25 Feb 2004 22:44:26 GMT
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> Everything is essentially done in hardware.  A processor is hardware.  I
> guess the main difference is when you build the hardware for a less general
> application.  Generally, the hardware implementation will be more parallel
> to make it faster.  The more parallelism, the more hardware you need, and
> the faster the operation.

Except if it is microcoded, then it is software even though
it looks like hardware.  You can never be too sure.
It could still be faster than non-microcoded versions, too!

-- glen


Article: 66719
Subject: Re: difference btw H/W & S/W implementations !!
From: Rene Tschaggelar <none@none.net>
Date: Wed, 25 Feb 2004 23:51:08 +0100
Links: << >>  << T >>  << A >>
OP wrote:
> Hi,
> 
> 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.  
> 
> 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??

Hardware implementations tend to be faster because the parallelize
the work to be done.
As example take a multiplication. It can be done in software by
shift & add or with a hardware multiplier which does if required
the lot in one clock cycle.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 66720
Subject: Re: $100 for Americans PCI-bridge in NGO netlist for Spartan-IIE (Was: Free ... VHDL)
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Date: Wed, 25 Feb 2004 22:59:51 GMT
Links: << >>  << T >>  << A >>
Kevin Brace wrote:

> My guess is that there are probably a few hundred people in the United
> States who will rather license a PCI IP core with testbench for $100
> than to do their own or use Opencores.org PCI IP core.
> 

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: 66721
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: Wed, 25 Feb 2004 23:23:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
Kevin Brace <kev0inb1rac2e@m3ail.c4om> wrote:
> 
>         That's because the licensee is paying only $100.
> If the licensee is willing to pay much more than that, that person can
> use my PCI IP core in a commercial project.
> 

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.

> 
> Kevin Brace

-- 
	Sander

+++ Out of cheese error +++

Article: 66722
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: Wed, 25 Feb 2004 23:32:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
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: 66723
Subject: Re: difference btw H/W & S/W implementations !!
From: Andrew Reilly <andrew@gurney.reilly.home>
Date: Wed, 25 Feb 2004 23:39:28 GMT
Links: << >>  << T >>  << A >>
On 25 Feb 2004 13:09:41 -0800, OP wrote:
> What is the difference between a hardware implementation of an
> algorithm and a software one.  

It's all hardware.  If it's not hardware, it's not doing
anything (see question below).

> 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??

The faster one is the one that takes less time to do whatever
it was that you wanted done.  This involves actually doing
the thing in question.  Only hardware actually does stuff,
therefore, ipso facto, hardware is faster.

As my Dad used to say: as fast as ten thousand gazebos.

-- 
Andrew

Article: 66724
Subject: Re: Usage of Xilinx Library elements in ModelSim simulation
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Wed, 25 Feb 2004 18:21:03 -0700
Links: << >>  << T >>  << A >>

Jürgen,

     Which version of the Xilinx tools are you using?  The 
xilinx_lib_4.tcl was written for ISE version 4.1i and should not be used 
with newer versions of the tools.  If you are using version 5.1i or 
newer, you should be using the installed tool, compxlib in order to 
compile the simulation libraries.  For information on compxlib either 
just type compxlib at the command prompt or look at the Synthesis and 
Verification Design Guide at: 
http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf.  If you 
are using 6.1i or newer, this can also be done within Xilinx Project 
Navigator.  Search the on-line help for "simulation library compile" for 
instructions.

If that doesn't help, let me know which version of ISE you are using and 
I might be able to figure out the problem.

--  Brian

J?rgen wrote:
> I like to simulate our design by using Xilinx library elements
> (RAMB16_s4_s4) with ModelSim SE plus 5.7d (on PC). While using the
> downloaded xilinx_lib_4.tcl file I obtain the following error
> messages:
> 
> # Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 10 2003
> # -- Loading package standard
> # -- Loading package std_logic_1164
> # -- Loading package vital_timing
> # -- Loading package vital_primitives
> # -- Loading package textio
> # -- Compiling package vpackage
> # -- Compiling package body vpackage
> # -- Loading package vpackage
> # Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 10 2003
> # -- Loading package standard
> # -- Loading package std_logic_1164
> # -- Loading package vital_timing
> # -- Compiling package vcomponents
> # Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 10 2003
> # -- Loading package standard
> # -- Loading package std_logic_1164
> # -- Loading package std_logic_arith
> # -- Loading package std_logic_unsigned
> # -- Loading package vital_timing
> # -- Loading package vital_primitives
> # -- Loading package textio
> # -- Loading package vpackage
> # -- Compiling entity x_and16
> # -- Compiling architecture x_and16_v of x_and16
> # -- Compiling entity x_and2
> # -- Compiling architecture x_and2_v of x_and2
> # -- Compiling entity x_and3
> # -- Compiling architecture x_and3_v of x_and3
> # -- Compiling entity x_and32
> # -- Compiling architecture x_and32_v of x_and32
> # -- Compiling entity x_and4
> # -- Compiling architecture x_and4_v of x_and4
> # -- Compiling entity x_and5
> # -- Compiling architecture x_and5_v of x_and5
> # -- Compiling entity x_and6
> # -- Compiling architecture x_and6_v of x_and6
> # -- Compiling entity x_and7
> # -- Compiling architecture x_and7_v of x_and7
> # -- Compiling entity x_and8
> # -- Compiling architecture x_and8_v of x_and8
> # -- Compiling entity x_and9
> # -- Compiling architecture x_and9_v of x_and9
> # -- Compiling entity x_bpad
> # -- Compiling architecture x_bpad_v of x_bpad
> # -- Compiling entity x_buf
> # -- Compiling architecture x_buf_v of x_buf
> # -- Compiling entity x_buf_pp
> # -- Compiling architecture x_buf_pp_v of x_buf_pp
> # -- Compiling entity x_bufgmux
> # -- Compiling architecture x_bufgmux_v of x_bufgmux
> # -- Compiling entity x_bufgmux_1
> # -- Compiling architecture x_bufgmux_1_v of x_bufgmux_1
> # -- Compiling entity x_ckbuf
> # -- Compiling architecture x_ckbuf_v of x_ckbuf
> # -- Compiling entity x_clkdll_maximum_period_check
> # -- Compiling architecture x_clkdll_maximum_period_check_v of 
> x_clkdll_maximum_period_check
> # -- Compiling entity x_clkdll
> # -- Compiling architecture x_clkdll_v of x_clkdll
> # -- Loading entity x_clkdll_maximum_period_check
> # -- Compiling entity x_clkdlle_maximum_period_check
> # -- Compiling architecture x_clkdlle_maximum_period_check_v of 
> x_clkdlle_maximum_period_check
> # -- Compiling entity x_clkdlle
> # -- Compiling architecture x_clkdlle_v of x_clkdlle
> # -- Loading entity x_clkdlle_maximum_period_check
> # -- Compiling entity dcm_clock_divide_by_2
> # -- Compiling architecture dcm_clock_divide_by_2_v of
> dcm_clock_divide_by_2
> # -- Compiling entity dcm_maximum_period_check
> # -- Compiling architecture dcm_maximum_period_check_v of 
> dcm_maximum_period_check
> # -- Compiling entity dcm_clock_lost
> # -- Compiling architecture dcm_clock_lost_v of dcm_clock_lost
> # -- Compiling entity x_dcm
> # -- Compiling architecture x_dcm_v of x_dcm
> # -- Loading entity dcm_clock_divide_by_2
> # -- Loading entity dcm_maximum_period_check
> # -- Loading entity dcm_clock_lost
> # -- Compiling entity x_fddrcpe
> # -- Compiling architecture x_fddrcpe_v of x_fddrcpe
> # -- Compiling entity x_fddrrse
> # -- Compiling architecture x_fddrrse_v of x_fddrrse
> # -- Compiling entity x_ff
> # -- Compiling architecture x_ff_v of x_ff
> # -- Compiling entity x_ibufds
> # -- Compiling architecture x_ibufds_v of x_ibufds
> # -- Compiling entity x_inv
> # -- Compiling architecture x_inv_v of x_inv
> # -- Compiling entity x_ipad
> # -- Compiling architecture x_ipad_v of x_ipad
> # -- Compiling entity x_keeper
> # -- Compiling architecture x_keeper_v of x_keeper
> # -- Compiling entity x_latch
> # -- Compiling architecture x_latch_v of x_latch
> # -- Compiling entity x_latche
> # -- Compiling architecture x_latche_v of x_latche
> # -- Compiling entity x_lut2
> # -- Compiling architecture x_lut2_v of x_lut2
> # -- Compiling entity x_lut3
> # -- Compiling architecture x_lut3_v of x_lut3
> # -- Compiling entity x_lut4
> # -- Compiling architecture x_lut4_v of x_lut4
> # -- Compiling entity x_lut5
> # -- Compiling architecture x_lut5_v of x_lut5
> # -- Compiling entity x_lut6
> # -- Compiling architecture x_lut6_v of x_lut6
> # -- Compiling entity x_lut7
> # -- Compiling architecture x_lut7_v of x_lut7
> # -- Compiling entity x_lut8
> # -- Compiling architecture x_lut8_v of x_lut8
> # -- Compiling entity x_mult18x18
> # -- Compiling architecture x_mult18x18_v of x_mult18x18
> # -- Compiling entity x_mult18x18s
> # ** Error: 
> C:/Programme/FPGAdv61/Modeltech/xilinx/vhdl/unisim/ramb4_s16_s16/vhdl/src/simpri
> ms/simprim_VITAL.vhd(9368): VITAL TISD timing generic must be a scalar
> form of
> VITAL 
> # delay type
> # (1076.4 section 4.3.2.1.3.13)
> # ** Error: 
> C:/Programme/FPGAdv61/Modeltech/xilinx/vhdl/unisim/ramb4_s16_s16/vhdl/src/simpri
> ms/simprim_VITAL.vhd(9369): VITAL TISD timing generic must be a scalar
> form of
> VITAL 
> # delay type
> # (1076.4 section 4.3.2.1.3.13)
> # ** Error: 
> C:/Programme/FPGAdv61/Modeltech/xilinx/vhdl/unisim/ramb4_s16_s16/vhdl/src/simpri
> ms/simprim_VITAL.vhd(9391): VHDL Compiler exiting
> 
> What can I do/where can I obtain already compiled Xilinx library
> elements for simulation ?
> 
> Jürgen




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