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 41700

Article: 41700
Subject: Re: hand placement
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 5 Apr 2002 08:24:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3cacff43@news.starhub.net.sg>,
Kelvin Xu Qijun <qijun@okigrp.com.sg> wrote:
>Nicholas, pls stop laugh since they have made it possible that you stay on
>your job for a while...
>I feel the laziness of CAD companies has saved many jobs in IC design
>area...:-)

Hehehehhe.  I'm an academic, so well, I find it entertaining, not a
guarentee of employment.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 41701
Subject: Re: Monostable multivibrator
From: "Phil Connor" <p.connorXXX@optionYYY.com>
Date: Fri, 5 Apr 2002 08:44:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
"JB" <jbonill1@optonline.net> wrote in message
news:E30r8.139983$u77.31687100@news02.optonline.net...

> I am new come in the FPGA business.
> 
> I guess that to implement a monostable multivibrator using a Xilinx FPGA
> should be pretty common.
> 
> Maybe somebody provide me with a hint or an example?
> 
> Thanks


Hi,

Yes, to my mind the most basic element of clocked logic but in FPGAs
you use a clock rather than an RC timer. Below is some code to play
with that illustrates this. (ignore the fact its called a UART which
it is not of course). The comments in the testbench give the best
clues as to whats going on.

I've run this code on modelsim.

Regards

Phil

-- *******************************************************************
-- Purpose: 	Top level 
-- *******************************************************************
library ieee;
use ieee.STD_LOGIC_1164.all;
use ieee.STD_LOGIC_ARITH.all;
use ieee.STD_LOGIC_MISC.all;
use ieee.STD_LOGIC_UNSIGNED.all;
 
 
entity uart is
  port (
        clock 		: in STD_LOGIC;								-- Master clock 
	write_en	: in std_logic;
        output 		: out STD_LOGIC								--
        );
end uart;
 

architecture behavior of uart is

signal we_delay1 : std_logic;
signal we_delay2 : std_logic;
signal we_delay3 : std_logic;
signal we_delay4 : std_logic;
signal we_delay5: std_logic;
begin
 
--what are we attempting here ? Well to delay a write enable pulse so it
frames the
--rising edge of a write clock pulse.

process(clock) begin
  if clock'event and clock='0' then
  		
    we_delay1 	<= write_en;	--set up a train of waveforms delayed by 1
clock
    we_delay2 	<= we_delay1;
    we_delay3 	<= we_delay2;
    we_delay4 	<= we_delay3;
    we_delay5 	<= we_delay4;

	--craft the output required
    output <= we_delay1 and not we_delay2; --	rising on delay1 and
falling on
	 
       -- other outputs can be crafted with other logic
															-- delay2
  end if;
end process;

end


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

-- *******************************************************************
-- Purpose: 	UART test bench to test code snippets 
-- *******************************************************************

library ieee;
use ieee.STD_LOGIC_1164.all;
use ieee.STD_LOGIC_ARITH.all;
use ieee.STD_LOGIC_MISC.all;
use ieee.STD_LOGIC_UNSIGNED.all;

 
entity testbench is
end ;
 
architecture behavior of testbench is

component uart
 	port (
        	clock	  : in STD_LOGIC;								-- Master clock 
		write_en  : in std_logic;
        	output 	  : out STD_LOGIC								--
            );
            
end component;

signal regionoftest 	: std_logic;  
signal clock	 	: STD_LOGIC;
signal write_en	        : std_logic;
signal output 		: STD_LOGIC;

signal i : INTEGER := 0;


begin
  --  Instantiate UART top level module
  uart_test: uart
    port map (
              	clock 	 => clock 	,
		write_en => write_en	,
              	output 	 => output	);
              
--  Generate Clock - 20 ns period
process
begin
		loop
      clock <= '1';    
 		wait for 10 ns ;
  		clock <= not(clock);
		wait for 10 ns ;
		end loop;
end process;
  
--  Main test program
process

----------------------------------------------------------------
--**************main test sequence******************************
begin

--initialise
	write_en <= '0';
	regionoftest <= '1';
	wait for 100 ns;
--wip

	--long write enable
	write_en <= '1';
	wait for 102 ns;
	write_en <= '0';
	--short write enable
	wait for 47 ns ;
	write_en <= '1';
	wait for 30 ns ;
	write_en <= '0';
	wait for 100 ns;
	--too short - less than clock period (glitch suppression) but still
catches a -ve edge.
	write_en <= '1';
	wait for 15 ns ;
	write_en <= '0';
	wait for 100 ns;
	--too short - less than clock high and not capturing an edge  
	write_en <= '1';
	wait for 5 ns ;
	write_en <= '0';
--too short - less than clock high but still capturing an edge so output
present
	wait for 108 ns;
	write_en <= '1';
	wait for 5 ns ;
	write_en <= '0';
	wait;
end process;

--**************end of main test sequence***********************
----------------------------------------------------------------

end;



xxxxxxxxxxxxxxxx end of message xxxxxxxxxxxxxxxxxxxxxxxxxxxx







-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 41702
Subject: Re: Schematic Stuff
From: "Phil Connor" <p.connorXXX@optionYYY.com>
Date: Fri, 5 Apr 2002 09:46:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
"Christopher Saunter" <Christopher.Saunter@durham.ac.uk> wrote in
message news:a8h9ff$qhq$1@sirius.dur.ac.uk...

> Greetigns All,
> 
> I have always found it more natural to work with schematics than an HDL
> (although learnign vhdl is proving very usefull in some areas...)
> 
> I have used the Aldec schematic capture program from Xilinx Foundation 3/4
> and ECS from Webpack.
> 
> Thus far, I am somewhat underwhelmed by these tools - I have always felt
> that a good tool (eg text editor, ide etc.) should allow you to work about 
> as fast as you can enter data, and this is just not the case with the
> schematic capture tools I have used.
> 
> So my question is:  Does anyone know of a powerfull, flexible schematic
> editor with decent (preferably configurable) key bindings, rock like
> stability, a nice user interface, highly intuitive, that is fast and a
> pleasure to use etc?
> 
> One that uses an HDL description of each schematic behind the scenes ECS
> style is probably a plus.
> 
> Or should I just be gratefull I'm not directly entering netlists... ;-)
> 
> Cheers,
> 	Chris Saunter


Hi Chris,

Like you when I started in HDL I thought that the ideal approach is
a top level schematic to show how the HDL interconnects. I stared
using the Xilinx tools but found them time consuming for a large
design. 

I ended up having top level VHDL and a pencil schematic because this 
was quickest and with a rubber the most flexible.

The consensus seems to be that the future lies in all HDL designs but
I find this uncomfortable having been brought up on a whole array of 
beautiful hardware block diagrams and schematics that make everything
visible at a glance. 

It does seem to be true that any EDA drawing tool becomes horrendously
complex even without linking it to logic functionality. Any knowledge
or skills will have limited portability into the future.

I am currently experimenting with working in VHDL as far as possible
and using something as simple as Microsoft Excel to draw block diagrams
of modules. Interconnects are not explicitly drawn but shown by
common labels. Modules can be expanded on separate sheets. There
is also a nice array of colours and shading that can make it all clear.
Cut and paste is easy, nearly every PCs can run excel and most people
can drive the package. Its a bit tedious to get exactly what you want
but like I say all EDA becomes tedious ( cue the deluge of "no it 
doesn't").

So far so good, but I may scrap it all tomorrow.

Good luck on your journey.

Regards

Phil






-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 41703
Subject: Re: hand placement
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 05 Apr 2002 11:15:20 GMT
Links: << >>  << T >>  << A >>
On Thu, 04 Apr 2002 20:15:11 -0600, Kevin Brace
<ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:

>(I already figured
>out how that secret PCILOGIC thing works, and I only now need to know
>how Bitgen's /Gclkdel option works to insert more delay on the global
>clock buffer . . . )
>
>   ....
>
>However, this "It's an FAE's tool" mentality seems to create a myth that
>only Xilinx or really experienced users can use it, and that myth seems
>to be similar to a PCILOGIC myth people talk about when a question comes
>up about  "The special IRDY and TRDY pin for PCI in Virtex."
>People always say only Xilinx knows how PCILOGIC works, but should I
>shatter the PCILOGIC myth for once and for all by posting a sample code,
>and some explanation on how to instantiate it and actually use it?
>

Before you hurt your self with too much patting yourself on the
back, you might want to look at this, from a year ago:

  http://www.fpga-faq.com/archives/30000.html#30017

and

  http://www.fpga-faq.com/archives/30000.html#30018


Not much of a secret really.  :-)  :-)  :-)

But /Gclkdel is a different story.

Maybe you should write an explanation for inclusion in the FAQ??





===================
Philip Freidin
philip@fliptronics.com
Host for WWW.FPGA-FAQ.COM

Article: 41704
Subject: Re: hand placement
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 05 Apr 2002 11:19:53 GMT
Links: << >>  << T >>  << A >>

For a tutorial (somewhat dated, but a reasonable intro) you
might want to look at:

   http://www.fliptronics.com/floorplanning1.html

and to see some really beautiful examples of floorplanning
you can see them at

   http://www.fliptronics.com/gallery.html

In particular, the designs MFILT, DVB_DEMOD, LINEAR, and
FORMATTER show what can be achieved.




Philip Freidin
Fliptronics

Article: 41705
Subject: Re: Schematic Stuff
From: newman5382@aol.com (newman)
Date: 5 Apr 2002 04:49:53 -0800
Links: << >>  << T >>  << A >>
> 2: How much learning does it mean to those engineers who is never willing to
> learn new stuff, for example
> those above 30 years old?
> 

Kelvin,

  Just remember, someday you will be above 30 years old, if you are lucky.

Newman

Article: 41706
Subject: Help: Design a crystal oscillator in a Xilinx XCR3256XL
From: thedimreaper@hotmail.com (Jack Nimble)
Date: 5 Apr 2002 04:53:19 -0800
Links: << >>  << T >>  << A >>
I am currently looking at two solutions to a frequency generation
problem.

Either I can use a PIC microprocessor or a CPLD (Xilinx XCR3256XL).

The PIC includes a crystal oscillator on chip. What I am wondering is,
can I use some gates from the CPLD to create an embedded crystal
oscillator rather than having to include an external design based
around a couple of inverters in a discrete logic chip.

Has anyone done this already?

I haven't been able to gather much from the Web or news groups so far.

Many thanks in advance

Jack

Article: 41707
Subject: DPLL
From: "Roberto Capobianco" <capobianco@igi.pd.cnr.it>
Date: Fri, 5 Apr 2002 15:32:28 +0200
Links: << >>  << T >>  << A >>
Hi,
How to build a digital PLL in VHDL to extract clock and data from an
incoming NRZI signal ?
Thanks.

--
Roberto Capobianco
Consorzio RFX - CNR di Padova
C.so Stati Uniti, 4
35127 - Camin (PD)
email: capobianco@igi.pd.cnr.it
web: www.igi.pd.cnr.it
tel.: +39-049-8295048
fax: +39-049-8700718



Article: 41708
Subject: Re: Design a crystal oscillator in a Xilinx XCR3256XL
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 5 Apr 2002 15:26:58 +0100
Links: << >>  << T >>  << A >>
Jack Nimble wrote

> Either I can use a PIC microprocessor or a CPLD (Xilinx XCR3256XL).
>
> The PIC includes a crystal oscillator on chip. What I am wondering is,
> can I use some gates from the CPLD to create an embedded crystal
> oscillator rather than having to include an external design based
> around a couple of inverters in a discrete logic chip.

Could become a FAQ.  Look in the archives for previous reponses.

Don't do it - you don't know enough about the PAL pin structures.
Only the device manufacturer has the key info to make a _reliable_
design.  $1.36 clock drivers can be bought from ICS, or use the
LT app note to cook up a design with a transistor.






Article: 41709
Subject: Re: DPLL
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 05 Apr 2002 15:33:03 GMT
Links: << >>  << T >>  << A >>
What is the bit time or frequency? Do you have a re-synchronizing start
bit? What is the max run length? What kind of timing source or
oscillator do you have available, and what is its stability?

Peter Alfke
================================
Roberto Capobianco wrote:

> Hi,
> How to build a digital PLL in VHDL to extract clock and data from an
> incoming NRZI signal ?
> Thanks.
>
> --
> Roberto Capobianco
> Consorzio RFX - CNR di Padova
> C.so Stati Uniti, 4
> 35127 - Camin (PD)
> email: capobianco@igi.pd.cnr.it
> web: www.igi.pd.cnr.it
> tel.: +39-049-8295048
> fax: +39-049-8700718


Article: 41710
Subject: Re: DPLL
From: "Roberto Capobianco" <capobianco@igi.pd.cnr.it>
Date: Fri, 5 Apr 2002 17:59:09 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> What is the bit time or frequency?
My bit time is 40ns

> Do you have a re-synchronizing start bit?
Yes. I want to use HDLC flag (01111110) to synchronize the receiver and NRZI
code with bit stuffing for data

>What is the max run length?
The max frame lenght is about 50 bits but transmission is burst like
(flag+data+pause+flag+data+pause.........)

>What kind of timing source or oscillator do you have available, and what is
its stability?
100 MHz oscillator


--
Roberto Capobianco
Consorzio RFX - CNR di Padova
C.so Stati Uniti, 4
35127 - Camin (PD)
email: capobianco@igi.pd.cnr.it
web: www.igi.pd.cnr.it
tel.: +39-049-8295048
fax: +39-049-8700718




Article: 41711
Subject: Parallel cable IV schematic available???
From: "Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de>
Date: Fri, 5 Apr 2002 17:59:40 +0200
Links: << >>  << T >>  << A >>
Hi !

Does somebody know what are the technical differences between the "Parallel
cable III" and the "Parallel cable IV"?
Technical means, are the pinouts at the DB25 connector changed?
Esp. i'm interested in lpt-pins 2, 3, 4, 5, 6 and 13.
Is there a schematic available for the Parallel cable IV ???
                                It's really, really IMPORTANT !!!

Thanks in advance.


Best regards,
Jens Frauenschlaeger


----------------------------------------------------------------------------
----------------------------
Jens Frauenschlaeger - conny@informatik.uni-leipzig.de
University of Leipzig
Germany



Article: 41712
Subject: Re: hand placement
From: Ken McElvain <ken@synplicity.com>
Date: Fri, 05 Apr 2002 16:47:35 GMT
Links: << >>  << T >>  << A >>
I think a more detailed description of what Amplify does is in order.

The logical hierarchy of a design can be easily reorganized into
a good physical hierarchy without touching the source code.  This
may not matter to some people who thought physically from the
beginning of their design and have the experience to know up front
what the organization should be.  Part of this reorganization
capability includes the ability to replicate chunks of RTL objects.
You may find that replicating an FSM or counter into different parts
of the chip yields large improvements.

Because the floorplan definition in Amplify is at an RTL level and we
worked very hard at making generated RTL object names repeatable even
with design changes, the RTL floorplan can survive design changes.
Gate level floorplans that don't stick to module boundaries often have
to be redone for even trivial design changes.  (If you are doing
structural netlisting in your HDL and generating placements, then that
would be an exception).  Amplify will also perform boundary optimization
on your floorplan which involve timing optimizations mixed with
placing results back into the regions.

The current version of Amplify (3.0) includes a full detail placer for
regions that works in cooperation with timing optimization of the logic.
This feature is currently only available for Virtex/VirtexE.  Detail
placement obviously gives Amplify much more accurate delay information.

An experienced Amplify user can get substantial performance improvements
in 3-5 iterations through P&R.  The first iteration gets you calibrated 
and the following iterations are like a game of whack a mole where the
mole doesn't come back up again.

Amplify obviously works best when the critical paths in your design are
through a chunks of RTL.  If you are willing to do a structural design
and hand place everything, then it won't be useful to you.  Most designs
aren't done that way.

Ken McElvain CTO
Synplicity, Inc.

Ray Andraka wrote:

> Frankly, I don't see the cost justified by the marginal added value with
> amplify.  You can do almost* everything it does with the area constraints in
> the floorplanner, plus with the floorplanner you can lock down some and area
> constrain other logic.
> 
> *The one thing it does buy you is to take into consideration the layout
> while doing the synthesis.
> 
> Like you mention, there was a time when we did floorplanning with graph
> paper.  The GUI makes it easier, but I still use the graph paper method for
> doing placement in the source.
> 
> 
> Phil Hays wrote:
> 
> 
>>Jimmy Zhang wrote:
>>
>>
>>>Just keep hearing about this hand placement thing, don't know how it
>>>is done in reality. Does someone actually use their hands to do the
>>>placement as opposed to CAD based P&R. Any hints?
>>>
>>The first way I learned to do this was with a paper diagram of the
>>target chip, writing the constraints with a text editor, and coloring on
>>the paper to indicate what had been put where.  I didn't do the best of
>>jobs (had an register reversed, with the msb where the lsb should be),
>>but it was still ~30% faster resulting clock speed than the automatic
>>placement.  Made place and route times drop nicely as well.  It was even
>>better than that once I got the twist removed.  But this is as close to
>>"by hand" as I can picture.
>>
>>The floorplanner that Xilinx provides is just a nicely automated way of
>>doing the same sort of puzzle.  Do the data path(s) first, fit things
>>together in a "logical" fashion, and for the first one floor plan at
>>least plan on spending some time fiddling.  Some people seem to get this
>>skill right away, and some take longer.
>>
>>A slightly "higher level" way of gaining much of the benefit from
>>floorplanning with potentially rather less effort is to use a "physical
>>design" tool.  Synplicity had the first ("Amplify") aimed at FPGA design
>>(and I'm not sure if Mentor, Synopsys or anyone else have anything in
>>this space yet), however there were physical design tools for ASIC
>>design long before Amplify.  These work by putting large chunks of the
>>design into subsections of the target chip.
>>
>>Synopsys's ASIC physical design tool set:
>>
>>http://www.synopsys.com/products/phy_syn/phy_syn.html
>>
>>Amplify is at:
>>
>>http://www.synplicity.com/products/amplify.html
>>
>>--
>>Phil Hays
>>
> 
> --
> --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
> 
> 
> 


Article: 41713
Subject: Re: hand placement
From: John_H <johnhandwork@mail.com>
Date: Fri, 05 Apr 2002 16:48:34 GMT
Links: << >>  << T >>  << A >>
Please, please...

Tell me what constructs I can manually edit into my edif file to produce
orderly layout!  If the synthesis tool isn't giving the P&R the info it needs
to get the job done, what can I possibly do to have the P&R do better than the
fumbling I get now?


Nicholas Weaver wrote:

> I actually assert that a lot of the problem is right in the synthesis,
> not in the P&R: There has been a lot of work which has been done on
> work which, given a datapath, constructs an orderly layout.  Yet none
> of this seems to have found its way into the commercial synthesis
> toolflows.  So much informtion is thrown away.


Article: 41714
Subject: Vertex 2 DCM problem
From: sajjadd@hotmail.com (sajjad)
Date: 5 Apr 2002 09:03:33 -0800
Links: << >>  << T >>  << A >>
I'm relatively new to V2 design, so this is probably very basic. 

Warning : CLKFX_DIVIDE =           2 is not 1 ... 32.
Warning : CLKFX_MULTIPLY =           4 is not 1 ... 32.
Warning : CLKFX_DIVIDE =           1 is not 1 ... 32.
Warning : CLKFX_MULTIPLY =           4 is not 1 ... 32.

any clues?

Article: 41715
Subject: Re: Vertex 2 DCM problem
From: Kamal <>
Date: Fri, 5 Apr 2002 09:28:48 -0800
Links: << >>  << T >>  << A >>
Hello Sajjad,

This is a known issue and the message can be ignored.
The issue will be resolved in Service Pack 2 of the 
ISE software, tentatively due in mid-April.

Regards,
Kamal

Article: 41716
Subject: Re: hand placement
From: John_H <johnhandwork@mail.com>
Date: Fri, 05 Apr 2002 18:03:11 GMT
Links: << >>  << T >>  << A >>
Let me start by saying thanks for providing the Synplify tool to the market.
Compile times are great and the results are reasonable though I still have my
troubles with every design.  I need to hand-tweak much less of the code than with
other tools I've used in the past.  Ken, you have my respect.


The replication of chunks of RTL is potentially helpful:  it save the manual
replication I regularly do by hand in my code for a good hour or two savings in a
large project.

Thank you for working "very hard at making generated RTL object names repeatable
even with design changes" since this is the biggest open sore of the tool that I
actually own.  I just wish it could benefit me.

(more below...)

Ken McElvain wrote:
<snip>

> An experienced Amplify user can get substantial performance improvements
> in 3-5 iterations through P&R.  The first iteration gets you calibrated
> and the following iterations are like a game of whack a mole where the
> mole doesn't come back up again.

I've suggested in the past that my 8 year old nephew could get just about as good
results using Amplify as an engineer with intimate knowledge of the design.  I
leave it to you to decide if this is praise for the ease of use of the product or
a criticism of the tool to take that "extra step" and decide on the area
optimizations itself.

I realize the Amplify tool has a market because of the inadequacies of the Xilinx
P&R tools but it also has a place because Synplify falls short of allowing us to
do the light work ourselves.


Article: 41717
Subject: Re: Parallel cable IV schematic available???
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 5 Apr 2002 20:52:18 +0200
Links: << >>  << T >>  << A >>
"Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de> schrieb im
Newsbeitrag news:a8khfq$o9s$1@news.uni-leipzig.de...

> Does somebody know what are the technical differences between the
"Parallel
> cable III" and the "Parallel cable IV"?
> Technical means, are the pinouts at the DB25 connector changed?
> Esp. i'm interested in lpt-pins 2, 3, 4, 5, 6 and 13.
> Is there a schematic available for the Parallel cable IV ???

I dont know. But since the parallel cable III is just a serial thing (JTAG
or Slave Serial Download), its rather slow.
I guess Parallel cable IV is a small CPLD (an  Altera one ;-) wich just
works as a parallel serial converter. The parallel port should run in EPP
mode, giving up to 2 Mbyte/s troughput. Serialized, this gives 16 Mbit/s.
Iam sure it could be build using a 32 macrocell CPLD.

>                                 It's really, really IMPORTANT !!!

Does the fate of earth depend on it?
;-)

> Jens Frauenschlaeger - conny@informatik.uni-leipzig.de
> University of Leipzig
> Germany

Hello to Leiptzsch von Dräääsden.

;-)

--
MfG
Falk





Article: 41718
Subject: Re: hand placement
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Fri, 05 Apr 2002 13:57:12 -0600
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
> 
> On Thu, 04 Apr 2002 20:15:11 -0600, Kevin Brace
> <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
> 
> 
> Before you hurt your self with too much patting yourself on the
> back, you might want to look at this, from a year ago:
> 

        Not a very nice comment.




>   http://www.fpga-faq.com/archives/30000.html#30017
> 
> and
> 
>   http://www.fpga-faq.com/archives/30000.html#30018
> 


        When I figured it out how to instantiate it from XST, I used the
information from the following website.

http://www.opencores.org/forums/pci/2001/09/00003


The problem was, the guy who did the analysis didn't post the code he
wrote, and it wasn't in Verilog. (I am a VHDL hater.)
Until I thought of cracking the PCILOGIC secret, I never used a blackbox
in my code (Now I use it. It is a very useful feature.), so I had to
learn that, and not having an initiator/target PCI IP core (It was a
target only one at that time.) to play around with at the time also
caused some problems when I experimented with it.




> Not much of a secret really.  :-)  :-)  :-)
> 


        Before reading that opencore.org conversation, I have already
done a Google Groups search of this newsgroup, but I didn't find any
useful information about PCILOGIC at that time.
Only after I figured out how the PCILOGIC works, I noticed that the
equation inside was indeed discussed at this newsgroup.
I didn't used to visit this newsgroup at the time it was discussed
either.
I find it surprising that Eric Crabill of Xilinx who supposedly works
with LogiCORE PCI at Xilinx publically admitting the equations inside.
Isn't that supposed to be a trade secret of Xilinx?
        PCILOGIC may not be a huge secret to you, but a question about
it seems to come up once every two months or so, and people who answer
it keeps saying that it is a secret feature only Xilinx knows.
Yes, if you ask a Xilinx employee about it, they won't tell you at all
saying that it is an undisclosed feature.
So, I will still call it a secret feature, but I already got it.
After I figured it out how it works, it turns out there is really no big
deal other than unregistered long signal paths (unregistered IRDY# and
TRDY#) leading to CE (Clock Enable) input of IOB output FFs will not
cause timing problems during P&R.
So, there is really not big deal, and I will like to shatter that myth
that it is some kind of a magic box.




> But /Gclkdel is a different story.
> 


        All the publically available Xilinx documents say, "Don't use it
unless you are instructed by Xilinx."
Trying to keep something secret, of course, makes me more interested in
knowing about it.
Supposedly, the customers of their 66MHz PCI IP core know how to use it
according to LogiCORE PCI implementation document, because they are
required to use it in order to meet Tsu < 3ns.
One concern I have with a /Gclkdel option is that it is added after a
static timing analysis is done, so the static timing analyzer's numbers
won't reflect the /Gclkdel option.





> Maybe you should write an explanation for inclusion in the FAQ??
> 
> ===================
> Philip Freidin
> philip@fliptronics.com
> Host for WWW.FPGA-FAQ.COM


        Yes, if it is possible, I will rather have a sample code, a
constraint file, and the analysis of how it works included in the FPGA
FAQ than simply being posted to this newsgroup because that way, people
can refer to the FAQ rather than having to search this newsgroup.
Where should I send all the information?



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41719
Subject: Re: hand placement
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Fri, 05 Apr 2002 14:21:50 -0600
Links: << >>  << T >>  << A >>
Thanks, Philip for the information.
Why not update the information to cover Virtex architecture FPGAs?
I believe I already know the basics of floorplanning in Virtex
architecture FPGAs because I had to floorplan my design to meet Tsu <
7ns requirement of 33MHz PCI a few months ago.
Although I no longer have to do so now because of design improvements I
made.
Several times in the past, I have "tried" to get my PCI IP core to meet
Tsu < 3ns in Spartan-II-6, and, of course, I had to manually floorplan
very timing critical unregistered control signal paths. (i.e.,
unregistered DEVSEL#, TRDY#, and STOP# to FRAME# and IRDY IOB FFs.)
I came within about 15% of meeting Tsu < 3ns after tying two global
clock buffers in series to artificially generate more setup time. (I
consider this an alternative to Bitgen's /Gclkdel option, but I am not
sure how reliable it is.)
Likely, Virtex-E-7 might make it if everything works out, but I haven't
tried that yet.
However, the problem I am having here is not with the Xilinx
Floorplanner, but with Quartus II 2.0 Web Edition's floorplanner, and do
you know any online resources about it?
I guess Altera users don't use floorplanner that much like some Xilinx
users do, but for things like PCI, I think it is very important.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Philip Freidin wrote:
> 
> For a tutorial (somewhat dated, but a reasonable intro) you
> might want to look at:
> 
>    http://www.fliptronics.com/floorplanning1.html
> 
> and to see some really beautiful examples of floorplanning
> you can see them at
> 
>    http://www.fliptronics.com/gallery.html
> 
> In particular, the designs MFILT, DVB_DEMOD, LINEAR, and
> FORMATTER show what can be achieved.
> 
> Philip Freidin
> Fliptronics

Article: 41720
Subject: Re: hand placement
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 05 Apr 2002 20:38:28 GMT
Links: << >>  << T >>  << A >>
On Fri, 05 Apr 2002 13:57:12 -0600, Kevin Brace
<ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
>Philip Freidin wrote:
>> 
>> On Thu, 04 Apr 2002 20:15:11 -0600, Kevin Brace
>> <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
>> 
>> Before you hurt your self with too much patting yourself on the
>> back, you might want to look at this, from a year ago:
>
>        Not a very nice comment.

Oh, come on! I know that other have written personal attacks
that were uncalled for, but this hardly counts. How much more
gentle could I have been?  The info is available, it's in the
archive, anyone can see it.

>> Not much of a secret really.  :-)  :-)  :-)
>
>        Before reading that opencore.org conversation, I have already
>done a Google Groups search of this newsgroup, but I didn't find any
>useful information about PCILOGIC at that time.
>Only after I figured out how the PCILOGIC works, I noticed that the
>equation inside was indeed discussed at this newsgroup.
>I didn't used to visit this newsgroup at the time it was discussed
>either.

Well, that doesn't make it a secret. Just an undocumented feature
of the chip. Others have reverse engineered its functionality and
published the info in this news group.

>I find it surprising that Eric Crabill of Xilinx who supposedly works
>with LogiCORE PCI at Xilinx publically admitting the equations inside.

Typical Xilinx person being helpfull.

>Isn't that supposed to be a trade secret of Xilinx?

Who supposes? Not much of a trade secret if it has been published.

Since Xilinx tools even output a simulation model for it for
post P&R simulation, there is no way it could be considered a
secret. Just poorly (i.e. not at all) documented.

>        PCILOGIC may not be a huge secret to you, but a question about
>it seems to come up once every two months or so, and people who answer
>it keeps saying that it is a secret feature only Xilinx knows.

Who said that ??? Show them too me !!! I'll give them the URL too.

>Yes, if you ask a Xilinx employee about it, they won't tell you at all
>saying that it is an undisclosed feature.

More likely, they just don't know. Xilinx probably has 2000 people, and
of them only 6 people (approx) know the details:

The Product Planner
The I.C. designer
The I.C. test engineer
The SW QA engineer
The SW engineer that created the simulation model
The engineer in the IP group that created the PCI cores.

If you talk to any of the other 1994 people, they will look at the
same info you have access to, and wont find an answer. Then they
might answer "It must be a secret".

Just like the secret that you can do higher quality designs with
schematics and hierarchial floorplanning. And timing based simulation
is unnecessary if you have done fully synchronous design and have 100%
coverage of timespecs with static timing analysis.

>So, I will still call it a secret feature, but I already got it.

Good enough.

>After I figured it out how it works, it turns out there is really no big
>deal other than unregistered long signal paths (unregistered IRDY# and
>TRDY#) leading to CE (Clock Enable) input of IOB output FFs will not
>cause timing problems during P&R.
>So, there is really not big deal, and I will like to shatter that myth
>that it is some kind of a magic box.
>

>> Maybe you should write an explanation for inclusion in the FAQ??
>> 
>> ===================
>> Philip Freidin
>> philip@fliptronics.com
>> Host for WWW.FPGA-FAQ.COM
>
>
>        Yes, if it is possible, I will rather have a sample code, a
>constraint file, and the analysis of how it works included in the FPGA
>FAQ than simply being posted to this newsgroup because that way, people
>can refer to the FAQ rather than having to search this newsgroup.

Sure it is possible.

>Where should I send all the information?

Go to http://www.fpga-faq.com/FAQ_Root.htm , and at the bottom of the
page, down load the template of a FAQ page. Then fill in the page the
way you would like it to be, and email it to philip@fpga-faq.com
If you need help doing this, let me know.

It will be published for all to see in the FAQ, and will not be a
secret anymore. You may want to look at some other FAQ pages, to get a
feel for the current style.

This is also an open invitation to everyone else to write some FAQ
pages. It is only as good as the sum of the contributions !!


Philip Freidin

Philip Freidin
Fliptronics

Article: 41721
Subject: Re: 32 bit accumulator/comparator PWM?
From: "clevin1234" <clevin1234@comcast.net>
Date: Fri, 05 Apr 2002 21:20:38 GMT
Links: << >>  << T >>  << A >>
Patrick,

   The following Verilog code should implement the design that you have
described below. I have targeted it to a QuickLogic QL3012 device in a -1
speed and it reports a 46 Mhz worst case speed. A -2 device should run over
50 Mhz.  If you would like a programmed sample of the device I could arrange
to have one shipped to you. The good thing about QuickLogic is they will
provide the devices pre-programmed, no need to but a $1000 programmer.

Chuck Levin



module pwm(data_in, clk, rst, we, sel, pwmout);
input [31:0] data_in;
input clk, rst, we, sel;
output pwmout;
reg [31:0] rega, regb, regc;
reg pwmout;


 always @(posedge clk or posedge rst)
   begin
     if(rst)
      begin
        rega <= 32'b0;
        regb <= 32'b0;
        regc <= 32'b0;
        pwmout <= 1'b0;
    end
  else
    begin
      regc <= rega + regc;
   if(we && !sel)
     rega <= data_in;
   if(we && sel)
     regb <= data_in;
   if( regc > regb)
     pwmout <= 1'b1;
   else
     pwmout <= 1'b0;
    end
    end
endmodule

"Patrick Robin" <circaeng@hotmail.com> wrote in message
news:3CADD0A8.9D605257@hotmail.com...
> Hi,
>
> I am new to this field. I am a senior software engineer with some
> college experience in basic digital design from 12 years ago.
>
> I also have experience programming AVR Atmel uC.
>
> I am contemplating moving one of my uC design to part hardware, part
> software to increase speed. It consists in a frequency and pulse width
> adjustable square wave generator.
>
> I would apreciate your opinion on how difficult and costly ($) would it
> be for someone like me to design a hardware (chip) with:
>
> -a 32 bit accumulator
> -a 32 bit comparator
> -one 32 bit register (A) to store the number to be added by the
> accumulator
> -one 32 bit register (B) to store the number to compare against the
> accumulator sum (C)
> -one digtal output =1 if C>B 0 otherwise or vice versa
>
> The accumulator should run at least at 25MHZ, preferably 50MHZ
>
> I could probably do this with individual components but I want to
> minimize part count. Please let me know of the best way to approach
> this. I don't want to invest in costly ($1000) programmators if
> possible.
>
> Of course if you already know of such a chip I would like to know also
> :)
>
> Thanks for your time.
>
> Patrick
>
>



Article: 41722
Subject: Re: hand placement
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Fri, 05 Apr 2002 13:48:54 -0800
Links: << >>  << T >>  << A >>

Hi,

Kevin Brace wrote:
> I find it surprising that Eric Crabill of Xilinx who supposedly works
> with LogiCORE PCI at Xilinx publically admitting the equations inside.
> Isn't that supposed to be a trade secret of Xilinx?

I don't supposedly work at Xilinx, I actually work at Xilinx, in the IP
Solutions Group, developing IP.  I am, in a tangential way, associated
with the PCI and PCI-X cores...

I wouldn't call it a trade secret.  You may find the general invention
patented and assigned to Xilinx, however.  The implementation in Virtex,
Spartan-II, Virtex-E, and Spartan-IIE is the same and intended to assist
implementation of PCI cores in these devices -- the logic implemented is
quite literally a tiny part of our core cast into silicon (and, in the
grand scheme of things, immaterial; the real advantage of this "feature"
is the dedicated routing associated with it).

This feature is, however, undocumented, unsupported, and not intended
for
general use.  It is supported in the context of the Xilinx PCI LogiCORE.
The feature was put in the silicon by the request of the PCI Development
team, for use by the PCI Development team.

If you use it in your own designs, that is fine.  However, if you run
into
problems/issues, you are on your own -- the feature is undocumented and
unsupported.  If you were to file a case with the Support Hotline, they
probably won't be able to help you directly.  Such a case would most
likely be forwarded to me, and I would write back, "This feature is
undocumented, unsupported, and not intended for general use.  Sorry."

> So, there is really not big deal, and I will like to shatter that myth
> that it is some kind of a magic box.

I prefer to think of it as a magic box.  In fact, the instance name of
it
in our core is "MAGICBOX".  Maybe that is where the notion came from...

Anyone who is really interested can determine the logic function using
the publically available tool set.  Likewise, if you are very curious
about the GCLKDEL option, you can experimentally determine what it does.

Eric

Article: 41723
Subject: Re: hand placement
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Fri, 05 Apr 2002 13:56:29 -0800
Links: << >>  << T >>  << A >>

Philip Freidin wrote:

> More likely, they just don't know. Xilinx probably has 2000
> people, and of them only 6 people (approx) know the details:
> 
> The Product Planner
> The I.C. designer
> The I.C. test engineer
> The SW QA engineer
> The SW engineer that created the simulation model
> The engineer in the IP group that created the PCI cores.

Even less, if by chance one person did, say, three or four
of those things...

You are all trying to steal my magic bag!
Eric

Article: 41724
Subject: Re: Help: Design a crystal oscillator in a Xilinx XCR3256XL
From: kayrock66@yahoo.com (Jay)
Date: 5 Apr 2002 14:16:49 -0800
Links: << >>  << T >>  << A >>
Ya, it should work no problem.  All you need is an inverting amplifier
(i.e. not gate in the CPLD) and a suitable feedback network (crystal
or resonator, and 2 caps) and you should be on your way.  The accuracy
of your time base will be effected by how well you tune it.

But as another poster said, canned oscillators are cheap and
plentiful, so you better be building this sucker in quantity to
justify reinventing this wheel.

Regards
news:<e0e065dd.0204050453.399de84@posting.google.com>...
> I am currently looking at two solutions to a frequency generation
> problem.
> 
> Either I can use a PIC microprocessor or a CPLD (Xilinx XCR3256XL).
> 
> The PIC includes a crystal oscillator on chip. What I am wondering is,
> can I use some gates from the CPLD to create an embedded crystal
> oscillator rather than having to include an external design based
> around a couple of inverters in a discrete logic chip.
> 
> Has anyone done this already?
> 
> I haven't been able to gather much from the Web or news groups so far.
> 
> Many thanks in advance
> 
> Jack



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