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 81200

Article: 81200
Subject: Re: XC3000 non-recoverable lockup problem
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 19 Mar 2005 06:18:49 GMT
Links: << >>  << T >>  << A >>
On 18 Mar 2005 12:09:04 -0800, lecroy7200@chek.com wrote:
>
>After running an automated test for the last 24 hours, finally one part
>on my test unit failed.  Because the software would try and program the
>devices after a fixed amount of time in order to detect the fault, I am
>not sure if the pins were in this state at the time of the failure.
>However, Looking at the the control pins, HDC is high, LDC is low,
>done/pgm' is low and init is low.
>
>I increased the reset time to over a second with no luck.  I tried
>reloading the device over 50 times with no luck.  This is what we are
>seeing.  I am not sure why it entered this mode and if it had anything
>to do with my testing, or was just its time.
>
>I have left the device in this state is anyone has ideas on further
>test.

Great.

As I have read further, you no longer have it in this state.
Assuming you get it into this failed state again, please try the followig 2 things:

1) supply a continuous CCLK, with DIN alternating 0 and 1. Please tell us what
   you see on the DOUT pin.

2) Supply a continuous CCLK for at least 2**24 cycles (16 million cycles) plus
   a few extra 100000 cycles. At 1 MHz, this will take about 16 seconds. Set
   DIN to 1 for all of this. Please report any changes you observe on Done/Prog,
   HDC, LDC, and DOUT. There is a "fault " mode where if it gets some clock
   cycles that are unexpected at the beginning, or corruption of the header
   it can take 16000000 clocks for it to get back to the beginning of the
   state sequence.


I am suspecting that the note by Hal Murray of a week ago may be occuring,
although your observation are also in line with guess of Brownout.

Just as a reminder, here what Hal Wrote:

>I think there is a combined ~prog and done pin.  It's pulled low
>(open drain) by the 3000 until it gets configured.  Power up starts
>needing configutation.  A high-to-low transition on ~prog asks for
>another configuration cycle.  If your attempted configuration gets
>confused, there is no way to start over until you finish configuration
>since ~done is held low so you can't make it go high-to-low.
>
>Configuration starts with a 24 bit bit-count value.  After that many
>configuration clocks, all the devices in the the chain release
>their done pulldown.  If one of the devices in the chain gets
>(somehow) a low value in that counter you have to cycle through
>2**24 cycles to wrap around and finish the current cycle.


Keep working on it,
Philip



Philip Freidin
Fliptronics

Article: 81201
Subject: Ask for PicoBlaze C compiler
From: Sir_Pal13@hotmail-dot-com.no-spam.invalid (Sir Pal)
Date: Sat, 19 Mar 2005 02:10:32 -0600
Links: << >>  << T >>  << A >>
Dear Franceso!

Congratulation for the C compiler working with PicoBlaze! It's a great
idea, and a much more faster way of code evaluation. Would you please
send me a copy of the compiler and the "partially written" user
manual for a test?

Thanks!

E-mail: Sir_Pal13@hotmail.com

Best regards:
Sir Pal


Article: 81202
Subject: One-hot statemachine design problems
From: Preben Holm <64bitNOnoNOSPAM@mailme.dk>
Date: Sat, 19 Mar 2005 09:46:03 +0100
Links: << >>  << T >>  << A >>
Hi everyone,

I try to construct this statemachine as described in VHDL below:
(the machine is supposed to set the hold as soon as the trig-signal is 
asserted (initialized only when all signals have been low for a 
clock-cycle) and go low when both the read and holdoff signals have been 
asserted for some time...

------------------------------------------
entity holdoffcontroller is
     Port ( clk : in std_logic;
            reset : in std_logic;
            save : in std_logic;
            trig : in std_logic;
            read : in std_logic;
            holdoff : in std_logic;
            hold : out std_logic;
            state : out std_logic_vector(4 downto 0));
end holdoffcontroller;

architecture Behavioral of holdoffcontroller is
     constant stateStart   : std_logic_vector(4 downto 0) := "00001";
     constant stateWait    : std_logic_vector(4 downto 0) := "00010";
     constant stateTrigger : std_logic_vector(4 downto 0) := "00100";
     constant stateHold    : std_logic_vector(4 downto 0) := "01000";
     constant stateRead    : std_logic_vector(4 downto 0) := "10000";
begin

     STATEMACHINE: block
         signal current_state, next_state : std_logic_vector(4 downto 0) 
:= stateStart;
     begin
         stateRegister : process(clk, reset)
         begin
             if reset = '1' then
                 current_state <= stateStart;
             elsif rising_edge(clk) then
                 current_state <= next_state;
             end if;
         end process;


         stateTransitions : process(current_state, holdoff, read, trig)
         begin
             -- stateStart
             if current_state(0) = '1' then
                 hold <= '0';

                 if holdoff = '0' and read = '0' and trig = '0' then
                     next_state <= stateWait;
                 end if;
             end if;

             -- stateWait
             if current_state(1) = '1' then
                 if trig = '1' then
                     next_state <= stateTrigger;
                 end if;
             end if;

             -- stateTrigger
             if current_state(2) = '1' then
                 hold <= '1';

                 if holdoff = '1' and read = '0' then
                     next_state <= stateHold;
                 end if;

                 if holdoff = '0' and read = '1' then
                     next_state <= stateRead;
                 end if;

                 if holdoff = '1' and read = '1' then
                     next_state <= stateStart;
                 end if;
             end if;

             -- stateHold
             if current_state(3) = '1' then
                 if read = '1' then
                     next_state <= stateStart;
                 end if;
             end if;

             -- stateRead
             if current_state(4) = '1' then
                 if holdoff = '1' then
                     next_state <= stateStart;
                 end if;
             end if;
         end process;

         state <= current_state;
     end block;

end Behavioral;

------------------------------------------


Simulating the behavioral model works just fine, but when simulating the 
Translate-model the function of the model is just awkward!


When synthesis runs i get these warnings:
WARNING:Xst:647 - Input <save> is never used.
WARNING:Xst:737 - Found 1-bit latch for signal <hold>.
WARNING:Xst:737 - Found 5-bit latch for signal <next_state>.
     Found 5-bit register for signal <current_state>.


Furthermore I get these three strange clock-signals:
-----------------------------------+------------------------+-------+
Clock Signal                       | Clock buffer(FF name)  | Load  |
-----------------------------------+------------------------+-------+
_n0066(_n006637:O)                 | NONE(*)(next_state_4)  | 4     |
clk                                | BUFGP                  | 8     |
current_state_0:Q                  | NONE                   | 1     |
-----------------------------------+------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) 
generated by combinatorial logic.
INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically 
buffered by XST with BUFG/BUFR resources. Please use the buffer_type 
constraint in order to insert these buffers to the clock signals to help 
prevent skew problems.



Can anybody tell me what I do wrong in the design of the statemachine!


Thanks for helping me out!

Article: 81203
Subject: Re: rocketio
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 19 Mar 2005 10:18:45 +0100
Links: << >>  << T >>  << A >>

"news.verizon.net" <res0rsef@verizon.net> schrieb im Newsbeitrag
news:DZK_d.4272$uw6.817@trnddc06...
> Hi,
> I would like some help from roketio users to find what is the maximum
> realizable freq we can get out of it. I hear that although it supports
upto
> 3.125Ghz, you can only get only upto 2.5Ghz. Also, can I get any eval
board

3.125 Gbit/s, not GHz. This is the line data rate. Effective data rate is
only 2.5 Gbits/s due to line encoding using 8B/10B encoder (encodes 8 data
bits into 10 data bits to guarantee a constant DC level and transition
density) Virtex4 supports also 64B/66B encoding (which is much more
effcient).

Regards
Falk




Article: 81204
Subject: FCCM 2005 Final Call for Participation (note 3/20 deadline!)
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 19 Mar 2005 09:38:57 GMT
Links: << >>  << T >>  << A >>

Well, I don't remember seeing anything on FCCM 2005 in this news group,
and I just got this email today. Cheap seats end this Sunday Night.

I'll be there!


==================

	    C A L L    F O R    P A R T I C I P A T I O N

			 THE THIRTEENTH ANNUAL
		 IEEE SYMPOSIUM ON FIELD PROGRAMMABLE
		      CUSTOM COMPUTING MACHINES
			   Napa, California
			April 17 - 20, 2005

			 http://www.fccm.org

Register now!  The FCCM pre-registration deadline is Sunday, 20 March.

Advance registration will be accepted by mail, fax, or online
submission through 20 March 2005. After 20 March, you must pay late
registration fees.  After 3 April only on-site registration will be accepted.

All no-show registrations will be billed in full. Students are
required to show current picture ID cards at the time of registration.

To register, please visit the FCCM home page at http://www.fccm.org.

The registration application accepts MasterCard, Visa, American
Express, and Diners Club cards. If you do not have one of these credit
cards, or if you prefer not to register online, please print out the
form and fax or mail with payment, to:

	IEEE Computer Society
	ATTN: FCCM '05 Registration
	Dept. 6006
	Washington, DC 20042-6006
	(202) 371-0101 Phone
	(202) 728-0884 FAX

Sorry, no phone registrations.
Please make checks payable to IEEE Computer Society.

Registrations received without payment will not be accepted.

Please remember to make hotel accomodations, too!


                          FCCM '05
                     Preliminary Program
                              
________________________________________________________________

Sunday 17 April 2005
Registration and reception, 7:00pm -- 9:00pm
________________________________________________________________

Monday 18 April 2005

Session 1:         Applications I
8:30 -- 10:00

Title:             Efficient Hardware Data Mining with the
                   Apriori Algorithm on FPGAs
Authors:           Zachary K. Baker, Viktor K. Prasanna
Organization:      University of Southern California

Title:             A Novel 2D Filter Design Methodology for
                   Heterogeneous Devices
Authors:           Christos-Savvas Bouganis, George A.
                   Constantinides, Peter Y.K. Cheung
Organization:      Imperial College

Title:             Prototyping Architectural Support for
                   Program Rollback Using FPGAs
Authors:           Radu Teodorescu, Josep Torrellas
Organization:      UIUC
________________________________________________________________

Poster Session 1
10:00 -- 11:00
________________________________________________________________

Session 2:         Architecture
11:00 -- 12:00

Title:             Register File Architecture Optimization
                   in a Coarse-Grained Reconfigurable Architecture
Authors:           Zion Kwok, Steven J.E. Wilton
Organization:      University of British Columbia

Title:             Handling Different Computational
                   Granularity by a Reconfigurable IC featuring
                   Embedded FPGAa and a Network-on-Chip
Authors:           Francesco Lertora, Michele Borgatti
Organization:      ST Microelectronics
________________________________________________________________

Session 3:         Tools I
1:30 -- 3:00

Title:             A Study of the Scalability of On-Chip
                   Routing for Just-in-Time FPGA Compilation
Authors:           Roman Lysecky, Frank Vahid, Sheldon X.-D. Tan
Organization:      University of California, Riverside

Title:             Simplifying the Integration of Processing
                   Elements in Computing Systems using a
                   Programmable Controller
Authors:           Lesley Shannon, Paul Chow
Organization:      University of Toronto

Title:             Evaluation of Code Generation Strategies
                   for Scalar Replaced Codes in Fine-Grain
                   Configurable Architectures
Authors:           Pedro C. Diniz
Organization:      University of Southern California/ISI

________________________________________________________________

Poster Session 2
3:00 -- 4:00
________________________________________________________________

Session 4:         Graphics
4:00 -- 5:00

Title:             FPGA Particle Graphics Hardware
Authors:           John S. Beeckler, Warren J. Gross
Organization:      McGill University

Title:             Reconfigurable Designs for Radiosity
Authors:           Paul Baker, Tim Todman, Henry Styles,
Wayne Luk
Organization:      Imperial College

________________________________________________________________

Demo Night
7:00 -- 9:00
________________________________________________________________

Tuesday 19 April 2005


Session 5:         Applications II
8:30 -- 10:00

Title:             Hardware Factorization Based on Elliptic
                   Curve Method
Authors:           Martin Simka, **Jan Pelzl, ***Thorsten
                   Kleinjung, Milos Drutarovsky, ****Viktor
                   Fischer, **Christof Paar
Organization:      Technical University of Kosice, Ruhr
                   University**, University of Bonn***, 
                   Universite Jean Monnet****

Title:             Metropolitan Road Traffic Simulation on
                   FPGAs
Authors:           Justin L. Tripp, Henning S. Mortveit,
                   Anders A. Hansson, Maya Gokhale
Organization:      Los Alamos National Laboratories

Title:             Time Domain Numerical Simulation for
                   Transient Wave Equations on Reconfigurable
                   Coprocessor Platform
Authors:           Chuan He, Wei Zhao, Mi Lu
Organization:      Texas A&M University

________________________________________________________________

Poster Session 3
10:00 -- 11:00
________________________________________________________________

Session 6:         Run Time
11:00 -- 12:00

Title:             COMA: A COoperative MAnagement Scheme for
                   Energy Efficient Implementation of Real-Time
                   Operating Systems on FPGA Based Soft Processors
Authors:           Jingzhao Ou, Viktor K. Prasanna
Organization:      University of Southern California

Title:             An Execution Environment for
                   Reconfigurable Computing
Authors:           W. Fu, K. Compton
Organization:      University of Wisconsin at Madison
                              
________________________________________________________________

Session 7:         Arithmetic
1:30 -- 3:00

Title:             Higher Radix Floating-Point
                   Representations for FPGA-Based Arithmetic
Authors:           Bryan Catanzaro, Brent Nelson
Organization:      Brigham Young University

Title:             An Analysis of the Double-Precision
                   Floating-Point FFT on FPGAs
Authors:           K. Scott Hemmert, Keith Underwood
Organization:      Sandia National Laboratories

Title:             A Comparision of Floating Point and
                   Logarithmic Number Systems for FPGAs
Authors:           Michael Haselman, Michael Beauchamp,
                   Aaron Wood, Scott Hauck, *Keith Underwood, *K.
                   Scott Hemmert
Organization:      University of Washington, Sandia National
                   Laboratories*
________________________________________________________________

Poster Session 4
3:00 -- 4:00
________________________________________________________________

Session 8:         Device Architecture
4:00 -- 5:00

Title:             Terrestrial-Based Radiation: A Cautionary
                   Tale
Authors:           Heather Quinn, Paul Graham
Organization:      Los Alamos National Laboratory

Title:             Automating the Layout of Reconfigurable
                   Subsystems using Circuit Generators
Authors:           Shawn Phillips, Scott Hauck
Organization:      University of Washington

________________________________________________________________

Wednesday 20 April 2005

Session 9:         Networking
8:30 -- 10:00

Title:             Fast Reconfiguring Deep Packet Filter for
                   1+ Gigabit Network
Authors:           Young H. Cho, William H. Mangione-Smith
Organization:      UCLA

Title:             A Framework For Rule Processing in
                   Reconfigurable Network Systems
Authors:           Michael E. Attig, John W. Lockwood
Organization:      Washington University in St. Louis

Title:             A Signature Match Processor Architecture
                   for Network Intrusion Detection
Authors:           Janardham Singaraju, Long Bu, John A.
                   Chandy
Organization:      University of Connecticut

________________________________________________________________

Session 10:        Tools II
10:30 -- 11:30

Title:             Interleaving Behavioral and Cycle-
                   Accurate Descriptions for Reconfigurable
                   Hardware Compilation
Authors:           Jose Gabriel F. Coutinho, Jun Jiang,
                   Wayne Luk
Organization:      Imperial College

Title:             Modeling and FPGA Implementation of
                   Applications using Parameterized Process
                   Networks with Non-Static Parameters
Authors:           Hristo Nikolov, Todor Stefanov, Ed
                   Deprettere
Organization:      Leiden University












Philip Freidin
Fliptronics

Article: 81205
Subject: Re: (Stupid/Newbie) Question on UART
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 19 Mar 2005 04:41:37 -0600
Links: << >>  << T >>  << A >>
>Thanks for that but I already knew it existed: I wasn't trying to pretend I
>had invented something.  But my original question was why isn't it more 
>widely used?  

It is widely used - at least if you are generous on what "it" is.

There are two conflicting properties you want when transmitting data
over a link.  You need transitions in the data stream so the receiver
can do clock recovery.  But useless transitions reduce link bandwidth
efficiency.

Another goal is to make the data stream ballanced so you can run
it through a capicator or transformer.

Manchester is very easy to implement with good DC ballancing but
only 50% efficient.  4B/5B (FDDI) is 80% efficient but not quite
ballanced in some cases.  8B/10B is ballanced but more complicated
to implement.

Typical async RS-232 is 80% efficient and easy to implement as
long as the signal is clean (aka distance is short relative to
the bit rate).

If you have long links, the fiber/cable is the expensive part and
you are willing to work harder (pay more) on clock recovery to get
more bits through the pipe.  On the other hand, for something like
Ethernet or RS-232 with short links, you are generally willing to
trade link bandwidth (or distance) for simpler decoding procedures.

For an alternative approach, google for scrambling as used on SONET.
The general idea is to start with a good clock recovery circuit (say
50 bits without any transitions) and then randomize the data stream
by XORing it with a random pattern so you still have transitions if
the user sends all 0s or whatever the nasty pattern is.

-- 
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: 81206
Subject: Is an XC3S1500 enough to implement a MP@ML MPEG-2 decoder?
From: kevin@nospam.nospam
Date: 19 Mar 2005 12:42:59 GMT
Links: << >>  << T >>  << A >>


I'm looking for a development board to implement an MPEG-2 video decoder, 
and currently interested in ADS-XLX-SP3-DEV1500 available from Avnet, which 
comes with the following components: 
    * Xilinx XC3S1500/2000-FG676 Spartan-3 FPGA
    * 2x16 character LCD
    * 128x64 OSRAM OLED graphical display
    * DB15 & video DAC
    * Audio CODEC
    * PS2 keyboard & mouse ports
    * 8-position DIP switch
    * 2 push-buttons
    * 8 discrete LEDs
    * Piezo buzzer
    * 3, 140-pin general purpose I/O expansion connectors (AvBus)
    * Up to 30 LVDS pairs
    * 1, 50-pin 0.1" header for easy I/O access
    * Micron DDR SDRAM (32 MB)
    * 16 MB FLASH
    * 2 MB SRAM
    * RS-232 serial port
    * 10/100 Ethernet
    * USB 2.0
    * Xilinx platform FLASH configuration PROM(s)
    * Parallel IV cable support for JTAG
    * Fly-wire support for Parallel III and MultiLINX™

The peripherals seem more than enough, but I still wonder whether the logic 
resources in XC3S1500 is sufficient.
Any suggestion is really appreciated. 

Thanks,
Kevin





 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

Article: 81207
Subject: Re: ISE 7.1 WebPack + EDK 6.3
From: "Alex Gibson" <news@alxx.net>
Date: Sat, 19 Mar 2005 23:44:24 +1100
Links: << >>  << T >>  << A >>

"Peter Særensen" <pbs@mortician.dk> wrote in message 
news:ee8cc3e.-1@webx.sUN8CHnE...
> Hi,
>
> Im a poor student who purchased the 6.3 version of the EDK a few months 
> back. Uptill now I have been using the evaluation version of ISE 6.3 (too 
> expensive for me). I have been unable to use the WebPack version of the 
> ISE 6.3 since "all" I have is a Virtex4 LX25. I had been planning to 
> switch to the ISE 7.1 webpack (which supports my device) but I am unable 
> to get it working with my EDK 6.3 installation. I get the following error:
>
> $XILINX does not point to an iSE 6.3 installation
>
> Isnt it possible to use the ISE 7.1 webpack with EKD 6.3 ??
>
> thanks

I thought you need to have the same version of both
to get them to work properly

Either go back to ise 6.3 or wait for edk 7.1

Usually better off staying behind a version or two

Can download old versions of web pack
http://www.xilinx.com/webpack/classics/wpclassic/index.htm

If your a university student surely your university can request the full 
software via XUP
Xilinx university program.
http://www.xilinx.com/univ/index.htm
http://xup.msu.edu/

Another option would be to buy a textbook with  or by itself
the student version of 6.3 which is same as full ise but without
any support.
http://www.amazon.com/exec/obidos/tg/detail/-/0131858394/qid=1111234703/sr=2-1/104-7812736-3159945?v=glance&s=books

Alex 



Article: 81208
Subject: Re: Is an XC3S1500 enough to implement a MP@ML MPEG-2 decoder?
From: "news.skynet.be" <com.246tNt@tnt>
Date: Sat, 19 Mar 2005 14:08:25 +0100
Links: << >>  << T >>  << A >>
Hi

kevin@nospam.nospam wrote:
> I'm looking for a development board to implement an MPEG-2 video decoder, 
> and currently interested in ADS-XLX-SP3-DEV1500 available from Avnet, which 
> comes with the following components: 
>     * Xilinx XC3S1500/2000-FG676 Spartan-3 FPGA
>     * 2x16 character LCD
>     * 128x64 OSRAM OLED graphical display
>     * DB15 & video DAC
>     * Audio CODEC
>     * PS2 keyboard & mouse ports
>     * 8-position DIP switch
>     * 2 push-buttons
>     * 8 discrete LEDs
>     * Piezo buzzer
>     * 3, 140-pin general purpose I/O expansion connectors (AvBus)
>     * Up to 30 LVDS pairs
>     * 1, 50-pin 0.1" header for easy I/O access
>     * Micron DDR SDRAM (32 MB)
>     * 16 MB FLASH
>     * 2 MB SRAM
>     * RS-232 serial port
>     * 10/100 Ethernet
>     * USB 2.0
>     * Xilinx platform FLASH configuration PROM(s)
>     * Parallel IV cable support for JTAG
>     * Fly-wire support for Parallel III and MultiLINX™
> 
> The peripherals seem more than enough, but I still wonder whether the logic 
> resources in XC3S1500 is sufficient.
> Any suggestion is really appreciated. 

I'd say yes.

http://www.4i2i.com/downloads/AllianceCoreMPEG4Decoder.pdf
This is a MPEG4 decoder in <1600 Slices ... The 1500 has > 10000 Slice 
IIRC so ...



	Sylvain

Article: 81209
Subject: Re: Is an XC3S1500 enough to implement a MP@ML MPEG-2 decoder?
From: "Marc Randolph" <mrand@my-deja.com>
Date: 19 Mar 2005 05:41:47 -0800
Links: << >>  << T >>  << A >>
kevin@nospam.nospam wrote:
> I'm looking for a development board to implement an MPEG-2 video
decoder,
> and currently interested in ADS-XLX-SP3-DEV1500 available from Avnet,
which
> comes with the following components:
>     * Xilinx XC3S1500/2000-FG676 Spartan-3 FPGA
>     * 128x64 OSRAM OLED graphical display
>     * DB15 & video DAC
>     * Audio CODEC
>     * PS2 keyboard & mouse ports
[... snip stuff like the Piezo buzzer and connectors ...]
>     * Micron DDR SDRAM (32 MB)
>     * 16 MB FLASH
>     * 2 MB SRAM
>     * 10/100 Ethernet
>     * USB 2.0
[...]
> The peripherals seem more than enough, but I still wonder
> whether the logic resources in XC3S1500 is sufficient.

Howdy Kevin,

That's quite a development board!  Seems like it would be perfect for
your project and you should have no problems fitting an mpeg decoder in
that device.  Compared to past FPGA's, XC3S1500 is quite a large device
- in fact, Xilinx has an IP partner that has a mpg decoder core which
fits in a 3S1000:

http://www.xilinx.com/bvdocs/ipcenter/data_sheet/Amphion_CS6651.pdf

I see that their core runs at only 50 MHz.  With just a little bit of
attention, running at 100 MHz in the S3 should not be a problem.  Going
out on a limb just a bit (it's a pretty strong one), you could likely
code up two decoders in the space of their one, or one decoder that
takes up half the space of theirs.

Have fun,

   Marc


Article: 81210
Subject: Re: (Stupid/Newbie) Question on UART
From: "Marc Randolph" <mrand@my-deja.com>
Date: 19 Mar 2005 06:37:59 -0800
Links: << >>  << T >>  << A >>

Hal Murray wrote:
> >Thanks for that but I already knew it existed: I wasn't trying to
pretend I
> >had invented something.  But my original question was why isn't it
more
> >widely used?
>
> It is widely used - at least if you are generous on what "it" is.

Like if "it" can be equal to Ethernet? :-)

> Manchester is very easy to implement with good DC ballancing but
> only 50% efficient.  4B/5B (FDDI) is 80% efficient but not quite
> ballanced in some cases.  8B/10B is ballanced but more complicated
> to implement.

Just to make this this discussion complete, with 64B/65B and 64B/66B
there are finally encoding schemes with efficiencies worth being proud
of.

[...]
> For an alternative approach, google for scrambling as used on SONET.
> The general idea is to start with a good clock recovery circuit (say
> 50 bits without any transitions) and then randomize the data stream
> by XORing it with a random pattern so you still have transitions if
> the user sends all 0s or whatever the nasty pattern is.

A CID (consecutive identical digits) of 50 bits will cover most
real-world cases of scrambled SONET traffic, but I'd personally want a
CDR with noticably more staying power than that.

Have fun,

   Marc


Article: 81211
Subject: Stratix II vs Virtex 4
From: "Keith Williams" <e_s_p_i_a_n_@insightbb.com>
Date: Sat, 19 Mar 2005 14:43:04 GMT
Links: << >>  << T >>  << A >>
Hello everyone,

I have a rather high performance design that acts as a high through-put data
path with some DSP manipulation on the way through.

I had been rather certain that I was going to move through to production
using Stratix/Stratix II parts.  However, the other day I sat down with a
distributor who was able to point out some very interesting items for
comparisons with the V4 chips.

Here are the four main items brought up:

1) Faster RAM
2) Potentially Lower power consumption
3) Price-points in the $120-160 range
4) More flexibility on the parallel LVDS inputs to the chip

I'm interested to hear anyone with first hand comparisons between the V4 and
other chips.

Thanks,

Keith



Article: 81212
Subject: Re: One-hot statemachine design problems
From: "Marc Randolph" <mrand@my-deja.com>
Date: 19 Mar 2005 06:53:04 -0800
Links: << >>  << T >>  << A >>

Preben Holm wrote:
> Hi everyone,
[...]

Really a comp.lang.vhdl question, but since you're here... at the
beginning of your process (right after the begin), I think you'd want a
default assignment for next_state:

               next_state <= current_state;

This will make it obvious to the tools that they should remain in the
current state unless one of the following conditions turns out to be
true.

>          stateTransitions : process(current_state, holdoff, read,
trig)
>          begin
>              -- stateStart
>              if current_state(0) = '1' then
>                  hold <= '0';
>
>                  if holdoff = '0' and read = '0' and trig = '0' then
>                      next_state <= stateWait;
>                  end if;
>              end if;
>
[...]
> WARNING:Xst:737 - Found 5-bit latch for signal <next_state>.
>      Found 5-bit register for signal <current_state>.

The latch warning for next_state is your clue.

Good luck,

   Marc


Article: 81213
Subject: Re: Stratix II vs Virtex 4
From: "Marc Randolph" <mrand@my-deja.com>
Date: 19 Mar 2005 07:07:41 -0800
Links: << >>  << T >>  << A >>

Keith Williams wrote:
> Hello everyone,
>
> I have a rather high performance design that acts as a high
through-put data
> path with some DSP manipulation on the way through.
>
> I had been rather certain that I was going to move through to
production
> using Stratix/Stratix II parts.  However, the other day I sat down
with a
> distributor who was able to point out some very interesting items for
> comparisons with the V4 chips.
>
> Here are the four main items brought up:
>
> 1) Faster RAM
> 2) Potentially Lower power consumption
> 3) Price-points in the $120-160 range
> 4) More flexibility on the parallel LVDS inputs to the chip
>
> I'm interested to hear anyone with first hand comparisons between the
V4 and
> other chips.

Howdy Keith,

If you register the output of the BRAM, then yes, it's probably faster.
 Otherwise, probably not.  Do you need that much speed?  You didn't
really give any design info (target speeds, device/design size, etc).

There was a considerable "debate" on comp.arch.fpga last month about
the power differences between the S2 and V4, and while I am positive
that the Virtex-4 static power is lower, I am less convinced that when
a high speed design is running in the device that is well utilized, the
total power will be THAT much different between the two.  Device size
factors into the power equation as well.

In short, he _might_ be right on any or all accounts, but until you
actually have a price quote in your hand from each vendor for a
selected part, and target your design to get design speeds, and run the
power estimators for each, it is too close to call, IMO.

The ISERDES and OSERDES are quite neat features though, and when
combined with the no-brainer local routing and clock divider, may make
a compelling sell on its own.  

Good luck,

   Marc


Article: 81214
Subject: Re: One-hot statemachine design problems
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 19 Mar 2005 16:50:11 +0100
Links: << >>  << T >>  << A >>
Hi,

I would make a few of suggestions :

* use an enumeration and traditional "case state is when =>"
  construct. This facilitates a lot of things, if only for the
  synthesis tool to properly recognize your FSM, but also for
  HSL simulation, readability, reliability, optimization etc...

* to output the state vector, use a simple decoder (which
  will be probably eliminated by synthesis). And maybe you don't
  want the one-hot vector vector to come out, but an binary
  (more compact) version ?

* Single-process style is easier to write (imo) and not prone
  to the usual errors in combinational processes.
  (you're not the first and not the last to get caught)
   You can even write Moore style in one process if
   you don't want to move your actions in the transitions.

* Keep in mind that the synthesizer sometimes can guess
  the "parallel case" and sometime can't.
  This is likely your case (can't guess). It should have
  trouble understanding that individual bit comparisons are
  (probably) mutually exclusive.
  So I'm afraid it would code the priority you've told him
  implicitly to implement (last "if" does win).
  I think this is inefficient synthesis-wise.

On my Website, you'll find many FSM examples, FWIW
http://www.alse-fr.com/English/ips.html

I never really liked the "textbook" two-processes style,
and I've seen lots of problems in code written this way...

But Text editors, FSM coding and VHDL vs Verilog are
almost religious issues :-) ...

Bert

Preben Holm wrote:
> Hi everyone,
> 
> I try to construct this statemachine as described in VHDL below:
> (the machine is supposed to set the hold as soon as the trig-signal is 
> asserted (initialized only when all signals have been low for a 
> clock-cycle) and go low when both the read and holdoff signals have been 
> asserted for some time...
> 
> ------------------------------------------
> entity holdoffcontroller is
>     Port ( clk : in std_logic;
>            reset : in std_logic;
>            save : in std_logic;
>            trig : in std_logic;
>            read : in std_logic;
>            holdoff : in std_logic;
>            hold : out std_logic;
>            state : out std_logic_vector(4 downto 0));
> end holdoffcontroller;
> 
> architecture Behavioral of holdoffcontroller is
>     constant stateStart   : std_logic_vector(4 downto 0) := "00001";
>     constant stateWait    : std_logic_vector(4 downto 0) := "00010";
>     constant stateTrigger : std_logic_vector(4 downto 0) := "00100";
>     constant stateHold    : std_logic_vector(4 downto 0) := "01000";
>     constant stateRead    : std_logic_vector(4 downto 0) := "10000";
> begin
> 
>     STATEMACHINE: block
>         signal current_state, next_state : std_logic_vector(4 downto 0) 
> := stateStart;
>     begin
>         stateRegister : process(clk, reset)
>         begin
>             if reset = '1' then
>                 current_state <= stateStart;
>             elsif rising_edge(clk) then
>                 current_state <= next_state;
>             end if;
>         end process;
> 
> 
>         stateTransitions : process(current_state, holdoff, read, trig)
>         begin
>             -- stateStart
>             if current_state(0) = '1' then
>                 hold <= '0';
> 
>                 if holdoff = '0' and read = '0' and trig = '0' then
>                     next_state <= stateWait;
>                 end if;
>             end if;
> etc..



Article: 81215
Subject: Re: XC3S50 or EPM1270?
From: austin <austin@xilinx.com>
Date: Sat, 19 Mar 2005 08:01:09 -0800
Links: << >>  << T >>  << A >>
vax,

For 5V inputs to the Spartan 3, you may also use 100 ohm series 
resistors from the 5V logic to the S3 inputs.

If you really want to cut costs, use a 1N4001 diode to drop the 3.3V to 
~ 2.6 volts for Vccaux.  Just be sure you have some reasonable value 
electolytic as bypass to ground on the Vccaux (like 100uF), along with 
the recommended bypass caps (0.01uf - 0.1uf).

The penalty of not having a perfect 2.50V voltage is that the LVDS 
outputs will have a few tens of millivolt higher common mode (basically, 
a don't care).

Austin

vax, 9000 wrote:
> Group,
>   Well, I need to choose between XC3S50 and EPM1270. Both have pros and
> cons. I list them below, and I'd like to ask you to point out other
> important issues, and which would you choose if you were me.
> 
>   My circuit occupies around 50% of XC3S50 or EPM1270. I might need several
> tens of the chips finally, But at this point I just need 1-3 for the
> prototype. I am aming at TQ144 package. It needs to interface 5V TTL logic.
> I plan to use 3.3V LVT244/245 to shift the voltage for inputs. I didn't
> check 5V/2.5V voltage shifters. My circuit is slow, working with 20MHz
> clock.
> 
> XC3S50 pros: 
> * Pin compatible SC3S200 available for possible growth
> * Cheap ($12+ for XC3S50, $15+ for XC3S200 at XILINX online store)
> * RAM on chip. Good if I want to add a small FIFO in the future
> cons:
> * Don't know where to buy XCF01S configuration flash. cost?
> * Needs both 2.5V and 3.3V power supply to interface 3.3V logic
> 
> EPM1270 pros:
> * On chip configuration flash
> * On chip user flash, if I want to store some bits in the future
> * Need only single 3.3V power supply to interface 3.3V logic
> cons:
> * expensive (EPM1270C5ES $25+ at digikey). May cost more for none-ES?
>   (for example, EPM1270C3 costs $73)
> * No TQ144 pin compatible bigger chips
> 
> cheers,
> vax, 9000
>   

Article: 81216
Subject: Re: Spartan 3 to tempsensor interface
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 19 Mar 2005 17:06:30 +0100
Links: << >>  << T >>  << A >>
Hi,

There is an LM70 (uWire / SPI) Temperature Sensor on our Tornado
board, and the VHDL code for the digital thermometer is free !

http://www.alse-fr.com/Tornado/Torn_Educ_us.pdf

We have also a reference design for the MaxII board with a different
temperature sensor (external transistor as sensor) : Max6627

This kind of interface is about 60 lines of (easy) code...
really simple.

I also wrote behavioral models for the Temperature sensors
so the design can be verified by simulation.

Best regards,

   Bert

rgebru wrote:

> Hi, 
> 
> I'm thinkin go of designing a heating/cooling system with VHDL and
> need to interface my Spartan 3 board to a real temp sensor. Does
> anyone have an idea of how I can do this? 
> 
> Thanks!!
> 


Article: 81217
Subject: Re: Stratix II vs Virtex 4
From: austin <austin@xilinx.com>
Date: Sat, 19 Mar 2005 08:10:35 -0800
Links: << >>  << T >>  << A >>
Keith,

The power story is a very good one, and we have the data to prove it.

When the chip is actually operating (only time you would care), the 
junction temoerature is bound to increase.

Then the static power different really stands out (>2X improvement, 
worst case, typically 4X better).

The dynamic interconnect power for the two is equal.

Our dynamic BRAM power is half that in S2.  That can be a few watts in a 
DSP design.

The DSP48 when arranged to use the internal dedicated cascading paths 
has 1/8th the power of the S2 solution.

Bottom line:  a high, end fast DSP design may disspate half the power in 
V4 over S2.  And the junction temperature will be at least 15 degress 
lower (for equivalent heatsinks) making heatsinking or airflow less 
costly as well.

That is why we are taking previously "won" sockets away from S2 for G4 
basestations.  Heat is the #1 enemy of all wired and wireless network 
equipment, because heat means energy, and energy means more batteries, 
and less holdover time, and more air conditioning costs in the central 
office, and more failures in the field.

We also have the SX25, SX35, and SX55 which are optimized for DSP 
applications, to provide a lower cost part to get the same amount of DSP 
resources.  There is NO COMPETITION AT ALL from Altera here:  it DOESN'T 
EVEN EXIST.

Austin



Article: 81218
Subject: FIR choice
From: Nemesis <nemesis@nowhere.invalid>
Date: Sat, 19 Mar 2005 16:20:45 GMT
Links: << >>  << T >>  << A >>
Hi all,
I'm implementing a Digital Down Converter for Virtex II pro device.

I think I'll not use the builtin DDC IP core because I'm using this
project to learn something about FPGAs and VHDL.

Essentially I have samples coming from an A/D at 64MHz. The signal is
bandpass, centered at 112 MHz and it can have to different bandwidth
5MHz and 25MHz.

I've already implemented in VHDL the I and Q components splitting, now I
have to filter these signals with low pass filter and decimate the
sequence. I'm going to use the "MAC FIR Filter" IP core (shipped with
Xilinx ISE).

I have some questions, I'm a newbie digital designer so please consider
this :-)

1) using a polyphase decimator is exactly the same of using a
single rate filter and then downsampling the output?

2) I need the same filter on both I and Q channels, so I think I could
set the core to use 2 channels, but I'm not sure how it works, is it
realized with time sharing? I'd need the two samples I(k) Q(k) at the
same time.

Thank you all, and 
-- 
I tried switching to gum but I couldn't keep it lit.
 
 |\ |       |HomePage   : http://nem01.altervista.org
 | \|emesis |XPN (my nr): http://xpn.altervista.org


Article: 81219
Subject: Re: One-hot statemachine design problems
From: Preben <64bitNOspamNO@mailme.dk>
Date: Sat, 19 Mar 2005 17:25:58 +0100
Links: << >>  << T >>  << A >>
info_ wrote:
> Hi,
> 
> I would make a few of suggestions :
> 
> * use an enumeration and traditional "case state is when =>"
>  construct. This facilitates a lot of things, if only for the
>  synthesis tool to properly recognize your FSM, but also for
>  HSL simulation, readability, reliability, optimization etc...

I thought the one-hot approach was quite better for performance issues?


> * to output the state vector, use a simple decoder (which
>  will be probably eliminated by synthesis). And maybe you don't
>  want the one-hot vector vector to come out, but an binary
>  (more compact) version ?

Well, you're just right about that, but for simulation purposes this 
works just fine!
I actually only need three bit-outputs!

> * Single-process style is easier to write (imo) and not prone
>  to the usual errors in combinational processes.
>  (you're not the first and not the last to get caught)
>   You can even write Moore style in one process if
>   you don't want to move your actions in the transitions.

Well, I tried doing this, but this gave me a lot of trouble so I took 
the "VHDL made easy" book and did the "cooking book"-version of a 
one-hot state machine design.


> On my Website, you'll find many FSM examples, FWIW
> http://www.alse-fr.com/English/ips.html

Thanks, i'll take a look!


> I never really liked the "textbook" two-processes style,
> and I've seen lots of problems in code written this way...

Maybe, Xilinx recommends this too, in their "templates".

Article: 81220
Subject: Re: One-hot statemachine design problems
From: "vax, 9000" <vax9000@gmail.com>
Date: Sat, 19 Mar 2005 11:29:38 -0500
Links: << >>  << T >>  << A >>
Preben Holm wrote:

> Hi everyone,
> 
> I try to construct this statemachine as described in VHDL below:
> (the machine is supposed to set the hold as soon as the trig-signal is
> asserted (initialized only when all signals have been low for a
> clock-cycle) and go low when both the read and holdoff signals have been
> asserted for some time...
> 

You made the typical mistake --- You didn't clock the inputs. Add one or
even two Flip-Flops to every input.

vax, 9000



Article: 81221
Subject: Re: Post-Trasnlation Simulation using ModelSim in XST
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 19 Mar 2005 17:40:34 +0100
Links: << >>  << T >>  << A >>
Hi,

Hard to say what's wrong without further info...

A few wild ideas :
* does the Technology View look fine ?
* does the post-layout model look fine ?
* when you load the design in the simulator, do you see all what you expect ?
* sdf file correctly attached and assigned ?
* simulation libraries okay ?
* How are you vector applied wrt to clock ?
* (async) Reset okay ?
* Timing resolution 1 ps ?
* Stimulus input timings realistic ?
* sure you didn't recompile your Vital models with ModelSim XE version ???
   (if that's what you're using)
* Try & simulate a trivial stuff (just a mult for example)
* "no warning no info" may not be a good sign (I'm joking here)

And after all, why are you so hot about post-layout simulation
if you're reasonably sure of the sanity of your design ?
If it's well-behaved, synchronous and all, and no scary synthesis
warnings, HDL simulation fine, static timing analysis okay, and
you're in a BIG hurry, then I would just keep things moving for now...

I hope it helps a tiny bit,

Best regards,

   Bert

morpheus wrote:
> Hi,
> I am trying to design a non-coherent DPSK demodulator as part of my RX
> chain of a DSP system in verilog. I have to target my design on a
> Vertex-4 development board (for prototyping purposes). Till now, I have
> designed my RX chain using two multiplier cores (I and Q multiplied
> with their delayed versions) and an adder core ((In)*(In-10) +
> (Qn)*(Qn-10)). When I simulate my design at the behavioural level
> everything's working fine. I synthesize my design, no warnings/ INFO/
> errors. But, when I do a post-translate simulation, my Q-channel
> multiplier stops working. Moreover, when I MAP my design and do a
> post-map simulation, the design does not work at all. I get no warnings
> or errors in any of the processes
> Can anyone help me. If someone decides to be gracious, I can send you
> my archived project to look at. I have had this problem in the past and
> couldnt solve it. It may be my test-bench (as it is very simple)...but
> i just can figure it out.
> Any help will be appreciated....i am on a schedule and would like to
> keep my job....Lrd have MERCY!!!
> Thanks
> MORPHEUS
> 


Article: 81222
Subject: Re: One-hot statemachine design problems
From: DerekSimmons@FrontierNet.net
Date: 19 Mar 2005 08:49:03 -0800
Links: << >>  << T >>  << A >>
What is this for? If you are a student and this is part of an
assignment I don't want to just give you the answer but that doesn't
mean I won't try to help you.

Are there any design requirements that need to be followed or met?

Style and presentation is very important with VHDL. WIth a programming
language like 'C' you can get away with creating compound and nested if
statements with different structures and with an optimizing compiler
end up with the same result.

Early when I was learning VHDL, I noticed that depending on how you
structure your code effects the circuit design. In VHDL the compiler
tries to implement designs it recognizes ie. state machines.

As, someone else pointed out, the way you went about implementing your
state machine isn't the expected way. Try implementng using case
structure instead of if control structure. Don't forget the differences
between case and if statements - if statements are evaluated sequential
and case states are evaluated parallel.

In VHDL as in C, if you have a large chunk of code and are having
trouble with it you should break it up into smaller chunks. Use block
and process structures to make your code smaller. It should make your
code easier to read and make the compilers job easier.

Derek


Article: 81223
Subject: Re: One-hot statemachine design problems
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 19 Mar 2005 19:07:08 +0100
Links: << >>  << T >>  << A >>
Preben wrote:
> info_ wrote:
> 
>> Hi,
>>
>> I would make a few of suggestions :
>>
>> * use an enumeration and traditional "case state is when =>"
>>  construct. This facilitates a lot of things, if only for the
>>  synthesis tool to properly recognize your FSM, but also for
>>  HSL simulation, readability, reliability, optimization etc...
> 
> 
> I thought the one-hot approach was quite better for performance issues?

Quite often it's the case, but using an enumeration does NOT mean
at all giving up one-hot encoding !!! Quite the contrary.

> 
> 
>> * to output the state vector, use a simple decoder (which
>>  will be probably eliminated by synthesis). And maybe you don't
>>  want the one-hot vector vector to come out, but an binary
>>  (more compact) version ?
> 
> 
> Well, you're just right about that, but for simulation purposes this 
> works just fine!
> I actually only need three bit-outputs!

For simulation, isn't it nicer to see "Writing" in the waveform
viewer rather than "00100" ?

> 
>> * Single-process style is easier to write (imo) and not prone
>>  to the usual errors in combinational processes.
>>  (you're not the first and not the last to get caught)
>>   You can even write Moore style in one process if
>>   you don't want to move your actions in the transitions.
> 
> 
> Well, I tried doing this, but this gave me a lot of trouble so I took 
> the "VHDL made easy" book and did the "cooking book"-version of a 
> one-hot state machine design.

Dave wrote this book a long long time ago, and it was real nice
at that time. Today, the synthesizers are very much smarter,
so it's better to adopt more modern coding styles which are
now well supported by all synthesis tools.

Single process FSM usually means resynchronized Mealy style
as I call it, meaning you have to move the state actions up in
the arriving transitions. (But there is way to code Moore
actions in a single process FSM). That's another way to
desoign, but it's often even easier than Moore style.
See my Quadrature decoder as an example.

> Maybe, Xilinx recommends this too, in their "templates".

I don't want to sound controversial  here, but I wouldn't trust
Xilinx as a model of well-written HDL code !

They still deliver this bad code with ISE 6.3.03i (despite my
fixing this bad code more than 3 years ago). It's irritating.

You will appreciate the inout (bidirectional buffer) for the LEDs,
the absence of resynchronization for the async inputs, the initialization
of signals, the absence of reset, the hard tabs in the source file, etc !
(and I won't comment the test bench)
Maybe I misread and it was an example of things NOT to do :-)

There are more experts than good code hanging around...


---------cut & paste from ISE 6.3.03i J2C_vhd Example ----------------------
library IEEE;
use IEEE.std_logic_1164.all;  -- defines std_logic types

entity jc2_top is
     port (
	  LEFT : in STD_LOGIC;   -- Active-low switch #3 (left)
	  RIGHT : in STD_LOGIC;  -- Active-low switch #0 (right)
	  STOP : in STD_LOGIC;   -- Active-low switch #2
      CLK : in STD_LOGIC;
      Q : inout STD_LOGIC_VECTOR (3 downto 0) := "0000"  -- Active-low LEDs
          );
end jc2_top;

architecture jc2_top_arch of jc2_top is
    signal DIR: STD_LOGIC := '0';	 -- Left=1, Right=0
    signal RUN: STD_LOGIC := '0';
begin

process (CLK)
begin
    if (CLK'event and CLK='1') then       -- CLK rising edge

    -- DIR register:
      if (RIGHT='0') then
         DIR <= '0';
      elsif (LEFT='0') then
         DIR <= '1';
      end if;

    -- RUN register:
      if (STOP='0') then
         RUN <= '0';
      elsif (LEFT='0' or RIGHT='0') then
         RUN <= '1';
      end if;

    -- Counter section:
      if (RUN='1') then
         if (DIR='1') then
            Q(3 downto 1) <= Q(2 downto 0);    -- Shift lower bits (Left Shift)
            Q(0) <= not Q(3);                  -- Circulate inverted MSB to LSB
         else
            Q(2 downto 0) <= Q(3 downto 1);    -- Shift upper bits (Right Shift)
            Q(3) <= not Q(0);                  -- Circulate inverted LSB to MSB
         end if;
      end if;

    end if;
end process;

end jc2_top_arch;
---------------------------------------


Article: 81224
Subject: Re: rocketio
From: austin <austin@xilinx.com>
Date: Sat, 19 Mar 2005 10:21:40 -0800
Links: << >>  << T >>  << A >>
Falk,

You could decide to scramble the data and not use 8B10B, but then you 
would have to be sure your scrambling never violated run length, or DC 
imbalance issues, and you could live with scrambling multiplying a 
single error into to more than one.

That way you could actually get 3.125 Gbs in V2 Pro, or 10 Gb/s in V2 
Pro-X, or 10 Gbs in V4.

Austin

Falk Brunner wrote:

> "news.verizon.net" <res0rsef@verizon.net> schrieb im Newsbeitrag
> news:DZK_d.4272$uw6.817@trnddc06...
> 
>>Hi,
>>I would like some help from roketio users to find what is the maximum
>>realizable freq we can get out of it. I hear that although it supports
> 
> upto
> 
>>3.125Ghz, you can only get only upto 2.5Ghz. Also, can I get any eval
> 
> board
> 
> 3.125 Gbit/s, not GHz. This is the line data rate. Effective data rate is
> only 2.5 Gbits/s due to line encoding using 8B/10B encoder (encodes 8 data
> bits into 10 data bits to guarantee a constant DC level and transition
> density) Virtex4 supports also 64B/66B encoding (which is much more
> effcient).
> 
> Regards
> Falk
> 
> 
> 



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