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

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

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

Custom Search

Messages from 66675

Article: 66675
Subject: Re: SmartMedia writer (implments using VHDL)....
From: "Kelvin" <kelvin8157@hotmail.com>
Date: Wed, 25 Feb 2004 16:10:40 +0800
Links: << >>  << T >>  << A >>
you idea is quite interesting...last time i had an idea of writing some
codes to R/W FAT file systems as
this will make life easier I can read it in Windows directly. of course, i
have only one file on this card...
of course I never did it...:(

MMC/SD is easier in terms of hardware...as there is only three active
wires...saves a lot of soldering time.
i guess u can write to individual addresses in the memory array at a time
via serial interface...SM requires
writing one sector at a time...

I don't know what disk dump does...in my mind, unix is something in the
server room I can Exceed across
but never know it can handle flash disks...

Correct me if I am wrong.

Kelvin




<someone@somedomain.com.invalid> wrote in message
news:uPV_b.595937$JQ1.75324@pd7tw1no...
> Hi, I'm undergrad working on project that invovles data transfering from a
PCB to computer using removable media.
>
> I had been studying the smartMedia format for some time now. I think I can
write a custom VHDL firmware that will work on one type of SmartMedia
card(8mb)
> 1. write the serial input command to the command latch
> 2. sets up the col and row address to the address register(starting from
the very first byte of the first block of the first page)
> 3. left the program in a waiting state
> 4. once the write enable signal is triggered, output the actual data(ascii
decimal) to the card
> 5. once the write enable signal is dropped, terminate the writing action
> 6. now that the raw data is in the chip, I use the unix utility dd (disk
dump) to convert this raw data to an ascii file...
>
> I know that the SSFDC forum has the full functional firmware for free, but
I don't want to use it since we do not all the *junk features, like the ECC
and power code.
> I don't even have a proper smartmedia card connector. I'm just going to
connect 22 wires to the card...
>
> I will be using Xilinx foundation to implment my design. The PCB is
already set up. Hardware shouldn't be an issue. The clk is definitely fast
enough for smartmedia
>
> 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?
>
> Thanks for any input!
>
>



Article: 66676
Subject: Re: Dual-stack (Forth) processors
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 25 Feb 2004 09:17:00 GMT
Links: << >>  << T >>  << A >>
"Uwe Klo▀" wrote:

> > The other interesting choice today is V2 Pro.
>
> Could you give a link for that?

www.xilinx.com

Look at the Virtex II Pro family of devices.


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

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



Article: 66677
Subject: Re: Why warnings: "Input <xyz> never used???"
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 25 Feb 2004 09:27:19 GMT
Links: << >>  << T >>  << A >>
Chris Carlen wrote:

> I have a module test_delay8 that instantiates a module Delay8Bit, which
> in turn instantiates two further modules, an 8-bit comparator and an
> 8-bit counter, where the counter is inferred from the XST library.
>
> But I get lots of warnings about inputs and signals not used:

<SNIP>

> WARNING:Xst:647 - Input <Delay<7>> is never used.

Chris,

I didn't have time to look at your code.  I'll just offer a couple of
pointers here.

The Xilinx tools will optimize away logic you are not using.  In doing so, a
path that you thought was complete might endup without logic to connect to.
A warning will be issued to let you know.

In general terms, take a look at your design and make sure that every single
signal contributes to physical chip outputs.  That's the key.  If a singnal,
say, the high bit of a counter, doesn't influence an output at all, the
tools will remove that flip-flop and anything else prior to that flip-flop
that does not add anything to the mix.

I soft of doesn't make sense in the context of building out a design, when
you might not have all the blocks ready.  It can be a real pain.  One
approach is to put in dummy blocks that do something with signals you are
not using yet (a large AND function, for example, with the single output
assigned to a pin).


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

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



Article: 66678
Subject: Re: Spartan 3 - avaliable in small quantities?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 25 Feb 2004 09:52:56 -0000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> In my experience, the stumbling block for custom CPUs is not so much
> the hardware as it is the compiler for it.

Jan Gray did an interesting article on this for Circuit Cellar
a few years back, targeting the lcc compiler.  The article
will still be on www.fpgacpu.org



Article: 66679
Subject: Re: Altera ACEX chip wide reset
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 25 Feb 2004 10:53:45 +0000
Links: << >>  << T >>  << A >>
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.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 66680
Subject: Re: Driving INOUT signals
From: Mike Nicklas <michaeln@nospamplease.slayer.com>
Date: Wed, 25 Feb 2004 11:19:26 +0000
Links: << >>  << T >>  << A >>
Hi

tried that too.

No joy unfortunately.

Any other ideas?

Regards

Mike

MM wrote:
> "Mike Nicklas" <michaeln@nospamplease.slayer.com> wrote in message
> news:403b1cd3$0$4101$5a6aecb4@news.aaisp.net.uk...
> 
>>The problem i have is that when i set the value of the INOUT signal in
>>my design, the testbench does not appear to assert it as desired and the
>>port stays at value zero.
> 
> 
> Can it be that you are initializing this signal in the test bench as zero?
> Assuming the signal is std_logic try setting it to 'L' or 'Z' instead.
> 
> 
> /Mikhail


Article: 66681
Subject: Re: SmartMedia writer (implments using VHDL)....
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Wed, 25 Feb 2004 13:18:55 +0100
Links: << >>  << T >>  << A >>
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: 66682
Subject: Re: Experience with Simulating RocketIO in Modelsim
From: Martin Kellermann <martin.kellermann@nospam.xilinx.com>
Date: Wed, 25 Feb 2004 13:59:02 +0100
Links: << >>  << T >>  << A >>
Hi Timothy,

if you really want to punish yourself then you can work with the 
force-commands.

However, if you want to work with the Rocket-IOs properly then the only 
real way is to build a testbench which models your system.

This means:
- create the clock-signals in the testbench
- build a system that lives on itself as far as possible and is not 
dependent on force-commands.

Cheers,

Martin

Timothy Campbell wrote:

> Does anyone have any experience simulating RocketIO in Modelsim SE via 
> use of SmartModels. I am trying to stimulate the TXP and TXN pins of the 
> MGT via use of a .do file. Is there are proper way to do this, or is the 
> following acceptable:
> 
> restart -f
> force RocketIO_10mhz 0 0ns, 1 50ns -repeat 100ns
> run 2us
> run 50ns
> force RXNIn1_Data 1
> force RXPIn1_Data 0
> run 100ns
> force RXNIn1_Data 1
> force RXPIn1_Data 0
> run 100ns
> force RXNIn1_Data 1
> force RXPIn1_Data 0
> run 100ns
> force RXNIn1_Data 0
> force RXPIn1_Data 1
> run 100ns
> force RXNIn1_Data 0
> force RXPIn1_Data 1
> run 100ns
> force RXNIn1_Data 0
> force RXPIn1_Data 1
> run 100ns
> force RXNIn1_Data 1
> force RXPIn1_Data 0
> run 100ns
> force RXNIn1_Data 1
> force RXPIn1_Data 0
> run 100ns
> force RXNIn1_Data 0
> force RXPIn1_Data 1
> run 100ns
> force RXNIn1_Data 1
> force RXPIn1_Data 0
> run 100ns
> 
> p.s. The input clock to the MGT is running at 40Mhz
> 
> Best Regards,
> T. Justin Campbell


Article: 66683
Subject: Re: Dual-stack (Forth) processors
From: "Davka" <mygarbagepail@hotmail.com>
Date: Wed, 25 Feb 2004 06:01:42 -0700
Links: << >>  << T >>  << A >>

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:5vkZb.27977$_76.2895@newssvr25.news.prodigy.com...
> rickman wrote:
> > You had to go and say that, didn't you!  This is being posted to the
> > Forth newsgroup and you will hear a few comments about this...  ;)
>
> I realize that.  No flames please.  I have two decades of Forth
experience.
> I'm from the days when you built your own computer from chips, wrote a
> monitor, got Forth in there, wrote your own editor and then developed your
> apps.  I enjoy and love Forth.  I truly do.  I also love a language called
> APL.  I think it should rule the World.

Heh.  Heheh.

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.

I, too, have been programming in Forth for 20+ years.  I wrote a multi-user
virtual
reality system that used byte-coded Forth to move virtual objects between
hosts
on the Internet.  One of the things that struck me is that's it's less
awkward to write
long floating-point expressions multiplying sine and cosine terms in Forth
than it is in C.  That's
why Forth came to mind as language for designing filters, etc.  Also for
physical modeling
of musical instruments.  It's easy to build up waveguides, etc into function
blocks that can
be strung together on the command line.  *Everything* is better with an
interactive command
prompt.

The scripting language for the virtual reality objects was Forth, but the
Forth interpreter itself was written in
plain-vanilla C for portability.  It ran fast enough (on Pentium 90s with
software-only 3D rendering!)
that the extra work of an assembler implementation wasn't worth it.  I used
Forth exactly where
it made the most sense -- as a platform-independent VM-based object code -- 
and used C in a
way that reflected _its_ strengths.  I chose the languages based on their
technical merits for a particular
application, something I'd like to see more programmers do.

The majority of the coding that I have done, both for pay and for
self-directed projects, has been
in C.  I have been living in the same world of wanting portability,
maintainability and ease of finding programmers.

My goals for asking about DSP and Forth processors:

I'm teaching myself digital design and DSP.

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.

Looking at the Stratix family, I see they're chock-full of optimized
multiply-and-accumulate blocks.  Very nice!
I did a stint at Korg R&D years ago, working on a legendary unreleased synth
(the OASys).  It was my intro
to state-of-the-art synthesis, using physical modeling of instruments.  At
that time, I would have very much
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.

And hardware for separating signals on the ham radio bands.  And hardware to
develop multi-processing
ideas I've been toying with for years.

I'm going to experiment and read all the papers I can get my hands on and
pursue what's interesting, and if
something I do looks like it has better cost/performance than something on
the market, I'll look into commercializing
it.

After I have a project or two that I have physically realized, maybe someone
will give me a job doing FPGA design.

-Davka




Article: 66684
Subject: Basic jitter from a CPLD (XC7500XL)
From: "Jim" <jim@nospam.com>
Date: Wed, 25 Feb 2004 13:06:30 -0000
Links: << >>  << T >>  << A >>
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



Article: 66685
Subject: Re: Using 3.3V compliant FPGA for 5V PCI
From: "Torsten Lauter" <torsten.lauter@opti-x-soft.de>
Date: Wed, 25 Feb 2004 14:37:50 +0100
Links: << >>  << T >>  << A >>
Hello,

read the solution under
http://www.infotech.tu-chemnitz.de/~knoll/vhdl_pci_bridge/

It is also 3,3 and 5V with a Spartan-IIE.

"Nicky" <Miaz371240@austromail.at> schrieb im Newsbeitrag
news:c7068a2e.0402180404.71afeaa@posting.google.com...
> Hello,
>
> I have to design a universal PCI card according to PCI spec 2.2 with
> 33Mhz and 32 pins. However for several reasons I have to use a FPGA
> that is not 5V but only 3.3V tolerant. Since nearly all motherboards
> just offer 5V slots I have to make this card somehow 5V compliant. I
> thought of using a quickswith from IDT. Is this a good idea? What are
> the things I have to take care of when using this method? Are there
> any other ways to make my card 5V compliant?
>
> thanks+regards,
> Nicky



Article: 66686
Subject: PC parallel port interface and configuration sources for free
From: "Peter Seng" <NOSPAM@seng.de>
Date: Wed, 25 Feb 2004 14:47:38 +0100
Links: << >>  << T >>  << A >>
┤dlk┤ sources available for free now (non-commercial use or evaluation).

The ┤digital logic kernel┤ (┤dlk┤) is an easy applicable system construction
kit for developing FPGA based digital systems. For development and
production of ┤dlk┤ based FPGA systems no programming devices,
pre-programmed or special parts are needed. The system includes a standard
interface to the PC for fast communication and comfortable administration
purposes.

included sources:

+ PC interface (FPGA based, via parallel port, including SPP, PS2 and EPP
mode)
+ JTAG (Xilinx Parallel Cable III, DLC5) emulation in FPGA for CPLD or FPGA
programming
+ CPLD logic for boot process and FPGA configuration from bytewide standard
FLASH memory
+ software for systems administration
+ device driver for Windows operating systems
+ demo board schematic with application examples and MCU software

for description see:
http://www.seng.de/dlk_html

direct link to downloads:
http://www.seng.de/dlk_downloadEnter1_.html

direct link to Xcell Journal, ┤DLK Enables Cost-Effective Design┤:
http://www.xilinx.com/publications/xcellonline/xcell_45/xc_pdf/xc_seng45.pdf



hope that sources and ideas are helpful, comments welcome !


with best regards,

Peter Seng


#############################
SENG digitale Systeme GmbH
Im Bruckwasen 35
D 73037 G÷ppingen
Germany
tel  +7161-75245
fax  +7161-72965
eMail  p.seng@seng.de
net  http://www.seng.de
#############################



Article: 66687
Subject: Re: DCM Simulation Error
From: "Kelvin @ SG" <kelvin8157@hotmail.com>
Date: Wed, 25 Feb 2004 22:28:06 +0800
Links: << >>  << T >>  << A >>
I tried simulating two cascaded DCM, also not successful...some postings
said cascading DCMs is no good...

Just my 2cent...

Best Regards,
Kelvin




"Austin Lesea" <austin@xilinx.com> wrote in message
news:c1fupg$l3u1@cliff.xsj.xilinx.com...
> Timothy,
>
> 1)  You must hold the cascaded DM in reset until the first DCM has locked
>
> 2) The tool is correct, cascading DCM CLK2X is not recommended, as the
> jitter out of the first exceeds the specs of the input of the second.
>
> They will work, but the resulting jitter out of the second one is not
> pretty (probably close to 400 to 600 ps P-P, which may be alright for
> your application).
>
> Oh, and one last item, 10 MHz is too low a frequency to go into a DCM
> with (Fin min is > 24 MHz).
>
> Austin



Article: 66688
Subject: Re: Driving INOUT signals
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 25 Feb 2004 09:32:23 -0500
Links: << >>  << T >>  << A >>
"Mike Nicklas" <michaeln@nospamplease.slayer.com> wrote in message
news:403c84b3$0$4103$5a6aecb4@news.aaisp.net.uk...
> Hi
>
> tried that too.
>
> No joy unfortunately.
>
> Any other ideas?

Post the relevant pieces of your code... Are you saying it works in another
simulator?

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



Article: 66689
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 25 Feb 2004 14:34:28 +0000
Links: << >>  << T >>  << A >>
On Tue, 24 Feb 2004 15:25:02 -0600, Kevin Brace
<kev0inb1rac2e@m3ail.c4om> wrote:

>Sander Vesik wrote:
>> 
>> 
>> Rather heavy-handed set of restrictions, don't you think?
>> 

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

Given Sander's email address, I'm guessing he was objecting to one
restriction in particular... and it may not have been the price.
I have problems with it too... ans I'm curious - what is it there for?

- Brian

Article: 66690
Subject: Re: quartus II 3.0 , block editor, how to connect signals of buses
From: "chi" <huageng.chi@vtt.fi>
Date: Wed, 25 Feb 2004 16:51:47 +0200
Links: << >>  << T >>  << A >>
Thank you Subroto!


"Subroto Datta" <sdatta@altera.com> wrote in message
news:9XqXb.21059$Wk3.20856@newssvr16.news.prodigy.com...
> Use the WIRE primitive and use a[1] as the name of the input to te WIRE
> primitive, and b[0] as the name of the ouput of the WIRE primitive. You
can
> insert the WIRE primitive from the Symbol Enter box.
>
>                    |\
> a[1]             |  \           b[0]
> -------------|   /----------------
>                     |/
> Where the buf type symbol is the WIRE primitive.
>
> Alternatively if you are using Blocks instead of symbols you an use
Conduits
> and set the properties of the mappers correctly. This information is
> available in the online help for Quartus.
>
> - Subroto Datta
> Altera Corp.
>
> "chi" <chi_huageng@yahoo.com> wrote in message
> news:232ce803.0402131341.2dc8763a@posting
> .google.com...
> > Hi all,
> >
> > For example, I want to connect a[1] to b[0], where both a and b are
> > buses in the current file of block editor. How to do that? Can you
> > show documents on how to use block editor?
> >
> > I've been using VHDL for years, graphical design entry of QuartusII
> > looks wired to me. I'm trying to get familar with it.
> >
> > Thanks a lot.
> >
> > Chi
>
>



Article: 66691
Subject: Re: Driving INOUT signals
From: Mike Nicklas <michaeln@nospamplease.slayer.com>
Date: Wed, 25 Feb 2004 14:59:17 +0000
Links: << >>  << T >>  << A >>
Hi

here is a copy of the top module entity declaration.  The testbench i 
tried was generated by a tool called HDL Bencher but i also tried using 
the command line interface on ModelSIM XE to no avail.

entity nueping2 is
     port (	-- Interface clock.
         	DSP_CLK: in STD_LOGIC;
         	-- Global reset.
         	RSTl: in STD_LOGIC;
         	-- Indicates whether Spartan can receive data.
         	BUSY: in STD_LOGIC;
         	-- Indicates whether Spartan has data to send.
         	EMPTY: in STD_LOGIC;
         	-- Indicates that ADIO is address or data.
         	AS_DSl: in STD_LOGIC;
         	-- Read/Write enable.
         	RENl_WENl: out STD_LOGIC;
         	-- Indicates if Spartan is being read or written to.
         	RDl_WR: out STD_LOGIC;
         	-- Interrupt to Spartan.
         	INTl: out STD_LOGIC;
         	-- Test LEDs.
         	LEDS: out STD_LOGIC_VECTOR (7 downto 0);
         	-- Data IO between Spartan and Virtex.
         	ADIO: inout STD_LOGIC_VECTOR (31 downto 0)
     		);
end nueping2;

I can add in the code from the auto-generated testbench as well if you like?

Mike

MM wrote:
> "Mike Nicklas" <michaeln@nospamplease.slayer.com> wrote in message
> news:403c84b3$0$4103$5a6aecb4@news.aaisp.net.uk...
> 
>>Hi
>>
>>tried that too.
>>
>>No joy unfortunately.
>>
>>Any other ideas?
> 
> 
> Post the relevant pieces of your code... Are you saying it works in another
> simulator?
> 
> /Mikhail


Article: 66692
Subject: Re: An old FPGA paper back to 1986...
From: "fabbl" <nospam@nospam.com>
Date: Wed, 25 Feb 2004 15:07:04 GMT
Links: << >>  << T >>  << A >>

> in Proc. Custom Integr. Circuits Conf., 1986, pp. 233--235.

Contact who sponsored it



Article: 66693
Subject: Example using a custom OPB slave core with and interrupt
From: jweese@senstarstellar.com (Jeremy)
Date: 25 Feb 2004 07:11:10 -0800
Links: << >>  << T >>  << A >>
Hello,

I have been exploring the microblaze for about 2 weeks now and have
gotten to the point where I have created a simple OPB slave device
that consists of 4 32-bit registers that contain hard coded values and
a pushbutton input that generates an interrupt. There is only one
single interrupt so I have connected it directly to the Mblaze without
the use of an OPB Intc at this point.

The peripherial is designe around the opb_core_ssp1 example that is
included with the EDK. I can read the registers fine. My problem lies
with the interrupt. When I first set out I addes the int_handler
parameter to the MSS file for my core, but of course I had no driver
and was using the generic. I used the IPIF sw driver and created the
MDD and some sort of a TCL file. I wrote the interrupt handler to
change the value being sent out the UART.

When I press my pushbutton to generate the interrupt the execution
stops. I am not sure if the processor is getting lost in the interrupt
vector table or if the interrupt is locked on so that I am never able
to get out of the ISR........

I am stumped and looking desparately for some help. If anyone has done
something similar and would be willing to share their knowledge I
would appreciate it greatly.

Thanks,
Jeremy

Article: 66694
Subject: Re: Driving INOUT signals
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 25 Feb 2004 10:12:49 -0500
Links: << >>  << T >>  << A >>
> here is a copy of the top module entity declaration.

This doesn't help much. We need to see how you drive the signal.

> I can add in the code from the auto-generated testbench as well if you
like?

Yes, but only the lines relevant to the signal of interest...

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



Article: 66695
Subject: Re: Warning on DCM min frequency...
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 25 Feb 2004 07:35:22 -0800
Links: << >>  << T >>  << A >>
Kelvin,

The CLKFX output can not go below 24 MHz.  If you do not use CLKFX, and 
are using CLKDV, then do not set M, or D, and do not use (instantiate) 
the CLKFX output, and the software will not error out.

Austin

Kelvin wrote:
> Hi, there:
> 
> I am using a Virtex-2's DCM to convert a 40MHz clock into synchronized 12MHz
> (40X3/10) and 4MHz
> (40/10) clocks.
> 
> In the attributes I set these constrainsts...Simulation and synthesis were
> correct. The min frequency
> seems to be within the specification of DCM. but I don't want to see this
> warning...What constraint do
> I need to set? (Not the trick suppress the warning)
> 
> WARNING:Timing:2799 - The output clock clk_12m_rx from DCM DCM0 has a period
>    (frequency) specification of 83333 ps (12.00 Mhz).  This violates the
> maximum
>    period (minimum frequency) of 41670 ps (24.00 Mhz).
> 
> 
> 
> //synthesis translate_off
> defparam .......................blah blah............................
> //synthesis translate_on
> // synthesis attribute CLKIN_PERIOD of DCM0 is 25
> // synthesis attribute DLL_FREQUENCY_MODE of DCM0 is "LOW"
> // synthesis attribute DUTY_CYCLE_CORRECTION of DCM0 is "TRUE"
> // synthesis attribute STARTUP_WAIT of DCM0 is "TRUE"
> // synthesis attribute DFS_FREQUENCY_MODE of DCM0 is "LOW"
> // synthesis attribute CLKDV_DIVIDE of DCM0 is 10
> // synthesis attribute CLKFX_DIVIDE of DCM0 is 10
> // synthesis attribute CLKFX_MULTIPLY of DCM0 is 3
> // synthesis attribute CLK_FEEDBACK of DCM0 is "1X"
> // synthesis attribute CLKOUT_PHASE_SHIFT of DCM0 is "FIXED"
> // synthesis attribute PHASE_SHIFT of DCM0 is 0
> 
> 
> 
> Best Regards,
> Kelvin
> 
> 

Article: 66696
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 25 Feb 2004 07:46:58 -0800
Links: << >>  << T >>  << A >>
Jim,

Any question that has the word "jitter" in it is by no means simple, or 
even easy, so no apologies required.

Any CMOS circuit must slice the input, and then send it thru the logic, 
and pass it back out again.

Programmable logic is no different from any other CMOS device.


At each rising (or falling) edge, common mode noise will change the 
switching threshold, and add jitter.  To find out how much jitter is 
added, one has to measure it.

Measurements of a statistical value requires many millions of cycles to 
be captured, and analysed.

There are special software packages, and instruments that do this:

Tektronix scope + jitter software package
LeCroy Jitter Analyser Scopes (software built in)
Agilent DCA's with jitter software packages (built in)
Wavecrest

For the folks who do not have the right equipment, just using infinite 
persistence on the scope and triggering on the 1,000th pulse (for 
example using time delay) will probably underestimate the peak to peak 
jitter by 2 or 3 times!

Peak to peak jitter is all that you really need to know, yet it is 
really tough to actually comply with the spec for jitter measurement and 
determine the "differences in time of the significant instances of the 
signal with respect to a theoretically perfect clock..."  from ITU.

If you have a Tek scope, a LeCroy scope, or an Agilent scope, call the 
rep, and set up a jitter training session.

Jitter is 'just' phase noise, and like any other noise measurement, is 
extremely sensitive to setup.  Ground leads, scope bandwidth, signal 
integrity (matching) all make it worse, and mask the true jitter added 
if you are not careful.

My rule is that I measure jitter, changing and modifying the setup and 
instruments until I have measured the smallest value.  Until I reach the 
smallest value, I have no confidence that I have measured the actual 
jitter as if I can measure a smaller number, I still have not taken all 
of the other noise factors out of the measurement setup itself!

Oh, and I alwasy make sure I have at least a million clock cycles, and 
take repeated samples of a million cycles to be sure that I have the 
peak values captured.

Austin

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.
> 
> Many thanks,
> 
> Jim
> 
> 

Article: 66697
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: "Jim" <jim@nospam.com>
Date: Wed, 25 Feb 2004 16:24:43 -0000
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> wrote in message
news:c1ig0l$9nl1@cliff.xsj.xilinx.com...
> Jim,
>
> Any question that has the word "jitter" in it is by no means simple, or
> even easy, so no apologies required.
>
> Any CMOS circuit must slice the input, and then send it thru the logic,
> and pass it back out again.
>
> Programmable logic is no different from any other CMOS device.
>
>
> At each rising (or falling) edge, common mode noise will change the
> switching threshold, and add jitter.  To find out how much jitter is
> added, one has to measure it.
>
> Measurements of a statistical value requires many millions of cycles to
> be captured, and analysed.
>
> There are special software packages, and instruments that do this:
<snip>

Many thanks, Austin, for such a detailed reply.

I never appreciated there was so much to it (for my sins coming mainly from
a software background). Yes I realise now that it is dependent on each
rising and falling edge and so depends on a lot more than the spec of the
CPLD.

I do have a small Tek TDS-220 digital storage scope, but I can see I would
be unlikely to acheive worthwhile results without training and/or other
equipment, and a lot of time.

TBH, the information is partly for our marketing; jitter on a digital audio
(SPDIF) signal is a big issue to many using mid/high-end audio gear,
although TBH I am not sure if some of this is snake oil... However, since
our product processes and then reclocks the stream, it would be useful to
know what the resultant jitter is.

Thanks again Austin,

Jim



Article: 66698
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 25 Feb 2004 09:00:03 -0800
Links: << >>  << T >>  << A >>
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

Jim wrote:
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:c1ig0l$9nl1@cliff.xsj.xilinx.com...
> 
>>Jim,
>>
>>Any question that has the word "jitter" in it is by no means simple, or
>>even easy, so no apologies required.
>>
>>Any CMOS circuit must slice the input, and then send it thru the logic,
>>and pass it back out again.
>>
>>Programmable logic is no different from any other CMOS device.
>>
>>
>>At each rising (or falling) edge, common mode noise will change the
>>switching threshold, and add jitter.  To find out how much jitter is
>>added, one has to measure it.
>>
>>Measurements of a statistical value requires many millions of cycles to
>>be captured, and analysed.
>>
>>There are special software packages, and instruments that do this:
> 
> <snip>
> 
> Many thanks, Austin, for such a detailed reply.
> 
> I never appreciated there was so much to it (for my sins coming mainly from
> a software background). Yes I realise now that it is dependent on each
> rising and falling edge and so depends on a lot more than the spec of the
> CPLD.
> 
> I do have a small Tek TDS-220 digital storage scope, but I can see I would
> be unlikely to acheive worthwhile results without training and/or other
> equipment, and a lot of time.
> 
> TBH, the information is partly for our marketing; jitter on a digital audio
> (SPDIF) signal is a big issue to many using mid/high-end audio gear,
> although TBH I am not sure if some of this is snake oil... However, since
> our product processes and then reclocks the stream, it would be useful to
> know what the resultant jitter is.
> 
> Thanks again Austin,
> 
> Jim
> 
> 

Article: 66699
Subject: Re: Basic jitter from a CPLD (XC7500XL)
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Feb 2004 12:14:12 -0500
Links: << >>  << T >>  << A >>
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?

Jim wrote:

> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:c1ig0l$9nl1@cliff.xsj.xilinx.com...
> > Jim,
> >
> > Any question that has the word "jitter" in it is by no means simple, or
> > even easy, so no apologies required.
> >
> > Any CMOS circuit must slice the input, and then send it thru the logic,
> > and pass it back out again.
> >
> > Programmable logic is no different from any other CMOS device.
> >
> >
> > At each rising (or falling) edge, common mode noise will change the
> > switching threshold, and add jitter.  To find out how much jitter is
> > added, one has to measure it.
> >
> > Measurements of a statistical value requires many millions of cycles to
> > be captured, and analysed.
> >
> > There are special software packages, and instruments that do this:
> <snip>
>
> Many thanks, Austin, for such a detailed reply.
>
> I never appreciated there was so much to it (for my sins coming mainly from
> a software background). Yes I realise now that it is dependent on each
> rising and falling edge and so depends on a lot more than the spec of the
> CPLD.
>
> I do have a small Tek TDS-220 digital storage scope, but I can see I would
> be unlikely to acheive worthwhile results without training and/or other
> equipment, and a lot of time.
>
> TBH, the information is partly for our marketing; jitter on a digital audio
> (SPDIF) signal is a big issue to many using mid/high-end audio gear,
> although TBH I am not sure if some of this is snake oil... However, since
> our product processes and then reclocks the stream, it would be useful to
> know what the resultant jitter is.
>
> Thanks again Austin,
>
> Jim

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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

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

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

Custom Search